From exim@www1.ietf.org Mon Feb 2 11:42:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21970 for ; Mon, 2 Feb 2004 11:42: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 1Anh9A-0006SN-At for ipcdn-archive@odin.ietf.org; Mon, 02 Feb 2004 11:42:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Gg4mG024811 for ipcdn-archive@odin.ietf.org; Mon, 2 Feb 2004 11:42:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anh97-0006Rb-Hp; Mon, 02 Feb 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anh8s-0006Qh-W6 for ipcdn@optimus.ietf.org; Mon, 02 Feb 2004 11:41:47 -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 LAA21957 for ; Mon, 2 Feb 2004 11:41:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anh8r-0005oR-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 11:41:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anh82-0005jG-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 11:40:55 -0500 Received: from boreas.telenet-ops.be ([195.130.132.48]) by ietf-mx with esmtp (Exim 4.12) id 1Anh7S-0005cd-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 11:40:18 -0500 Received: from localhost (astra.telenet-ops.be [195.130.132.58]) by boreas.telenet-ops.be (Postfix) with SMTP id 0618337F19 for ; Mon, 2 Feb 2004 17:40:17 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by astra.telenet-ops.be (Postfix) with SMTP id C266837E87 for ; Mon, 2 Feb 2004 17:40:16 +0100 (MET) Received: (qmail 16514 invoked from network); 2 Feb 2004 16:39:37 -0000 Received: from localhost (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 2 Feb 2004 16:39:37 -0000 Received: from ([10.5.5.72]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 2 Feb 2004 17:39:37 +0100 (CET) From: "David De Reu" To: "IPCDN Mailing List" Date: Mon, 2 Feb 2004 17:39:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 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 Subject: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default values 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 Dear all, For a number of objects, the MIB does not specify default values. To my knowledge, it was the intention of the document to let the MTA vendor choose and implement reasonable default values in these cases. As proposed, I will try to suggest wording to add to the description text to make this more clear. - pktcSigDevStandardRingCadence "A default value MUST be provided, but it is left up to the implementation to choose a reasonable default." - pktcSigDevRingSplashCadence "A default value MUST be provided, but it is left up to the implementation to choose a reasonable default." - pktcSigDevToneTable "The MTA device MUST make sure that, after the provisioning cycle, the table is fully populated (i.e. for each possible index, an entry MUST be defined) using reasonable defaults for each row that was not defined by the provisioing information." - pktcSigDevRingCadenceTable Do we also need default values for each of the 128 possible entries in the pktcSigDevRingCadenceTable? I would also like to note that there are already a few default values foreseen in ETSI TS 101 909-4, as per Table B.1: Table B.1: Ring cadence default values cr(x)| t1-ring | t2-idle | t3-ring | t4-idle | t5-ring | t6-idle -----+---------+---------+---------+---------+---------+--------- 0 | 1000 | 4000 | 1000 | 4000 | 1000 | 4000 1 | 1000 | 500 | 1000 | 3500 | 1000 | 3500 2 | 500 | 500 | 500 | 500 | 1000 | 3000 3 | 500 | 500 | 1000 | 500 | 500 | 3000 4 | 1000 | 500 | 500 | 4000 | | 5 | | | | | | 6 | | | | | | 7 | | | | | | 8 | | | | | | ... | | | | | | 127 | | | | | | Maybe we can express this as: "The MTA device is allowed to provide appropriate default values for each of the ring cadences." Thanks, 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 From exim@www1.ietf.org Mon Feb 2 11:44:28 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22063 for ; Mon, 2 Feb 2004 11:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhB3-0006g2-3g for ipcdn-archive@odin.ietf.org; Mon, 02 Feb 2004 11:44:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Gi1pQ025643 for ipcdn-archive@odin.ietf.org; Mon, 2 Feb 2004 11:44:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhB2-0006fL-IF; Mon, 02 Feb 2004 11:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnhAp-0006eX-AR for ipcdn@optimus.ietf.org; Mon, 02 Feb 2004 11:43:47 -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 LAA22049 for ; Mon, 2 Feb 2004 11:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnhAo-00061U-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 11:43:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anh9t-0005vS-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 11:42:50 -0500 Received: from poros.telenet-ops.be ([195.130.132.44]) by ietf-mx with esmtp (Exim 4.12) id 1Anh9K-0005pe-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 11:42:15 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by poros.telenet-ops.be (Postfix) with SMTP id 8137238001E for ; Mon, 2 Feb 2004 17:42:14 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by poros.telenet-ops.be (Postfix) with SMTP id 5A2103800C2 for ; Mon, 2 Feb 2004 17:42:14 +0100 (MET) Received: (qmail 16594 invoked from network); 2 Feb 2004 16:41:35 -0000 Received: from localhost (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 2 Feb 2004 16:41:35 -0000 Received: from ([10.5.5.72]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 2 Feb 2004 17:41:34 +0100 (CET) From: "David De Reu" To: "IPCDN Mailing List" Date: Mon, 2 Feb 2004 17:41:19 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 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 Subject: [ipcdn] Signaling MIB - Draft 3 - Last Call - Clarification US/intl. requirements 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 Dear all, To clarify upon the mapping from NCS signal to MIB object, and upon the "US"/"international" objects, we suggest the following descriptions and references to be added (or something along those lines): - pktcSigDevRgCadence and pktcSigDevRsCadence DESCRIPTION "This object is used for non-ETSI systems only. ..." - pktcSigPulseSignalTable DESCRIPTION "... This table only needs to be supported when the MTA device implements the NCS E-package. The signals defined in this table are triggered by the corresponding signals defined in the E-package." REFERENCE "TS 101 909-4 Specification" - pktcSigDevRingCadenceTable For this object, I would also like to suggest different wording regarding the "LE SIGNAL message". Since the MTA does not directly communicate with a Local Exchange, the description might be changed as follows: DESCRIPTION "In V5.2, Cadence rings are defined by the telco governing body for each country. The MTA must be able to support various ranges of cadence patterns and cadence periods. The MTA will be able to support country specific provisioning of the cadence and idle period. There will be at most 3 on/off transitions per cadence period. Each cadence pattern will be assigned a unique value ranging from 1 to 128 (inclusive) corresponding to the value of x plus one, where x is the value sent in the cr(x) signal requested per the appropriate NCS message, and defined in the E-package. The MTA will derive the cadence periods from the ring cadence table entry as provisioned by the customer. Objects in this table do not persist across MTA reboots. This table only needs to be supported when the MTA device implements the NCS E-package." REFERENCE "TS 101 909-4 Specification" - pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence DESCRIPTION "This object is used for ETSI systems only. ..." - pktcSigDevToneTable The problem here is that some, but not all, tones will be specific to ETSI because the corresponding signal is (or will be) only defined in TS 101 909-4, and not in the PacketCable specifications. We may want to list these separately, e.g. "The following tones are used for ETSI systems only: alertingSignal(17), specialDial(18), specialInfo(19), release(20) and congestion(21). These tones are triggered by the corresponding NCS signals as defined in ETSI TS 101 909-4." Note for the editor: the final list may be different and/or have different OID's. A reference could also be added: REFERENCE "TS 101 909-4 Specification, PacketCable NCS specification" Thanks, 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 From exim@www1.ietf.org Mon Feb 2 16:07:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09865 for ; Mon, 2 Feb 2004 16:07: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 1AnlHc-0007Lk-6c for ipcdn-archive@odin.ietf.org; Mon, 02 Feb 2004 16:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12L73nW028222 for ipcdn-archive@odin.ietf.org; Mon, 2 Feb 2004 16:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlHZ-0007KR-Hx; Mon, 02 Feb 2004 16:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnlGc-0007Ih-27 for ipcdn@optimus.ietf.org; Mon, 02 Feb 2004 16:06:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09592; Mon, 2 Feb 2004 16:05:58 -0500 (EST) Message-Id: <200402022105.QAA09592@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: Mon, 02 Feb 2004 16:05:58 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-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 : Multimedia Terminal Adapter (MTA) Management Information Base for PacketCable and IPCablecom compliant devices Author(s) : E. Nechamkin, J. Mule Filename : draft-ietf-ipcdn-pktc-mtamib-03.txt Pages : 49 Date : 2004-2-2 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of PacketCable and IPCablecom compliant Multimedia Terminal Adapter devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-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-mtamib-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-mtamib-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-2-2150917.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-mtamib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150917.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Feb 2 19:21:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26516 for ; Mon, 2 Feb 2004 19:21: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 1AnoJM-0006S6-6V for ipcdn-archive@odin.ietf.org; Mon, 02 Feb 2004 19:21:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i130L401024779 for ipcdn-archive@odin.ietf.org; Mon, 2 Feb 2004 19:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoJJ-0006RH-EI; Mon, 02 Feb 2004 19:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoIQ-0006Kt-BM for ipcdn@optimus.ietf.org; Mon, 02 Feb 2004 19:20:06 -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 TAA26345 for ; Mon, 2 Feb 2004 19:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnoIO-0004Y0-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 19:20:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnoHQ-0004LW-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 19:19:04 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AnoGT-00047x-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 19:18:05 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i130Hv5w018399 for ; Mon, 2 Feb 2004 17:17:57 -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 i130Ht9x017174 for ; Mon, 2 Feb 2004 18:17:56 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 2 Feb 2004 16:17:55 -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, 2 Feb 2004 16:17:54 -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,LINES_OF_YELLING 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 following summarizes the proposed changes to pktcSigDevCodecTable based on the suggestion(s) from David and Eugene: DELETE THE FOLLOWING: -- -- The codec table (pktcSigDevCodecTable) defines all combinations -- of codecs supported by the Multimedia Terminal Adapter (MTA). -- For example, an MTA may support the following codecs and maximum -- number of connections for each codec: -- -- Codec Type Maximum Number of Connections -- pcmu 2 -- g728 1 -- -- or -- -- pcmu 1 -- g728 1 -- g729E 1 -- -- Based on this example, the entries in the codec table would be: -- -- pktcSigDevCodecComboIndex pktcSigDevCodecType pktcSigDevCodecMax -- 1 pcmu 2 -- 1 g728 1 -- 2 pcmu 1 -- 2 g728 1 -- 2 g729E 1 -- ADD THE FOLLOWING: -- -- The codec table (pktcSigDevCodecTable) defines all possible -- combinations of codecs supported for simultaneous operation by the -- Multimedia Terminal Adapter (MTA). -- -- For example, an MTA with two endpoints may be designed with a -- particular DSP and memory architecture that allows it to support -- the following fixed combinations of codecs for simultaneous -- operation: -- -- Codec Type Maximum Number of Simultaneous Codec Instantiations -- -- PCMA 3 -- -- PCMA 2 -- PCMU 1 -- -- PCMA 1 -- PCMU 2 -- -- PCMU 3 -- -- PCMA 1 -- G729 1 -- -- G729 2 -- -- 1 PCMU 1 -- 1 G729 1 -- -- Based on this example, the entries in the codec table would be: -- -- pktcSigDevCodecComboIndex pktcSigDevCodecType pktcSigDevCodecMax -- -- 1 pcma 3 -- 2 pcma 2 -- 2 pcmu 1 -- 3 pcma 1 -- 3 pcmu 2 -- 4 pcmu 3 -- 5 pcma 1 -- 5 g729 1 -- 6 g729 2 -- 7 pcmu 1 -- 7 g729 1 REPLACE THE pktcSigDevCodecTable DESCRIPTION WITH THE FOLLOWING: pktcSigDevCodecTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcSigDevCodecEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " This table describes the MTA supported codec types. An MTA MUST populate this table with all possible combinations of codecs it supports for simultaneous operation. An operator querying this table is able to determine all possible codec combinations the MTA is capable of simultaneously supporting." ::= { pktcSigDevConfigObjects 1 } 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 Feb 3 07:56: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 HAA07328 for ; Tue, 3 Feb 2004 07:56: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 1Ao05y-0001ZY-T0 for ipcdn-archive@odin.ietf.org; Tue, 03 Feb 2004 07:56:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Cu2CV006026 for ipcdn-archive@odin.ietf.org; Tue, 3 Feb 2004 07:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao05y-0001Yx-40; Tue, 03 Feb 2004 07:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao05M-0001XY-Qc for ipcdn@optimus.ietf.org; Tue, 03 Feb 2004 07:55:25 -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 HAA07318 for ; Tue, 3 Feb 2004 07:55:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao05M-0005Q1-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 07:55:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao04W-0005K0-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 07:54:33 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ao03V-00055W-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 07:53:29 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i13CqYZ08043 for ; Tue, 3 Feb 2004 06:52:38 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 3 Feb 2004 13:52:33 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155028EC4E5@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Beacham Gordon-CGB005'" , "'ipcdn@ietf.org'" Subject: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Call fo r Comments Date: Tue, 3 Feb 2004 13:52:33 +0100 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: , In general, instead of having extensive ASN.1 comment lines, I prefer to see the extra information in DESCRIPTION clauses. That is hwere it belongs (I think). Thanks, Bert > -----Original Message----- > From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] > Sent: dinsdag 3 februari 2004 1:18 > To: 'ipcdn@ietf.org' > Subject: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - > Last Call > fo r Comments > > > The following summarizes the proposed changes to > pktcSigDevCodecTable based on the suggestion(s) from David and Eugene: > > DELETE THE FOLLOWING: > > -- > -- The codec table (pktcSigDevCodecTable) defines all > combinations > -- of codecs supported by the Multimedia Terminal > Adapter (MTA). > -- For example, an MTA may support the following codecs > and maximum > -- number of connections for each codec: > -- > -- Codec Type Maximum Number of Connections > -- pcmu 2 > -- g728 1 > -- > -- or > -- > -- pcmu 1 > -- g728 1 > -- g729E 1 > -- > -- Based on this example, the entries in the codec > table would be: > -- > -- pktcSigDevCodecComboIndex pktcSigDevCodecType > pktcSigDevCodecMax > -- 1 pcmu 2 > -- 1 g728 1 > -- 2 pcmu 1 > -- 2 g728 1 > -- 2 g729E 1 > -- > > ADD THE FOLLOWING: > > -- > -- The codec table (pktcSigDevCodecTable) defines all possible > -- combinations of codecs supported for simultaneous > operation by the > -- Multimedia Terminal Adapter (MTA). > -- > -- For example, an MTA with two endpoints may be designed with a > -- particular DSP and memory architecture that allows > it to support > -- the following fixed combinations of codecs for simultaneous > -- operation: > -- > -- Codec Type Maximum Number of Simultaneous Codec > Instantiations > -- > -- PCMA 3 > -- > -- PCMA 2 > -- PCMU 1 > -- > -- PCMA 1 > -- PCMU 2 > -- > -- PCMU 3 > -- > -- PCMA 1 > -- G729 1 > -- > -- G729 2 > -- > -- 1 PCMU 1 > -- 1 G729 1 > -- > -- Based on this example, the entries in the codec > table would be: > -- > -- pktcSigDevCodecComboIndex pktcSigDevCodecType > pktcSigDevCodecMax > -- > -- 1 pcma 3 > -- 2 pcma 2 > -- 2 pcmu 1 > -- 3 pcma 1 > -- 3 pcmu 2 > -- 4 pcmu 3 > -- 5 pcma 1 > -- 5 g729 1 > -- 6 g729 2 > -- 7 pcmu 1 > -- 7 g729 1 > > REPLACE THE pktcSigDevCodecTable DESCRIPTION WITH THE FOLLOWING: > > pktcSigDevCodecTable OBJECT-TYPE > SYNTAX SEQUENCE OF PktcSigDevCodecEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > " This table describes the MTA supported codec > types. An MTA > MUST populate this table with all possible > combinations of > codecs it supports for simultaneous > operation. An operator > querying this table is able to determine all possible > codec combinations the MTA is capable of > simultaneously > supporting." > ::= { pktcSigDevConfigObjects 1 } > > > 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 Feb 3 14: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 OAA26704 for ; Tue, 3 Feb 2004 14: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 1Ao6Rp-0007Ys-WA for ipcdn-archive@odin.ietf.org; Tue, 03 Feb 2004 14:43:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Jh1lQ029062 for ipcdn-archive@odin.ietf.org; Tue, 3 Feb 2004 14:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6Rp-0007YR-AN; Tue, 03 Feb 2004 14:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6RT-0007X9-9V for ipcdn@optimus.ietf.org; Tue, 03 Feb 2004 14:42:39 -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 OAA26623 for ; Tue, 3 Feb 2004 14:42:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6RQ-0003OQ-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 14:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6QX-0003HW-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 14:41:42 -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 1Ao6Pn-000345-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 14:40:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Feb 2004 11:47: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.9/8.12.6) with ESMTP id i13JeI5j027544; Tue, 3 Feb 2004 11:40:18 -0800 (PST) Received: from milu-w2k01.cisco.com (georgel-w2k1-8.cisco.com [171.71.50.232]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQO50138; Tue, 3 Feb 2004 11:40:16 -0800 (PST) Message-Id: <4.3.2.7.2.20040203113347.01d7ebe8@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Feb 2004 11:40:15 -0800 To: Donati Andrew-MGIA0477 , "'Jean-Francois Mule'" From: Minnie Lu Subject: RE: [ipcdn] clarification text for docsIfCmtsModulationTable re: row persistency Cc: "'Wijnen, Bert (Bert)'" , milu@cisco.com, Murwin William-LWM008 , ipcdn@ietf.org In-Reply-To: <62173B970AE0A044AED8723C3BCF2381028EB4A2@ma19exm01.e6.bcs. mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed 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=none 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 Hi, Jean and Andy, It seems to me that there are two things we need to address and add the=20 text in the description. 1. Pre-defined modulation profiles MAY read-only. Andy's proposal as below= =20 looks good to me. "In some implementations, pre-defined rows created at system initialization= =20 time may not be deleted". 2. Rows persistence. Jean's proposal as below looks good to me. "Entries with a status column (docsIfCmtsModControl) of value 'active' MUST be persist across reboots. Entries with a status column (docsIfCmtsModControl) of value 'notReady' and 'notInService' may not persist after reboots since those entries were explicit made not be available for use by the managed device ('notInService') or the agent had not sufficient info anyway ('notReady')." Thanks a lot ! Minnie At 09:14 AM 1/29/2004 -0500, Donati Andrew-MGIA0477 wrote: >All, > >Basically, the initial concern is to cover the cases where the default=20 >rows created at system initialization cannot be deleted. We need to find= =20 >some way to legally allow vendors to implement these default rows as "read= =20 >only" (rows cannot be changed or deleted) or "permanent" (rows can be=20 >changed but not deleted). > >Either one of the following options are possible: > >1. Add the following sentence to the DESCRIPTION clause for=20 >docsIfCmtsModControl: > >"In some implementations, pre-defined rows created at system=20 >initialization time may >not be deleted" > > >2. Implement the StorageType object in the table. > > >Thanks, >Andy > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, January 29, 2004 4:50 AM >To: 'Jean-Francois Mule'; Donati Andrew-MGIA0477; milu@cisco.com >Cc: ipcdn@ietf.org >Subject: RE: [ipcdn] clarification text for docsIfCmtsModulationTable re:= =20 >row persistency > > >Mmmm... when I see this discussion, then it seems to me that using=20 >StorageType object is the better choice and makes it possible for vendors= =20 >to show "may not be deleted" by making them permanent for example. > >Also... the issue of when a row gets deleted that is in >notInService or notReady state, that is described in >RFC2579 in the RowStatus TC DESCRIPTION clause. > >Thanks, >Bert > > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: donderdag 29 januari 2004 1:52 > > To: Donati Andrew-MGIA0477; milu@cisco.com > > Cc: ipcdn@ietf.org > > Subject: [ipcdn] clarification text for docsIfCmtsModulationTable re: > > row persistency > > > > > > Andy wrote: > > > The proposed additional sentence for docsIfCmtsModControl > > > should be more explicit. > > > > > > Instead of, "In some implementations, rows created at run > > > time may not be deleted", state "In some implementations, > > > pre-defined rows created at system initialization time may > > > not be deleted" > > Based on a chat with Eduardo, I do understand a little better > > that the persistence of those rows may depend on the product > > implementation. However, I'm curious what this > > implementation-dependent behavior means to operators & sys admins? > > I am a bit concerned that adding such vague statements don't > > help any of us in the end (they don't help sysadmins because > > one cannot assume much and they don't help new implementors > > because they don't give much guidance). > > See below. > > > > Minnie wrote: > > > I would like to propose that only the those entries with > > > active value in > > > docsIfCmtsModControl object MUST be saved after the managed > > > device restarts. > > I like this proposal better because it states what the > > behavior should be for *all* implementations on a subset of > > entries ('active' rows only, right?). Are they any concerns > > with this approach? > > > > Minnie wrote: > > > For those notInService entries, it is vendor specific > > > implementation to save them or not. > > What about 'notReady'? To me 'notReady' and 'notInService' > > should fall in the same bucket. > > > > Minnie wrote: > > > Those entries which rowStatus is notInService might not have > > > all consistent > > > attributes and they are not ready to be used (that is why the > > > rowstatus is > > > notInService). I don't think there is a need to save those > > > notInService > > > rows. But some vendor might want to save them, so I propose > > > to leave it to > > > vendor's choice. > > I personally think it is acceptable to not mandate the > > persistency of data for 'notReady' and 'notInService' and > > that we can justify it as you proposed. It may also convey > > Andy's comment about implementation specific behaviors - but > > it constraints those to a subset of rows for which nothing > > was certain from a mgmt station point of view. > > > > How about the following text: > > Entries with a status column (docsIfCmtsModControl) of value > > 'active' MUST be persist across reboots. Entries with a > > status column (docsIfCmtsModControl) of value 'notReady' and > > 'notInService' may not persist after reboots since those > > entries were explicit made not be available for use by the > > managed device ('notInService') or the agent had not > > sufficient info anyway ('notReady'). > > > > Comments? > > Jean-Fran=E7ois > > > > _______________________________________________ > > 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 Feb 3 15:50: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 PAA00457 for ; Tue, 3 Feb 2004 15:50: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 1Ao7Ug-00007G-Em for ipcdn-archive@odin.ietf.org; Tue, 03 Feb 2004 15:50:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Ko1be000414 for ipcdn-archive@odin.ietf.org; Tue, 3 Feb 2004 15:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Ue-00006M-R1; Tue, 03 Feb 2004 15:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao7Tz-0008WT-9d for ipcdn@optimus.ietf.org; Tue, 03 Feb 2004 15:49:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00352; Tue, 3 Feb 2004 15:49:16 -0500 (EST) Message-Id: <200402032049.PAA00352@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, 03 Feb 2004 15:49:16 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docsisevent-mib-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 : Event Notification Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems Author(s) : A. Ahmad Filename : draft-ietf-ipcdn-docsisevent-mib-03.txt Pages : 30 Date : 2004-2-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based event notification management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Cable Device MIB, RFC 2669 [5]. This memo specifies a MIB module in a manner that is compliant to the SMIv2. The set of objects is 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-docsisevent-mib-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-docsisevent-mib-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-docsisevent-mib-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-2-3150055.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docsisevent-mib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docsisevent-mib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-3150055.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 Feb 3 19:28: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 TAA14516 for ; Tue, 3 Feb 2004 19:28: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 1AoAtg-0004k0-VL for ipcdn-archive@odin.ietf.org; Tue, 03 Feb 2004 19:28:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i140S48L018201 for ipcdn-archive@odin.ietf.org; Tue, 3 Feb 2004 19:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAtd-0004jL-2U; Tue, 03 Feb 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAtN-0004iW-2Y for ipcdn@optimus.ietf.org; Tue, 03 Feb 2004 19:27:45 -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 TAA14505 for ; Tue, 3 Feb 2004 19:27:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAtL-0005DR-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:27:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAsR-00058R-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:26:47 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AoAru-00053L-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:26:15 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i140QFpg007148 for ; Tue, 3 Feb 2004 17:26:15 -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 i140QCSC018886 for ; Tue, 3 Feb 2004 18:26:12 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 3 Feb 2004 16:26:11 -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 (pktcSigPulseSignalDbLevel range) Date: Tue, 3 Feb 2004 16:26:10 -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 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: , Yes, agree that a more reasonable range should be considered for the pktcSigPulseSignalDbLevel object. In looking at the meter pulse range for this object, the max value specified in 300 001 is for Sweden (-30 dBm). Motorola recommends setting the range of this object to (-350..0) to accommodate Sweden and to allow some margin for other international countries. This range is specified at the analog POTs interface (i.e., the a-b terminals). > Independent of this, it might worth noting that the current range of the "pktcSigPulseSignalDbLevel" MIB Object (-250..152) is very large considering only one of the modes (meterPulse) uses it and the country specifications do not require it to be so high. We would recommend reducing this to a more reasonable range of (-250..0). 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 Feb 3 19:33: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 TAA14643 for ; Tue, 3 Feb 2004 19:33: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 1AoAyS-00051U-Pj for ipcdn-archive@odin.ietf.org; Tue, 03 Feb 2004 19:33:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i140X0Dl019285 for ipcdn-archive@odin.ietf.org; Tue, 3 Feb 2004 19:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAyS-00050w-EC; Tue, 03 Feb 2004 19:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoAyD-00050I-TZ for ipcdn@optimus.ietf.org; Tue, 03 Feb 2004 19:32:45 -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 TAA14626 for ; Tue, 3 Feb 2004 19:32:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoAyC-0005j5-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:32:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoAxM-0005dP-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:31:53 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AoAwY-0005XR-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:31:02 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i140V1pg010954 for ; Tue, 3 Feb 2004 17:31:02 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i140O9Ii014512 for ; Tue, 3 Feb 2004 18:24:09 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 3 Feb 2004 16:24:41 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: [ipcdn] Signaling MIB - Draft 3 - Last Call - Clarification US/in tl. requirements Date: Tue, 3 Feb 2004 16:24:39 -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 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 am concerned about many of the proposed clarifications. I previously commented: "Remember, in the international market there is a hybrid need. For example, some operators use the L package and require E package extensions." Clearly, there are situations where an operator uses L package AND E package features. Making references to ETSI only or NA only in the object descriptions is not accurate, and I think misleading. It is important to allow operators the flexibility to use the objects from the MIB they deem necessary for their operations. As an alternative, I would propose adding comments to the introductory section of the MIB to make it clear that the term L package refers to the core functionality (as defined by CableLabs/PacketCable) and the term E package refers to extensions over and above the core package (defined in support of international requirements). Further, all references to ETSI and NA in the MIB object descriptions could then be eliminated in a subsequent draft of the MIB, and replaced with L or E package comments as appropriate. 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 Feb 3 19:40: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 TAA14848 for ; Tue, 3 Feb 2004 19:40: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 1AoB5G-0005dP-Fe for ipcdn-archive@odin.ietf.org; Tue, 03 Feb 2004 19:40:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i140e2AT021627 for ipcdn-archive@odin.ietf.org; Tue, 3 Feb 2004 19:40:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoB5F-0005cb-4x; Tue, 03 Feb 2004 19:40:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoB55-0005by-K5 for ipcdn@optimus.ietf.org; Tue, 03 Feb 2004 19:39: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 TAA14834 for ; Tue, 3 Feb 2004 19:39:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoB53-0006V4-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:39:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoB4C-0006Op-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:38:57 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AoB3Q-0006IL-00 for ipcdn@ietf.org; Tue, 03 Feb 2004 19:38:08 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i140c8pg016959 for ; Tue, 3 Feb 2004 17:38:08 -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 i140PQUY017528 for ; Tue, 3 Feb 2004 18:25:26 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 3 Feb 2004 16:25:31 -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 (pktcSigDevToneDbLevel syntax & range) Date: Tue, 3 Feb 2004 16:25:30 -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 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: , Yes agreed. The SYNTAX for pktcSigDevToneDbLevel has been changed to "TenthdBm". Also, after further review, Motorola recommends the range of this object be changed to (-250..30). Per EN 300 001 the largest signal level for voice band tones is 0 dBm. Considering G.711 PCM coding allows amplitudes slightly above + 3 dBm, it would appear that the voice band tone maximum specification could be set to +3 dBm and meet the intent of the ETSI specification. This range (-250..30) is specified at the analog POTs interface (i.e., the a-b terminals). >> Also, is it intentional that the SYNTAX of the >> pktcSigPulseSignalDbLevel object is TenthdBm, and that it is >> Integer32 for pktcSigDevToneDbLevel? >We agree. By using "TenthdBm" SYNTAX in all "dB" related MIB objects we would make the SIG MIB more consistent 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 Feb 4 20:32: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 UAA12475 for ; Wed, 4 Feb 2004 20:32: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 1AoYN9-0006SU-47 for ipcdn-archive@odin.ietf.org; Wed, 04 Feb 2004 20:32:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i151W3ot024802 for ipcdn-archive@odin.ietf.org; Wed, 4 Feb 2004 20:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYN6-0006Rn-Iz; Wed, 04 Feb 2004 20:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYMi-0006RC-BB for ipcdn@optimus.ietf.org; Wed, 04 Feb 2004 20:31:36 -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 UAA12466 for ; Wed, 4 Feb 2004 20:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoYMg-0003q6-00 for ipcdn@ietf.org; Wed, 04 Feb 2004 20:31:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYLj-0003kz-00 for ipcdn@ietf.org; Wed, 04 Feb 2004 20:30:35 -0500 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1AoYLE-0003gF-00 for ipcdn@ietf.org; Wed, 04 Feb 2004 20:30:05 -0500 Received: from h-68-164-156-184.snvacaid.dynamic.covad.net ([68.164.156.184] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1AoYLE-0004se-00 for ipcdn@ietf.org; Wed, 04 Feb 2004 17:30:05 -0800 Message-ID: <007b01c3eb87$bac39cc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "IPCDN Mailing List" References: Subject: Re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default values Date: Wed, 4 Feb 2004 17:31:07 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 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.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: , Hi - > From: "David De Reu" > To: "IPCDN Mailing List" > Sent: Monday, February 02, 2004 8:39 AM > Subject: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default values ... > For a number of objects, the MIB does not specify default values. To my > knowledge, it was the intention of the document to let the MTA vendor > choose and implement reasonable default values in these cases. As > proposed, I will try to suggest wording to add to the description text > to make this more clear. ... But this is exactly what DEFVAL means. RFC 2578 clause 7.9 says: The DEFVAL clause, which need not be present, defines an acceptable default value which may be used at the discretion of an agent when an object instance is created. That is, the value is a "hint" to implementors. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Feb 5 04:02:35 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 EAA07900 for ; Thu, 5 Feb 2004 04:02:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofOf-0003z6-Q9 for ipcdn-archive@odin.ietf.org; Thu, 05 Feb 2004 04:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15924tq015295 for ipcdn-archive@odin.ietf.org; Thu, 5 Feb 2004 04:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofOa-0003yD-VE; Thu, 05 Feb 2004 04:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AofOO-0003xV-TR for ipcdn@optimus.ietf.org; Thu, 05 Feb 2004 04:01:48 -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 EAA07891 for ; Thu, 5 Feb 2004 04:01:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AofOM-0005br-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 04:01:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AofNT-0005XD-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 04:00:52 -0500 Received: from elpis.telenet-ops.be ([195.130.132.40]) by ietf-mx with esmtp (Exim 4.12) id 1AofN3-0005S4-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 04:00:25 -0500 Received: from localhost (adicia.telenet-ops.be [195.130.132.56]) by elpis.telenet-ops.be (Postfix) with SMTP id A377037F56 for ; Thu, 5 Feb 2004 10:00:20 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by adicia.telenet-ops.be (Postfix) with SMTP id 737FD1F70AB for ; Thu, 5 Feb 2004 10:00:20 +0100 (MET) Received: (qmail 955 invoked from network); 5 Feb 2004 08:59:36 -0000 Received: from localhost (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 5 Feb 2004 08:59:36 -0000 Received: from ([10.5.5.72]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Thu, 5 Feb 2004 09:59:36 +0100 (CET) From: "David De Reu" To: , "Beacham Gordon-CGB005" Subject: RE: [ipcdn] Signaling MIB - Draft 3 - Last Call - Clarification US/intl. requirements Date: Thu, 5 Feb 2004 09:59:21 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 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=none 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 > Clearly, there are situations where an operator uses L package > AND E package features. Making references to ETSI only or NA only > in the object descriptions is not accurate, and I think > misleading. It is important to allow operators the flexibility to use t= he > objects from the MIB they deem necessary for their operations. Well, if you have the E-package, then you would also need the L-package. Using the E-package alone, without also using the L-package, is not possible. Remember, the E-package, defined in appendix B.4 of TS 101 909-4, is an extension to the L-package, that was defined out of a need to map V5 sign= als and events to NCS. For instance, there is no way to let an MTA play dial tone using only the E-package; you need the "dl" signal from the L-packag= e for this. > As an alternative, I would propose adding comments to the > introductory section of the MIB to make it clear that the term L > package refers to the core functionality (as defined by > CableLabs/PacketCable) and the term E package refers to > extensions over and above the core package (defined in support of > international requirements). Further, all references to ETSI and > NA in the MIB object descriptions could then be eliminated in a > subsequent draft of the MIB, and replaced with L or E package > comments as appropriate. My idea of the "ETSI systems" and "non-ETSI systems" terminology, was tha= t an operator that uses the L- and E-package would fall under the "ETSI systems" category, and an operator using the L-package alone would fall under the "non-ETSI systems" category. I believe that this is the source of the confusion; you maybe interpreted= it as if "ETSI systems" referred to E-package *only*? In any case, it would indeed be beneficial to clarify on what "ETSI syste= ms" and "non-ETSI systems" mean in this context. With this in mind, is my proposal not the same as yours, then? Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Feb 5 16:22: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 QAA09686 for ; Thu, 5 Feb 2004 16:22:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqwm-0001Fr-R3 for ipcdn-archive@odin.ietf.org; Thu, 05 Feb 2004 16:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15LM47w004817 for ipcdn-archive@odin.ietf.org; Thu, 5 Feb 2004 16:22:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqwj-0001C1-PG; Thu, 05 Feb 2004 16:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoqw0-00019q-4T for ipcdn@optimus.ietf.org; Thu, 05 Feb 2004 16:21: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 QAA09515 for ; Thu, 5 Feb 2004 16:21:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoqvx-0002Q2-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 16:21:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aoqv3-0002Ka-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 16:20:18 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AoquL-00029Y-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 16:19:33 -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 i15LIrJj023627; Thu, 5 Feb 2004 14:18:53 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] clarification text for docsIfCmtsModulationTable re: row persistency Date: Thu, 5 Feb 2004 14:18:53 -0700 Message-ID: Thread-Topic: [ipcdn] clarification text for docsIfCmtsModulationTable re: row persistency Thread-Index: AcPqjfjrq1hryNFZRDS9zepdmSp3wQBn4Xnw From: "Matthew Schmitt" To: "Minnie Lu" , "Donati Andrew-MGIA0477" , "Jean-Francois Mule" Cc: "Wijnen, Bert (Bert)" , "Murwin William-LWM008" , 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.0 required=5.0 tests=none 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 One thing I would like to recommend is to avoid using the phrase "may = not", as its meaning can be somewhat ambiguous. Matt -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Tuesday, February 03, 2004 12:40 PM To: Donati Andrew-MGIA0477; Jean-Francois Mule Cc: 'Wijnen, Bert (Bert)'; milu@cisco.com; Murwin William-LWM008; = ipcdn@ietf.org Subject: RE: [ipcdn] clarification text for docsIfCmtsModulationTable = re: row persistency Hi, Jean and Andy, It seems to me that there are two things we need to address and add = the=20 text in the description. 1. Pre-defined modulation profiles MAY read-only. Andy's proposal as = below=20 looks good to me. "In some implementations, pre-defined rows created at system = initialization=20 time may not be deleted". 2. Rows persistence. Jean's proposal as below looks good to me. "Entries with a status column (docsIfCmtsModControl) of value 'active' MUST be persist across reboots. Entries with a status column (docsIfCmtsModControl) of value 'notReady' and 'notInService' may not persist after reboots since those entries were explicit made not be available for use by the managed device ('notInService') or the agent had not sufficient info anyway ('notReady')." Thanks a lot ! Minnie At 09:14 AM 1/29/2004 -0500, Donati Andrew-MGIA0477 wrote: >All, > >Basically, the initial concern is to cover the cases where the default >rows created at system initialization cannot be deleted. We need to = find=20 >some way to legally allow vendors to implement these default rows as = "read=20 >only" (rows cannot be changed or deleted) or "permanent" (rows can be=20 >changed but not deleted). > >Either one of the following options are possible: > >1. Add the following sentence to the DESCRIPTION clause for >docsIfCmtsModControl: > >"In some implementations, pre-defined rows created at system >initialization time may >not be deleted" > > >2. Implement the StorageType object in the table. > > >Thanks, >Andy > > > >-----Original Message----- >From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] >Sent: Thursday, January 29, 2004 4:50 AM >To: 'Jean-Francois Mule'; Donati Andrew-MGIA0477; milu@cisco.com >Cc: ipcdn@ietf.org >Subject: RE: [ipcdn] clarification text for docsIfCmtsModulationTable=20 >re: >row persistency > > >Mmmm... when I see this discussion, then it seems to me that using >StorageType object is the better choice and makes it possible for = vendors=20 >to show "may not be deleted" by making them permanent for example. > >Also... the issue of when a row gets deleted that is in notInService or = >notReady state, that is described in RFC2579 in the RowStatus TC=20 >DESCRIPTION clause. > >Thanks, >Bert > > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: donderdag 29 januari 2004 1:52 > > To: Donati Andrew-MGIA0477; milu@cisco.com > > Cc: ipcdn@ietf.org > > Subject: [ipcdn] clarification text for docsIfCmtsModulationTable=20 > > re: row persistency > > > > > > Andy wrote: > > > The proposed additional sentence for docsIfCmtsModControl should=20 > > > be more explicit. > > > > > > Instead of, "In some implementations, rows created at run time may = > > > not be deleted", state "In some implementations, pre-defined rows=20 > > > created at system initialization time may not be deleted" > > Based on a chat with Eduardo, I do understand a little better that=20 > > the persistence of those rows may depend on the product=20 > > implementation. However, I'm curious what this=20 > > implementation-dependent behavior means to operators & sys admins? I = > > am a bit concerned that adding such vague statements don't help any=20 > > of us in the end (they don't help sysadmins because one cannot=20 > > assume much and they don't help new implementors because they don't=20 > > give much guidance). See below. > > > > Minnie wrote: > > > I would like to propose that only the those entries with active=20 > > > value in docsIfCmtsModControl object MUST be saved after the=20 > > > managed device restarts. > > I like this proposal better because it states what the behavior=20 > > should be for *all* implementations on a subset of entries ('active' = > > rows only, right?). Are they any concerns with this approach? > > > > Minnie wrote: > > > For those notInService entries, it is vendor specific=20 > > > implementation to save them or not. > > What about 'notReady'? To me 'notReady' and 'notInService' should=20 > > fall in the same bucket. > > > > Minnie wrote: > > > Those entries which rowStatus is notInService might not have all=20 > > > consistent attributes and they are not ready to be used (that is=20 > > > why the rowstatus is > > > notInService). I don't think there is a need to save those > > > notInService > > > rows. But some vendor might want to save them, so I propose > > > to leave it to > > > vendor's choice. > > I personally think it is acceptable to not mandate the persistency=20 > > of data for 'notReady' and 'notInService' and that we can justify it = > > as you proposed. It may also convey Andy's comment about=20 > > implementation specific behaviors - but it constraints those to a=20 > > subset of rows for which nothing was certain from a mgmt station=20 > > point of view. > > > > How about the following text: > > Entries with a status column (docsIfCmtsModControl) of value=20 > > 'active' MUST be persist across reboots. Entries with a status=20 > > column (docsIfCmtsModControl) of value 'notReady' and 'notInService' = > > may not persist after reboots since those entries were explicit made = > > not be available for use by the managed device ('notInService') or=20 > > the agent had not sufficient info anyway ('notReady'). > > > > Comments? > > Jean-Fran=E7ois > > > > _______________________________________________ > > IPCDN mailing list > > IPCDN@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipcdn > > > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Feb 5 18:57:27 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 SAA20005 for ; Thu, 5 Feb 2004 18:57: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 1AotMj-0002f4-3L for ipcdn-archive@odin.ietf.org; Thu, 05 Feb 2004 18:57:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Nv1wK010206 for ipcdn-archive@odin.ietf.org; Thu, 5 Feb 2004 18:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotMi-0002eQ-1z; Thu, 05 Feb 2004 18:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotM5-0002e3-LT for ipcdn@optimus.ietf.org; Thu, 05 Feb 2004 18:56: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 SAA19971 for ; Thu, 5 Feb 2004 18:56:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotM2-0005Vp-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:56:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotL7-0005U8-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:55:22 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AotKa-0005SL-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:54:48 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i15NsmAH013738 for ; Thu, 5 Feb 2004 16:54:48 -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 i15NsklH002998 for ; Thu, 5 Feb 2004 17:54:46 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 5 Feb 2004 15:54:46 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Cal lfor Comments [NEW ISSUE Caller ID Ranges] Date: Thu, 5 Feb 2004 15:54:45 -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 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: , After taking a quick look at 300 659, I note the lower bound for the T4 parameter for the pktcSigDevCIDFskAfterDTAS object is 45 ms not 50 ms. Clearly, there is nothing broken regarding the MIB definition for these objects. In fact, the change proposed for pktcSigDevCIDFskAfterDTAS would cause an MTA to be unable to meet lower bound for the 300 659 timing specification noted above. I recommend leaving the range for these objects as 0, as presently defined in the MIB and indicating that the object range meets or exceeds the ranges in the 300 659 specification. The later specification should be the definitive guide for any pass/fail test criteria. >New issues that we feel need to be accommodated in the draft-03. >Issue #6 - ranges for some values need to be changed >a) pktcSigDevCIDFskAfterRing - minimum should be 50 (not 0) >b) pktcSigDevCIDFskAfterDTAS - minimum should be 50 (not 0) >c) pktcSigDevCIDRingAfterFSK - minimum should be 50 (not 0) >d) pktcSigDevCIDDTASAfterLR - minimum should be 50 (not 0) >e) pktcSigDevVmwiDTASAfterLR - minimum should be 50 (not 0) 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 Thu Feb 5 19:00: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 TAA20121 for ; Thu, 5 Feb 2004 19:00: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 1AotPg-0002pH-T6 for ipcdn-archive@odin.ietf.org; Thu, 05 Feb 2004 19:00:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i160031k010774 for ipcdn-archive@odin.ietf.org; Thu, 5 Feb 2004 19:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotPd-0002nP-TG; Thu, 05 Feb 2004 19:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotOu-0002in-4a for ipcdn@optimus.ietf.org; Thu, 05 Feb 2004 18:59: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 SAA20044 for ; Thu, 5 Feb 2004 18:59:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotOq-0005cy-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:59:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotNs-0005aT-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:58:13 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AotMu-0005XC-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:57:12 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i15Ntecw023920 for ; Thu, 5 Feb 2004 16:55:44 -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 i15NurUY017994 for ; Thu, 5 Feb 2004 17:56:53 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 5 Feb 2004 15:56:58 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default val ues Date: Thu, 5 Feb 2004 15:56:57 -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 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 comments: >- pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence >"A default value MUST be provided, but it is left up to the implementation to choose a reasonable default." - It seems to me that having a requirement of this nature in the MIB is not meaningful. Also, I don't see how "reasonable" can be tested. An arbitrary value is not meaningful. Instead, how about "The default value for this object is as specified in the "L" package as defined in the PacketCable NCS specification". >- pktcSigDevToneTable >"The MTA device MUST make sure that, after the provisioning cycle, the table is fully populated (i.e. for each possible index, an entry MUST be defined) using reasonable defaults for each row that was not defined by the provisioning information." This statement is not necessary. By utilizing the DEFVAL clause an initial value for each parameter associated with a row can be established. Unfortunately, I see the DEFVAL clause is missing in many of the table objects. Consequently, I would recommend a DEFVAL clause be added for the following objects: pktcSigDevToneFirstFrequency DEFVAL { 0 } pktcSigDevToneSecondFrequency DEFVAL { 0 } pktcSigDevToneThirdFrequency DEFVAL { 0 } pktcSigDevToneFourthFrequency DEFVAL { 0 } pktcSigDevToneFirstToneOn DEFVAL { 0 } pktcSigDevToneFirstToneOff DEFVAL { 0 } pktcSigDevToneSecondToneOn DEFVAL { 0 } pktcSigDevToneSecondToneOff DEFVAL { 0 } pktcSigDevToneThirdToneOn DEFVAL { 0 } pktcSigDevToneThirdToneOff DEFVAL { 0 } pktcSigDevToneFourthToneOn DEFVAL { 0 } pktcSigDevToneFourthToneOff DEFVAL { 0 } pktcSigDevToneWholeToneRepeatCount DEFVAL { 0 } pktcSigDevToneSteady DEFVAL { false } The DEFVAL approach would also minimize any operator configurations. >- pktcSigDevRingCadenceTable >"The MTA device is allowed to provide appropriate default values for each of the ring cadences." How about: "The MTA is allowed to predefine the ring cadence for one or more rows in the pktcSigDevRingCadenceTable." 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 Thu Feb 5 19:01: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 TAA20179 for ; Thu, 5 Feb 2004 19:01:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotQc-0002tE-Kq for ipcdn-archive@odin.ietf.org; Thu, 05 Feb 2004 19:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16011WH010985 for ipcdn-archive@odin.ietf.org; Thu, 5 Feb 2004 19:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotQb-0002r5-BM; Thu, 05 Feb 2004 19:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AotPw-0002qS-RD for ipcdn@optimus.ietf.org; Thu, 05 Feb 2004 19:00:20 -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 TAA20108 for ; Thu, 5 Feb 2004 19:00:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AotPt-0005gS-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 19:00:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AotP1-0005ee-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:59:24 -0500 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx with esmtp (Exim 4.12) id 1AotOH-0005cN-00 for ipcdn@ietf.org; Thu, 05 Feb 2004 18:58:37 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id i15Nw3tv018844 for ; Thu, 5 Feb 2004 16:58:03 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i15NsiIi030774 for ; Thu, 5 Feb 2004 17:54:45 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 5 Feb 2004 15:55:18 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments (NEW ISSUE pktcSigDevToneDbLevel reference point) Date: Thu, 5 Feb 2004 15:55:17 -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 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: , 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. 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 Fri Feb 6 02:34: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 CAA15209 for ; Fri, 6 Feb 2004 02:34: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 1Ap0V2-0004hL-Ry for ipcdn-archive@odin.ietf.org; Fri, 06 Feb 2004 02:34:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i167Y4T5018055 for ipcdn-archive@odin.ietf.org; Fri, 6 Feb 2004 02:34:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0Uz-0004gn-M5; Fri, 06 Feb 2004 02:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap0UZ-0004fT-Cw for ipcdn@optimus.ietf.org; Fri, 06 Feb 2004 02:33: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 CAA15203 for ; Fri, 6 Feb 2004 02:33:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0UV-0001wk-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 02:33:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap0Ti-0001ub-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 02:32:42 -0500 Received: from elektra.telenet-ops.be ([195.130.132.49]) by ietf-mx with esmtp (Exim 4.12) id 1Ap0TF-0001s6-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 02:32:13 -0500 Received: from localhost (apate.telenet-ops.be [195.130.132.57]) by elektra.telenet-ops.be (Postfix) with SMTP id CE67E33E97 for ; Fri, 6 Feb 2004 08:32:08 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by apate.telenet-ops.be (Postfix) with SMTP id 9A67A37E67 for ; Fri, 6 Feb 2004 08:32:08 +0100 (MET) Received: (qmail 18894 invoked from network); 6 Feb 2004 07:31:23 -0000 Received: from unknown (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 6 Feb 2004 07:31:23 -0000 Received: from ([10.5.5.72]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 6 Feb 2004 08:31:23 +0100 (CET) From: "David De Reu" To: "Beacham Gordon-CGB005" , Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default values Date: Fri, 6 Feb 2004 08:31:08 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 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=none 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 > >- pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence > >"A default value MUST be provided, but it is left up to the > implementation to choose a reasonable default." - > It seems to me that having a requirement of this nature in the > MIB is not meaningful. Also, I don't see how "reasonable" can be > tested. Well, about anything that is not plain silence could be considered reasonable :-) > An arbitrary value is not meaningful. Instead, how about > "The default value for this object is as specified in the "L" > package as defined in the PacketCable NCS specification". Fine with me. In that case however, I would make the default value explicitly clear using a DEFVAL clause. > >- pktcSigDevToneTable > >"The MTA device MUST make sure that, after the provisioning > cycle, the table is fully populated (i.e. for each possible > index, an entry MUST be defined) using reasonable defaults for > each row that was not defined by the provisioning information." > > This statement is not necessary. By utilizing the DEFVAL clause > an initial value for each parameter associated with a row can be > established. I agree with the DEFVAL clause approach, but don't we still need to make sure that every row is present in the table? > The DEFVAL approach would also minimize any operator configurations. Agreed. > >- pktcSigDevRingCadenceTable > >"The MTA device is allowed to provide appropriate default values > for each of the ring cadences." > How about: > > "The MTA is allowed to predefine the ring cadence for one or more > rows in the pktcSigDevRingCadenceTable." Agreed. David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Feb 6 17:15: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 RAA25663 for ; Fri, 6 Feb 2004 17:15: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 1ApEFd-0004Q8-5s for ipcdn-archive@odin.ietf.org; Fri, 06 Feb 2004 17:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16MF5Hw016962 for ipcdn-archive@odin.ietf.org; Fri, 6 Feb 2004 17:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEFb-0004O9-Df; Fri, 06 Feb 2004 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApEEu-0004KC-D3 for ipcdn@optimus.ietf.org; Fri, 06 Feb 2004 17:14:20 -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 RAA25342 for ; Fri, 6 Feb 2004 17:14:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApEEs-0006pM-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 17:14:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApEDc-0006bd-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 17:13:01 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1ApECh-0006Wt-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 17:12:03 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 06 Feb 2004 14:11: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 OAA05084; Fri, 6 Feb 2004 14:11:16 -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) ; Fri, 6 Feb 2004 14:11:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Cal lfor Comments [NEW ISSUE Caller ID Ranges] Date: Fri, 6 Feb 2004 14:11:47 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B9A4EE7@nt-rmna-0740.ca.broadcom.com> Thread-Topic: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Cal lfor Comments [NEW ISSUE Caller ID Ranges] Thread-Index: AcPsQ8tDXz70sswyRyuTJLtMp2wvGgAuIJCg From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" cc: ipcdn@ietf.org X-OriginalArrivalTime: 06 Feb 2004 22:11:48.0400 (UTC) FILETIME=[36EF3300:01C3ECFE] X-WSS-ID: 6C3ACEA52IW2996512-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=none 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 > After taking a quick look at 300 659, I note the lower bound for the = T4=20 > parameter for the pktcSigDevCIDFskAfterDTAS object is 45 ms not 50 ms. ... > I recommend leaving the range for these objects as 0,=20 We do not see anything particular attractive in number "45" or "50" = except that it should be some value greater than "0" as the latter = really does not make sense (one cannot expect the MTA to be able to deal = with the 0-length interval between the ring and the beginning of the FSK = signal). If 300 659 states that the lower bound is 45, why not to make = it "45". If you are concerned about possiblity for the 300 659 to be = modified with the lower than the number "45" value than, I think, a new = value will still be reasonably greater than "0". The bottom line - we feel comfortable with any value for the lower bound = (say 45) which is in line with 300 659 and provided that this value is = reasonable. Eugene. -----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: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Cal lfor Comments [NEW ISSUE Caller ID Ranges] After taking a quick look at 300 659, I note the lower bound for the T4 = parameter for the pktcSigDevCIDFskAfterDTAS object is 45 ms not 50 ms. Clearly, there is nothing broken regarding the MIB definition for these = objects. In fact, the change proposed for pktcSigDevCIDFskAfterDTAS = would cause an MTA to be unable to meet lower bound for the 300 659 = timing specification noted above. I recommend leaving the range for these objects as 0, as presently = defined in the MIB and indicating that the object range meets or exceeds = the ranges in the 300 659 specification. The later specification should = be the definitive guide for any pass/fail test criteria. >New issues that we feel need to be accommodated in the draft-03. >Issue #6 - ranges for some values need to be changed >a) pktcSigDevCIDFskAfterRing - minimum should be 50 (not 0) >b) pktcSigDevCIDFskAfterDTAS - minimum should be 50 (not 0) >c) pktcSigDevCIDRingAfterFSK - minimum should be 50 (not 0) >d) pktcSigDevCIDDTASAfterLR - minimum should be 50 (not 0) >e) pktcSigDevVmwiDTASAfterLR - minimum should be 50 (not 0) 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 Fri Feb 6 18:28: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 SAA29522 for ; Fri, 6 Feb 2004 18:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFOE-000778-Se for ipcdn-archive@odin.ietf.org; Fri, 06 Feb 2004 18:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16NS2Ef027316 for ipcdn-archive@odin.ietf.org; Fri, 6 Feb 2004 18:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFOD-00075r-NH; Fri, 06 Feb 2004 18:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFNV-00074B-Kw for ipcdn@optimus.ietf.org; Fri, 06 Feb 2004 18:27:17 -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 SAA29483 for ; Fri, 6 Feb 2004 18:27:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFNS-00041J-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 18:27:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFMV-0003xd-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 18:26:16 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1ApFLr-0003sb-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 18:25:35 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 06 Feb 2004 15:25:16 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 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 PAA18617; Fri, 6 Feb 2004 15:16:03 -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) ; Fri, 6 Feb 2004 15:16:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default val ues Date: Fri, 6 Feb 2004 15:16:34 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B9A4EE5@nt-rmna-0740.ca.broadcom.com> Thread-Topic: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default val ues Thread-Index: AcPsRDs1I/EhgBRpQcu+cvTikj5lFQAtEQSA From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" cc: ipcdn@ietf.org X-OriginalArrivalTime: 06 Feb 2004 23:16:35.0416 (UTC) FILETIME=[43C6C580:01C3ED07] X-WSS-ID: 6C3AFDD61MW3011949-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=none 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 >- pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence ... > Instead, how about "The default value for this object is as specified = in=20 > the "L" package as defined in the PacketCable NCS specification". As NCS Spec does not have any specific reqs for L-package except for ref = to GR-506 (appendix A.2 of the NCS Spec), we feel comfortable with the = original tComLabs' proposal: "A default value MUST be provided, but it = is left up to the implementation to choose a reasonable default." >- pktcSigDevToneTable >"The MTA device MUST make sure that, after the provisioning cycle, the = table=20 > is fully populated (i.e. for each possible index, an entry MUST be = defined)=20 > using reasonable defaults for each row that was not defined by the = provisioning information." ... > This statement is not necessary. By utilizing the DEFVAL clause an=20 > initial value for each parameter associated with a row can be = established.=20 > Unfortunately, I see the DEFVAL clause is missing in many of the table = objects.=20 > Consequently, I would recommend a DEFVAL clause be added for the = following objects: > pktcSigDevToneFirstFrequency DEFVAL { 0 } > pktcSigDevToneSecondFrequency DEFVAL { 0 } .... As "0" values beaing the defaults for these object will actually = generate no audible tone, we feel that instead of trying to consolidate = all values for these object amoung all countries, the original tComlabs' = proposal will serve the purpose better.=20 >- pktcSigDevRingCadenceTable >"The MTA device is allowed to provide appropriate default values for = each of the ring cadences."=20 > How about: > "The MTA is allowed to predefine the ring cadence for one or more rows = in the pktcSigDevRingCadenceTable." We do not see the real difference between these two, and original = tComlabs' proposal seems to be satisfactory.=20 Eugene Nechamkin, Broadcom Corp, (604) 233-8500 -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: Thursday, February 05, 2004 3:57 PM To: 'ipcdn@ietf.org' Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Default val ues My comments: >- pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence >"A default value MUST be provided, but it is left up to the = implementation to choose a reasonable default." -=20 It seems to me that having a requirement of this nature in the MIB is = not meaningful. Also, I don't see how "reasonable" can be tested. An = arbitrary value is not meaningful. Instead, how about "The default value = for this object is as specified in the "L" package as defined in the = PacketCable NCS specification". >- pktcSigDevToneTable >"The MTA device MUST make sure that, after the provisioning cycle, the = table is fully populated (i.e. for each possible index, an entry MUST be = defined) using reasonable defaults for each row that was not defined by = the provisioning information." This statement is not necessary. By utilizing the DEFVAL clause an = initial value for each parameter associated with a row can be = established. Unfortunately, I see the DEFVAL clause is missing in many = of the table objects. Consequently, I would recommend a DEFVAL clause be = added for the following objects: pktcSigDevToneFirstFrequency DEFVAL { 0 } pktcSigDevToneSecondFrequency DEFVAL { 0 } pktcSigDevToneThirdFrequency DEFVAL { 0 } pktcSigDevToneFourthFrequency DEFVAL { 0 } pktcSigDevToneFirstToneOn DEFVAL { 0 } pktcSigDevToneFirstToneOff DEFVAL { 0 } pktcSigDevToneSecondToneOn DEFVAL { 0 } pktcSigDevToneSecondToneOff DEFVAL { 0 } pktcSigDevToneThirdToneOn DEFVAL { 0 } pktcSigDevToneThirdToneOff DEFVAL { 0 } pktcSigDevToneFourthToneOn DEFVAL { 0 } pktcSigDevToneFourthToneOff DEFVAL { 0 } pktcSigDevToneWholeToneRepeatCount DEFVAL { 0 } pktcSigDevToneSteady DEFVAL { false }=20 The DEFVAL approach would also minimize any operator configurations. >- pktcSigDevRingCadenceTable >"The MTA device is allowed to provide appropriate default values for = each of the ring cadences."=20 How about: "The MTA is allowed to predefine the ring cadence for one or more rows = in the pktcSigDevRingCadenceTable." 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 Fri Feb 6 18:28: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 SAA29521 for ; Fri, 6 Feb 2004 18:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFOE-000773-Rn for ipcdn-archive@odin.ietf.org; Fri, 06 Feb 2004 18:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16NS2Ox027315 for ipcdn-archive@odin.ietf.org; Fri, 6 Feb 2004 18:28:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFOD-00075d-EF; Fri, 06 Feb 2004 18:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApFNU-000746-SP for ipcdn@optimus.ietf.org; Fri, 06 Feb 2004 18:27:17 -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 SAA29480 for ; Fri, 6 Feb 2004 18:27:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApFNR-00041E-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 18:27:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApFMV-0003xV-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 18:26:15 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1ApFLT-0003sX-00 for ipcdn@ietf.org; Fri, 06 Feb 2004 18:25:11 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 06 Feb 2004 15:25:12 -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 PAA20286; Fri, 6 Feb 2004 15:24:29 -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) ; Fri, 6 Feb 2004 15:25:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Feb 2004 15:24:59 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B85E6F0@nt-rmna-0740.ca.broadcom.com> Thread-Topic: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments (NEW ISSUE pktcSigDevToneDbLevel reference point) Thread-Index: AcPsRFhNPnXfnARlSPG5NgJ97IQa8QAwzW2w From: "Eugene Nechamkin" To: ipcdn@ietf.org cc: "Beacham Gordon-CGB005" X-OriginalArrivalTime: 06 Feb 2004 23:25:01.0338 (UTC) FILETIME=[715457A0:01C3ED08] X-WSS-ID: 6C3AFDD22IW3010652-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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Repetition indicator for pktcSigDevRingCadence, pktcSigDevStandardRingCadence, pktcSigDevRingSplashCadence Objects 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 current definition of the ring cadence related objects such as = pktcSigDevRingCadence, pktcSigDevStandardRingCadence, and = pktcSigDevRingSplashCadence, does not accomodate the possiblity for the = cadence sequence to be repeatable. This is also inconsistent with what = currently exists in the PacketCable Signaling MIB. To compencate for = this deficiency, the either of the following approaches is proposed for = further discussion: 1. "Borrow" one bit (MSb) from the second byte to indicate the = repeatable sequence. This will reduce the max time interval by 50msec, = but will require just to slightly modify the description of the MIB = objects. 2. Extend the SIZE range by one byte, indicating the repeatable tone = sequence. This extra byte will immediately follow the first one (the = length). In this case SIZE and desciptoins of all MIB objects should be = modified. Eugene Nechamkin, Broadcom Corp., (604) 233-8500 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Feb 9 03:41: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 DAA06979 for ; Mon, 9 Feb 2004 03:41: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 1Aq6ya-0000Z4-Hc for ipcdn-archive@odin.ietf.org; Mon, 09 Feb 2004 03:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i198f8JC002145 for ipcdn-archive@odin.ietf.org; Mon, 9 Feb 2004 03:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6yY-0000Xq-CJ; Mon, 09 Feb 2004 03:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aq6yS-0000VP-6x for ipcdn@optimus.ietf.org; Mon, 09 Feb 2004 03:41:00 -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 DAA06945 for ; Mon, 9 Feb 2004 03:40:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6yP-0001NW-00 for ipcdn@ietf.org; Mon, 09 Feb 2004 03:40:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aq6xg-0001IQ-00 for ipcdn@ietf.org; Mon, 09 Feb 2004 03:40:13 -0500 Received: from elektra.telenet-ops.be ([195.130.132.49]) by ietf-mx with esmtp (Exim 4.12) id 1Aq6wj-0001CN-00 for ipcdn@ietf.org; Mon, 09 Feb 2004 03:39:13 -0500 Received: from localhost (apate.telenet-ops.be [195.130.132.57]) by elektra.telenet-ops.be (Postfix) with SMTP id 5CFAE33EED for ; Mon, 9 Feb 2004 09:39:09 +0100 (MET) Received: from tcomlabs.com (D5E0060A.kabel.telenet.be [213.224.6.10]) by apate.telenet-ops.be (Postfix) with SMTP id 1C19437E6B for ; Mon, 9 Feb 2004 09:39:09 +0100 (MET) Received: (qmail 2308 invoked from network); 9 Feb 2004 08:38:19 -0000 Received: from unknown (HELO tComGateway.tComlabs.com) (127.0.0.1) by tcomlabs.com with SMTP; 9 Feb 2004 08:38:19 -0000 Received: from ([10.5.5.72]) by tComGateway.tComLabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 9 Feb 2004 09:37:57 +0100 (CET) From: "David De Reu" To: "Beacham Gordon-CGB005" , Date: Mon, 9 Feb 2004 09:38:39 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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: 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=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - Last Callfor Comments [NEW ISSUE Caller ID Ranges] 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 > I recommend leaving the range for these objects as 0, as > presently defined in the MIB and indicating that the object range > meets or exceeds the ranges in the 300 659 specification. That would imply that it is possible to configure, by MIB, the MTA to be non-ETSI compliant. Is there a specific reason for this? For instance, do you have knowledge of large numbers of rolled-out equipment (e.g. caller = ID devices) that are non-ETSI compliant, and thus require different timing constraints? Or do you want a lower bound of zero to accomodate for futur= e changes in the ETSI specs? > The > later specification should be the definitive guide for any > pass/fail test criteria. The ETSI specs would indeed be the basis for the test criteria. For examp= le, for the pktcSigDevCIDRingAfterFSK value, the 300 659 spec says the minimu= m is 200 ms. Assuming that the range in the MIB allows for values outside t= he ETSI range, then how do we interpret this? We feel that, for testing purposes, the MTA MUST implement at least the E= TSI range. Values outside the ETSI range, but inside the MIB range, would the= n have to return an SNMP "Commit failed" error on a SET for such a value. T= his would then be tested. Second, values outside of the MIB range would retur= n a different error, "Bad value", which is of course also tested. This means that, depending on the value SET, the error message would be different. However, we also feel that, apart from adding a little complexity to the MTA, a MIB range that differs from the ETSI range possibly confuses the users of the MIB, i.e. the operators. So why not use the ETSI range as th= e MIB range? David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Feb 10 12:33:39 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 MAA28778 for ; Tue, 10 Feb 2004 12:33:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqbl1-0000dK-Bl for ipcdn-archive@odin.ietf.org; Tue, 10 Feb 2004 12:33:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AHXBkm002410 for ipcdn-archive@odin.ietf.org; Tue, 10 Feb 2004 12:33:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqbkr-0000cV-4G; Tue, 10 Feb 2004 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqbkq-0000cK-EW for ipcdn@optimus.ietf.org; Tue, 10 Feb 2004 12:33:00 -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 MAA28762 for ; Tue, 10 Feb 2004 12:32:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqbko-0000dr-00 for ipcdn@ietf.org; Tue, 10 Feb 2004 12:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqbjr-0000ZT-00 for ipcdn@ietf.org; Tue, 10 Feb 2004 12:31:59 -0500 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 1AqbjF-0000Uw-00 for ipcdn@ietf.org; Tue, 10 Feb 2004 12:31:21 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id i1AHV3pW006225 for ; Tue, 10 Feb 2004 10:31:07 -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 i1AHAXWJ003975 for ; Tue, 10 Feb 2004 11:11:34 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 10 Feb 2004 09:13:19 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: RE: [ipcdn] RE: IETF IPCDN Signaling MIB - Draft 3 - LastCal lfor Comments [NEW ISSUE Caller ID Ranges] Date: Tue, 10 Feb 2004 09:13:18 -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 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 bottom line - we feel comfortable with any value for the lower bound (say 45) which is in line with 300 659 and provided that this value is reasonable. Agree with 45 ms as the lower bound for pktcSigDevCIDFskAfterDTAS and with 50 ms as the lower bound for the other objects as proposed. 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 Sat Feb 14 08:56:35 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 IAA17925 for ; Sat, 14 Feb 2004 08:56:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As0H6-0001ub-KU for ipcdn-archive@odin.ietf.org; Sat, 14 Feb 2004 08:56:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1EDu4Uw007325 for ipcdn-archive@odin.ietf.org; Sat, 14 Feb 2004 08:56:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As0H3-0001tm-Uz; Sat, 14 Feb 2004 08:56:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1As0Go-0001tJ-Fm for ipcdn@optimus.ietf.org; Sat, 14 Feb 2004 08:55:48 -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 IAA17915 for ; Sat, 14 Feb 2004 08:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1As0Gn-0006Um-00 for ipcdn@ietf.org; Sat, 14 Feb 2004 08:55:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1As0Fs-0006Re-00 for ipcdn@ietf.org; Sat, 14 Feb 2004 08:54:49 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1As0FZ-0006O2-00 for ipcdn@ietf.org; Sat, 14 Feb 2004 08:54:29 -0500 Received: from comcast.net (h00045af3c79a.ne.client2.attbi.com[24.128.14.216]) by comcast.net (sccrmhc11) with SMTP id <2004021413535801100krmjse> (Authid: sawyerwd); Sat, 14 Feb 2004 13:53:59 +0000 Message-ID: <402E2894.80D5B9BB@comcast.net> Date: Sat, 14 Feb 2004 08:54:28 -0500 From: Wilson Sawyer X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipcdn@ietf.org, harrie@lisanza.net Content-Type: text/plain; charset=us-ascii 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 Subject: [ipcdn] subscriber management mib -14 submission 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 I have submitted draft -14 of the subscriber management mib internet draft. It should be available soon in the usual places. The only changes are: the last sentence of the abstract was changed from: The Differentiated Services MIB (RFC 3289) is extended to provide the filtering functions needed here. to The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. (see Harrie's email 19-January) the description of docsSubMgtCpeControlTable was changed to read "This table AUGMENTs the docsIfCmtsCmStatusTable, adding four WRITEable objects, as well as a read-only object, which reflect the state of subscriber management on a particular CM." (see Harrie's email 19-January) the reference to the DOCSIS RFI spec was changed to [ITU-T-J122] Second-Generation Transmission Systems for Interactive Cable Television Services, J.122, ITU-T, December, 2002. (see Jean-Francois's email 29-January) Respectfully submitted, Wilson Sawyer _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Feb 16 15:39:43 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 PAA19831 for ; Mon, 16 Feb 2004 15:39:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspWM-0001sP-Jl for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:39:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKdEwe007189 for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 15:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspW9-0001mN-BB; Mon, 16 Feb 2004 15:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspVg-0001h4-QG for ipcdn@optimus.ietf.org; Mon, 16 Feb 2004 15:38:33 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19501; Mon, 16 Feb 2004 15:38:30 -0500 (EST) Message-Id: <200402162038.PAA19501@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: Mon, 16 Feb 2004 15:38:29 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-14.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 : Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-14.txt Pages : 25 Date : 2004-2-16 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-14.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-subscriber-mib-14.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-subscriber-mib-14.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-2-16122724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16122724.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Feb 16 19:16: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 TAA15193 for ; Mon, 16 Feb 2004 19:16: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 1AssuB-0002GU-Ur for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 19:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H0G3FG008682 for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 19:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AssuA-0002Fr-Pz; Mon, 16 Feb 2004 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asstq-0002Eo-5O for ipcdn@optimus.ietf.org; Mon, 16 Feb 2004 19:15: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 TAA15136 for ; Mon, 16 Feb 2004 19:15:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Assto-0000VE-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:15:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Assss-0000PS-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:14:43 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AsssM-0000LT-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:14:10 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1H0E5AH027227 for ; Mon, 16 Feb 2004 17:14:05 -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 i1H0E2SC030534 for ; Mon, 16 Feb 2004 18:14:03 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 16 Feb 2004 16:14:02 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Clarification U S/intl. requirements Date: Mon, 16 Feb 2004 16:13:54 -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 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: , Editorial changes made: pktcSigDevRingCadenceTable -change made as requested pktcSigDevStandardRing/SplashCadence -added: "This object is required for the E line package." to the description. pktcSigDevToneType -added: "The alertingSignal, specialDial, specialInfo, release, congestion and userDefined1-4 tone types are triggered using the E line package." to the description. -reference added pktcSigDevRg/RsCadence -added: "This object is required for the L line package." to the description. pktcSigPulseSignalTable -added: "This object is required for the E line package. Signals defined in this table are triggered using the E line package." to the description." -reference added Other -added definitions: L Line Package The L line package refers to the core signaling functionality as defined by PacketCable and IPCablecom. An MTA provides all L package elements, however the operator determines their application. E Line Package The E line package refers to extensions, over and above the core L package, defined in support of international requirements. E line package elements are optional, vary from country to country, and are set by operator or regulatory requirements. 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 Mon Feb 16 19:20: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 TAA15550 for ; Mon, 16 Feb 2004 19:20:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Assy8-0002VS-1P for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 19:20:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H0K75X009610 for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 19:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Assy4-0002TQ-He; Mon, 16 Feb 2004 19:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Assxw-0002SS-Vx for ipcdn@optimus.ietf.org; Mon, 16 Feb 2004 19:19: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 TAA15521 for ; Mon, 16 Feb 2004 19:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Assxv-0000yI-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:19:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AssxB-0000tT-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:19:09 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AsswR-0000me-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:18:23 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i1H0IK7X004652 for ; Mon, 16 Feb 2004 17:18:22 -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 i1H0AY0b027786 for ; Mon, 16 Feb 2004 18:10:35 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 16 Feb 2004 16:13:33 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: re: [ipcdn] Repetition indicator for pktcSigDevRingCadence,pktcSi gDevStandardRingCadence, pktcSigDevRingSplashCadence Objects Date: Mon, 16 Feb 2004 16:13:30 -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 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: , >2. Extend the SIZE range by one byte, indicating the repeatable tone sequence. This extra byte will immediately follow the first one (the length). In this case SIZE and desciptoins of all MIB objects should be modified. These objects will need to have their size extended in any case because the current cadence definition is too short to handle Germany per TS 101 183. The following proposed change handles the longer cadence and an additional octet to indicate repeatable characteristics. SYNTAX OCTET STRING (SIZE(4..36)) " 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 cadence cycle. This object is required for the E line package." 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 Mon Feb 16 19:21: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 TAA15621 for ; Mon, 16 Feb 2004 19:21: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 1Assz1-0002XD-9F for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 19:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H0L3fS009714 for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 19:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Assz0-0002Wa-RW; Mon, 16 Feb 2004 19:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Assya-0002Vg-HY for ipcdn@optimus.ietf.org; Mon, 16 Feb 2004 19:20:36 -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 TAA15541 for ; Mon, 16 Feb 2004 19:20:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AssyY-00010R-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:20:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Assxd-0000vq-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:19:38 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1Asswh-0000pE-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 19:18:39 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i1H0Id3h028709 for ; Mon, 16 Feb 2004 17:18:39 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i1H0IXt8008927 for ; Mon, 16 Feb 2004 18:18:34 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 16 Feb 2004 16:18:33 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues Date: Mon, 16 Feb 2004 16:18: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=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: , >As NCS Spec does not have any specific reqs for L-package except for ref to GR-506 (appendix A.2 of the NCS Spec), we feel comfortable with the original tComLabs' proposal: "A default value MUST be provided, but it is left up to the implementation to choose a reasonable default." My concern is whether the MIB Drs are going to flag this statement as having no value during review. The object, when queried, is going to return a value whether the statement above is included in the description clause or not. Suggestions: 1. The MTA MUST provide a default value for this object in accordance with published specifications for the country of operation. Reference "TR 101 183 Specification." OR 2. As Mark indicated DEFVAL can be used. Since tComlabs proposed this change, perhaps they could identify the exact DEFVAL clause to be used. 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 Mon Feb 16 20:54: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 UAA18744 for ; Mon, 16 Feb 2004 20:54: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 1AsuQz-0008NZ-3L for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 20:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H1s1IM032189 for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 20:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuQy-0008Mb-I9; Mon, 16 Feb 2004 20:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuQg-0008J4-MJ for ipcdn@optimus.ietf.org; Mon, 16 Feb 2004 20:53: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 UAA18734 for ; Mon, 16 Feb 2004 20:53:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsuQe-0006Gz-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 20:53:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsuPj-0006EG-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 20:52:44 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1AsuP2-0006Bj-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 20:52:00 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 16 Feb 2004 17:52:13 -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 RAA10623; Mon, 16 Feb 2004 17:51:16 -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, 16 Feb 2004 17:51:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Repetition indicator for pktcSigDevRingCadence, pktcSi gDevStandardRingCadence, pktcSigDevRingSplashCadence Objects Date: Mon, 16 Feb 2004 17:51:53 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B85E76D@nt-rmna-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Repetition indicator for pktcSigDevRingCadence, pktcSi gDevStandardRingCadence, pktcSigDevRingSplashCadence Objects Thread-Index: AcP069i0KLocNMCrQs2RLpz9jAy36AADHYDg From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 17 Feb 2004 01:51:49.0039 (UTC) FILETIME=[9B425BF0:01C3F4F8] X-WSS-ID: 6C2FAC462IW5472084-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=none 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 Agreed.=20 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: Monday, February 16, 2004 4:14 PM To: 'ipcdn@ietf.org' Subject: re: [ipcdn] Repetition indicator for pktcSigDevRingCadence, pktcSi gDevStandardRingCadence, pktcSigDevRingSplashCadence Objects >2. Extend the SIZE range by one byte, indicating the repeatable tone = sequence. This extra byte will immediately follow the first one (the = length). In this case SIZE and desciptoins of all MIB objects should be = modified.=20 These objects will need to have their size extended in any case because = the current cadence definition is too short to handle Germany per TS 101 = 183. The following proposed change handles the longer cadence and an = additional octet to indicate repeatable characteristics. SYNTAX OCTET STRING (SIZE(4..36))=20 " 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 cadence cycle. This object is required for the E line = package." =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 Mon Feb 16 21:11: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 VAA19909 for ; Mon, 16 Feb 2004 21:11: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 1AsuhS-0001Rq-DO for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 21:11:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H2B2rj005547 for ipcdn-archive@odin.ietf.org; Mon, 16 Feb 2004 21:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsuhR-0001R8-Om; Mon, 16 Feb 2004 21:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asuh9-0001Qb-7D for ipcdn@optimus.ietf.org; Mon, 16 Feb 2004 21:10:43 -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 VAA19896 for ; Mon, 16 Feb 2004 21:10:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Asuh6-0000Bo-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 21:10:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsugA-00009H-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 21:09:42 -0500 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 1Asufd-00006p-00 for ipcdn@ietf.org; Mon, 16 Feb 2004 21:09:09 -0500 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 16 Feb 2004 18:09:20 -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 SAA11653; Mon, 16 Feb 2004 18:08:24 -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, 16 Feb 2004 18:08:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues Date: Mon, 16 Feb 2004 18:09:01 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B85E770@nt-rmna-0740.brcm.ad.broadcom.com> Thread-Topic: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues Thread-Index: AcP06/wAI8F1L7j9Q3mc7uQlKUffqwADaw4Q From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 17 Feb 2004 02:08:57.0351 (UTC) FILETIME=[002E5170:01C3F4FB] X-WSS-ID: 6C2FA85A2IW5474763-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=none 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 #1 - agreed. #2 - do not agree: it does not seem logical to have single DEFVAL value = for the MIB object which has cross-country applicability.=20 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: Monday, February 16, 2004 4:18 PM To: 'ipcdn@ietf.org' Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues >As NCS Spec does not have any specific reqs for L-package except for = ref to GR-506 (appendix A.2 of the NCS Spec), we feel comfortable with = the original tComLabs' proposal: "A default value MUST be provided, but = it is left up to the implementation to choose a reasonable default."=20 My concern is whether the MIB Drs are going to flag this statement as = having no value during review. The object, when queried, is going to return a value whether the statement above is included in = the description clause or not. Suggestions: 1. The MTA MUST provide a default value for this object in accordance = with published specifications for the country of operation. Reference "TR 101 183 Specification." OR 2. As Mark indicated DEFVAL can be used. Since tComlabs proposed this = change, perhaps they could identify the exact DEFVAL clause to be used. 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 Feb 17 05:52: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 FAA23020 for ; Tue, 17 Feb 2004 05:52: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 1At2pe-0007AK-1d for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 05:52:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HAq1sQ027525 for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 05:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2pc-00079E-St; Tue, 17 Feb 2004 05:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At2pb-00078q-2W for ipcdn@optimus.ietf.org; Tue, 17 Feb 2004 05:51:59 -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 FAA22990 for ; Tue, 17 Feb 2004 05:51:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At2pX-00052E-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 05:51:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At2ob-0004yM-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 05:50:57 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1At2nk-0004t7-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 05:50:04 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HAnWr01121 for ; Tue, 17 Feb 2004 04:49:32 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <16980NLB>; Tue, 17 Feb 2004 11:49:30 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155039627E0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Beacham Gordon-CGB005 , "'ipcdn@ietf.org'" Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues Date: Tue, 17 Feb 2004 11:49:26 +0100 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: , You should check what specifying a DEFVAL in the OBJECT-TYPE definition means. RFC2578 says: 7.9. Mapping of the DEFVAL clause The DEFVAL clause, which need not be present, defines an acceptable default value which may be used at the discretion of an agent when an object instance is created. That is, the value is a "hint" to implementors. During conceptual row creation, if an instance of a columnar object is not present as one of the operands in the correspondent management protocol set operation, then the value of the DEFVAL clause, if present, indicates an acceptable default value that an agent might use (especially for a read-only object). There is more text in 2578, but the above should make it clear that it is at the discretion of the agent if it will use the exact DEFVAL value speified or not. It is only a "hint". It does help though that in case of a row-create, that column does nto have to be specified, since the presence of a DEFVAL clause means that the agent will fill out an acceptable default value (possibly the one specified). Hope this helps, Bert > -----Original Message----- > From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] > Sent: dinsdag 17 februari 2004 1:18 > To: 'ipcdn@ietf.org' > Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - > Defaultval ues > > > >As NCS Spec does not have any specific reqs for L-package > except for ref to GR-506 (appendix A.2 of the NCS Spec), we > feel comfortable with the original tComLabs' proposal: "A > default value MUST be provided, but it is left up to the > implementation to choose a reasonable default." > > My concern is whether the MIB Drs are going to flag this > statement as having no value during review. The object, when queried, > is going to return a value whether the statement above is > included in the description clause or not. > > Suggestions: > > 1. The MTA MUST provide a default value for this object in > accordance with published specifications for the country of operation. > > Reference "TR 101 183 Specification." > > OR > > 2. As Mark indicated DEFVAL can be used. Since tComlabs > proposed this change, perhaps they could identify the exact > DEFVAL clause to be used. > > 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 Feb 17 12:07: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 MAA17962 for ; Tue, 17 Feb 2004 12:07: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 1At8gZ-0005Eo-D0 for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 12:07:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HH73FK020105 for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 12:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8gX-0005Dm-SO; Tue, 17 Feb 2004 12:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnZNW-0001wt-RS for ipcdn@optimus.ietf.org; Mon, 02 Feb 2004 03:24: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 DAA24881 for ; Mon, 2 Feb 2004 03:24:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnZNU-0002Vx-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 03:24:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnZMW-0002Rn-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 03:23:21 -0500 Received: from harrie.inet.it ([213.92.1.193] helo=localhost.lisanza.net) by ietf-mx with esmtp (Exim 4.12) id 1AnZM4-0002JU-00 for ipcdn@ietf.org; Mon, 02 Feb 2004 03:22:52 -0500 Received: from lisanza.net (localhost [127.0.0.1]) by localhost.lisanza.net (8.12.9/8.12.6) with ESMTP id i128Ll5i005381; Mon, 2 Feb 2004 09:21:48 +0100 (CET) Date: Mon, 2 Feb 2004 09:21:45 +0100 Subject: Re: [ipcdn] Docsis subscriber management mib -13, submit to IESG? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: Harrie Hazewinkel , ipcdn@ietf.org, bwijnen@lucent.com, e.cardona@cablelabs.com To: Wilson Sawyer From: Harrie Hazewinkel In-Reply-To: <400DBC2A.B824EE6C@comcast.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) 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 On Wednesday, January 21, 2004, at 12:39 AM, Wilson Sawyer wrote: > Harrie - thank you. > > w.r.t. your first and third points, I'll add to or revise the wording. > > Do you have suggested text for your second point? I had chosen to err > on the > side of reticence but am willing to expand on it if you have something > in > mind. I have no real text and considering your comment it maybe is better this way. I can immagine that in the future filtering and, for instance, metering will be done. So explicitly forbidden it would not be a good idea. > As to your point (4), the short answer is "nothing". The cmFilterTable > is > unaffected, as are address entries other than "learned". Is there text > which > led you to believe otherwise? If you're referring to > docsSubMgtCpeControlActive=false, then the answer is similarly > "nothing" - > the docsSubMgtCmFilterEntry augments docsIfCmtsCmStatusEntry, and thus > is > bound to its existence. The FilterGroupTable applies to groups of > modems, > and is thus unaffected by the status of any particular modem. Yes, you are right. The augment takes care of of the existance of an entry for a particular modem and the FilterGroupTable is not affected by that. Correct me if I am wrong, but the filter group could be seen as an available configuration. Whether it is used or not is not a problem. This is similar to the approach of the DIFFSERV-CONFIG-MIB, only here you point to a specific sort of datapath element, the classifier element. Due to this I maybe found a 'bug', not sure if this is really true. In your MIB you always refer to the first pass of an classifier element, a diffServClfrElementEntry. However, the DIFFSERV-MIB also has a diffServClfrTable. This table is the common index of the complete classifier, not jsut an element. I beleive the difServClfrTable would be the right one to point to. Please read the commented 'text' above the diffServClfrTable of the DIFFSERV-MIB. I beleive that reflects this thought. Harrie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Feb 17 12:18: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 MAA18918 for ; Tue, 17 Feb 2004 12:18: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 1At8rB-0006KQ-PT for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 12:18:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHI1TZ024300 for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 12:18:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8rB-0006Jm-5t; Tue, 17 Feb 2004 12:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8qM-0006I0-MR for ipcdn@optimus.ietf.org; Tue, 17 Feb 2004 12:17: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 MAA18810 for ; Tue, 17 Feb 2004 12:17:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8qL-0000Mn-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 12:17:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8pR-0000IR-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 12:16:14 -0500 Received: from pacdcoavas04.cable.comcast.com ([208.17.33.53]) by ietf-mx with esmtp (Exim 4.12) id 1At8of-00008H-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 12:15:25 -0500 Message-ID: From: "Woundy, Richard" To: "'Harrie Hazewinkel'" , "IPCDN WG (E-mail)" Subject: RE: [ipcdn] Docsis subscriber management mib -13, submit to IESG? Date: Tue, 17 Feb 2004 12:10:03 -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: , My apologies to Harrie and the IPCDN mailing list. I was able to approve this email from Harrie from February 2nd only after I threw away about 550+ spam emails on the IPCDN approval list... Hopefully this shouldn't happen again. -- Rich -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Harrie Hazewinkel Sent: Monday, February 02, 2004 3:22 AM To: Wilson Sawyer Cc: Harrie Hazewinkel; ipcdn@ietf.org; bwijnen@lucent.com; e.cardona@cablelabs.com Subject: Re: [ipcdn] Docsis subscriber management mib -13, submit to IESG? On Wednesday, January 21, 2004, at 12:39 AM, Wilson Sawyer wrote: > Harrie - thank you. > > w.r.t. your first and third points, I'll add to or revise the wording. > > Do you have suggested text for your second point? I had chosen to err > on the > side of reticence but am willing to expand on it if you have something > in > mind. I have no real text and considering your comment it maybe is better this way. I can immagine that in the future filtering and, for instance, metering will be done. So explicitly forbidden it would not be a good idea. > As to your point (4), the short answer is "nothing". The cmFilterTable > is > unaffected, as are address entries other than "learned". Is there text > which > led you to believe otherwise? If you're referring to > docsSubMgtCpeControlActive=false, then the answer is similarly > "nothing" - > the docsSubMgtCmFilterEntry augments docsIfCmtsCmStatusEntry, and thus > is > bound to its existence. The FilterGroupTable applies to groups of > modems, > and is thus unaffected by the status of any particular modem. Yes, you are right. The augment takes care of of the existance of an entry for a particular modem and the FilterGroupTable is not affected by that. Correct me if I am wrong, but the filter group could be seen as an available configuration. Whether it is used or not is not a problem. This is similar to the approach of the DIFFSERV-CONFIG-MIB, only here you point to a specific sort of datapath element, the classifier element. Due to this I maybe found a 'bug', not sure if this is really true. In your MIB you always refer to the first pass of an classifier element, a diffServClfrElementEntry. However, the DIFFSERV-MIB also has a diffServClfrTable. This table is the common index of the complete classifier, not jsut an element. I beleive the difServClfrTable would be the right one to point to. Please read the commented 'text' above the diffServClfrTable of the DIFFSERV-MIB. I beleive that reflects this thought. Harrie _______________________________________________ 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 Feb 17 14:06: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 OAA27522 for ; Tue, 17 Feb 2004 14:06: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 1AtAXj-0001gI-Ev for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 14:06:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HJ632K006441 for ipcdn-archive@odin.ietf.org; Tue, 17 Feb 2004 14:06:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAXh-0001fX-Tg; Tue, 17 Feb 2004 14:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtAWw-0001ee-SO for ipcdn@optimus.ietf.org; Tue, 17 Feb 2004 14:05:15 -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 OAA27446 for ; Tue, 17 Feb 2004 14:05:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtAWu-0003M0-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 14:05:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtAW1-0003JW-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 14:04:18 -0500 Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx with esmtp (Exim 4.12) id 1AtAVH-0003Db-00 for ipcdn@ietf.org; Tue, 17 Feb 2004 14:03:31 -0500 Received: from dlep91.itg.ti.com ([157.170.152.55]) by go4.ext.ti.com (8.12.10/8.12.10) with ESMTP id i1HJ2xOo025954; Tue, 17 Feb 2004 13:02:59 -0600 (CST) Received: from dbde01.itg.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.10/8.12.10) with ESMTP id i1HJ2uUf013833; Tue, 17 Feb 2004 13:02:57 -0600 (CST) Received: by DBDE01 with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Feb 2004 00:32:55 +0530 Message-ID: From: "Kumar, Satish" To: "'Eugene Nechamkin'" , Beacham Gordon-CGB005 , ipcdn@ietf.org Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues Date: Wed, 18 Feb 2004 00:32:51 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , Country specific MIB defaults has to be defined in description or leave with "...but it is left up to the implementation to choose a reasonable default" Satish Kumar Texas Instruments -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Eugene Nechamkin Sent: Tuesday, February 17, 2004 2:09 AM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues #1 - agreed. #2 - do not agree: it does not seem logical to have single DEFVAL value for the MIB object which has cross-country applicability. 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: Monday, February 16, 2004 4:18 PM To: 'ipcdn@ietf.org' Subject: RE: re: [ipcdn] Signaling MIB - Draft 3 - Last Call - Defaultval ues >As NCS Spec does not have any specific reqs for L-package except for ref to GR-506 (appendix A.2 of the NCS Spec), we feel comfortable with the original tComLabs' proposal: "A default value MUST be provided, but it is left up to the implementation to choose a reasonable default." My concern is whether the MIB Drs are going to flag this statement as having no value during review. The object, when queried, is going to return a value whether the statement above is included in the description clause or not. Suggestions: 1. The MTA MUST provide a default value for this object in accordance with published specifications for the country of operation. Reference "TR 101 183 Specification." OR 2. As Mark indicated DEFVAL can be used. Since tComlabs proposed this change, perhaps they could identify the exact DEFVAL clause to be used. 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 Wed Feb 18 09:59: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 JAA15681 for ; Wed, 18 Feb 2004 09:59: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 1AtTAG-0005RJ-6W for ipcdn-archive@odin.ietf.org; Wed, 18 Feb 2004 09:59:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IEx40K020908 for ipcdn-archive@odin.ietf.org; Wed, 18 Feb 2004 09:59:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTAC-0005Qc-MB; Wed, 18 Feb 2004 09:59:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtT9g-0005Pb-SW for ipcdn@optimus.ietf.org; Wed, 18 Feb 2004 09:58:28 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15538; Wed, 18 Feb 2004 09:58:25 -0500 (EST) Message-Id: <200402181458.JAA15538@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: Wed, 18 Feb 2004 09:58:25 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-eventmess-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 : Management Event MIB for PacketCable/IPCablecom MTAs Author(s) : W. De Ketelaere, E. Nechamkin Filename : draft-ietf-ipcdn-pktc-eventmess-03.txt Pages : 28 Date : 2004-2-18 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format definition for events and specifies by what means events are transmitted 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-eventmess-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-eventmess-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-eventmess-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-2-18101140.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-eventmess-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-eventmess-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101140.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Feb 25 14:03: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 OAA05470 for ; Wed, 25 Feb 2004 14:03: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 1Aw4JD-0003fy-1b for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:03:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJ32Rt014106 for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4JA-0003fJ-LO; Wed, 25 Feb 2004 14:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4IF-0003Jp-MU for ipcdn@optimus.ietf.org; Wed, 25 Feb 2004 14:02:03 -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 OAA05405 for ; Wed, 25 Feb 2004 14:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4ID-0005bE-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:02:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4HM-0005WN-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:01:09 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4Gw-0005Qg-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:00:42 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1PJ0gUg010115 for ; Wed, 25 Feb 2004 12:00:42 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i1PIxKEp006690 for ; Wed, 25 Feb 2004 12:59:20 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Wed, 25 Feb 2004 11:00:35 -0800 Message-ID: From: Beacham Gordon-CGB005 To: ipcdn@ietf.org Date: Wed, 25 Feb 2004 11:00:33 -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 Subject: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant 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 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 From exim@www1.ietf.org Wed Feb 25 14:36: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 OAA07478 for ; Wed, 25 Feb 2004 14:36: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 1Aw4p8-0006se-AS for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:36:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJa2dP026444 for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4p6-0006s5-Kp; Wed, 25 Feb 2004 14:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4oL-0006rX-OG for ipcdn@optimus.ietf.org; Wed, 25 Feb 2004 14:35: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 OAA07304 for ; Wed, 25 Feb 2004 14:35:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4oJ-0001HO-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:35:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4nG-0001Bq-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:34:07 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4mx-00016h-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:33:47 -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 i1PJX7ut007782; Wed, 25 Feb 2004 12:33:08 -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: Wed, 25 Feb 2004 12:33:07 -0700 Message-ID: Thread-Topic: ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used Thread-Index: AcP2Rxqu2tfzPaJzStyWQCgMHRM+ugFiXhzA From: "Jean-Francois Mule" To: , , Cc: "Eugene Nechamkin" , "Satish Kumar at Texas Instruments" , "PacketCable Provisioning and OSS Majordomo List" 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used 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 Folks, Some operators are using SNMPv2c for MTA device management (and will continue to do so for some period of time). We've been discussing the impact that the unsecure SNMPv2 mgmt has on the MTA MIB with the PacketCable OSS vendor team. I would like to share some of our thoughts and our suggestions to make sure that we are doing the right thing and to that those proposed changes are sound and can later be reflected in the IETF ID mtamib draft 04. Note that the IETF ID mtamib draft 03 does have a fairly detailed security consideration section and recommends the use of secure SNMPv3. Yet, the MIB module and its objects definitions assume v3 only and we've found that the implementers feel that there should be clear guidance when v2c mgmt is used. Some MIB objects don't mean anything when v2 is used (these objects are related to the key mgmt for the security relationship with the SNMP entity or prov server (pktcMtaDevProvSolicitedKeyTimeout and alike), or to key/hash values for the config file that are passed in secure v3 mode when the MTA enrollment mechanism is used (pktcMtaDevProvConfigKey), etc.=20 At this point, our suggestions are as follows: - maintain the compliance statements as-is, all MTAs will support SNMPv3 and when v3 is used, all the objects as defined in draft 03 make sense (at least, we think they do); - define in our PacketCable MIB framework the mib views, access right for v2 mgmt, - for the specific objects that do not mean anything in v2, enhance the DESCRIPTION clause to state what the device must do if v2 mgmt is used, that is, specify the MTA's behavior when receiving SNMPv2 SET & GET operations on those v3-specific objects. - Suggestions: add something like this in the impacted objects: for pktcMtaDevProvConfigKey: This object should not be used in non secure SNMPv3 modes. In non secure SNMPv3 modes, the MTA MUST return an=20 'inconsistentValue' in response to SNMP SET operations,=20 and the MTA MUST return a 'genErr' error in response to=20 SNMP GET operations." for pktcMtaDevProvConfigHash: When the MTA SNMP Enrollment mechanism is not in use, the hash value is provided in the configuration file itself=20 and it is also calculated by the MTA. This object value MUST represent the hash value calculated by the MTA. When the MTA SNMP Enrollment mechanism is not in use, the MTA must reject all SNMP SET operations on this object and return an 'inconsistentValue' error. These are just 2 examples but they basically say: - if unsecure v2 is used, SNMP SET on the object =3D> 'inconsistentValue', SNMP GET =3D> 'genErr' This seems to be consistent with RFC 3416 (one could argue that 'noAccess' could be returned as well). Question: Is this the proper way to do this to provide some info in the MIB module as our MTA implementers have been asking for? We plan on adding some more details on the VACM model (MIB views, access rights and object trees that cannot be accessed without the proper security policies. Thanks in advance for any input on this, Jean-Francois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Feb 25 14:37: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 OAA07521 for ; Wed, 25 Feb 2004 14:37: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 1Aw4q7-000747-M7 for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PJb3Yr027120 for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 14:37:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4q6-00072s-OV; Wed, 25 Feb 2004 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw4q3-00071g-Lr for ipcdn@optimus.ietf.org; Wed, 25 Feb 2004 14:36:59 -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 OAA07511 for ; Wed, 25 Feb 2004 14:36:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4q1-0001SZ-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:36:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw4pD-0001Nz-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:36:08 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Aw4oU-0001CB-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 14:35:22 -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 i1PJYnut007977; Wed, 25 Feb 2004 12:34:49 -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: Wed, 25 Feb 2004 12:34:48 -0700 Message-ID: Thread-Topic: ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used Thread-Index: AcP2Rxqu2tfzPaJzStyWQCgMHRM+ugFiXhzAAAFweOA= From: "Jean-Francois Mule" To: , "Randy Presuhn" , Cc: "Eugene Nechamkin" , "Satish Kumar at Texas Instruments" , "PacketCable Provisioning and OSS Majordomo List" 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.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: ipcdn MTA MIB: update of description clauses when secure SNMPv3 is not used 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 RESEND with Randy's email add corrected - sorry, removed the old one for good from my add book. > -----Original Message----- > From: Jean-Francois Mule=20 > Sent: Wednesday, February 25, 2004 12:33 PM > To: ipcdn@ietf.org; 'randy_presuhn@bmc.com'; 'bwijnen@lucent.com' > Cc: 'Eugene Nechamkin'; Satish Kumar at Texas Instruments;=20 > PacketCable Provisioning and OSS Majordomo List > Subject: ipcdn MTA MIB: update of description clauses when=20 > secure SNMPv3 is not used >=20 >=20 > Folks, >=20 > Some operators are using SNMPv2c for MTA device management=20 > (and will continue to do so for some period of time). We've=20 > been discussing the impact that the unsecure SNMPv2 mgmt has=20 > on the MTA MIB with the PacketCable OSS vendor team. I would=20 > like to share some of our thoughts and our suggestions to=20 > make sure that we are doing the right thing and to that those=20 > proposed changes are sound and can later be reflected in the=20 > IETF ID mtamib draft 04. >=20 > Note that the IETF ID mtamib draft 03 does have a fairly=20 > detailed security consideration section and recommends the=20 > use of secure SNMPv3. Yet, the MIB module and its objects=20 > definitions assume v3 only and we've found that the=20 > implementers feel that there should be clear guidance when=20 > v2c mgmt is used. Some MIB objects don't mean anything when=20 > v2 is used (these objects are related to the key mgmt for the=20 > security relationship with the SNMP entity or prov server=20 > (pktcMtaDevProvSolicitedKeyTimeout and alike), or to key/hash=20 > values for the config file that are passed in secure v3 mode=20 > when the MTA enrollment mechanism is used=20 > (pktcMtaDevProvConfigKey), etc.=20 >=20 > At this point, our suggestions are as follows: > - maintain the compliance statements as-is, all MTAs will=20 > support SNMPv3 and when v3 is used, all the objects as=20 > defined in draft 03 make sense (at least, we think they do); > - define in our PacketCable MIB framework the mib views,=20 > access right for v2 mgmt, > - for the specific objects that do not mean anything in v2,=20 > enhance the DESCRIPTION clause to state what the device must=20 > do if v2 mgmt is used, that is, specify the MTA's behavior=20 > when receiving SNMPv2 SET & GET operations on those=20 > v3-specific objects. > - Suggestions: > add something like this in the impacted objects: > for pktcMtaDevProvConfigKey: > This object should not be used in non secure=20 > SNMPv3 modes. > In non secure SNMPv3 modes, the MTA MUST return an=20 > 'inconsistentValue' in response to SNMP SET operations,=20 > and the MTA MUST return a 'genErr' error in response to=20 > SNMP GET operations." > for pktcMtaDevProvConfigHash: > When the MTA SNMP Enrollment mechanism is not in use, the > hash value is provided in the configuration file itself=20 > and it is also calculated by the MTA. This object value > MUST represent the hash value calculated by the MTA. > When the MTA SNMP Enrollment mechanism is not in use, the > MTA must reject all SNMP SET operations on this=20 > object and > return an 'inconsistentValue' error. > These are just 2 examples but they basically say: > - if unsecure v2 is used, SNMP SET on the object =3D>=20 > 'inconsistentValue', SNMP GET =3D> 'genErr' > This seems to be consistent with RFC 3416 (one could argue=20 > that 'noAccess' could be returned as well). >=20 > Question: > Is this the proper way to do this to provide some info in the=20 > MIB module as our MTA implementers have been asking for? We=20 > plan on adding some more details on the VACM model (MIB=20 > views, access rights and object trees that cannot be accessed=20 > without the proper security policies. >=20 > Thanks in advance for any input on this, > Jean-Francois=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Feb 25 20:24: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 UAA28365 for ; Wed, 25 Feb 2004 20:24: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 1AwAFt-0007DO-7w for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 20:24:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1Q1O1Bw027730 for ipcdn-archive@odin.ietf.org; Wed, 25 Feb 2004 20:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAFs-0007D6-J8; Wed, 25 Feb 2004 20:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwAF5-0007Cb-5h for ipcdn@optimus.ietf.org; Wed, 25 Feb 2004 20:23:11 -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 UAA28350 for ; Wed, 25 Feb 2004 20:23:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwAF3-0000Zl-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 20:23:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwAE3-0000VK-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 20:22:07 -0500 Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx with esmtp (Exim 4.12) id 1AwADJ-0000RX-00 for ipcdn@ietf.org; Wed, 25 Feb 2004 20:21:21 -0500 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 25 Feb 2004 17:21:04 -0800 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 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 RAA09946; Wed, 25 Feb 2004 17:20:36 -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) ; Wed, 25 Feb 2004 17:21:08 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Wed, 25 Feb 2004 17:21:17 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2CE16@nt-rmna-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence are redundant thread-index: AcP70hhNL+TS/+hbTVeu5varyCBKZAAMLbZw From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 26 Feb 2004 01:21:09.0009 (UTC) FILETIME=[D03BD010:01C3FC06] X-WSS-ID: 6C23958A1MS1104650-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 pktcSigDevStandardRingCadence and pktcSigDevRingSplashCadence=20 > objects are redundant.=20 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 From exim@www1.ietf.org Fri Feb 27 17:01: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 RAA27086 for ; Fri, 27 Feb 2004 17:01:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq2c-0000I0-MO for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:01:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RM16i1001112 for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq2X-0000Ge-QW; Fri, 27 Feb 2004 17:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awq28-0000Es-Dd for ipcdn@optimus.ietf.org; Fri, 27 Feb 2004 17:00:36 -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 RAA27008 for ; Fri, 27 Feb 2004 17:00:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awq26-0004aG-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:00:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awq18-0004RB-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 16:59:34 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Awq0G-0004LC-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 16:58:41 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1RLwh5h026967 for ; Fri, 27 Feb 2004 14:58:43 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i1RLvNEp010956 for ; Fri, 27 Feb 2004 15:57:24 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Fri, 27 Feb 2004 13:58:37 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'Wim De Ketelaere'" , "'Eugene Nechamkin'" , ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Fri, 27 Feb 2004 13:58:37 -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: , 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 From exim@www1.ietf.org Fri Feb 27 17:15: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 RAA28125 for ; Fri, 27 Feb 2004 17:15: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 1AwqG9-0002dA-EW for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMF5LM010091 for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqG7-0002c4-31; Fri, 27 Feb 2004 17:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwqFp-0002bR-Kg for ipcdn@optimus.ietf.org; Fri, 27 Feb 2004 17:14:45 -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 RAA28110 for ; Fri, 27 Feb 2004 17:14:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqFn-0006SD-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:14:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwqEu-0006MU-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:13:49 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1AwqEL-0006G7-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:13:13 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 27 Feb 2004 14:13:07 -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 OAA13782; Fri, 27 Feb 2004 14:12:29 -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) ; Fri, 27 Feb 2004 14:13:02 -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: Fri, 27 Feb 2004 14:13:11 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2CE3A@nt-rmna-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant thread-index: AcP9fWV5sg4nyFKNQrKo3a9i5Pp8WgAAHvqg From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , "Wim De Ketelaere" , ipcdn@ietf.org X-OriginalArrivalTime: 27 Feb 2004 22:13:02.0269 (UTC) FILETIME=[DDA376D0:01C3FD7E] X-WSS-ID: 6C211F791NO1644015-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 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.=20 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 Fri Feb 27 17:48: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 RAA29901 for ; Fri, 27 Feb 2004 17:48: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 1Awqm2-0004W0-IB for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:48:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMm2xb017332 for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:48:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqm1-0004VO-SR; Fri, 27 Feb 2004 17: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 1Awqlz-0004Ut-7i for ipcdn@optimus.ietf.org; Fri, 27 Feb 2004 17:47:59 -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 RAA29875 for ; Fri, 27 Feb 2004 17:47:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Awqlw-0002ec-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:47:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awql2-0002Uy-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:47:01 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1AwqkL-0002N2-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:46:17 -0500 Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1RMkK5h011774 for ; Fri, 27 Feb 2004 15:46:20 -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 i1RMk1SZ003911 for ; Fri, 27 Feb 2004 16:46:02 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Fri, 27 Feb 2004 14:46:00 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'Eugene Nechamkin'" , Beacham Gordon-CGB005 , Wim De Ketelaere , ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Fri, 27 Feb 2004 14:45:53 -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: , 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 Fri Feb 27 17:53:27 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 RAA00358 for ; Fri, 27 Feb 2004 17:53: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 1Awqqq-0004qV-PX for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:53:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMr0Ur018572 for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqqq-0004pN-Ff; Fri, 27 Feb 2004 17: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 1AwqqV-0004ob-NN for ipcdn@optimus.ietf.org; Fri, 27 Feb 2004 17:52:39 -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 RAA00341 for ; Fri, 27 Feb 2004 17:52:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwqqT-0003QD-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqpa-0003Ju-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:51:43 -0500 Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx with esmtp (Exim 4.12) id 1Awqoh-000344-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:50:47 -0500 Received: from dlep91.itg.ti.com ([157.170.152.55]) by dragon.ti.com (8.12.11/8.12.11) with ESMTP id i1RMoGBC001802; Fri, 27 Feb 2004 16:50:16 -0600 (CST) Received: from dlee2k70.ent.ti.com (localhost [127.0.0.1]) by dlep91.itg.ti.com (8.12.10/8.12.10) with ESMTP id i1RMoFUf005259; Fri, 27 Feb 2004 16:50:15 -0600 (CST) Received: from dlee2k05.ent.ti.com ([157.170.152.114]) by dlee2k70.ent.ti.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 27 Feb 2004 16:50:15 -0600 x-mimeole: Produced By Microsoft Exchange V6.0.6510.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Date: Fri, 27 Feb 2004 16:50:15 -0600 Message-ID: Thread-Topic: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant Thread-Index: AcP9g8dG0HUZbJ4kRO63LVqMq6xGZgAAEYww From: "Kumar, Satish" To: "Beacham Gordon-CGB005" , "Eugene Nechamkin" , "Wim De Ketelaere" , X-OriginalArrivalTime: 27 Feb 2004 22:50:15.0356 (UTC) FILETIME=[10A97FC0:01C3FD84] 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 It would be better to mark the MIB with usage like E-Package or = L-package. This avoids possible confusion. -Satish -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: Friday, February 27, 2004 10:46 PM 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.=20 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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Feb 27 17:57:27 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 RAA00541 for ; Fri, 27 Feb 2004 17:57: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 1Awquj-0005Ro-1U for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:57:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RMv005020919 for ipcdn-archive@odin.ietf.org; Fri, 27 Feb 2004 17:57:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Awqui-0005RF-OB; Fri, 27 Feb 2004 17:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwquY-0005Lz-Pl for ipcdn@optimus.ietf.org; Fri, 27 Feb 2004 17:56:50 -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 RAA00519 for ; Fri, 27 Feb 2004 17:56:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwquW-0003sD-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:56:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Awqte-0003lW-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:55:55 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1Awqt7-0003eU-00 for ipcdn@ietf.org; Fri, 27 Feb 2004 17:55:21 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 27 Feb 2004 14:55:11 -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 OAA21113; Fri, 27 Feb 2004 14:54:33 -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) ; Fri, 27 Feb 2004 14:55:06 -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: Fri, 27 Feb 2004 14:55:16 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2CE3D@nt-rmna-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevStandardRingCadence and pktcSigDevRingSplas hCadence are redundant thread-index: AcP9g48gLI+oYCevSDSgKkrF7Cx8YwAADtUQ From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , "Wim De Ketelaere" , ipcdn@ietf.org X-OriginalArrivalTime: 27 Feb 2004 22:55:06.0112 (UTC) FILETIME=[BDF75800:01C3FD84] X-WSS-ID: 6C2115451NO1653889-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 As a reminder - "pktcSigDevRingCadenceTable" is currently defined as the = holder of all cadence related objects for the E-Package only, so it = cannot accommodate the L-package objects unless the definition of the = L-Package in the Euro-L-Package Document is properly changed. Eugene. -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: Friday, February 27, 2004 2:46 PM 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.=20 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