From mailman-bounces@ietf.org Fri Oct 1 07:43:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20480 for ; Fri, 1 Oct 2004 07:43:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CDLxs-00058w-Ic for ipcdn-archive@ietf.org; Fri, 01 Oct 2004 07:52:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CDJra-0002eW-5B for ipcdn-archive@ietf.org; Fri, 01 Oct 2004 05:38:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: ipcdn-archive@ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Oct 2004 05:16:04 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for ipcdn-archive@ietf.org: List Password // URL ---- -------- ipcdn@ietf.org ichuas https://www1.ietf.org/mailman/options/ipcdn/ipcdn-archive%40ietf.org From ipcdn-bounces@ietf.org Tue Oct 5 17:28:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13862 for ; Tue, 5 Oct 2004 17:28:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEx16-0008WU-Ef for ipcdn-archive@ietf.org; Tue, 05 Oct 2004 17:38:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEwq8-0003v8-Ry; Tue, 05 Oct 2004 17:27:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEwjK-00038G-DW for ipcdn@megatron.ietf.org; Tue, 05 Oct 2004 17:20:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13430 for ; Tue, 5 Oct 2004 17:20:16 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEwsg-0007Cm-2W for ipcdn@ietf.org; Tue, 05 Oct 2004 17:29:59 -0400 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 i95LJekH023336; Tue, 5 Oct 2004 15:19:41 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Date: Tue, 5 Oct 2004 15:19:40 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E97E@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Thread-Index: AcSrGjdqfn9mYsXqQ++EwKAmjJAQuAABjbig From: "Eduardo Cardona" To: "Steven M. Bellovin" , "Jean-Francois Mule" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org, Greg White , bwijnen@lucent.com, Oscar Marcia , Russ Housley , "Richard Woundy @ Comcast" , Eric Rosenfeld X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Thanks Steve, we will scope the text showing the lack of robustness for targeted attacks as you pointed, or even removing it on favor or a more encouraging text for stronger encryption. Thanks Eduardo -----Original Message----- From: Steven M. Bellovin [mailto:smb@research.att.com]=20 Sent: Tuesday, October 05, 2004 12:49 PM To: Jean-Francois Mule Cc: Russ Housley; bwijnen@lucent.com; ipcdn@ietf.org; Eduardo Cardona; Richard Woundy @ Comcast; Eric Rosenfeld; Oscar Marcia; Greg White Subject: Re: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14=20 That address most of my concerns. But I also said this: The Security Considerations section says =20 The time to crack DES could be additionally mitigated by a compromised value for the TEK lifetime and Grace Time (up to a minimum of 30 minutes for the TEK lifetime, see Appendix A [1]). =20 That's only partially correct. These keys are confidentiality keys;=20 they're still valuable even after they're no longer in active use,=20 because they can be used to decrypt old traffic. (By contrast, old=20 authentication keys are useless to an attacker.) =20 You need to strengthen your text; while frequent key changes help, an attacker can often select what to attack. For example, email checking is generally timer-driven; someone monitoring the link can easily spot an eamil session by noticing the periodicity. For example, in the middle of the night, when there's little email traffic (except, of course, for the daily spam load), there will be a set of very similar (in length and timing) packets in each direction, every N minutes, where N is probably in the range 5-15 minutes. Select the confidentiality key for this period, attack it, and recover the user's email password. For that attack, a key lifetime of 30 minutes or 30 days is the same -- it's a targeted attack. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 6 10:39:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02828 for ; Wed, 6 Oct 2004 10:39:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFD6e-000757-6l for ipcdn-archive@ietf.org; Wed, 06 Oct 2004 10:49:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFCtz-00007O-DL; Wed, 06 Oct 2004 10:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEvxH-00083I-Oa for ipcdn@megatron.ietf.org; Tue, 05 Oct 2004 16:30:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07745 for ; Tue, 5 Oct 2004 16:30:37 -0400 (EDT) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEw6c-0008Vb-Qt for ipcdn@ietf.org; Tue, 05 Oct 2004 16:40:20 -0400 Received: by machshav.com (Postfix, from userid 512) id F35C6FB257; Tue, 5 Oct 2004 20:30:35 +0000 (UTC) Received: from berkshire.research.att.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5FC59FB24D; Tue, 5 Oct 2004 20:30:32 +0000 (UTC) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id B79B21AEE4; Tue, 5 Oct 2004 14:48:56 -0400 (EDT) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: to-smb From: "Steven M. Bellovin" To: "Jean-Francois Mule" Subject: Re: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 In-Reply-To: Your message of "Fri, 24 Sep 2004 16:29:43 MDT." Mime-Version: 1.0 Content-Type: text/plain Date: Tue, 05 Oct 2004 14:48:56 -0400 Message-Id: <20041005184856.B79B21AEE4@berkshire.research.att.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Wed, 06 Oct 2004 10:36:21 -0400 Cc: ipcdn@ietf.org, Greg White , Eduardo Cardona , bwijnen@lucent.com, Oscar Marcia , Russ Housley , "Richard Woundy @ Comcast" , Eric Rosenfeld X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a That address most of my concerns. But I also said this: The Security Considerations section says The time to crack DES could be additionally mitigated by a compromised value for the TEK lifetime and Grace Time (up to a minimum of 30 minutes for the TEK lifetime, see Appendix A [1]). That's only partially correct. These keys are confidentiality keys; they're still valuable even after they're no longer in active use, because they can be used to decrypt old traffic. (By contrast, old authentication keys are useless to an attacker.) You need to strengthen your text; while frequent key changes help, an attacker can often select what to attack. For example, email checking is generally timer-driven; someone monitoring the link can easily spot an eamil session by noticing the periodicity. For example, in the middle of the night, when there's little email traffic (except, of course, for the daily spam load), there will be a set of very similar (in length and timing) packets in each direction, every N minutes, where N is probably in the range 5-15 minutes. Select the confidentiality key for this period, attack it, and recover the user's email password. For that attack, a key lifetime of 30 minutes or 30 days is the same -- it's a targeted attack. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 6 17:08:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14226 for ; Wed, 6 Oct 2004 17:08:21 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFJAv-0001mm-Vr for ipcdn-archive@ietf.org; Wed, 06 Oct 2004 17:18:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFIfO-0007Ha-Pj; Wed, 06 Oct 2004 16:45:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFHuP-0003rj-C4 for ipcdn@megatron.ietf.org; Wed, 06 Oct 2004 15:57:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00093 for ; Wed, 6 Oct 2004 15:57:07 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFI3u-0002Yp-Vx for ipcdn@ietf.org; Wed, 06 Oct 2004 16:07:02 -0400 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 i96JuWkH004524; Wed, 6 Oct 2004 13:56:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis Date: Wed, 6 Oct 2004 13:56:32 -0600 Message-ID: Thread-Topic: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis Thread-Index: AcSr3pOlXSLjo5geSsqj7YH6bRjMFw== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Cc: Eduardo Cardona , david.raftus@terayon.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable This note provides a brief status update on the ipcdn DOCSIS RFIv2 mib Internet-Draft. It is also a follow-up from the IETF meeting #60 in San Diego. --- Brief status The current ID is draft-ietf-ipcdn-docs-rfmibv2-11.=20 =20 ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt A working group last call was issued on 1/23/2004 and ended on 2/6/2004. The authors believe that draft 11 does address all the wg comments as well as AD review comments from Bert. Based on the input received this week from the authors and the current editor Eduardo, no new comments have been received since the ID was revised at the end of July 2004. --- San Diego wg meeting follow-up Based on our meeting minutes at http://www.ietf.org/proceedings/04aug/171.htm#rfimib , we wanted to ping the mailing list to see if another WGLC is needed. If you think a second WGLC should be issued, please let the ipcdn wg know by sending an email to the list by Wednesday October 13, 5pm ET. --- Next steps Pending wg consensus that a new WGLC is not needed and no objection to move this ID forward, it is the wg chairs intent to submit the ID for publication/IESG review to Bert. Rich and Jean-Francois. IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Oct 6 19:05:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27690 for ; Wed, 6 Oct 2004 19:05:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFL0X-0001we-RY for ipcdn-archive@ietf.org; Wed, 06 Oct 2004 19:15:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKp5-0005od-IH; Wed, 06 Oct 2004 19:03:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFKoW-0005cP-Ox for ipcdn@megatron.ietf.org; Wed, 06 Oct 2004 19:03:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27588 for ; Wed, 6 Oct 2004 19:03:13 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFKy6-0001sg-Ll for ipcdn@ietf.org; Wed, 06 Oct 2004 19:13:11 -0400 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 i96N2dkH013905; Wed, 6 Oct 2004 17:02:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Date: Wed, 6 Oct 2004 17:02:39 -0600 Message-ID: Thread-Topic: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Thread-Index: AcSjPw+50+RH77EWSeG7TSvaK+2yJAItaruQ From: "Jean-Francois Mule" To: "Russ Housley" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org, bwijnen@lucent.com, Eduardo Cardona , Greg White , Oscar Marcia , "Richard Woundy @ Comcast" , Eric Rosenfeld , "Steven M. Bellovin" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable See more inline, sorry for the delay in responding to you. > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Friday, September 24, 2004 4:41 PM > To: Jean-Francois Mule; Steven M. Bellovin;=20 > bwijnen@lucent.com; ipcdn@ietf.org > Cc: Eduardo Cardona; Greg White; Oscar Marcia; Richard Woundy=20 > @ Comcast; Eric Rosenfeld > Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 >=20 >=20 > Jean-Francois: >=20 > >--- 1. Syntax of docsBpi2CmPublicKey and range limitations: [snip], the proposed resolution on issue #1 was fine with you. > This is fine with me. > >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS > >BPI+ [snip] > > Symmetric encryption: > > AES (AES128CbcMode, AES256CbcMode), 3DES, DES > > ^^^ new addition, optional to support You wrote: > You need to specify a mode for 3DES too. It will probably be=20 > CBC like the=20 > rest of the algorithms you support. Yes. The following has been proposed: t3DES128EdeMode - equivalent to openssl's DES_ecb2_encrypt() two-key = Triple-DES ECB t3DES128CbcMode - equivalent to openssl's DES_ede2_cbc_encrypt() = two-key Triple-DES CBC PS: as a separate note, should the IETF be defining a set of crypto MIB = textual-conventions for the crypto libraries (like some of the ones in = the openssl lib http://www.openssl.org/docs/crypto/crypto.html)? [snip] > > Data integrity algorithms: > > SHA-1, SHA-256, MD5 > > ^ new addition, optional to support You wrote:=20 > I expected HMAC-SHA-1. This can be truncated as is done in=20 > IPsec. Look at=20 > the HMAC-SHA1-96 definition for an example. The following has been proposed: HMAC-SHA1-96 and HMAC-SHA1-128 > MD5 is certainly not a good thing to add at this point. Ok. This response should close all the comments received from Russ. Let us = know if this is good to go and we will draft the ID changes accordingly. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 7 09:38:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15750 for ; Thu, 7 Oct 2004 09:38:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFYdQ-0005GQ-5m for ipcdn-archive@ietf.org; Thu, 07 Oct 2004 09:48:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFYPH-0003wk-Ec; Thu, 07 Oct 2004 09:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFLCO-0002ob-He for ipcdn@megatron.ietf.org; Wed, 06 Oct 2004 19:27:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29068 for ; Wed, 6 Oct 2004 19:27:52 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFLLx-0003Ek-HH for ipcdn@ietf.org; Wed, 06 Oct 2004 19:37:51 -0400 Received: (qmail 15223 invoked by uid 0); 6 Oct 2004 23:27:45 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.221.254.66) by woodstock.binhost.com with SMTP; 6 Oct 2004 23:27:45 -0000 Message-Id: <6.1.2.0.2.20041006192237.08786820@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 06 Oct 2004 19:27:29 -0400 To: "Jean-Francois Mule" From: Russ Housley Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Thu, 07 Oct 2004 09:34:06 -0400 Cc: ipcdn@ietf.org, bwijnen@lucent.com, Eduardo Cardona , Greg White , Oscar Marcia , "Richard Woundy @ Comcast" , Eric Rosenfeld , "Steven M. Bellovin" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Jean-Francois: > > >--- 2. Lack of strong encryption & authentication mechanism in DOCSIS > > >BPI+ >[snip] > > > Symmetric encryption: > > > AES (AES128CbcMode, AES256CbcMode), 3DES, DES > > > ^^^ new addition, optional to support Fine. >You wrote: > > You need to specify a mode for 3DES too. It will probably be > > CBC like the > > rest of the algorithms you support. > >Yes. The following has been proposed: > t3DES128EdeMode - equivalent to openssl's DES_ecb2_encrypt() two-key > Triple-DES ECB > t3DES128CbcMode - equivalent to openssl's DES_ede2_cbc_encrypt() two-key > Triple-DES CBC I seriously doubt that t3DES128EdeMode is useful in this context. ECB had some properties that are probably bad in this environment. >PS: as a separate note, should the IETF be defining a set of crypto MIB >textual-conventions for the crypto libraries (like some of the ones in the >openssl lib http://www.openssl.org/docs/crypto/crypto.html)? I do not think this is needed. It certainly does not belong in this document. > > > Data integrity algorithms: > > > SHA-1, SHA-256, MD5 > > > ^ new addition, optional to support > > >You wrote: > > I expected HMAC-SHA-1. This can be truncated as is done in > > IPsec. Look at > > the HMAC-SHA1-96 definition for an example. > >The following has been proposed: >HMAC-SHA1-96 and HMAC-SHA1-128 Fine. > > MD5 is certainly not a good thing to add at this point. >Ok. Good. Russ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 7 17:57:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02197 for ; Thu, 7 Oct 2004 17:57:15 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFgQ0-0007Tf-P3 for ipcdn-archive@ietf.org; Thu, 07 Oct 2004 18:07:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFg84-0007Ag-UL; Thu, 07 Oct 2004 17:48:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFfop-0008KV-B1 for ipcdn@megatron.ietf.org; Thu, 07 Oct 2004 17:29:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29344 for ; Thu, 7 Oct 2004 17:28:56 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFfyb-0005pS-MH for ipcdn@ietf.org; Thu, 07 Oct 2004 17:39:06 -0400 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 i97LSOkH023954; Thu, 7 Oct 2004 15:28:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Date: Thu, 7 Oct 2004 15:28:23 -0600 Message-ID: Thread-Topic: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 Thread-Index: AcSr/CARucdzLV0YRuuYOnQUxCyfsgAtrivA From: "Jean-Francois Mule" To: "Russ Housley" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org, bwijnen@lucent.com, Eduardo Cardona , Greg White , Oscar Marcia , "Richard Woundy @ Comcast" , Eric Rosenfeld , "Steven M. Bellovin" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Russ wrote: > I seriously doubt that t3DES128EdeMode is useful in this=20 > context. ECB had=20 ^^^=20 you mean EDE here > some properties that are probably bad in this environment. Okay, we can remove it, no pb. Just fyi, 3DES EDE was also proposed because it is already used in the BPI+ spec for the traffic encryption key (TEK). See page 21 of BPI+ at http://www.cablemodem.com/downloads/specs/BPI+_I11-040407.pdf : "The traffic encryption key (TEK) in the Key Reply is triple DES (encrypt-decrypt-encrypt or EDE mode) encrypted, using a two-key, triple DES key encryption key (KEK) derived from the Authorization Key." This should close the threads on your comment - thank you again for the review.=20 Jean-Francois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 7 20:41:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19748 for ; Thu, 7 Oct 2004 20:41:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFiz0-0001bC-MR for ipcdn-archive@ietf.org; Thu, 07 Oct 2004 20:51:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFilh-00078y-40; Thu, 07 Oct 2004 20:37:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFif2-0005Ud-B8 for ipcdn@megatron.ietf.org; Thu, 07 Oct 2004 20:31:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18723 for ; Thu, 7 Oct 2004 20:31:02 -0400 (EDT) Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFioq-0000la-27 for ipcdn@ietf.org; Thu, 07 Oct 2004 20:41:12 -0400 Received: from dlep90.itg.ti.com ([157.170.152.54]) by dragon.ti.com (8.12.11/8.12.11) with ESMTP id i980UVXr020890; Thu, 7 Oct 2004 19:30:32 -0500 (CDT) Received: from dlee2k71.ent.ti.com (localhost [127.0.0.1]) by dlep90.itg.ti.com (8.12.11/8.12.11) with ESMTP id i980UVEQ028592; Thu, 7 Oct 2004 19:30:31 -0500 (CDT) Received: from dlee2k05.ent.ti.com ([157.170.152.114]) by dlee2k71.ent.ti.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 7 Oct 2004 19:30:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Oct 2004 19:30:31 -0500 Message-ID: Thread-Topic: Cadence description text Thread-Index: AcSmQic1DmLK8l5YRUKJ6ueaR9dCSwGipjBg From: "Kumar, Satish" To: "Beacham Gordon-CGB005" , X-OriginalArrivalTime: 08 Oct 2004 00:30:31.0737 (UTC) FILETIME=[04D2A290:01C4ACCE] X-Spam-Score: 0.8 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Subject: [ipcdn] Cadence description text X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0782993669==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. --===============0782993669== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4ACCE.04ABBCC1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4ACCE.04ABBCC1 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, The pktcRingCadence description has below text. =20 PktcRingCadence ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 " =20 This object represents a ring cadence and repeatable=20 Characteristics in a bit string format. The first two=20 octets of the bit string represent the length in bits of=20 the duration of the cadence (i.e., the number of bits that=20 follow the third octet). The third octet is used to=20 represent repeatable characteristics. 00000000 means=20 repeatable, and 10000000 means non repeatable. Each bit=20 after the third octet represents 50 ms and 1 represents=20 ring and 0 represents silent. The first bit of the fourth=20 octet is the first bit of the ring cadence. All bits are=20 counted in network order such that the octet with only the=20 first bit set will look like 10000000 bit sequence. A=20 total of 264 bits can be set to represent 13200 ms of=20 total cadence cycle. There will be at most 3 on/off=20 transitions per cadence period."=20 SYNTAX OCTET STRING (SIZE(4..36))=20 The text in red color above in description has no relevance to cadence type description. This is very confusing, and may lead to think that all cadences are not supposed to have more than 3 transition periods. I am proposing to remove this text. =20 Comments please =20 Thanks, Satish Kumar, Texaas Instruments =20 ------_=_NextPart_001_01C4ACCE.04ABBCC1 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Hi,
 The pktcRingCadence description has = below=20 text.
 
 PktcRingCadence   ::=3D=20 TEXTUAL-CONVENTION
      =20 STATUS        current=20
       DESCRIPTION=20
           "  =
           &nb= sp;=20 This object represents a ring cadence and repeatable=20
           &nb= sp;=20 Characteristics in a bit string format. The first two=20
           &nb= sp;=20 octets of the bit string represent the length in bits of=20
           &nb= sp; the=20 duration of the cadence (i.e., the number of bits that=20
           &nb= sp;=20 follow the third octet). The third octet is used to=20
           &nb= sp;=20 represent repeatable characteristics. 00000000 means=20
           &nb= sp;=20 repeatable, and 10000000 means non repeatable. Each bit=20
           &nb= sp;=20 after the third octet represents 50 ms and 1 represents=20
           &nb= sp;=20 ring and 0 represents silent. The first bit of the fourth=20
           &nb= sp;=20 octet is the first bit of the ring cadence. All bits are=20
           &nb= sp;=20 counted in network order such that the octet with only the=20
           &nb= sp;=20 first bit set will look like 10000000 bit sequence. A=20
           &nb= sp;=20 total of 264 bits can be set to represent 13200 ms of=20
           &nb= sp;=20 total cadence cycle. There will be at most 3 = on/off=20
           &nb= sp;=20 transitions per cadence period." =
      =20 SYNTAX  OCTET STRING (SIZE(4..36))
The text in red color above in description = has no=20 relevance to cadence type description. This is very confusing, and may = lead to=20 think that all cadences are not supposed to have more than 3 = transition=20 periods. I am proposing to remove this text.
 
Comments please
 
Thanks,
Satish Kumar,
Texaas Instruments
 

------_=_NextPart_001_01C4ACCE.04ABBCC1-- --===============0782993669== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0782993669==-- From ipcdn-bounces@ietf.org Fri Oct 8 08:46:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20457 for ; Fri, 8 Oct 2004 08:46:18 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CFuIS-0005sl-UJ for ipcdn-archive@ietf.org; Fri, 08 Oct 2004 08:56:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFu7u-0002Vt-47; Fri, 08 Oct 2004 08:45:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CFn6S-0001j3-MZ for ipcdn@megatron.ietf.org; Fri, 08 Oct 2004 01:15:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08418 for ; Fri, 8 Oct 2004 01:15:40 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.240.3]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CFnGJ-0006DW-Ag for ipcdn@ietf.org; Fri, 08 Oct 2004 01:25:51 -0400 Received: (qmail 30652 invoked by uid 0); 8 Oct 2004 05:15:24 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (64.221.254.66) by woodstock.binhost.com with SMTP; 8 Oct 2004 05:15:24 -0000 Message-Id: <6.1.2.0.2.20041008011232.03a95a70@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 08 Oct 2004 01:15:27 -0400 To: "Jean-Francois Mule" From: Russ Housley Subject: RE: [ipcdn] FW: DISCUSS: draft-ietf-ipcdn-bpiplus-mib-14 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.9 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Fri, 08 Oct 2004 08:45:35 -0400 Cc: ipcdn@ietf.org, bwijnen@lucent.com, Eduardo Cardona , Greg White , Oscar Marcia , "Richard Woundy @ Comcast" , Eric Rosenfeld , "Steven M. Bellovin" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Jean-Francois: > > I seriously doubt that t3DES128EdeMode is useful in this > > context. ECB had > ^^^ >you mean EDE here > > some properties that are probably bad in this environment. > >Okay, we can remove it, no pb. Okay. >Just fyi, 3DES EDE was also proposed because it is already used in the >BPI+ spec for the traffic encryption key (TEK). See page 21 of BPI+ at >http://www.cablemodem.com/downloads/specs/BPI+_I11-040407.pdf : >"The traffic encryption key (TEK) in the Key Reply is triple DES >(encrypt-decrypt-encrypt or EDE mode) encrypted, using a two-key, triple >DES key encryption key (KEK) derived from the Authorization Key." This is still a poor choice. See RFC 3217 and RFC 3394 for better solutions. Russ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Oct 11 09:37:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06142 for ; Mon, 11 Oct 2004 09:37:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0Xf-000886-Lb for ipcdn-archive@ietf.org; Mon, 11 Oct 2004 09:48:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0LG-00029T-Qq; Mon, 11 Oct 2004 09:35:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CH0Kr-00021q-Nq for ipcdn@megatron.ietf.org; Mon, 11 Oct 2004 09:35:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05858 for ; Mon, 11 Oct 2004 09:35:32 -0400 (EDT) Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CH0VO-00084I-Fu for ipcdn@ietf.org; Mon, 11 Oct 2004 09:46:27 -0400 Received: from comcast.net (h00045af3c79a.ne.client2.attbi.com[24.128.30.151]) by comcast.net (sccrmhc11) with SMTP id <2004101113345701100k48uue> (Authid: sawyerwd); Mon, 11 Oct 2004 13:35:01 +0000 Message-ID: <416A8C3F.111CAE79@comcast.net> Date: Mon, 11 Oct 2004 09:35:59 -0400 From: Wilson Sawyer X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ipcdn@ietf.org, bwijnen@lucent.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: housley@vigilsec.com Subject: [ipcdn] docsis subscriber management i-d draft -16 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit I've just submitted draft -16 to fix a couple of issues from the IESG review and to align the publication order with expected updates of RFC 2669 and 2670. The changes are: (1) References to RFC 2669 are changed to informative, and the corresponding RFC editor notes were removed. (2) The second paragraph of 'Security Considerations' was reworded per Russ Housley's suggestion. (3) The section reference in that same paragraph was fixed per Allison Mankin's note. (4) Editor notes w.r.t. successor of RFC 2670 were left in, as it is expected that submgt will be held until that successor is available. Respectfully submitted, Wilson Sawyer _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 12 17:17:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12277 for ; Tue, 12 Oct 2004 17:17:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CHUCL-0002oD-Hv for ipcdn-archive@ietf.org; Tue, 12 Oct 2004 17:28:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHTPw-0004b3-O6; Tue, 12 Oct 2004 16:38:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CHSw0-0001yk-DU; Tue, 12 Oct 2004 16:07:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27895; Tue, 12 Oct 2004 16:07:47 -0400 (EDT) Message-Id: <200410122007.QAA27895@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 12 Oct 2004 16:07:47 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-mib-16.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 --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-16.txt Pages : 26 Date : 2004-10-12 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. The Differentiated Services MIB (RFC 3289) provides the filtering functions needed here, making use of classification items defined in this specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-16.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-16.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-16.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-10-12160521.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-12160521.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Tue Oct 19 22:27:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17272 for ; Tue, 19 Oct 2004 22:27:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6OL-0003gN-N3 for ipcdn-archive@ietf.org; Tue, 19 Oct 2004 22:39:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4Dl-0004kT-FF; Tue, 19 Oct 2004 20:20:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJwDB-0005cX-Ei for ipcdn@megatron.ietf.org; Tue, 19 Oct 2004 11:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08761 for ; Tue, 19 Oct 2004 11:47:37 -0400 (EDT) Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJwPJ-0001Av-8x for ipcdn@ietf.org; Tue, 19 Oct 2004 12:00:18 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id i9JFoTTG012766 for ; Tue, 19 Oct 2004 08:50:29 -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 i9JFjDNM011612 for ; Tue, 19 Oct 2004 10:45:13 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Oct 2004 08:47:35 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'Kumar, Satish'" , ipcdn@ietf.org, "'sumanth@cablelabs.com'" Date: Tue, 19 Oct 2004 08:47:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.4 (++) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [ipcdn] RE: Cadence description text X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0157505849==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0157505849== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B5F2.F388CE1E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B5F2.F388CE1E Content-Type: text/plain Satish, I agree with your comment to remove the text. Gordon -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Thursday, October 07, 2004 5:31 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: Cadence description text Hi, The pktcRingCadence description has below text. PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " This object represents a ring cadence and repeatable Characteristics in a bit string format. The first two octets of the bit string represent the length in bits of the duration of the cadence (i.e., the number of bits that follow the third octet). 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. All bits are counted in network order such that the octet with only the first bit set will look like 10000000 bit sequence. A total of 264 bits can be set to represent 13200 ms of total cadence cycle. There will be at most 3 on/off transitions per cadence period." SYNTAX OCTET STRING (SIZE(4..36)) The text in red color above in description has no relevance to cadence type description. This is very confusing, and may lead to think that all cadences are not supposed to have more than 3 transition periods. I am proposing to remove this text. Comments please Thanks, Satish Kumar, Texaas Instruments ------_=_NextPart_001_01C4B5F2.F388CE1E Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0yMTUxMTI4MTUtMTkxMDIwMDQ+PEZP TlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0Kc2l6ZT0yPlNhdGlzaCwgPC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjE1MTEyODE1LTE5MTAyMDA0PjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0K PERJVj48U1BBTiBjbGFzcz0yMTUxMTI4MTUtMTkxMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIHNpemU9Mj5JIA0KYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnQgdG8gcmVtb3ZlIHRo ZSB0ZXh0LjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIGNsYXNzPTIxNTExMjgxNS0x OTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpzaXplPTI+PC9GT05UPjwv U1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9MjE1MTEyODE1LTE5MTAyMDA0PjxG T05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCnNpemU9Mj5Hb3Jkb248L0ZPTlQ+PC9TUEFO PjwvRElWPg0KPEJMT0NLUVVPVEUgc3R5bGU9Ik1BUkdJTi1SSUdIVDogMHB4Ij4NCiAgPERJVj48 L0RJVj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1s dHIgYWxpZ249bGVmdD48Rk9OVCANCiAgZmFjZT1UYWhvbWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBLdW1hciwgU2F0aXNoIA0KICBbbWFpbHRvOnNh dGlzaC5rdW1hckB0aS5jb21dIDxCUj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIE9jdG9iZXIgMDcs IDIwMDQgNTozMSANCiAgUE08QlI+PEI+VG86PC9CPiBCZWFjaGFtIEdvcmRvbi1DR0IwMDU7IGlw Y2RuQGlldGYub3JnPEJSPjxCPlN1YmplY3Q6PC9CPiANCiAgQ2FkZW5jZSBkZXNjcmlwdGlvbiB0 ZXh0PEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNzPTcxNzI2MjEw MC0wODEwMjAwND5IaSw8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFz cz03MTcyNjIxMDAtMDgxMDIwMDQ+Jm5ic3A7VGhlIHBrdGNSaW5nQ2FkZW5jZSBkZXNjcmlwdGlv biBoYXMgYmVsb3cgDQogIHRleHQuPC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJViBkaXI9bHRy IGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiAN CiAgY2xhc3M9NzE3MjYyMTAwLTA4MTAyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQog IDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWw+PFNQQU4gDQogIGNsYXNz PTcxNzI2MjEwMC0wODEwMjAwND4mbmJzcDtQa3RjUmluZ0NhZGVuY2UmbmJzcDsmbmJzcDsgOjo9 IA0KICBURVhUVUFMLUNPTlZFTlRJT04gPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgU1RBVFVTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGN1cnJlbnQgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg REVTQ1JJUFRJT04gDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIiZuYnNwOyANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAN CiAgVGhpcyBvYmplY3QgcmVwcmVzZW50cyBhIHJpbmcgY2FkZW5jZSBhbmQgcmVwZWF0YWJsZSAN CiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgQ2hhcmFjdGVyaXN0aWNzIGluIGEgYml0IHN0cmlu ZyBmb3JtYXQuIFRoZSBmaXJzdCB0d28gDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIG9jdGV0 cyBvZiB0aGUgYml0IHN0cmluZyByZXByZXNlbnQgdGhlIGxlbmd0aCBpbiBiaXRzIG9mIA0KICA8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB0aGUgZHVyYXRpb24gb2YgdGhlIGNhZGVuY2UgKGkuZS4s IHRoZSBudW1iZXIgb2YgYml0cyB0aGF0IA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBmb2xs b3cgdGhlIHRoaXJkIG9jdGV0KS4gVGhlIHRoaXJkIG9jdGV0IGlzIHVzZWQgdG8gDQogIDxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgDQogIHJlcHJlc2VudCByZXBlYXRhYmxlIGNoYXJhY3RlcmlzdGljcy4g MDAwMDAwMDAgbWVhbnMgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHJlcGVhdGFibGUsIGFu ZCAxMDAwMDAwMCBtZWFucyBub24gcmVwZWF0YWJsZS4gRWFjaCBiaXQgDQogIDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIGFmdGVyIHRoZSB0aGlyZCBvY3RldCByZXByZXNlbnRzIDUwIG1zIGFuZCAx IHJlcHJlc2VudHMgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHJpbmcgYW5kIDAgcmVwcmVz ZW50cyBzaWxlbnQuIFRoZSBmaXJzdCBiaXQgb2YgdGhlIGZvdXJ0aCANCiAgPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyANCiAgb2N0ZXQgaXMgdGhlIGZpcnN0IGJpdCBvZiB0aGUgcmluZyBjYWRlbmNlLiBB bGwgYml0cyBhcmUgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIGNvdW50ZWQgaW4gbmV0d29y ayBvcmRlciBzdWNoIHRoYXQgdGhlIG9jdGV0IHdpdGggb25seSB0aGUgDQogIDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgDQogIGZpcnN0IGJpdCBzZXQgd2lsbCBsb29rIGxpa2UgMTAwMDAwMDAgYml0IHNl cXVlbmNlLiBBIA0KICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICB0b3RhbCBvZiAyNjQgYml0cyBj YW4gYmUgc2V0IHRvIHJlcHJlc2VudCAxMzIwMCBtcyBvZiANCiAgPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyANCiAgdG90YWwgY2FkZW5jZSBjeWNsZS4gPEZPTlQgY29sb3I9I2ZmMDAwMD5UaGVyZSB3aWxs IGJlIGF0IG1vc3QgMyBvbi9vZmYgDQogIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHRyYW5zaXRp b25zIHBlciBjYWRlbmNlIHBlcmlvZC48L0ZPTlQ+IiANCiAgPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBTWU5UQVgmbmJzcDsgT0NURVQgU1RSSU5HIA0KICAoU0laRSg0 Li4zNikpIDxCUj48L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVm dD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz03 MTcyNjIxMDAtMDgxMDIwMDQ+VGhlIHRleHQgaW4gcmVkIGNvbG9yIGFib3ZlIGluIGRlc2NyaXB0 aW9uIGhhcyBubyANCiAgcmVsZXZhbmNlIHRvIGNhZGVuY2UgdHlwZSBkZXNjcmlwdGlvbi4gVGhp cyBpcyB2ZXJ5IGNvbmZ1c2luZywgYW5kIG1heSBsZWFkIHRvIA0KICB0aGluayB0aGF0Jm5ic3A7 YWxsIGNhZGVuY2VzIGFyZSBub3Qgc3VwcG9zZWQgdG8gaGF2ZSBtb3JlIHRoYW4gMyB0cmFuc2l0 aW9uIA0KICBwZXJpb2RzLiZuYnNwO0kgYW0gcHJvcG9zaW5nIHRvIHJlbW92ZSB0aGlzIHRleHQu PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NzE3MjYyMTAwLTA4 MTAyMDA0PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1s ZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQogIGNsYXNz PTcxNzI2MjEwMC0wODEwMjAwND5Db21tZW50cyBwbGVhc2U8L1NQQU4+PC9GT05UPjwvRElWPg0K ICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYg c2l6ZT0yPjxTUEFOIA0KICBjbGFzcz03MTcyNjIxMDAtMDgxMDIwMDQ+PC9TUEFOPjwvRk9OVD4m bmJzcDs8L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCiAgY2xhc3M9NzE3MjYyMTAwLTA4MTAyMDA0PlRo YW5rcyw8L1NQQU4+PC9GT05UPjwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9O VCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KICBjbGFzcz03MTcyNjIx MDAtMDgxMDIwMDQ+U2F0aXNoIEt1bWFyLDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogIDxESVYgZGly PWx0ciBhbGlnbj1sZWZ0PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gDQogIGNsYXNzPTcxNzI2MjEwMC0wODEwMjAwND5UZXhhYXMgSW5zdHJ1bWVudHM8L1NQQU4+ PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PC9GT05UPiZuYnNwOzwvRElWPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05UPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAw MDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQpz aXplPTI+PC9GT05UPjxCUj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C4B5F2.F388CE1E-- --===============0157505849== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0157505849==-- From ipcdn-bounces@ietf.org Tue Oct 19 22:27:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17276 for ; Tue, 19 Oct 2004 22:27:12 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6OM-0003gW-Qw for ipcdn-archive@ietf.org; Tue, 19 Oct 2004 22:39:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4Do-0004nF-VL; Tue, 19 Oct 2004 20:20:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJwDI-0005cp-2N for ipcdn@megatron.ietf.org; Tue, 19 Oct 2004 11:47:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08783 for ; Tue, 19 Oct 2004 11:47:44 -0400 (EDT) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJwPQ-0001Bb-0t for ipcdn@ietf.org; Tue, 19 Oct 2004 12:00:25 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i9JFliMO009039 for ; Tue, 19 Oct 2004 08:47:44 -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 i9JFdhtD007519 for ; Tue, 19 Oct 2004 10:39:43 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Oct 2004 08:47:42 -0700 Message-ID: From: Beacham Gordon-CGB005 To: ipcdn@ietf.org, "'sumanth@cablelabs.com'" Date: Tue, 19 Oct 2004 08:47:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 1.8 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [ipcdn] pktcSigPowerRingFrequency description change X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0915897366==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 1.9 (+) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0915897366== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B5F2.F8334840" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B5F2.F8334840 Content-Type: text/plain The following changes are recommended to the description of the pktcSigPowerRingFrequency object. delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. Gordon ------_=_NextPart_001_01C4B5F2.F8334840 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz0yMjg0MjI4MTUtMTkxMDIwMDQ+VGhlIGZvbGxvd2luZyANCmNoYW5nZXMgYXJlIHJlY29tbWVu ZGVkIHRvIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgPFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAx MnB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IEVOLVVTOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPnBrdGNTaWdQb3dlclJpbmdGcmVx dWVuY3k8U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PEZPTlQgZmFjZT1B cmlhbCANCnNpemU9Mj5vYmplY3Q8L0ZPTlQ+LjwvU1BBTj48L1NQQU4+PC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MjI4NDIyODE1 LTE5MTAyMDA0PjxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdU aW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5z aS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGkt bGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiANCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+PC9TUEFO PjwvU1BBTj48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFs IHNpemU9Mj48U1BBTiBjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+PFNQQU4gDQpzdHlsZT0iRk9O VC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28tYmlkaS1sYW5ndWFnZTogQVItU0EiPjxTUEFOIA0Kc3R5 bGU9Im1zby1zcGFjZXJ1bjogeWVzIj5kZWxldGU6Jm5ic3A7PEZPTlQgZmFjZT0iQ291cmllciBO ZXciPkRFRlZBTCB7IGYyMEh6IA0KfTw/eG1sOm5hbWVzcGFjZSBwcmVmaXggPSBvIG5zID0gInVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgDQovPjxvOnA+PC9vOnA+PC9G T05UPjwvU1BBTj48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MjI4NDIyODE1LTE5MTAyMDA0PjxTUEFOIA0Kc3R5bGU9 IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFy ZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1m YXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiAN CnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+YWRkOiBUaGlzIGRlZmF1bHQgdmFsdWUgZm9yIHRo aXMgb2JqZWN0IE1VU1QgDQpiZSZuYnNwOzxTUEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsg Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog QmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBF Ti1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj5mMjBIeiANCmZvciBNVEFzIGNvbXBsaWFu dCB0byA8U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+PFNQQU4gDQpzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTog J1RpbWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1h bnNpLWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28tYmlk aS1sYW5ndWFnZTogQVItU0EiPjxTUEFOIA0KY2xhc3M9MjI4NDIyODE1LTE5MTAyMDA0Pls8L1NQ QU4+UEtULVNQLU1JQi1TSUc8U1BBTiBjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+XS4gDQpUaGUg ZGVmYXVsdCB2YWx1ZSBmb3IgdGhpcyBvYmplY3QgTVVTVCBiZSA8U1BBTiANCnN0eWxlPSJGT05U LVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+ZjI1SHogDQpmb3Ig TVRBcyBjb21wbGlhbnQgdG8gDQo8L1NQQU4+PC9TUEFOPjwvU1BBTj48L1NQQU4+PC9TUEFOPjwv U1BBTj48L1NQQU4+PC9TUEFOPjwvRk9OVD48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7 IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTog RU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+W0lUVS1ULUoxNjldPFNQQU4gDQpjbGFz cz0yMjg0MjI4MTUtMTkxMDIwMDQ+LjwvU1BBTj48L1NQQU4+PC9ESVY+DQo8RElWPjxTUEFOIA0K c3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBt c28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7 IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48 U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBB Ui1TQSI+PFNQQU4gDQpjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+PEZPTlQgZmFjZT1BcmlhbCAN CnNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWPjxT UEFOIA0Kc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t YW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTog RU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFS LVNBIj48U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMg TmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFu Z3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1 YWdlOiBBUi1TQSI+PFNQQU4gDQpjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+PEZPTlQgZmFjZT1B cmlhbCANCnNpemU9Mj5Hb3Jkb248L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L1NQQU4+PC9ESVY+PC9C T0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C4B5F2.F8334840-- --===============0915897366== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0915897366==-- From ipcdn-bounces@ietf.org Tue Oct 19 22:28:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17464 for ; Tue, 19 Oct 2004 22:28:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CK6PN-0003kM-EM for ipcdn-archive@ietf.org; Tue, 19 Oct 2004 22:41:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CK4EY-00057V-Ql; Tue, 19 Oct 2004 20:21:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CJwNL-0006hn-2G for ipcdn@megatron.ietf.org; Tue, 19 Oct 2004 11:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09886 for ; Tue, 19 Oct 2004 11:58:07 -0400 (EDT) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CJwZS-0001ZC-WF for ipcdn@ietf.org; Tue, 19 Oct 2004 12:10:48 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id i9JFxRG2002627 for ; Tue, 19 Oct 2004 08:59:27 -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 i9JFw5Lw032277 for ; Tue, 19 Oct 2004 10:58:06 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Tue, 19 Oct 2004 08:58:05 -0700 Message-ID: From: Beacham Gordon-CGB005 To: Beacham Gordon-CGB005 , "'ipcdn@ietf.org'" , "'sumanth@cablelabs.com'" Date: Tue, 19 Oct 2004 08:58:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Subject: [ipcdn] RE: pktcSigPowerRingFrequency description change X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1347830148==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1347830148== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B5F4.6ACD2FFA" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B5F4.6ACD2FFA Content-Type: text/plain Slight grammar fix: Change first "This" to "The" in first "add:" sentence. Gordon -----Original Message----- From: Beacham Gordon-CGB005 Sent: Tuesday, October 19, 2004 8:48 AM To: ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: pktcSigPowerRingFrequency description change The following changes are recommended to the description of the pktcSigPowerRingFrequency object. delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. Gordon ------_=_NextPart_001_01C4B5F4.6ACD2FFA Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSANCiJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmlj ZTpvZmZpY2UiPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5U PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExFPg0K DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NTgiIG5hbWU9R0VORVJBVE9SPjwv SEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz0zMTI1NzU2MTUtMTkxMDIwMDQ+PEZPTlQg ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj5TbGlnaHQgDQpncmFtbWFyIGZpeDogQ2hh bmdlIGZpcnN0ICJUaGlzIiB0byAiVGhlIiBpbiBmaXJzdCAiYWRkOiIgc2VudGVuY2UuIA0KR29y ZG9uPC9GT05UPjwvU1BBTj48L0RJVj4NCjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJ Ti1SSUdIVDogMHB4Ij4NCiAgPERJVj48L0RJVj4NCiAgPERJViBjbGFzcz1PdXRsb29rTWVzc2Fn ZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD48Rk9OVCANCiAgZmFjZT1UYWhv bWEgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPjxCPkZyb206PC9CPiBCZWFj aGFtIA0KICBHb3Jkb24tQ0dCMDA1IDxCUj48Qj5TZW50OjwvQj4gVHVlc2RheSwgT2N0b2JlciAx OSwgMjAwNCA4OjQ4IEFNPEJSPjxCPlRvOjwvQj4gDQogIGlwY2RuQGlldGYub3JnOyAnc3VtYW50 aEBjYWJsZWxhYnMuY29tJzxCUj48Qj5TdWJqZWN0OjwvQj4gDQogIHBrdGNTaWdQb3dlclJpbmdG cmVxdWVuY3kgZGVzY3JpcHRpb24gY2hhbmdlPEJSPjxCUj48L0ZPTlQ+PC9ESVY+DQogIDxESVY+ PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gY2xhc3M9MjI4NDIyODE1LTE5MTAyMDA0PlRo ZSBmb2xsb3dpbmcgDQogIGNoYW5nZXMgYXJlIHJlY29tbWVuZGVkIHRvIHRoZSBkZXNjcmlwdGlv biBvZiB0aGUgPFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAn VGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFu c2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRp LWxhbmd1YWdlOiBBUi1TQSI+cGt0Y1NpZ1Bvd2VyUmluZ0ZyZXF1ZW5jeTxTUEFOIA0KICBzdHls ZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj5v YmplY3Q8L0ZPTlQ+LjwvU1BBTj48L1NQQU4+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgPERJVj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+PFNQ QU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv bWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6 IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBB Ui1TQSI+PFNQQU4gDQogIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+PC9TUEFOPjwvU1BBTj48 L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y PjxTUEFOIGNsYXNzPTIyODQyMjgxNS0xOTEwMjAwND48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0la RTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250 LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxh bmd1YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiANCiAgc3R5bGU9 Im1zby1zcGFjZXJ1bjogeWVzIj5kZWxldGU6Jm5ic3A7PEZPTlQgZmFjZT0iQ291cmllciBOZXci PkRFRlZBTCB7IGYyMEh6IA0KICB9PG86cD48L286cD48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L1NQ QU4+PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNs YXNzPTIyODQyMjgxNS0xOTEwMjAwND48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsg Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog QmF0YW5nOyBtc28tYW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBF Ti1VUzsgbXNvLWJpZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiANCiAgc3R5bGU9Im1zby1zcGFj ZXJ1bjogeWVzIj5hZGQ6IFRoaXMgZGVmYXVsdCB2YWx1ZSBmb3IgdGhpcyBvYmplY3QgTVVTVCAN CiAgYmUmbmJzcDs8U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28t YW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJp ZGktbGFuZ3VhZ2U6IEFSLVNBIj5mMjBIeiANCiAgZm9yIE1UQXMgY29tcGxpYW50IHRvIDxTUEFO IA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h bic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxhbmd1YWdlOiBF Ti1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28tYmlkaS1sYW5ndWFnZTogQVIt U0EiPjxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ1RpbWVz IE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNpLWxh bmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28tYmlkaS1sYW5n dWFnZTogQVItU0EiPjxTUEFOIA0KICBjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+WzwvU1BBTj5Q S1QtU1AtTUlCLVNJRzxTUEFOIA0KICBjbGFzcz0yMjg0MjI4MTUtMTkxMDIwMDQ+XS4gVGhlIGRl ZmF1bHQgdmFsdWUgZm9yIHRoaXMgb2JqZWN0IE1VU1QgYmUgPFNQQU4gDQogIHN0eWxlPSJGT05U LVNJWkU6IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFz dC1sYW5ndWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+ZjI1SHogDQogIGZv ciBNVEFzIGNvbXBsaWFudCB0byANCiAgPC9TUEFOPjwvU1BBTj48L1NQQU4+PC9TUEFOPjwvU1BB Tj48L1NQQU4+PC9TUEFOPjwvU1BBTj48L0ZPTlQ+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6 IDEycHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5n dWFnZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+W0lUVS1ULUoxNjldPFNQQU4g DQogIGNsYXNzPTIyODQyMjgxNS0xOTEwMjAwND4uPC9TUEFOPjwvU1BBTj48L0RJVj4NCiAgPERJ Vj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6ICdUaW1lcyBO ZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28tYW5zaS1sYW5n dWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJpZGktbGFuZ3Vh Z2U6IEFSLVNBIj48U1BBTiANCiAgc3R5bGU9IkZPTlQtU0laRTogMTJwdDsgRk9OVC1GQU1JTFk6 ICdUaW1lcyBOZXcgUm9tYW4nOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTogQmF0YW5nOyBtc28t YW5zaS1sYW5ndWFnZTogRU4tVVM7IG1zby1mYXJlYXN0LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWJp ZGktbGFuZ3VhZ2U6IEFSLVNBIj48U1BBTiANCiAgY2xhc3M9MjI4NDIyODE1LTE5MTAyMDA0PjxG T05UIGZhY2U9QXJpYWwgDQogIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvU1BBTj48L1NQQU4+Jm5i c3A7PC9ESVY+DQogIDxESVY+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQt RkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFu ZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7 IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PFNQQU4gDQogIHN0eWxlPSJGT05ULVNJWkU6IDEy cHQ7IEZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6IEJhdGFuZzsgbXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFn ZTogRU4tVVM7IG1zby1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PFNQQU4gDQogIGNsYXNzPTIyODQy MjgxNS0xOTEwMjAwND48Rk9OVCBmYWNlPUFyaWFsIA0KICBzaXplPTI+R29yZG9uPC9GT05UPjwv U1BBTj48L1NQQU4+PC9TUEFOPjwvRElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C4B5F4.6ACD2FFA-- --===============1347830148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1347830148==-- From ipcdn-bounces@ietf.org Wed Oct 20 05:43:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15358 for ; Wed, 20 Oct 2004 05:43:37 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKDCl-00047g-DJ for ipcdn-archive@ietf.org; Wed, 20 Oct 2004 05:56:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKBbJ-0005Ss-0k; Wed, 20 Oct 2004 04:13:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKAMb-0006wz-RB for ipcdn@megatron.ietf.org; Wed, 20 Oct 2004 02:54:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05223 for ; Wed, 20 Oct 2004 02:54:19 -0400 (EDT) Received: from asia.telenet-ops.be ([195.130.132.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKAYr-0000yT-BJ for ipcdn@ietf.org; Wed, 20 Oct 2004 03:07:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by asia.telenet-ops.be (Postfix) with SMTP id C7E1137F0E for ; Wed, 20 Oct 2004 08:54:16 +0200 (MEST) Received: from tcomlabs.com (D5E00496.kabel.telenet.be [213.224.4.150]) by asia.telenet-ops.be (Postfix) with ESMTP id 745FD37F3E for ; Wed, 20 Oct 2004 08:54:16 +0200 (MEST) Received: (qmail 16822 invoked from network); 20 Oct 2004 08:54:16 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 20 Oct 2004 08:54:16 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Wed, 20 Oct 2004 08:54:16 +0200 (CEST) From: "David De Reu" To: Date: Wed, 20 Oct 2004 08:54:15 +0200 Message-ID: MIME-Version: 1.0 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.4942.400 Importance: Normal In-Reply-To: X-Spam-Score: 0.4 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Subject: [ipcdn] RE: Cadence description text X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1917500251==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 This is a multi-part message in MIME format. --===============1917500251== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C4B682.60D45B70" This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C4B682.60D45B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MessageDear all, I agree as well. Regards, David -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Beacham Gordon-CGB005 Sent: dinsdag 19 oktober 2004 17:48 To: 'Kumar, Satish'; ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: [ipcdn] RE: Cadence description text Satish, I agree with your comment to remove the text. Gordon -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Thursday, October 07, 2004 5:31 PM To: Beacham Gordon-CGB005; ipcdn@ietf.org Subject: Cadence description text Hi, The pktcRingCadence description has below text. PktcRingCadence ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " This object represents a ring cadence and repeatable Characteristics in a bit string format. The first two octets of the bit string represent the length in bits of the duration of the cadence (i.e., the number of bits that follow the third octet). 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. All bits are counted in network order such that the octet with only the first bit set will look like 10000000 bit sequence. A total of 264 bits can be set to represent 13200 ms of total cadence cycle. There will be at most 3 on/off transitions per cadence period." SYNTAX OCTET STRING (SIZE(4..36)) The text in red color above in description has no relevance to cadence type description. This is very confusing, and may lead to think that all cadences are not supposed to have more than 3 transition periods. I am proposing to remove this text. Comments please Thanks, Satish Kumar, Texaas Instruments ------=_NextPart_000_0015_01C4B682.60D45B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Dear=20 all,
 
I=20 agree as well.
 
Regards,
 
David
 
 
-----Original Message-----
From: = ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org]On Behalf Of Beacham=20 Gordon-CGB005
Sent: dinsdag 19 oktober 2004 = 17:48
To:=20 'Kumar, Satish'; ipcdn@ietf.org; = 'sumanth@cablelabs.com'
Subject:=20 [ipcdn] RE: Cadence description text

Satish,
 
I=20 agree with your comment to remove the text.
 
Gordon
-----Original Message-----
From: = Kumar, Satish=20 [mailto:satish.kumar@ti.com]
Sent: Thursday, October 07, = 2004=20 5:31 PM
To: Beacham Gordon-CGB005;=20 ipcdn@ietf.org
Subject: Cadence description=20 text

Hi,
 The pktcRingCadence description has = below=20 text.
 
 PktcRingCadence   ::=3D=20 TEXTUAL-CONVENTION
      =20 STATUS        current=20
       DESCRIPTION=20
           = " =20 =
           &nb= sp;=20 This object represents a ring cadence and repeatable=20 =
           &nb= sp;=20 Characteristics in a bit string format. The first two=20 =
           &nb= sp;=20 octets of the bit string represent the length in bits of=20 =
           &nb= sp;=20 the duration of the cadence (i.e., the number of bits that=20 =
           &nb= sp;=20 follow the third octet). The third octet is used to=20 =
           &nb= sp;=20 represent repeatable characteristics. 00000000 means=20 =
           &nb= sp;=20 repeatable, and 10000000 means non repeatable. Each bit=20 =
           &nb= sp;=20 after the third octet represents 50 ms and 1 represents=20 =
           &nb= sp;=20 ring and 0 represents silent. The first bit of the fourth=20 =
           &nb= sp;=20 octet is the first bit of the ring cadence. All bits are=20 =
           &nb= sp;=20 counted in network order such that the octet with only the=20 =
           &nb= sp;=20 first bit set will look like 10000000 bit sequence. A=20 =
           &nb= sp;=20 total of 264 bits can be set to represent 13200 ms of=20 =
           &nb= sp;=20 total cadence cycle. There will be at most 3 = on/off=20 =
           &nb= sp;=20 transitions per cadence period."=20
       SYNTAX  OCTET STRING=20 (SIZE(4..36))
The text in red color above in = description has no=20 relevance to cadence type description. This is very confusing, and = may lead=20 to think that all cadences are not supposed to have more than 3 = transition periods. I am proposing to remove this=20 text.
 
Comments please
 
Thanks,
Satish Kumar,
Texaas Instruments
 

------=_NextPart_000_0015_01C4B682.60D45B70-- --===============1917500251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1917500251==-- From ipcdn-bounces@ietf.org Thu Oct 21 07:42:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06092 for ; Thu, 21 Oct 2004 07:42:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbXW-0005XD-R5 for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 07:55:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKUNS-0000XN-Qz; Thu, 21 Oct 2004 00:16:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKbd-00081T-Pn for ipcdn@megatron.ietf.org; Wed, 20 Oct 2004 13:50:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02130 for ; Wed, 20 Oct 2004 13:50:35 -0400 (EDT) Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKKo2-0007Jm-Mw for ipcdn@ietf.org; Wed, 20 Oct 2004 14:03:29 -0400 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 20 Oct 2004 10:50:19 -0700 X-Server-Uuid: 062D48FB-9769-4139-967C-478C67B5F9C9 Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA04613; Wed, 20 Oct 2004 10:50:23 -0700 (PDT) Received: from nt-sjca-0741.brcm.ad.broadcom.com ([10.16.192.42]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 10:50:16 -0700 Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 10:50:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Date: Wed, 20 Oct 2004 10:50:14 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E765E5@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigPowerRingFrequency description change Thread-Index: AcS2TIhpM6T2w8YbQNucXiwdH6FliAAfPfqg From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org, sumanth@cablelabs.com X-OriginalArrivalTime: 20 Oct 2004 17:50:16.0377 (UTC) FILETIME=[41EC4290:01C4B6CD] X-WSS-ID: 6D687AD11TG10162327-01-01 X-Spam-Score: 0.2 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1332695258==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. --===============1332695258== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6CD.40C4B89F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B6CD.40C4B89F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable =20 While not disagreeing with the proposal to delete the DEFVAL clause from the MIB Object definition, I am not completely comfortable with the fact that IETF MIB draft would make a reference to the document ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC (or soon thereafter). Besides, I am not sure to which extent the mentioning of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is unambigous. Not sure presisely what this "compliency" means. What's the intention here - to say that for MTAs compliant with NorthAmerican-PC the defval should be f20 but for MTAs compliant with Euro-PC the defval should be f25Hz ? I think the reference to the compliency should be made less ambiguous.=20 =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Tuesday, October 19, 2004 8:48 AM To: ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: [ipcdn] pktcSigPowerRingFrequency description change The following changes are recommended to the description of the pktcSigPowerRingFrequency object. =20 delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. =20 Gordon ------_=_NextPart_001_01C4B6CD.40C4B89F Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
 
While not disagreeing with the proposal to = delete the=20 DEFVAL clause from the MIB Object definition, I am not completely = comfortable=20 with the fact that IETF MIB draft would make a reference to the document = ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC (or = soon=20 thereafter). Besides, I am not sure to which extent the mentioning of = compliency=20 with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is unambigous. Not = sure=20 presisely what this "compliency" means. What's the intention here - to = say that=20 for MTAs compliant with NorthAmerican-PC the defval should be f20 but = for MTAs=20 compliant with Euro-PC the defval should be f25Hz ? I = think the=20 reference to the compliency should be made less ambiguous. =
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Tuesday, October 19, 2004 8:48 = AM
To:=20 ipcdn@ietf.org; 'sumanth@cablelabs.com'
Subject: [ipcdn]=20 pktcSigPowerRingFrequency description change

The = following=20 changes are recommended to the description of the pktcSigPowerRingFrequency object.
 
delete: DEFVAL { f20Hz=20 }
add: This default value for this object MUST = be f20Hz=20 for MTAs compliant to [PKT-SP-MIB-SIG].=20 The default value for this object MUST be f25Hz=20 for MTAs compliant to=20 [ITU-T-J169].
 
Gordon
------_=_NextPart_001_01C4B6CD.40C4B89F-- --===============1332695258== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1332695258==-- From ipcdn-bounces@ietf.org Thu Oct 21 07:45:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06617 for ; Thu, 21 Oct 2004 07:45:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbau-0005hY-LI for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 07:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKalg-0005Ae-NO; Thu, 21 Oct 2004 07:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKKoc-0001ZA-4j for ipcdn@megatron.ietf.org; Wed, 20 Oct 2004 14:04:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03592 for ; Wed, 20 Oct 2004 14:03:55 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKL0x-0007jo-S9 for ipcdn@ietf.org; Wed, 20 Oct 2004 14:16:49 -0400 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 i9KI3C1e028968; Wed, 20 Oct 2004 12:03:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Date: Wed, 20 Oct 2004 12:03:12 -0600 Message-ID: Thread-Topic: [ipcdn] pktcSigPowerRingFrequency description change Thread-Index: AcS2TIhpM6T2w8YbQNucXiwdH6FliAAfPfqgAAEsCjA= From: "Sumanth Channabasappa" To: "Eugene Nechamkin" , "Beacham Gordon-CGB005" , X-Approved: ondar X-Spam-Score: 0.4 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1336710350==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b This is a multi-part message in MIME format. --===============1336710350== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6CF.10A6BA52" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B6CF.10A6BA52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Eugene, =20 =20 How about: =20 "The default value for this object is dependent on the primary usage area of the device. For devices compliant with PacketCable (North America) it MUST be set to f20Hz and for devices compliant with IPCablecom (Europe) it MUST be set to f25Hz." =20 =20 Sumanth -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Wednesday, October 20, 2004 11:50 AM To: Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth Channabasappa Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 =20 While not disagreeing with the proposal to delete the DEFVAL clause from the MIB Object definition, I am not completely comfortable with the fact that IETF MIB draft would make a reference to the document ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC (or soon thereafter). Besides, I am not sure to which extent the mentioning of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is unambigous. Not sure presisely what this "compliency" means. What's the intention here - to say that for MTAs compliant with NorthAmerican-PC the defval should be f20 but for MTAs compliant with Euro-PC the defval should be f25Hz ? I think the reference to the compliency should be made less ambiguous.=20 =20 Eugene. _____ =20 From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Tuesday, October 19, 2004 8:48 AM To: ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 The following changes are recommended to the description of the pktcSigPowerRingFrequency object. =20 delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. =20 Gordon ------_=_NextPart_001_01C4B6CF.10A6BA52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Eugene,
 
 
How=20 about:
 
"The=20 default value for this object is dependent on the primary usage area of = the=20 device. For devices compliant with PacketCable (North America) =  it=20 MUST be set to f20Hz and for devices compliant with IPCablecom (Europe)  it MUST be set to=20 f25Hz."
 
 
Sumanth
-----Original Message-----
From: = Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Wednesday, October = 20, 2004=20 11:50 AM
To: Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth=20 Channabasappa
Subject: RE: [ipcdn] pktcSigPowerRingFrequency = description change

 
While not disagreeing with the proposal to = delete the=20 DEFVAL clause from the MIB Object definition, I am not completely = comfortable=20 with the fact that IETF MIB draft would make a reference to the = document=20 ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC = (or soon=20 thereafter). Besides, I am not sure to which extent the mentioning of=20 compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is = unambigous.=20 Not sure presisely what this "compliency" means. What's the intention = here -=20 to say that for MTAs compliant with NorthAmerican-PC the defval should = be f20=20 but for MTAs compliant with Euro-PC the defval should be f25Hz ?=20 I think the reference to the compliency should be made less = ambiguous.=20
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Tuesday, October 19, 2004 8:48 = AM
To:=20 ipcdn@ietf.org; 'sumanth@cablelabs.com'
Subject: [ipcdn]=20 pktcSigPowerRingFrequency description change

The = following=20 changes are recommended to the description of the pktcSigPowerRingFrequency object.
 
delete: DEFVAL { f20Hz=20 }
add: This default value for this object = MUST=20 be f20Hz=20 for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST = be f25Hz=20 for MTAs compliant to=20 [ITU-T-J169].
 
Gordon
------_=_NextPart_001_01C4B6CF.10A6BA52-- --===============1336710350== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1336710350==-- From ipcdn-bounces@ietf.org Thu Oct 21 07:56:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09055 for ; Thu, 21 Oct 2004 07:56:43 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKblI-0006Ur-EW for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 08:09:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKamz-0007qT-OK; Thu, 21 Oct 2004 07:07:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKLUv-00019a-Fl for ipcdn@megatron.ietf.org; Wed, 20 Oct 2004 14:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09128 for ; Wed, 20 Oct 2004 14:47:37 -0400 (EDT) Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKLhG-0000tY-IY for ipcdn@ietf.org; Wed, 20 Oct 2004 15:00:32 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 20 Oct 2004 11:46:34 -0700 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA20770; Wed, 20 Oct 2004 11:46:38 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 20 Oct 2004 11:46:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Date: Wed, 20 Oct 2004 11:46:30 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E765EA@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigPowerRingFrequency description change Thread-Index: AcS2TIhpM6T2w8YbQNucXiwdH6FliAAfPfqgAAEsCjAAAak58A== From: "Eugene Nechamkin" To: "Sumanth Channabasappa" , "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 20 Oct 2004 18:46:31.0627 (UTC) FILETIME=[1DBA89B0:01C4B6D5] X-WSS-ID: 6D686D002C011584370-01-01 X-Spam-Score: 0.4 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0194720540==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 This is a multi-part message in MIME format. --===============0194720540== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B6D5.1CE65151" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B6D5.1CE65151 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Yes, this addresses my conserns. =20 Eugene. ________________________________ From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Wednesday, October 20, 2004 11:03 AM To: Eugene Nechamkin; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Hi Eugene, =20 =20 How about: =20 "The default value for this object is dependent on the primary usage area of the device. For devices compliant with PacketCable (North America) it MUST be set to f20Hz and for devices compliant with IPCablecom (Europe) it MUST be set to f25Hz." =20 =20 Sumanth -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Wednesday, October 20, 2004 11:50 AM To: Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth Channabasappa Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 =20 While not disagreeing with the proposal to delete the DEFVAL clause from the MIB Object definition, I am not completely comfortable with the fact that IETF MIB draft would make a reference to the document ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC (or soon thereafter). Besides, I am not sure to which extent the mentioning of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is unambigous. Not sure presisely what this "compliency" means. What's the intention here - to say that for MTAs compliant with NorthAmerican-PC the defval should be f20 but for MTAs compliant with Euro-PC the defval should be f25Hz ? I think the reference to the compliency should be made less ambiguous.=20 =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Tuesday, October 19, 2004 8:48 AM To: ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 The following changes are recommended to the description of the pktcSigPowerRingFrequency object. =20 delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. =20 Gordon ------_=_NextPart_001_01C4B6D5.1CE65151 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
Yes, this addresses my = conserns.
 
Eugene.

From: Sumanth Channabasappa=20 [mailto:sumanth@cablelabs.com]
Sent: Wednesday, October 20, = 2004=20 11:03 AM
To: Eugene Nechamkin; Beacham Gordon-CGB005;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] pktcSigPowerRingFrequency=20 description change

Hi=20 Eugene,
 
 
How=20 about:
 
"The=20 default value for this object is dependent on the primary usage area of = the=20 device. For devices compliant with PacketCable (North America) =  it=20 MUST be set to f20Hz and for devices compliant with IPCablecom (Europe)  it MUST be set to=20 f25Hz."
 
 
Sumanth
-----Original Message-----
From: = Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Wednesday, October = 20, 2004=20 11:50 AM
To: Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth=20 Channabasappa
Subject: RE: [ipcdn] pktcSigPowerRingFrequency = description change

 
While not disagreeing with the proposal to = delete the=20 DEFVAL clause from the MIB Object definition, I am not completely = comfortable=20 with the fact that IETF MIB draft would make a reference to the = document=20 ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC = (or soon=20 thereafter). Besides, I am not sure to which extent the mentioning of=20 compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is = unambigous.=20 Not sure presisely what this "compliency" means. What's the intention = here -=20 to say that for MTAs compliant with NorthAmerican-PC the defval should = be f20=20 but for MTAs compliant with Euro-PC the defval should be f25Hz ?=20 I think the reference to the compliency should be made less = ambiguous.=20
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Tuesday, October 19, 2004 8:48 = AM
To:=20 ipcdn@ietf.org; 'sumanth@cablelabs.com'
Subject: [ipcdn]=20 pktcSigPowerRingFrequency description change

The = following=20 changes are recommended to the description of the pktcSigPowerRingFrequency object.
 
delete: DEFVAL { f20Hz=20 }
add: This default value for this object = MUST=20 be f20Hz=20 for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST = be f25Hz=20 for MTAs compliant to=20 [ITU-T-J169].
 
Gordon
------_=_NextPart_001_01C4B6D5.1CE65151-- --===============0194720540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0194720540==-- From ipcdn-bounces@ietf.org Thu Oct 21 08:46:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19275 for ; Thu, 21 Oct 2004 08:46:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcX8-0000Xu-Op for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 08:59:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbM7-0001UN-SA; Thu, 21 Oct 2004 07:43:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKVwc-0004Ty-AQ for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 01:57:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28193 for ; Thu, 21 Oct 2004 01:56:55 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKW95-00070H-FQ for ipcdn@ietf.org; Thu, 21 Oct 2004 02:09:56 -0400 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 i9L5uL1e021122; Wed, 20 Oct 2004 23:56:22 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Date: Wed, 20 Oct 2004 23:56:21 -0600 Message-ID: Thread-Topic: [ipcdn] pktcSigPowerRingFrequency description change Thread-Index: AcS2TIhpM6T2w8YbQNucXiwdH6FliAAfPfqgAAEsCjAAAak58AAXStCw From: "Sumanth Channabasappa" To: "Eugene Nechamkin" , "Beacham Gordon-CGB005" , X-Approved: ondar X-Spam-Score: 0.4 (/) X-Scan-Signature: ba231eeb0ba293f319cac22693e776bc X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1871530117==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 34a12386bc31e4adf7d931eae58f5833 This is a multi-part message in MIME format. --===============1871530117== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B732.B09CE68D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B732.B09CE68D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I was looking at some of the comments regarding 'pktcRingCadence' and would like to propose the following text: =20 (This also takes care of removing the text initially proposed by Satish to which others, including myself agree to.) =20 "This object provides an encoding scheme for ring cadences, including repeatability characteristics.=20 =20 The first three octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50 milliseconds. A bit value of '1' indicates the presence of a ring-tone and a bit value of '0' indicates the absence of a ring-tone, for that duration (50 ms). This entire bit-string MUST be placed using network-byte order and encoded as octets that preserve that ordering. =20 The first two of the reserved octets indicate the length of the encoded 'bit-string' and MUST range between 1 and 264. (Note: The length MUST also be consistent with the number of octets that encode the cadence). The third of the reserved octets indicates 'repeatability' and MUST support only the values 0x80 or 0x00 - the former value indicating 'repeatability' and the latter indicating 'non-repeatability'. =20 The MTA MUST reject attempts to set any values which violate the above requirements." =20 =20 It is currently described as: =20 " This object represents a ring cadence and repeatable characteristics in bit string format. The first two octets of the bit string represent the bit-length of the duration of the cadence (i.e., the number of bits that follow the third octet). The first two octets MUST represent a value between 1 and 264. Any other values MUST be rejected. The bit count needs to be consistent with the OCTET STRING's length. If there are unused octets, the SNMP set MUST be rejected. If the length implied by the bit count is greater than the OCTET STRING's length the SNMP set MUST be rejected. The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. The value of the repeatable field MUST be 0x00 or 0x80. Each bit after the third octet corresponds to 50 ms where 1 represents ring and 0 represents silence. The first bit of the fourth octet is the first bit of the ring cadence. All bits are counted in network order such that the octet with only the first bit set will look like 10000000 bit sequence. A total of 264 bits can be set to represent 13200 ms of total cadence cycle. There will be at most 3 on/off transitions per cadence cycle. If there are more than three on-to-off transitions, the SNMP set MUST be rejected. " =20 =20 Comments? =20 Thanks Sumanth =20 =20 =20 -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Wednesday, October 20, 2004 12:47 PM To: Sumanth Channabasappa; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 Yes, this addresses my conserns. =20 Eugene. _____ =20 From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Wednesday, October 20, 2004 11:03 AM To: Eugene Nechamkin; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 Hi Eugene, =20 =20 How about: =20 "The default value for this object is dependent on the primary usage area of the device. For devices compliant with PacketCable (North America) it MUST be set to f20Hz and for devices compliant with IPCablecom (Europe) it MUST be set to f25Hz." =20 =20 Sumanth -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Wednesday, October 20, 2004 11:50 AM To: Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth Channabasappa Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 =20 While not disagreeing with the proposal to delete the DEFVAL clause from the MIB Object definition, I am not completely comfortable with the fact that IETF MIB draft would make a reference to the document ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC (or soon thereafter). Besides, I am not sure to which extent the mentioning of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is unambigous. Not sure presisely what this "compliency" means. What's the intention here - to say that for MTAs compliant with NorthAmerican-PC the defval should be f20 but for MTAs compliant with Euro-PC the defval should be f25Hz ? I think the reference to the compliency should be made less ambiguous.=20 =20 Eugene. _____ =20 From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Tuesday, October 19, 2004 8:48 AM To: ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 The following changes are recommended to the description of the pktcSigPowerRingFrequency object. =20 delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. =20 Gordon ------_=_NextPart_001_01C4B732.B09CE68D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I was=20 looking at some of the comments regarding 'pktcRingCadence' and would = like to=20 propose the following text:
 
(This=20 also takes care of removing the text initially proposed by Satish to = which=20 others, including myself agree to.)
 

"This object provides an encoding scheme for ring cadences, = including=20 repeatability characteristics.

 

The first three octets are reserved. The octets that follow are = used to=20 encode a 'bit-string', with each bit corresponding to 50 milliseconds. A = bit=20 value of '1' indicates the presence of a ring-tone and a bit value of = '0'=20 indicates the absence of a ring-tone, for that duration (50 ms). This = entire=20 bit-string MUST be placed using network-byte order and encoded as octets = that=20 preserve that ordering.

 

The first two of the reserved octets indicate the length of the = encoded=20 'bit-string' and MUST range between 1 and 264. (Note: The length MUST = also be=20 consistent with the number of octets that encode the cadence). The third = of the=20 reserved octets indicates 'repeatability' and MUST support only the = values 0x80=20 or 0x00 - the former value indicating 'repeatability' and the latter = indicating=20 'non-repeatability'.

 

The MTA MUST reject attempts to set any values which violate = the above=20 requirements."

 

 

It = is currently=20 described as:

 

"

This object=20 represents a ring cadence and repeatable

characteristics=20 in bit string format. The first two

octets of the=20 bit string represent the bit-length  of

the duration of=20 the cadence (i.e., the number of bits that

follow the third=20 octet). The first two octets MUST

represent a=20 value between 1 and 264. Any other values MUST

be = rejected. The=20 bit count needs to be consistent with the

OCTET STRING's=20 length. If there are unused octets, the SNMP

set MUST be=20 rejected. If the length implied by the bit

count is greater=20 than the OCTET STRING's length the SNMP

set MUST be=20 rejected. The third octet is used to

represent=20 repeatable characteristics. 00000000 means

repeatable, and=20 10000000 means non repeatable. The value of

the repeatable=20 field MUST be 0x00 or 0x80. Each bit

after the third=20 octet corresponds to 50 ms where 1

represents ring=20 and 0 represents silence. The first bit of

the fourth octet=20 is the first bit of the ring cadence. All

bits are counted=20 in network order such that the octet with

only the first=20 bit set will look like 10000000 bit

sequence. A=20 total of 264 bits can be set to represent

13200 ms of=20 total cadence cycle. There will = be at most=20 3

on/off = transitions per=20 cadence cycle. If there are more

than three = on-to-off=20 transitions, the SNMP set MUST be

rejected. = "

 

 

Comments?

 

Thanks

Sumanth

 

 

 

=
-----Original Message-----
From: = Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Wednesday, October = 20, 2004=20 12:47 PM
To: Sumanth Channabasappa; Beacham Gordon-CGB005;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] = pktcSigPowerRingFrequency=20 description change

Yes, this addresses my = conserns.
 
Eugene.

From: Sumanth Channabasappa=20 [mailto:sumanth@cablelabs.com]
Sent: Wednesday, October 20, = 2004=20 11:03 AM
To: Eugene Nechamkin; Beacham Gordon-CGB005;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] = pktcSigPowerRingFrequency=20 description change

Hi=20 Eugene,
 
 
How=20 about:
 
"The=20 default value for this object is dependent on the primary usage area = of the=20 device. For devices compliant with PacketCable (North America) =  it=20 MUST be set to f20Hz and for devices compliant with IPCablecom (Europe)  it MUST be set to = f25Hz."
 
 
Sumanth
-----Original Message-----
From: = Eugene=20 Nechamkin [mailto:enechamkin@broadcom.com]
Sent: = Wednesday,=20 October 20, 2004 11:50 AM
To: Beacham Gordon-CGB005;=20 ipcdn@ietf.org; Sumanth Channabasappa
Subject: RE: [ipcdn] = pktcSigPowerRingFrequency description change

 
While not disagreeing with the proposal to = delete the=20 DEFVAL clause from the MIB Object definition, I am not completely=20 comfortable with the fact that IETF MIB draft would make a reference = to the=20 document ([PKT-SP-MIB-SIG]) which will be obsolete when draft = becomes an RFC=20 (or soon thereafter). Besides, I am not sure to which extent the = mentioning=20 of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is=20 unambigous. Not sure presisely what this "compliency" means. What's = the=20 intention here - to say that for MTAs compliant with = NorthAmerican-PC the=20 defval should be f20 but for MTAs compliant with Euro-PC the defval = should=20 be f25Hz ? I think the reference to the compliency = should be made=20 less ambiguous.
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Tuesday, October 19, 2004 8:48=20 AM
To: ipcdn@ietf.org; = 'sumanth@cablelabs.com'
Subject:=20 [ipcdn] pktcSigPowerRingFrequency description = change

The following=20 changes are recommended to the description of the pktcSigPowerRingFrequency object.
 
delete: DEFVAL {=20 f20Hz }
add: This default value for this object = MUST=20 be f20Hz=20 for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST = be f25Hz=20 for MTAs compliant to=20 [ITU-T-J169].
 
Gordon
------_=_NextPart_001_01C4B732.B09CE68D-- --===============1871530117== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1871530117==-- From ipcdn-bounces@ietf.org Thu Oct 21 09:23:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26923 for ; Thu, 21 Oct 2004 09:23:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKd7V-0002Qd-Hf for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 09:36:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcd0-0001iR-MX; Thu, 21 Oct 2004 09:05:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKbfe-0006EJ-NS for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 08:03:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11312 for ; Thu, 21 Oct 2004 08:03:53 -0400 (EDT) Received: from skutsje.san.webweaving.org ([209.132.96.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKbsF-0006wd-6C for ipcdn@ietf.org; Thu, 21 Oct 2004 08:16:56 -0400 Received: from localhost (localhost [127.0.0.1]) by skutsje.san.webweaving.org (8.12.9/8.12.9) with SMTP id i9LC2mFB091446; Thu, 21 Oct 2004 05:02:49 -0700 (PDT) (envelope-from harrie@inet.it) X-Authentication-Warning: skutsje.san.webweaving.org: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <4177A5A2.4090306@inet.it> Date: Thu, 21 Oct 2004 14:03:46 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sumanth Channabasappa Subject: Re: [ipcdn] pktcSigPowerRingFrequency description change References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: Eugene Nechamkin , Beacham Gordon-CGB005 , ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Hi, Sumanth Channabasappa wrote: > Hi Eugene, > > > How about: > > "The default value for this object is dependent on the primary usage > area of the device. For devices compliant with PacketCable (North > America) it MUST be set to f20Hz and for devices compliant with > IPCablecom (Europe) it MUST be set to f25Hz." I am not sure if it is a good idea to make a description like this. How about an 'IPCableCom (planet mars)' if there would be such a thing? I would suggest to add in the description of some common known usages, but not defining it formal. That is what is proposed above, but you already do make a 'REFERENCE' for frequency ranges per country as defined in EN 300 001. I would change the description saying that the default is defined on a per country basis or something similar. Harrie (member of the MIB review team) > > > Sumanth > > -----Original Message----- > *From:* Eugene Nechamkin [mailto:enechamkin@broadcom.com] > *Sent:* Wednesday, October 20, 2004 11:50 AM > *To:* Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth Channabasappa > *Subject:* RE: [ipcdn] pktcSigPowerRingFrequency description change > > > While not disagreeing with the proposal to delete the DEFVAL clause > from the MIB Object definition, I am not completely comfortable with > the fact that IETF MIB draft would make a reference to the document > ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC > (or soon thereafter). Besides, I am not sure to which extent the > mentioning of compliency with the [PKT-SP-MIB-SIG] or with the > [ITU-T-J169] is unambigous. Not sure presisely what this > "compliency" means. What's the intention here - to say that for MTAs > compliant with NorthAmerican-PC the defval should be f20 but for > MTAs compliant with Euro-PC the defval should be f25Hz ? I think the > reference to the compliency should be made less ambiguous. > > Eugene. > > ------------------------------------------------------------------------ > *From:* ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] *On > Behalf Of *Beacham Gordon-CGB005 > *Sent:* Tuesday, October 19, 2004 8:48 AM > *To:* ipcdn@ietf.org; 'sumanth@cablelabs.com' > *Subject:* [ipcdn] pktcSigPowerRingFrequency description change > > The following changes are recommended to the description of the > pktcSigPowerRingFrequency object. > > delete: DEFVAL { f20Hz } > add: This default value for this object MUST be f20Hz for MTAs > compliant to [PKT-SP-MIB-SIG]. The default value for this object > MUST be f25Hz for MTAs compliant to [ITU-T-J169]. > > Gordon > > > ------------------------------------------------------------------------ > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 09:37:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28386 for ; Thu, 21 Oct 2004 09:37:09 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKdKX-0002qY-O9 for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 09:50:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcrR-0002Mv-Fz; Thu, 21 Oct 2004 09:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKcOH-0003hS-Cu for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 08:50:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20137 for ; Thu, 21 Oct 2004 08:49:59 -0400 (EDT) Received: from skutsje.san.webweaving.org ([209.132.96.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKcas-0000mU-Ij for ipcdn@ietf.org; Thu, 21 Oct 2004 09:03:04 -0400 Received: from localhost (localhost [127.0.0.1]) by skutsje.san.webweaving.org (8.12.9/8.12.9) with SMTP id i9LCn0FB092870; Thu, 21 Oct 2004 05:49:00 -0700 (PDT) (envelope-from harrie@inet.it) X-Authentication-Warning: skutsje.san.webweaving.org: localhost [127.0.0.1] didn't use HELO protocol Message-ID: <4177B076.8010807@inet.it> Date: Thu, 21 Oct 2004 14:49:58 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sumanth Channabasappa Subject: Re: [ipcdn] pktcSigPowerRingFrequency description change References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Sumanth Channabasappa wrote: > Hi, > > I was looking at some of the comments regarding 'pktcRingCadence' and > would like to propose the following text: Not sure, if this is regarding the same description as before?? If not, I strongly suggest to start a new thread for that. That would help the discussion and seperate easier issues resolved and issues open. regards, Harrie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 14:04:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00141 for ; Thu, 21 Oct 2004 14:04:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhV9-0001km-PC for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 14:17:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh01-0005xr-Pm; Thu, 21 Oct 2004 13:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgqH-0007KW-EW for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 13:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26441 for ; Thu, 21 Oct 2004 13:35:09 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKh2v-0000gm-Bk for ipcdn@ietf.org; Thu, 21 Oct 2004 13:48:18 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKgqD-0001zN-00 for ipcdn@ietf.org; Thu, 21 Oct 2004 10:35:10 -0700 Message-ID: <005f01c4b794$6b6d8940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcSigPowerRingFrequency description change Date: Thu, 21 Oct 2004 10:35:55 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - > From: "Sumanth Channabasappa" > To: "Eugene Nechamkin" ; "Beacham Gordon-CGB005" ; > Sent: Wednesday, October 20, 2004 11:03 AM > Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change ... > How about: > > "The default value for this object is dependent on the primary usage > area of the device. For devices compliant with PacketCable (North > America) it MUST be set to f20Hz and for devices compliant with > IPCablecom (Europe) it MUST be set to f25Hz." ... In addition to Harrie's point about whether this is an exhaustive list of possibilities, note that these MUSTs impose a *stronger* conformance requirement than the original DEFVAL. 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. That's a *lot* weaker than a MUST in the DESCRIPTION clause. Now if that's what the group wants to do, fine. I just want to be sure it's a conscious decision. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 14:06:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00435 for ; Thu, 21 Oct 2004 14:06:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhXY-0001on-5z for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 14:19:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKh47-0008ER-EY; Thu, 21 Oct 2004 13:49:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKgwn-0003m2-0Z for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 13:41:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27695 for ; Thu, 21 Oct 2004 13:41:55 -0400 (EDT) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKh9R-00012l-Te for ipcdn@ietf.org; Thu, 21 Oct 2004 13:55:02 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKgwi-000429-00 for ipcdn@ietf.org; Thu, 21 Oct 2004 10:41:52 -0700 Message-ID: <007401c4b795$5ba88f40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] pktcSigPowerRingFrequency description change Date: Thu, 21 Oct 2004 10:42:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Hi - > From: "Sumanth Channabasappa" > To: "Eugene Nechamkin" ; "Beacham Gordon-CGB005" ; > Sent: Wednesday, October 20, 2004 10:56 PM > Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change ... > I was looking at some of the comments regarding 'pktcRingCadence' and > would like to propose the following text: ... > "This object provides an encoding scheme for ring cadences, including > repeatability characteristics. > > > > The first three octets are reserved. The octets that follow are used to > encode a 'bit-string', with each bit corresponding to 50 milliseconds. A > bit value of '1' indicates the presence of a ring-tone and a bit value > of '0' indicates the absence of a ring-tone, for that duration (50 ms). > This entire bit-string MUST be placed using network-byte order and > encoded as octets that preserve that ordering. "placed"? Also what value do the one to seven bits after the first bit-count bits have? must they be set to any particular value? on a get, do they need to have the same value that they were set to? > The first two of the reserved octets indicate the length of the encoded > 'bit-string' and MUST range between 1 and 264. (Note: The length MUST > also be consistent with the number of octets that encode the cadence). Which octet is high order, which is low order? Suggest adding "in bits" before "and MUST". > The third of the reserved octets indicates 'repeatability' and MUST > support only the values 0x80 or 0x00 - the former value indicating > 'repeatability' and the latter indicating 'non-repeatability'. ... Instead of "support only the values", suggest "be either" Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 14:32:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03164 for ; Thu, 21 Oct 2004 14:32:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhwJ-0002c1-3i for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 14:45:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhNW-00026j-7M; Thu, 21 Oct 2004 14:09:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhKJ-0000Rk-VN for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 14:06:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00383 for ; Thu, 21 Oct 2004 14:06:13 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhWv-0001n8-EI for ipcdn@ietf.org; Thu, 21 Oct 2004 14:19:20 -0400 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 i9LI5Z1e028165 for ; Thu, 21 Oct 2004 12:05:35 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Date: Thu, 21 Oct 2004 12:05:35 -0600 Message-ID: Thread-Topic: [ipcdn] pktcSigPowerRingFrequency description change Thread-Index: AcS3ZgQ/nNrs4hzhQ6u2SzTnbLpj1QAMXdmA From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Hi Harrie, I think it is a worthwhile suggestion.=20 How about - Remove DEFVAL and add: "The default value for this object is dependent on the primary usage area of the device. For example: Devices compliant with PacketCable (North America) require a default value of f20Hz; devices=20 compliant with IPCablecom (Europe) require a default value of f25Hz." Sumanth Hi, Sumanth Channabasappa wrote: > Hi Eugene, > =20 > =20 > How about: > =20 > "The default value for this object is dependent on the primary usage > area of the device. For devices compliant with PacketCable (North=20 > America) it MUST be set to f20Hz and for devices compliant with=20 > IPCablecom (Europe) it MUST be set to f25Hz." I am not sure if it is a good idea to make a description like this. How about an 'IPCableCom (planet mars)' if there would be such a thing? I would suggest to add in the description of some common known usages, but not defining it formal. That is what is proposed above, but you already do make a 'REFERENCE' for frequency ranges per country as defined in EN 300 001. I would change the description saying that the default is defined on a per country basis or something similar. Harrie (member of the MIB review team) > =20 > =20 > Sumanth >=20 > -----Original Message----- > *From:* Eugene Nechamkin [mailto:enechamkin@broadcom.com] > *Sent:* Wednesday, October 20, 2004 11:50 AM > *To:* Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth Channabasappa > *Subject:* RE: [ipcdn] pktcSigPowerRingFrequency description=20 > change >=20 > =20 > While not disagreeing with the proposal to delete the DEFVAL clause > from the MIB Object definition, I am not completely comfortable with > the fact that IETF MIB draft would make a reference to the document > ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC > (or soon thereafter). Besides, I am not sure to which extent the > mentioning of compliency with the [PKT-SP-MIB-SIG] or with the > [ITU-T-J169] is unambigous. Not sure presisely what this > "compliency" means. What's the intention here - to say that for MTAs > compliant with NorthAmerican-PC the defval should be f20 but for > MTAs compliant with Euro-PC the defval should be f25Hz ? I think the > reference to the compliency should be made less ambiguous. > =20 > Eugene. >=20 > ------------------------------------------------------------------------ > *From:* ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] *On > Behalf Of *Beacham Gordon-CGB005 > *Sent:* Tuesday, October 19, 2004 8:48 AM > *To:* ipcdn@ietf.org; 'sumanth@cablelabs.com' > *Subject:* [ipcdn] pktcSigPowerRingFrequency description change >=20 > The following changes are recommended to the description of the > pktcSigPowerRingFrequency object. > =20 > delete: DEFVAL { f20Hz } > add: This default value for this object MUST be f20Hz for MTAs > compliant to [PKT-SP-MIB-SIG]. The default value for this object > MUST be f25Hz for MTAs compliant to [ITU-T-J169]. > =20 > Gordon >=20 >=20 > ---------------------------------------------------------------------- > -- >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 14:56:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05678 for ; Thu, 21 Oct 2004 14:56:00 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiJ8-0003L6-Uj for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 15:09:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhm9-00054N-NE; Thu, 21 Oct 2004 14:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhYZ-0007bm-AP for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 14:20:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02031 for ; Thu, 21 Oct 2004 14:20:57 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhlD-0002G2-6Z for ipcdn@ietf.org; Thu, 21 Oct 2004 14:34:04 -0400 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 i9LIKO1e001350 for ; Thu, 21 Oct 2004 12:20:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Sig-Draft: pktcRingCadence description change Date: Thu, 21 Oct 2004 12:20:24 -0600 Message-ID: Thread-Topic: [ipcdn] Sig-Draft: pktcRingCadence description change Thread-Index: AcS3mMiIxgxOvWQDTMOTMCjBkt27YAAABXLg From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Thanks Randy (And the subject has been change, thanks Harrie!)=20 Ok, how about: pktcRingCadence "This object provides an encoding scheme for ring cadences, including=20 repeatability characteristics. All octets and bit-strings in this object MUST be encoded in network-byte order. ^ | Introduced network-byte order Added ordering | V The first three higher order octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50=20 milliseconds. A bit value of '1' indicates the presence of a ring-tone=20 and a bit value of '0' indicates the absence of a ring-tone, for that=20 duration (50 ms).=20 The first two of the reserved octets MUST indicate the length of the=20 encoded cadence (in bits) and MUST range between 1 and 264. (Note: The=20 length in bits MUST also be consistent with the number of octets that=20 encode the cadence.). The third of the reserved octets indicates 'repeatability' and MUST=20 be either 0x80 or 0x00 - the former value indicating=20 'repeatability' and the latter indicating 'non-repeatability'. ^ | Accepted suggestions. The MTA MUST reject attempts to set any values which violate the above=20 requirements." Thoughts? Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 14:57:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05802 for ; Thu, 21 Oct 2004 14:57:03 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiKA-0003NI-S7 for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 15:10:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhmE-000587-RO; Thu, 21 Oct 2004 14:35:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhbb-00008J-Sx for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 14:24:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02387 for ; Thu, 21 Oct 2004 14:24:05 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKhoF-0002Lu-Nq for ipcdn@ietf.org; Thu, 21 Oct 2004 14:37:13 -0400 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 i9LINW1e002134 for ; Thu, 21 Oct 2004 12:23:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Oct 2004 12:23:32 -0600 Message-ID: Thread-Topic: IETF NCS Sig MIB draft 6 -> Issue with E package requirements Thread-Index: AcS3ZgQ/nNrs4hzhQ6u2SzTnbLpj1QAMTLoQ From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with E package requirements X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Hi All, I agree with one of David's old comments to replace 'E Package' with 'International Systems'. Comments?=20 Thanks Sumanth MSG Reference: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01381.html (Reproduced below) Dear all, In the DESCRIPTION of a number of MIB objects, the term "international systems" has been replaced by "E package" in draft 6. This introduces the side-effect that a number of MIB objects that have nothing to do with E package support, now only have to be supported when the E package is supported. The following MIB objects are the ones I believe have nothing to do with the E package, since the caller ID and VMWI transmissions are triggered using the L package: pktcSigDevCIDMode pktcSigDevCIDFskAfterRing pktcSigDevCIDFskAfterDTAS pktcSigDevCIDFskAfterRPAS pktcSigDevCIDRingAfterFSK pktcSigDevCIDDTASAfterLR pktcSigDevVmwiFskAfterDTAS pktcSigDevVmwiFskAfterRPAS pktcSigDevVmwiDTASAfterLR An MTA for the international market that does however not support the E package, will want to support the above MIB objects. Maybe we can revert to the description of "international systems"? Thanks, Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 ? 9000 Ghent ? Belgium Tel: +32 9 269 22 91 ? Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 15:16:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08645 for ; Thu, 21 Oct 2004 15:16:57 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKidQ-0003uR-Qe for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 15:30:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiBQ-0004WB-7O; Thu, 21 Oct 2004 15:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKhtX-0007fk-CN for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 14:42:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04565 for ; Thu, 21 Oct 2004 14:42:37 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKi6B-0002yd-Qg for ipcdn@ietf.org; Thu, 21 Oct 2004 14:55:45 -0400 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 i9LIg51e006790 for ; Thu, 21 Oct 2004 12:42:05 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Sig-Draft: pktcRingCadence description change Date: Thu, 21 Oct 2004 12:42:05 -0600 Message-ID: Thread-Topic: [ipcdn] Sig-Draft: pktcRingCadence description change Thread-Index: AcS3mMiIxgxOvWQDTMOTMCjBkt27YAAABXLgAAEld/A= From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Hi all, A few more additions based on other comments: pktcRingCadence=20 "This object provides an encoding scheme for ring cadences, including=20 repeatability characteristics. All octets and bit-strings in this object MUST be encoded in network-byte order. The first three higher order octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50=20 milliseconds. A bit value of '1' indicates the presence of a ring-tone=20 and a bit value of '0' indicates the absence of a ring-tone, for that=20 duration (50 ms). (Note: A minimum number of octets required to encode the bit-string MUST be used.) The first two of the reserved octets MUST indicate the length of the=20 encoded cadence (in bits) and MUST range between 1 and 264. (Note: The=20 length in bits MUST also be consistent with the number of octets that=20 encode the cadence). The MTA MUST ignore any unused bits in the last octet, but MUST reflect the value as provided on a subsequent SNMP GET. The third of the reserved octets indicates 'repeatability' and MUST=20 be either 0x80 or 0x00 - the former value indicating=20 'repeatability' and the latter indicating 'non-repeatability'. The MTA MUST reject attempts to set a value that violates any of=20 the above requirements." - Sumanth -----Original Message----- From: Sumanth Channabasappa=20 Sent: Thursday, October 21, 2004 12:20 PM To: ipcdn@ietf.org Subject: RE: [ipcdn] Sig-Draft: pktcRingCadence description change Thanks Randy (And the subject has been change, thanks Harrie!)=20 Ok, how about: pktcRingCadence "This object provides an encoding scheme for ring cadences, including=20 repeatability characteristics. All octets and bit-strings in this object MUST be encoded in network-byte order. ^ | Introduced network-byte order Added ordering | V The first three higher order octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50=20 milliseconds. A bit value of '1' indicates the presence of a ring-tone=20 and a bit value of '0' indicates the absence of a ring-tone, for that=20 duration (50 ms).=20 The first two of the reserved octets MUST indicate the length of the=20 encoded cadence (in bits) and MUST range between 1 and 264. (Note: The=20 length in bits MUST also be consistent with the number of octets that=20 encode the cadence.). The third of the reserved octets indicates 'repeatability' and MUST=20 be either 0x80 or 0x00 - the former value indicating=20 'repeatability' and the latter indicating 'non-repeatability'. ^ | Accepted suggestions. The MTA MUST reject attempts to set any values which violate the above=20 requirements." Thoughts? Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 15:22:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09732 for ; Thu, 21 Oct 2004 15:22:45 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKij3-00045Q-9f for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 15:35:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiSc-0003xg-EZ; Thu, 21 Oct 2004 15:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiEy-0000od-Em for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 15:04:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06991 for ; Thu, 21 Oct 2004 15:04:46 -0400 (EDT) Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKiRd-0003eF-3o for ipcdn@ietf.org; Thu, 21 Oct 2004 15:17:54 -0400 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 21 Oct 2004 12:01:21 -0700 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id MAA23393; Thu, 21 Oct 2004 12:01:26 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Oct 2004 12:01:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcRingCadence (former pktcSigPowerRingFrequency description change) Date: Thu, 21 Oct 2004 12:01:07 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01E7660F@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcRingCadence (former pktcSigPowerRingFrequency description change) Thread-Index: AcS2TIhpM6T2w8YbQNucXiwdH6FliAAfPfqgAAEsCjAAAak58AAXStCwABrh0nA= From: "Eugene Nechamkin" To: "Sumanth Channabasappa" , "Beacham Gordon-CGB005" , ipcdn@ietf.org X-OriginalArrivalTime: 21 Oct 2004 19:01:15.0308 (UTC) FILETIME=[56DB4EC0:01C4B7A0] X-WSS-ID: 6D66D80B1Q425708-01-01 X-Spam-Score: 0.4 (/) X-Scan-Signature: dd530fb5c702ad6eef32cae6dcb86145 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1985719557==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: d3308915082aec5bdcb405956a0eb0ae This is a multi-part message in MIME format. --===============1985719557== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B7A0.521EB948" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4B7A0.521EB948 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I renamed the subject field of the e-mail thread for better "trackability". =20 As to the proposal, I am not sure what is the motivation to change the existing description clause. The currently exiting description seems to be quite adequite. =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Wednesday, October 20, 2004 10:56 PM To: Eugene Nechamkin; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change Hi, =20 I was looking at some of the comments regarding 'pktcRingCadence' and would like to propose the following text: =20 (This also takes care of removing the text initially proposed by Satish to which others, including myself agree to.) =20 "This object provides an encoding scheme for ring cadences, including repeatability characteristics.=20 =20 The first three octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50 milliseconds. A bit value of '1' indicates the presence of a ring-tone and a bit value of '0' indicates the absence of a ring-tone, for that duration (50 ms). This entire bit-string MUST be placed using network-byte order and encoded as octets that preserve that ordering. =20 The first two of the reserved octets indicate the length of the encoded 'bit-string' and MUST range between 1 and 264. (Note: The length MUST also be consistent with the number of octets that encode the cadence). The third of the reserved octets indicates 'repeatability' and MUST support only the values 0x80 or 0x00 - the former value indicating 'repeatability' and the latter indicating 'non-repeatability'. =20 The MTA MUST reject attempts to set any values which violate the above requirements." =20 =20 It is currently described as: =20 " This object represents a ring cadence and repeatable characteristics in bit string format. The first two octets of the bit string represent the bit-length of the duration of the cadence (i.e., the number of bits that follow the third octet). The first two octets MUST represent a value between 1 and 264. Any other values MUST be rejected. The bit count needs to be consistent with the OCTET STRING's length. If there are unused octets, the SNMP set MUST be rejected. If the length implied by the bit count is greater than the OCTET STRING's length the SNMP set MUST be rejected. The third octet is used to represent repeatable characteristics. 00000000 means repeatable, and 10000000 means non repeatable. The value of the repeatable field MUST be 0x00 or 0x80. Each bit after the third octet corresponds to 50 ms where 1 represents ring and 0 represents silence. The first bit of the fourth octet is the first bit of the ring cadence. All bits are counted in network order such that the octet with only the first bit set will look like 10000000 bit sequence. A total of 264 bits can be set to represent 13200 ms of total cadence cycle. There will be at most 3 on/off transitions per cadence cycle. If there are more than three on-to-off transitions, the SNMP set MUST be rejected. " =20 =20 Comments? =20 Thanks Sumanth =20 =20 =20 -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Wednesday, October 20, 2004 12:47 PM To: Sumanth Channabasappa; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 Yes, this addresses my conserns. =20 Eugene. ________________________________ From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Wednesday, October 20, 2004 11:03 AM To: Eugene Nechamkin; Beacham Gordon-CGB005; ipcdn@ietf.org Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 Hi Eugene, =20 =20 How about: =20 "The default value for this object is dependent on the primary usage area of the device. For devices compliant with PacketCable (North America) it MUST be set to f20Hz and for devices compliant with IPCablecom (Europe) it MUST be set to f25Hz." =20 =20 Sumanth -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com]=20 Sent: Wednesday, October 20, 2004 11:50 AM To: Beacham Gordon-CGB005; ipcdn@ietf.org; Sumanth Channabasappa Subject: RE: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 =20 While not disagreeing with the proposal to delete the DEFVAL clause from the MIB Object definition, I am not completely comfortable with the fact that IETF MIB draft would make a reference to the document ([PKT-SP-MIB-SIG]) which will be obsolete when draft becomes an RFC (or soon thereafter). Besides, I am not sure to which extent the mentioning of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is unambigous. Not sure presisely what this "compliency" means. What's the intention here - to say that for MTAs compliant with NorthAmerican-PC the defval should be f20 but for MTAs compliant with Euro-PC the defval should be f25Hz ? I think the reference to the compliency should be made less ambiguous.=20 =20 Eugene. ________________________________ From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham Gordon-CGB005 Sent: Tuesday, October 19, 2004 8:48 AM To: ipcdn@ietf.org; 'sumanth@cablelabs.com' Subject: [ipcdn] pktcSigPowerRingFrequency description change =09 =09 The following changes are recommended to the description of the pktcSigPowerRingFrequency object. =20 delete: DEFVAL { f20Hz } add: This default value for this object MUST be f20Hz for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST be f25Hz for MTAs compliant to [ITU-T-J169]. =20 Gordon ------_=_NextPart_001_01C4B7A0.521EB948 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message
I renamed the subject field of the e-mail = thread for=20 better "trackability".
 
As to the proposal, I am not sure what is the = motivation to change the existing description clause. The currently = exiting=20 description seems to be quite adequite.
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth=20 Channabasappa
Sent: Wednesday, October 20, 2004 10:56 = PM
To:=20 Eugene Nechamkin; Beacham Gordon-CGB005; = ipcdn@ietf.org
Subject: RE:=20 [ipcdn] pktcSigPowerRingFrequency description = change

Hi,
 
I was=20 looking at some of the comments regarding 'pktcRingCadence' and would = like to=20 propose the following text:
 
(This=20 also takes care of removing the text initially proposed by Satish to = which=20 others, including myself agree to.)
 

"This object provides an encoding scheme for ring cadences, = including=20 repeatability characteristics.

 

The first three octets are reserved. The octets that follow are = used to=20 encode a 'bit-string', with each bit corresponding to 50 milliseconds. A = bit=20 value of '1' indicates the presence of a ring-tone and a bit value of = '0'=20 indicates the absence of a ring-tone, for that duration (50 ms). This = entire=20 bit-string MUST be placed using network-byte order and encoded as octets = that=20 preserve that ordering.

 

The first two of the reserved octets indicate the length of the = encoded=20 'bit-string' and MUST range between 1 and 264. (Note: The length MUST = also be=20 consistent with the number of octets that encode the cadence). The third = of the=20 reserved octets indicates 'repeatability' and MUST support only the = values 0x80=20 or 0x00 - the former value indicating 'repeatability' and the latter = indicating=20 'non-repeatability'.

 

The MTA MUST reject attempts to set any values which violate = the above=20 requirements."

 

 

It = is currently=20 described as:

 

"

This object=20 represents a ring cadence and repeatable

characteristics=20 in bit string format. The first two

octets of the=20 bit string represent the bit-length  of

the duration of=20 the cadence (i.e., the number of bits that

follow the third=20 octet). The first two octets MUST

represent a=20 value between 1 and 264. Any other values MUST

be = rejected. The=20 bit count needs to be consistent with the

OCTET STRING's=20 length. If there are unused octets, the SNMP

set MUST be=20 rejected. If the length implied by the bit

count is greater=20 than the OCTET STRING's length the SNMP

set MUST be=20 rejected. The third octet is used to

represent=20 repeatable characteristics. 00000000 means

repeatable, and=20 10000000 means non repeatable. The value of

the repeatable=20 field MUST be 0x00 or 0x80. Each bit

after the third=20 octet corresponds to 50 ms where 1

represents ring=20 and 0 represents silence. The first bit of

the fourth octet=20 is the first bit of the ring cadence. All

bits are counted=20 in network order such that the octet with

only the first=20 bit set will look like 10000000 bit

sequence. A=20 total of 264 bits can be set to represent

13200 ms of=20 total cadence cycle. There will = be at most=20 3

on/off = transitions per=20 cadence cycle. If there are more

than three = on-to-off=20 transitions, the SNMP set MUST be

rejected. = "

 

 

Comments?

 

Thanks

Sumanth

 

 

 

=
-----Original Message-----
From: = Eugene Nechamkin=20 [mailto:enechamkin@broadcom.com]
Sent: Wednesday, October = 20, 2004=20 12:47 PM
To: Sumanth Channabasappa; Beacham Gordon-CGB005;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] = pktcSigPowerRingFrequency=20 description change

Yes, this addresses my = conserns.
 
Eugene.

From: Sumanth Channabasappa=20 [mailto:sumanth@cablelabs.com]
Sent: Wednesday, October 20, = 2004=20 11:03 AM
To: Eugene Nechamkin; Beacham Gordon-CGB005;=20 ipcdn@ietf.org
Subject: RE: [ipcdn] = pktcSigPowerRingFrequency=20 description change

Hi=20 Eugene,
 
 
How=20 about:
 
"The=20 default value for this object is dependent on the primary usage area = of the=20 device. For devices compliant with PacketCable (North America) =  it=20 MUST be set to f20Hz and for devices compliant with IPCablecom (Europe)  it MUST be set to = f25Hz."
 
 
Sumanth
-----Original Message-----
From: = Eugene=20 Nechamkin [mailto:enechamkin@broadcom.com]
Sent: = Wednesday,=20 October 20, 2004 11:50 AM
To: Beacham Gordon-CGB005;=20 ipcdn@ietf.org; Sumanth Channabasappa
Subject: RE: [ipcdn] = pktcSigPowerRingFrequency description change

 
While not disagreeing with the proposal to = delete the=20 DEFVAL clause from the MIB Object definition, I am not completely=20 comfortable with the fact that IETF MIB draft would make a reference = to the=20 document ([PKT-SP-MIB-SIG]) which will be obsolete when draft = becomes an RFC=20 (or soon thereafter). Besides, I am not sure to which extent the = mentioning=20 of compliency with the [PKT-SP-MIB-SIG] or with the [ITU-T-J169] is=20 unambigous. Not sure presisely what this "compliency" means. What's = the=20 intention here - to say that for MTAs compliant with = NorthAmerican-PC the=20 defval should be f20 but for MTAs compliant with Euro-PC the defval = should=20 be f25Hz ? I think the reference to the compliency = should be made=20 less ambiguous.
 
Eugene.

From: ipcdn-bounces@ietf.org=20 [mailto:ipcdn-bounces@ietf.org] On Behalf Of Beacham=20 Gordon-CGB005
Sent: Tuesday, October 19, 2004 8:48=20 AM
To: ipcdn@ietf.org; = 'sumanth@cablelabs.com'
Subject:=20 [ipcdn] pktcSigPowerRingFrequency description = change

The following=20 changes are recommended to the description of the pktcSigPowerRingFrequency object.
 
delete: DEFVAL {=20 f20Hz }
add: This default value for this object = MUST=20 be f20Hz=20 for MTAs compliant to [PKT-SP-MIB-SIG]. The default value for this object MUST = be f25Hz=20 for MTAs compliant to=20 [ITU-T-J169].
 
Gordon
------_=_NextPart_001_01C4B7A0.521EB948-- --===============1985719557== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1985719557==-- From ipcdn-bounces@ietf.org Thu Oct 21 15:47:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12742 for ; Thu, 21 Oct 2004 15:47:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKj6u-0004fX-A1 for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 16:00:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKinH-0003Z9-PC; Thu, 21 Oct 2004 15:40:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKicq-0004JH-3t for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 15:29:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10598 for ; Thu, 21 Oct 2004 15:29:25 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKipU-0004F7-HY for ipcdn@ietf.org; Thu, 21 Oct 2004 15:42:33 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKicl-0003tz-00 for ipcdn@ietf.org; Thu, 21 Oct 2004 12:29:23 -0700 Message-ID: <000801c4b7a4$60fb0680$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with E packagerequirements Date: Thu, 21 Oct 2004 12:30:09 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi - > From: "Sumanth Channabasappa" > To: > Sent: Thursday, October 21, 2004 11:23 AM > Subject: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with E packagerequirements ... > I agree with one of David's old comments to replace 'E Package' with > 'International Systems'. ... I object to using the term "International Systems" without an adequate definition. (I raised this issue in an earlier MIB review.) I don't particularly care what you call it, as long as the term and conformance requirements are clearly defined. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 16:37:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21382 for ; Thu, 21 Oct 2004 16:37:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjtJ-0007Lw-K2 for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 16:50:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKiui-0002xX-Q7; Thu, 21 Oct 2004 15:47:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKikX-0001S1-C3 for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 15:37:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11188 for ; Thu, 21 Oct 2004 15:37:23 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKixC-0004MO-GF for ipcdn@ietf.org; Thu, 21 Oct 2004 15:50:31 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CKikU-0006TY-00 for ipcdn@ietf.org; Thu, 21 Oct 2004 12:37:22 -0700 Message-ID: <001f01c4b7a5$7e6d5dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Sig-Draft: pktcRingCadence description change Date: Thu, 21 Oct 2004 12:38:08 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Hi - > From: "Sumanth Channabasappa" > To: > Sent: Thursday, October 21, 2004 11:42 AM > Subject: RE: [ipcdn] Sig-Draft: pktcRingCadence description change ... > repeatability characteristics. All octets and bit-strings in this object ... s/octets and bit-strings/fields/ (The first field is sixteen bits long, so saying that the octets are in network byte order isn't helpful.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 21:02:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18468 for ; Thu, 21 Oct 2004 21:02:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKo1p-00083L-Ks for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 21:15:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlG1-00064Z-8d; Thu, 21 Oct 2004 18:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKjSZ-00083V-11 for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 16:22:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18132 for ; Thu, 21 Oct 2004 16:22:52 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKjfE-0006CK-15 for ipcdn@ietf.org; Thu, 21 Oct 2004 16:36:01 -0400 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 i9LKMK1e029688 for ; Thu, 21 Oct 2004 14:22:20 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with Epackagerequirements Date: Thu, 21 Oct 2004 14:22:20 -0600 Message-ID: Thread-Topic: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with Epackagerequirements Thread-Index: AcS3ptb7OFeAZkRITdmEi/01DLPoxQAAwA+Q From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Hi Randy, How about we change the objects mentioned specifically as being required for 'L Package only'?=20 David? regards Sumanth Dear all, In the DESCRIPTION of a number of MIB objects, the term "international systems" has been replaced by "E package" in draft 6. This introduces the side-effect that a number of MIB objects that have nothing to do with E package support, now only have to be supported when the E package is supported. The following MIB objects are the ones I believe have nothing to do with the E package, since the caller ID and VMWI transmissions are triggered using the L package: pktcSigDevCIDMode pktcSigDevCIDFskAfterRing pktcSigDevCIDFskAfterDTAS pktcSigDevCIDFskAfterRPAS pktcSigDevCIDRingAfterFSK pktcSigDevCIDDTASAfterLR pktcSigDevVmwiFskAfterDTAS pktcSigDevVmwiFskAfterRPAS pktcSigDevVmwiDTASAfterLR An MTA for the international market that does however not support the E package, will want to support the above MIB objects. Maybe we can revert to the description of "international systems"? Thanks, Regards, David Hi - > From: "Sumanth Channabasappa" > To: > Sent: Thursday, October 21, 2004 11:23 AM > Subject: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue with E=20 > packagerequirements ... > I agree with one of David's old comments to replace 'E Package' with=20 > 'International Systems'. ... I object to using the term "International Systems" without an adequate definition. (I raised this issue in an earlier MIB review.) I don't particularly care what you call it, as long as the term and conformance requirements are clearly defined. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 21:16:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20809 for ; Thu, 21 Oct 2004 21:16:31 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoFT-00006V-CT for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 21:29:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlSN-00015x-KV; Thu, 21 Oct 2004 18:30:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKk4T-00011y-S2 for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 17:02:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26064 for ; Thu, 21 Oct 2004 17:02:03 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkH9-0000Ma-N5 for ipcdn@ietf.org; Thu, 21 Oct 2004 17:15:13 -0400 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 i9LL1V1e009890 for ; Thu, 21 Oct 2004 15:01:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Sig-Draft: pktcRingCadence description change Date: Thu, 21 Oct 2004 15:01:31 -0600 Message-ID: Thread-Topic: [ipcdn] Sig-Draft: pktcRingCadence description change Thread-Index: AcS3rdTt9hFom4chRbSSPf4Gv2F8egAAzOhA From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable =20 s/octets and bit-strings/fields/ [sumanth] Done - Thanks Randy! (The first field is sixteen bits long, so saying that the octets are in network byte order isn't helpful.) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 21:18:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21166 for ; Thu, 21 Oct 2004 21:18:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoHS-0000Ap-SQ for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 21:31:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKlTb-00039f-93; Thu, 21 Oct 2004 18:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKkEK-00050y-7r for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 17:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28413 for ; Thu, 21 Oct 2004 17:12:12 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKkQz-00017L-FN for ipcdn@ietf.org; Thu, 21 Oct 2004 17:25:22 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id i9LLBfPl028067 for ; Thu, 21 Oct 2004 16:11:42 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <4M32G8XZ>; Thu, 21 Oct 2004 23:11:40 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79DCD@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Wilson Sawyer'" , ipcdn@ietf.org Date: Thu, 21 Oct 2004 23:11:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: housley@vigilsec.com Subject: [ipcdn] RE: docsis subscriber management i-d draft -16 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Sorry for the slight delay. But I am doing follow up now. I expect approval RSN. Bert > -----Original Message----- > From: Wilson Sawyer [mailto:sawyerwd@comcast.net] > Sent: Monday, October 11, 2004 15:36 > To: ipcdn@ietf.org; bwijnen@lucent.com > Cc: housley@vigilsec.com > Subject: docsis subscriber management i-d draft -16 > > > I've just submitted draft -16 to fix a couple of issues from the IESG > review and to align the publication order with expected updates of RFC > 2669 and 2670. The changes are: > > (1) References to RFC 2669 are changed to informative, and the > corresponding RFC editor notes were removed. > > (2) The second paragraph of 'Security Considerations' was reworded per > Russ Housley's suggestion. > > (3) The section reference in that same paragraph was fixed per Allison > Mankin's note. > > (4) Editor notes w.r.t. successor of RFC 2670 were left in, as it is > expected that submgt will be held until that successor is available. > > Respectfully submitted, > Wilson Sawyer > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 21 22:03:41 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29701 for ; Thu, 21 Oct 2004 22:03:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoz7-0002PY-Oz for ipcdn-archive@ietf.org; Thu, 21 Oct 2004 22:16:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKoNA-0004mQ-5F; Thu, 21 Oct 2004 21:37:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKnyB-0000sX-Ma for ipcdn@megatron.ietf.org; Thu, 21 Oct 2004 21:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19978 for ; Thu, 21 Oct 2004 21:11:49 -0400 (EDT) Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKoAt-0008NW-8e for ipcdn@ietf.org; Thu, 21 Oct 2004 21:25:00 -0400 Received: from h-69-3-28-107.snvacaid.dynamic.covad.net ([69.3.28.107] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1CKny8-0004Wm-00 for ipcdn@ietf.org; Thu, 21 Oct 2004 18:11:48 -0700 Message-ID: <000401c4b7d4$3756c640$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements Date: Thu, 21 Oct 2004 18:12:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi - > From: "Sumanth Channabasappa" > To: > Sent: Thursday, October 21, 2004 1:22 PM > Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements ... > How about we change the objects mentioned specifically as being required > for 'L Package only'? ... I see two parts to your proposal. The first part, defining conformance in terms of "L Package," would be OK with me if the term "L Package" is defined and the WG agrees that this is the right thing to do. (As a MIB reviewer, I don't much care what you call the packages, as long as they are defined.) The second part, which you might not intend, comes from the word "only". The phrase "only required for L package" doesn't bother me, since it doesn't constrain those who do not implement the L package. The phrase "required for 'L package only'" bothers me because it can be read as prohibiting systems which do not implement L package from implementing these objects. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Oct 22 02:14:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01155 for ; Fri, 22 Oct 2004 02:14:06 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKstR-0006x6-0N for ipcdn-archive@ietf.org; Fri, 22 Oct 2004 02:27:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKsfv-00021U-Lh; Fri, 22 Oct 2004 02:13:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKscd-0008Jr-Jc for ipcdn@megatron.ietf.org; Fri, 22 Oct 2004 02:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26988 for ; Fri, 22 Oct 2004 02:09:54 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKspM-0006qO-Q8 for ipcdn@ietf.org; Fri, 22 Oct 2004 02:23:06 -0400 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 i9M69K1e026953 for ; Fri, 22 Oct 2004 00:09:20 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> IssuewithEpackagerequirements Date: Fri, 22 Oct 2004 00:09:19 -0600 Message-ID: Thread-Topic: [ipcdn] IETF NCS Sig MIB draft 6 -> IssuewithEpackagerequirements Thread-Index: AcS322CGQqzjzPECTGKmCmMgb76oQAAIgbXw From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Hi Randy, 'L' and 'E' packages are already defined, so it should be ok. Good suggestion on the semantics related to 'only'. Will take that into consideration. Thanks! Sumanth =20 > From: "Sumanth Channabasappa" > To: > Sent: Thursday, October 21, 2004 1:22 PM > Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue=20 > withEpackagerequirements ... > How about we change the objects mentioned specifically as being=20 > required for 'L Package only'? ... I see two parts to your proposal. The first part, defining conformance in terms of "L Package," would be OK with me if the term "L Package" is defined and the WG agrees that this is the right thing to do. (As a MIB reviewer, I don't much care what you call the packages, as long as they are defined.) The second part, which you might not intend, comes from the word "only". The phrase "only required for L package" doesn't bother me, since it doesn't constrain those who do not implement the L package. The phrase "required for 'L package only'" bothers me because it can be read as prohibiting systems which do not implement L package from implementing these objects. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Oct 22 03:24:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07612 for ; Fri, 22 Oct 2004 03:24:07 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtzE-0008BG-3B for ipcdn-archive@ietf.org; Fri, 22 Oct 2004 03:37:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtkI-0007Uw-6b; Fri, 22 Oct 2004 03:21:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CKtep-0005A5-77 for ipcdn@megatron.ietf.org; Fri, 22 Oct 2004 03:16:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06828 for ; Fri, 22 Oct 2004 03:16:13 -0400 (EDT) Received: from astra.telenet-ops.be ([195.130.132.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CKtrU-0007zx-FV for ipcdn@ietf.org; Fri, 22 Oct 2004 03:29:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id 6DAC5328261 for ; Fri, 22 Oct 2004 09:16:03 +0200 (MEST) Received: from tcomlabs.com (D5E00496.kabel.telenet.be [213.224.4.150]) by astra.telenet-ops.be (Postfix) with ESMTP id 1F9DC328223 for ; Fri, 22 Oct 2004 09:16:03 +0200 (MEST) Received: (qmail 28906 invoked from network); 22 Oct 2004 09:16:02 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 22 Oct 2004 09:16:02 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 22 Oct 2004 09:16:02 +0200 (CEST) From: "David De Reu" To: "Sumanth Channabasappa" , Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements Date: Fri, 22 Oct 2004 09:16:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit Cc: Kristof Sercu X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit > How about we change the objects mentioned specifically as being required > for 'L Package only'? > > David? I think this is different from the original intention. Background ========== The intention, to my belief, was to define these objects because they are needed for MTA's for the "international market" only (i.e. Europe in practice). These MTA's would have to be able to comply with the relevant ETSI specs. The MIB objects define different timing values regarding CID (Caller ID transmission) and VMWI (Visual Message Waiting Indicator) as defined in the ETSI specs. The timing values can be different per country or operator in Europe, but apparently don't apply to North America. Of course both CID and VMWI exist in North America as well. CID and VMWI are triggered by elements of the "L package" (which is always implemented by all MTA's). The only difference is that MTA's for the "international market" would have to take the MIB objects into account as well, whereas the "North American" MTA's would not. The "E package" is something that only applies to ETSI systems, but is in practice not always implemented (as opposed to the L package). Therefore, in practice the terms "ETSI systems" and "E package" are NOT equivalent. I am aware that one or some of my e-mails in the thread "Signaling MIB - Draft 3 - Last Call - Clarification US/intl. requirements" may have suggested otherwise, but these are the practical limitations we have to consider. By the way, the E package has nothing to do with the MIB objects at hand. Additional question =================== Are there no timers at all with respect to CID and VMWI in North Amercia? Or are the timers in North America standardized, and can they be expressed in terms of the MIB objects under discussion? Suggestion ========== (1) assuming that the MIB objects indeed do not make sense in North America: Referencing the L package as in "L package only" (with or without the "only" part) would make the MIB objects mandatory to implement for North American (i.e. pure PacketCable) MTA's as well, which apparently doesn't make sense since they do not apply there (remember, they are translations to the MIB of timers defined in the ETSI specs). The discussion is a bit analoguous to the recent pktcSigPowerRingFrequency issue raised (where you want a different default for North America vs. Europe). In other words, you would have to find some wording that makes this clear, without referencing either the L package or E package. If "international" is not good enough, maybe we can revert to the term "ETSI systems" as was once used? Alternatively, we can distinguish between PacketCable and Euro-PacketCable instead of North American and International, like e.g. in the IPCDN docsIfMib where there is a distinction between DOCSIS and Euro-DOCSIS (spelled "EuroDOCSIS", in ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt). An MTA would be an "ETSI system" or not, depending on its intended usage, i.e. the market it is meant for. (2) assuming that the North American timer values can be expressed in terms of the ETSI MIB objects: In this case it may make sense to make the MIB objects mandatory for all MTA's, which solves the problem very easily: no extra reference to L package, E package or ETSI systems would be necessary anymore. Hope this helps a bit, Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 - 9000 Ghent - Belgium Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Oct 22 18:12:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00745 for ; Fri, 22 Oct 2004 18:12:50 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL7rP-0005H1-1F for ipcdn-archive@ietf.org; Fri, 22 Oct 2004 18:26:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL6kR-00007F-SE; Fri, 22 Oct 2004 17:14:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL5ui-0007K9-Uy for ipcdn@megatron.ietf.org; Fri, 22 Oct 2004 16:21:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07638 for ; Fri, 22 Oct 2004 16:21:25 -0400 (EDT) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL67Y-0006DB-8N for ipcdn@ietf.org; Fri, 22 Oct 2004 16:34:45 -0400 Received: from h-69-3-92-124.snvacaid.dynamic.covad.net ([69.3.92.124] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CL5ud-0003Bw-00 for ipcdn@ietf.org; Fri, 22 Oct 2004 13:21:23 -0700 Message-ID: <001401c4b874$cfe7ab40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] IETF NCS Sig MIB draft 6 -> IssuewithEpackagerequirements Date: Fri, 22 Oct 2004 13:21:23 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: "David De Reu" > To: "Sumanth Channabasappa" ; > Cc: "Kristof Sercu" > Sent: Friday, October 22, 2004 12:16 AM > Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> IssuewithEpackagerequirements ... (Extremely helpful background deleted) ... > The discussion is a bit analoguous to the recent pktcSigPowerRingFrequency > issue raised (where you want a different default for North America vs. > Europe). In other words, you would have to find some wording that makes this > clear, without referencing either the L package or E package. If > "international" is not good enough, maybe we can revert to the term "ETSI > systems" as was once used? Alternatively, we can distinguish between > PacketCable and Euro-PacketCable instead of North American and > International, like e.g. in the IPCDN docsIfMib where there is a distinction > between DOCSIS and Euro-DOCSIS (spelled "EuroDOCSIS", in > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt). ... As a MIB reviewer, I'm not particularly hung up on what term is chosen, as long as (1) it is clearly defined so folks will know what the conformance requirements are and (2) the WG is actually agreed that those are indeed the conformance requirements. This discussion gives me the feeling that (2) is still a little fuzzy around the edges, but I'm very much an outsider to this technology, and perhaps this is something totally obvious to those who already understand it. :-) Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Oct 25 01:39:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05311 for ; Mon, 25 Oct 2004 01:39:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxnO-0005pE-CA for ipcdn-archive@ietf.org; Mon, 25 Oct 2004 01:53:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxYA-0007oA-6O; Mon, 25 Oct 2004 01:37:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLxUh-0007Oc-At for ipcdn@megatron.ietf.org; Mon, 25 Oct 2004 01:34:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04863 for ; Mon, 25 Oct 2004 01:34:09 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLxi4-0005gq-R2 for ipcdn@ietf.org; Mon, 25 Oct 2004 01:48:01 -0400 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 i9P5XZ1g026417 for ; Sun, 24 Oct 2004 23:33:37 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements Date: Sun, 24 Oct 2004 23:33:36 -0600 Message-ID: Thread-Topic: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements Thread-Index: AcS4BwAcFjCPHdLkSGC/E2+ckCFo7ACO0vJg From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: quoted-printable Hi David, Thanks for the very helpful background and the suggestions. Randy, Appreciate your expertise and aid in keeping us accurate and unambiguous. I took suggestion-1 since Euro-PacketCable is well-defined and suits our needs. I did however use the phrase=20 'only for Euro-PacketCable' - avoiding the confusion introduced earlier by the term 'only'!:) (Thanks for the catch Randy!) Version-7 of the draft should be submitted shortly... regards Sumanth -----Original Message----- From: David De Reu [mailto:DeReu@tComLabs.com]=20 Sent: Friday, October 22, 2004 1:16 AM To: Sumanth Channabasappa; ipcdn@ietf.org Cc: Kristof Sercu Subject: RE: [ipcdn] IETF NCS Sig MIB draft 6 -> Issue withEpackagerequirements=20 > How about we change the objects mentioned specifically as being=20 > required for 'L Package only'? > > David? I think this is different from the original intention. Background =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The intention, to my belief, was to define these objects because they are needed for MTA's for the "international market" only (i.e. Europe in practice). These MTA's would have to be able to comply with the relevant ETSI specs. The MIB objects define different timing values regarding CID (Caller ID transmission) and VMWI (Visual Message Waiting Indicator) as defined in the ETSI specs. The timing values can be different per country or operator in Europe, but apparently don't apply to North America. Of course both CID and VMWI exist in North America as well. CID and VMWI are triggered by elements of the "L package" (which is always implemented by all MTA's). The only difference is that MTA's for the "international market" would have to take the MIB objects into account as well, whereas the "North American" MTA's would not. The "E package" is something that only applies to ETSI systems, but is in practice not always implemented (as opposed to the L package). Therefore, in practice the terms "ETSI systems" and "E package" are NOT equivalent. I am aware that one or some of my e-mails in the thread "Signaling MIB - Draft 3 - Last Call - Clarification US/intl. requirements" may have suggested otherwise, but these are the practical limitations we have to consider. By the way, the E package has nothing to do with the MIB objects at hand. Additional question =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Are there no timers at all with respect to CID and VMWI in North Amercia? Or are the timers in North America standardized, and can they be expressed in terms of the MIB objects under discussion? Suggestion =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D (1) assuming that the MIB objects indeed do not make sense in North America: Referencing the L package as in "L package only" (with or without the "only" part) would make the MIB objects mandatory to implement for North American (i.e. pure PacketCable) MTA's as well, which apparently doesn't make sense since they do not apply there (remember, they are translations to the MIB of timers defined in the ETSI specs). The discussion is a bit analoguous to the recent pktcSigPowerRingFrequency issue raised (where you want a different default for North America vs. Europe). In other words, you would have to find some wording that makes this clear, without referencing either the L package or E package. If "international" is not good enough, maybe we can revert to the term "ETSI systems" as was once used? Alternatively, we can distinguish between PacketCable and Euro-PacketCable instead of North American and International, like e.g. in the IPCDN docsIfMib where there is a distinction between DOCSIS and Euro-DOCSIS (spelled "EuroDOCSIS", in ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt) . An MTA would be an "ETSI system" or not, depending on its intended usage, i.e. the market it is meant for. (2) assuming that the North American timer values can be expressed in terms of the ETSI MIB objects: In this case it may make sense to make the MIB objects mandatory for all MTA's, which solves the problem very easily: no extra reference to L package, E package or ETSI systems would be necessary anymore. Hope this helps a bit, Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 - 9000 Ghent - Belgium Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Oct 25 03:15:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25842 for ; Mon, 25 Oct 2004 03:15:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzHr-0007Y8-O1 for ipcdn-archive@ietf.org; Mon, 25 Oct 2004 03:29:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLz14-0006YQ-0n; Mon, 25 Oct 2004 03:11:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CLz0r-0006Vg-5O for ipcdn@megatron.ietf.org; Mon, 25 Oct 2004 03:11:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25508 for ; Mon, 25 Oct 2004 03:11:27 -0400 (EDT) Received: from hornbill.blue-cable.net ([62.117.20.8] helo=mail2.blue-cable.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CLzE5-0007Sx-PX for ipcdn@ietf.org; Mon, 25 Oct 2004 03:25:20 -0400 Received: from rochen.blue-cable.net ([172.16.20.19] helo=[IPv6:::1]) by mail2.blue-cable.net with esmtp (Exim 4.42) id 1CLz09-0003Pj-6E for ipcdn@ietf.org; Mon, 25 Oct 2004 09:10:45 +0200 Message-ID: <417CA6F4.2090300@blue-cable.de> Date: Mon, 25 Oct 2004 09:10:44 +0200 From: Thomas Anders User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: ipcdn@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Envelope-From: thomas.anders@blue-cable.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [ipcdn] SIG-MIB: non-ASCII chars in PktcSigType TC description X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit In draft-ietf-ipcdn-pktc-signaling-06.txt the DESCRIPTION of the PktcSigType TC contains non-ASCII characters (0xfb) that should probably rather be an ASCII hyphen-minus (0x2d) instead. Please fix before draft 7. Best regards, +Thomas -- Thomas Anders (thomas.anders at blue-cable.de) BN Breitbandnetze GmbH, Berlin, Germany _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Oct 26 18:52:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18486 for ; Tue, 26 Oct 2004 18:52:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CMaOy-0007Yh-7Y for ipcdn-archive@ietf.org; Tue, 26 Oct 2004 19:06:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYp0-0000a5-Mf; Tue, 26 Oct 2004 17:25:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMY1y-0006HF-Hf; Tue, 26 Oct 2004 16:34:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14172; Tue, 26 Oct 2004 16:34:56 -0400 (EDT) Message-Id: <200410262034.QAA14172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 16:34:56 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-07.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Network-Based Call Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) Author(s) : G. Beacham, et al. Filename : draft-ietf-ipcdn-pktc-signaling-07.txt Pages : 60 Date : 2004-10-26 This memo defines the Signaling Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-signaling-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.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-10-26160944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160944.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Oct 28 00:08:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16556 for ; Thu, 28 Oct 2004 00:08:52 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN1oq-0007Ec-9K for ipcdn-archive@ietf.org; Thu, 28 Oct 2004 00:23:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN1Zh-0002pa-6T; Thu, 28 Oct 2004 00:07:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CN1Vp-0002CJ-7Y for ipcdn@megatron.ietf.org; Thu, 28 Oct 2004 00:03:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15994 for ; Thu, 28 Oct 2004 00:03:42 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CN1jo-00076P-7z for ipcdn@ietf.org; Thu, 28 Oct 2004 00:18:13 -0400 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 i9S4361e011825 for ; Wed, 27 Oct 2004 22:03:06 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] SIG-MIB: non-ASCII chars in PktcSigType TC description Date: Wed, 27 Oct 2004 22:03:05 -0600 Message-ID: Thread-Topic: [ipcdn] SIG-MIB: non-ASCII chars in PktcSigType TC description Thread-Index: AcS6YnTt72tRhwQGTaeYTTDbV4aGLQCGOgdg From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Hi Thomas, Thanks for your input (And yes, your observation was right). I believe this has been fixed in draft-07. - Sumanth -----Original Message----- From: Thomas Anders [mailto:thomas.anders@blue-cable.de]=20 Sent: Monday, October 25, 2004 3:11 AM To: ipcdn@ietf.org Subject: [ipcdn] SIG-MIB: non-ASCII chars in PktcSigType TC description In draft-ietf-ipcdn-pktc-signaling-06.txt the DESCRIPTION of the PktcSigType TC contains non-ASCII characters (0xfb) that should probably rather be an ASCII hyphen-minus (0x2d) instead. Please fix before draft 7. Best regards, +Thomas --=20 Thomas Anders (thomas.anders at blue-cable.de) BN Breitbandnetze GmbH, Berlin, Germany _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 28 13:31:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27142 for ; Thu, 28 Oct 2004 13:31:24 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNELZ-0006SQ-Qj for ipcdn-archive@ietf.org; Thu, 28 Oct 2004 13:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNCju-0001qV-8f; Thu, 28 Oct 2004 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNBiY-0004xB-07; Thu, 28 Oct 2004 10:57:34 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20886; Thu, 28 Oct 2004 10:57:33 -0400 (EDT) Message-Id: <200410281457.KAA20886@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 28 Oct 2004 10:57:33 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-05.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --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-05.txt Pages : 51 Date : 2004-10-27 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-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-05.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-05.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-10-28110028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-mtamib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110028.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart-- From ipcdn-bounces@ietf.org Thu Oct 28 21:26:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09825 for ; Thu, 28 Oct 2004 21:26:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNLky-0004Yz-4K for ipcdn-archive@ietf.org; Thu, 28 Oct 2004 21:40:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJCZ-0005lv-9I; Thu, 28 Oct 2004 18:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGMg-0008Mr-Rz for ipcdn@megatron.ietf.org; Thu, 28 Oct 2004 15:55:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28529 for ; Thu, 28 Oct 2004 15:55:17 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNGan-00080o-UZ for ipcdn@ietf.org; Thu, 28 Oct 2004 16:09:55 -0400 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 i9SJsi1e014767 for ; Thu, 28 Oct 2004 13:54:44 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Oct 2004 13:54:44 -0600 Message-ID: Thread-Topic: Submission: IETF NCS Signaling MIB draft 7 (Update) Thread-Index: AcS4BwAcFjCPHdLkSGC/E2+ckCFo7ACPG54g From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b446c230caab880282be239780d76153 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Submission: IETF NCS Signaling MIB draft 7 (Update) X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 03798b51c5f8a7e89d7f7972440c2a03 Content-Transfer-Encoding: quoted-printable Hi All, Based on the comments received so far, draft-ietf-ipcdn-pktc-signaling-07 has been submitted for posting. Find enclosed the changes that have been incorporated into this version of the draft. =20 Note: Gordon Beacham incorporated/consolidated a majority of the changes indicated below. (Thanks Gordon!) Thanks also to everyone else for the numerous reviews/suggestions/comments. (Keep them coming!)=20 regards Sumanth **************************************************** Part 1: **************************************************** =20 1) lines limited to 72 characters: trailing blanks make line 26 too long (73 characters) trailing blanks make line 99 too long (73 characters) trailing blanks make line 2206 too long (73 characters) trailing blanks make line 2226 too long (73 characters) trailing blanks make line 2240 too long (73 characters) trailing blanks make line 2301 too long (73 characters) AI: Fix in final formatting. =20 2) some pages have more than 58 lines=20 AI: Fix in final formatting. =20 3) pages not separated by FF character AI: Fix in final formatting. =20 4) the words "INTERNET-DRAFT" should be in upper left corner of first page =20 AI: Changed. =20 5) IPR Boilerplate: OK, but note that alternative wording for "plural" authors has been presented on the WG chairs list: =20 By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of RFC 3668. =20 AI: Changed. =20 6) Internet-Draft boilerplate: text is OK, but formatting is strange. =20 No change. Not clear what is "strange". =20 7) Filename: broken by strange formatting on first page =20 AI: Changed. =20 8) author list: present, but mal-formatted =20 AI: Fixed formatting. =20 9) Introduction: missing. (2.2 #5) =20 AI: Added Introduction section. =20 10) IANA considerations: contradictory, (2.2 #7b) seems to apply, since an OID needs to be allocated. =20 AI: Added the following per 8/4 IPCDN reflector message from Dave Thaler. =20 The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: =20 Descriptor OBJECT IDENTIFIER Value ---------- ----------------------- pktcSigMib { mib-2 XXX } =20 Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for XXX under the mib-2 subtree and to record the assignment in the SMI Numbers registry. When the assignment has been made, the RFC Editor is asked to replace XXX (here and in the MIB module) with the assigned value and to remove this note. =20 11) authors' addresses: need cleanup (e.g., the first in the list uses normal US postal address format, but the last in the list doesn't.) =20 AI: Changed. =20 12) Keywords: text references RFC 2119, but it is missing from the list of normative references. =20 AI: Added normative reference: [RFC2119]. =20 13) formal language use: MIB compilation: smilint objects to pktcSigDevCodecType (an index of pktcSigDevCodecEntry) being read-only. It should be not-accessible. =20 AI: Changed. =20 14) References: [PKT-SP-MGCP-IO9-040113] is never cited. =20 [PKT-SP-PROV-IO8-040113] is never cited. =20 [PKT-SP-CODEC-IO5-040113] is never cited. =20 [PKT-SP-MIB-MTA-I08-040113] is never cited. =20 [ETSI TS 101 909-9] is never cited. =20 [TR 101 183] is never cited. =20 [RFC3289], while referenced in the MIB module, is not cited in the text of the document. =20 [RFC3291], while referenced in the MIB module, is never cited. [RFC3261] is never cited. =20 [RFC3435] is never cited. =20 MIB module IMPORTS from SNMP-FRAMEWORK-MIB, but it's missing from the normative references and not cited in text.=20 =20 AI: Deleted: [RFC3261], added normative references: [ITU-T-J169], [RFC3411]. Cited reference in introduction and overview sections. =20 **************************************************** Part 2: **************************************************** =20 1) abbreviations expanded on first use: need to add expansions for: IPR LCD CRCX MDCX DSP SDP DOCSIS CODEC (also shows up as "codec" and "Codec") RTP FSK MAP rg rs cr "Blvd" needs a "." "Inc" needs a "."=20 "Corp" needs a "." PCMU PCMA FQDN MIBMTA RSIP LCD CMS RJ =20 "frequences" should be "frequencies" "playout" should be "play out" (where it is a verb rather than a noun) "dBm" also appears as "dbm" =20 AI: Expanded abbreviations on first use. Fixed spelling. =20 2) two spaces after end of sentence: document needs to be fixed so that TWO spaces occur after "." at the end of a sentence. (2223bis 3.1 (7) =20 AI: Fix in final formating. =20 3) Table of contents / order of sections: the sections of the document are not in the order specified by 2223bis section 4. =20 AI: Fixed. Added Introduction. Reordered references after IANA section. Moved IPR after author's addresses. =20 4) Authors' Addresses and IPR Boilerplate (Full Copyright Statement) sections are supposed to NOT have numbers. =20 AI: Changed. =20 5) On title page, an Author's name should be on a single line, as should his/her affiliation. 2223bis section 4.1 =20 AI: Changed. =20 6) Document is inconsistant in the use of "a"/"an" before acronyms pronounced beginning with a vowel. (E.g. "MTA".) Suggest using "An" consistently. =20 AI: Changed. =20 7) Document uses both "endpoint" and "Endpoint". Is a distinction intended? =20 AI: Changed to lower case except at the start of a sentence. =20 8) "the widest range of marketplaces as is possible" -> "the widest possible range of markets" =20 AI: Changed. =20 10) format of references: =20 a) Author lists need a "," before the "and" if there are more than two authors. See the reference sections in 2223=20 bis for examples. b) If there is more than one author, an "and" is needed c) if there is more than one author, the last author's name is written as "F. Lastname" rather than "Lastname, F." =20 AI: Changed formatting. =20 **************************************************** Part 3 (1-13), Part 4 (14-30) **************************************************** =20 1) guidelines 3.2 para 1: need to describe relationship to other modules. for example, interfaces MIB since ifIndex is part of indexing scheme. =20 AI: Added descriptive text to overview section. =20 2) guidelines 3.2 para 2: need to document in narrative MIB modules (other than SMIv2 docs) from which things are imported =20 AI: Duplicate, see above. =20 3) guidelines 3.7.2: IANA considerations section needs to note that the mib-2 oid assignment for the module identity is needed =20 AI: Duplicate, see part 1 # 10 above. =20 4) the module name and the module-identity descriptor don't follow the recommended practices in guidelines appendix C (second bullet) and other descriptors don't follow the recommended practices in the third and fifth bullets) (I assume TenthdBm is intended for re-use by other MIB modules) =20 AI: Changed module identity descriptor to pktcIetfSigMib per appendix C bullet 2. =20 5) TenthdBm: "This data type" -> "This textual convention" =20 AI: Changed. =20 6) PktcCodecType: "Textual Convention defines " -> "This textual convention defines" =20 AI: Changed. =20 7) PktcCodecType: the ASN.1 comments aren't technically part of the TC. The descriptions of what the various enumerations should be given in the DESCRIPTION clause. (The ASN.1 comments don't hurt, but they're not enough.) =20 AI: Changed. =20 8) PktcCodecType: the "MUST" is inappropriate. It sounds like the intent is to mandate how a registry would operate. Is the likelihood of additional values being added to this enumeration high enough to justify creating an IANA registry, rather than keeping the TC in this MIB module? =20 AI: Changed. =20 9) (general) What are "international objects"? Does this term need to be defined? =20 AI: The use of "international" is a legacy issue dating from initial MIB creation. =20 10) PktcRingCadence: is a "cadence period" the same thing as a "cadence cycle"? =20 AI: Changed period to cycle. =20 11) PktcRingCadence: the sentence "Each bit=20 after the third octet represents 50 ms and 1 represents=20 ring and 0 represents silent." might be clearer if the first "represents" were replaced with "corresponds to", and if the first "and" were "where". ("silent" -> "silence" wouldn't hurt.) =20 AI: Changed. =20 12) PktcRingCadence: are implementations required to enforce any constraints on the values of a) the bit count field, b) the repeatable field, c) the 3 on-off transition limit, d) values for bits beyond the bit count, e) an octet-string length other than the minimum required to encode whatever length is specified in the bit count field? =20 [Sumanth]: A separate reflector thread was started to solicit comments from IPCDN members and the current recommendation is: =20 "This object provides an encoding scheme for ring cadences, including=20 repeatability characteristics. All octets and bit-strings in this object MUST be encoded in network-byte order. =20 The first three higher order octets are reserved. The octets that follow are used to encode a 'bit-string', with each bit corresponding to 50=20 milliseconds. A bit value of '1' indicates the presence of a ring-tone=20 and a bit value of '0' indicates the absence of a ring-tone, for that=20 duration (50 ms). (Note: A minimum number of octets required to encode the bit-string MUST be used. ) =20 The first two of the reserved octets MUST indicate the length of the=20 encoded cadence (in bits) and MUST range between 1 and 264. (Note: The=20 length in bits MUST also be consistent with the number of octets that=20 encode the cadence). The MTA MUST ignore any unused bits in the last octet, but MUST reflect the value as provided on a subsequent SNMP GET. =20 The third of the reserved octets indicates 'repeatability' and MUST=20 be either 0x80 or 0x00 - the former value indicating=20 'repeatability' and the latter indicating 'non-repeatability'. =20 The MTA MUST reject attempts to set a value that violates any of=20 the above requirements." ---------------------------------------------------------------------- =20 The addition below has NOT been incorporated (Do we need it? Unresolved): =20 PktcRingCadence (TC). There was a suggestion for additional text for the fourth=20 octet: "The ring cadence representation starts with the first 1 in the pattern=20 (the leading 0s in the MSB are padding and are to be ignored)." Apparently=20 there was some confusion trying to configure the ring cadence. [sumanth] I think we can drop this. No one seems to have a strong opinion. =20 13) PktcSigType: is any guidance needed on when to use reserved(2) and when to use other(1)? =20 AI: Changed description. =20 14) pktcSigDevCodecComboIndex: where does the range constraint (1..255) come from? There's nothing in the document to justify that particular upper bound. =20 AI: No change. See reflector discussion. =20 15) pktcSigDevCallerIdSigProtocol: the DESCRIPTION needs to spell out what is meant by each enumeration =20 AI: Changed description. =20 16) pktcSigDev*Cadence: wouldn't it be simpler to put these ten objects into a table? just a thought.... =20 AI: No change. =20 17) pktcSigDefMediaStreamDscp: There's no antecedant for "the new connection". Is "new connections" intended? =20 AI: Added the following before sentence starting with "When" to provide context for "new connections": =20 Any currently active connections are not affected by updates to this object. =20 18) pktcSignalingIndex: where does the range constraint (1..255) come from? There's nothing in the document to justify that particular upper bound. =20 AI: No change. See reflector discussion. =20 19) pktcSigDefNcsReceiveUdpPort: where does the lower range constraint come from? =20 AI: No change. IANA registers ports 0-1023 and port 1024 is indicated as reserved. =20 20) pktcSigPowerRingFrequency: for each of the enumeration values, the DESCRIPTION clause should spell out what that value means. =20 AI: Changed description. =20 21) pktcSigPulseSignalType: should spell out what each enumeration value means in the DESCRIPTION. =20 AI: Changed description to list enumerations. =20 22) pktcSigPulseSignalFrequency: does the "must" mean "MUST" in the sense that an attempt to write a value incompatible with the instance's pktcSigPulseSignalType must be rejected? What value does it take / can it be set to for "inapplicable" signal types? =20 AI: Changed must to MUST. Added description for returning inconsistent value for an inapplicable signal type. =20 23) pktcSigPulseSignalDbLevel: What value does it take / can it be set to an inapplicable signal types? =20 =20 AI: Added description for returning inconsistent value for an inapplicable signal type. =20 24) pktcSigPulseSignalDuration: what happens when something attempts to set this to a value that doesn't fall on one of the increment boundaries, or on the wrong increment boundary for the specific signal type? =20 AI: Added description for returning inconsistent value for incorrect increment for a signal type. =20 25) pktcSigPulseSignalPulseInterval: same questions. =20 AI: Added description for returning inconsistent value for incorrect increment for a signal type. =20 26) pktcSigPulseSignalRepeatCount: "must" means "MUST", right? Same questions as (24) and (25). =20 AI: Change must to MUST. Added description for returning inconsistent value for incorrect range. =20 27) pktcSigDevCIDFskAfterRing: how does one know whether a system is "international" or not? Is the table supposed to be of defaults? When "not used", what happens when one tries to get/set this object? =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 28) pktcSigDevCIDFskAfterDTAS: same questions as (27) =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 29) pktcSigDevCIDFskAfterRPAS: same questions as (27) For example, what happens when a system is not international but the pktcSigDevCIDMode is rpAsETS? =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 30) pktcSigDevCIDRingAfterFSK: same as (27) =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 **************************************************** Part 5 (31-71) **************************************************** =20 31) pktcSigDevCIDRingAfterFSK: what is the purpose of the table in the DESCRIPTION? =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 32) pktcSigDevCIDDTASAfterLR: explain what is meant by international, specify how it behaves for get/set on "non-international" systems, explain what the table in the DESCRIPTION is for, and specify what the "not used" behaviour is. =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 33) pktcSigDevVmwiFskAfterDTAS: same as (32) =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 34) pktcSigDevVmwiFskAfterRPAS: same as (32) =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 35) pktcSigDevVmwiDTASAfterLR: same as (32) =20 AI: Replaced historical MIB use of "international" with e line package. Added description for returning inconsistent value. =20 36) pktcSigDevRingCadenceTable: what is V5.2? V5.1 is mentioned elsewhere, but those references don't match this one. =20 AI: Deleted "In V5.2" since E line package contained in 101 909-4, which defines the ring cadences is already noted in the description and references. =20 37) pktcSigDevRingCadenceTable and pktcSigDevRingCadenceIndex: The indexing should probably be 0..127, since that's how its done in the protocol. Adding an offset of 1 doesn't add value in this case, and it appears to increase the likelihood of confusion for the user. =20 AI: Changed to 0 to 127 to match ETSI spec and updated description in associated table objects. =20 38) pktcSigDevRingCadenceTable: what is the lifecycle of entries in this table? When/How are they created and deleted? Do they persist across reboots or power failures? =20 AI: No change. The description already indicates the objects do not persist across reboots. =20 39) pktcSigDevRingCadenceEntry: the DESCRIPTION is the one that belongs on pktcSigDevRingCadenceIndex. =20 AI: Moved description. =20 40) pktcSigDevToneTable: the structure of this table is a bit awkward. It *might* make more sense if it were broken into two tables. The first, indexed by pktcSigDevToneType, would hold pktcSigDevToneDbLevel, pktcSigDevToneFreqType, pktcSigDevToneNumFrequencies, pktcSigDevToneWholeToneRepeatCount, pktcSigDevToneNumOnOffTimes, and pktcSigDevToneSteady. The second would be indexed by pktSigDevToneType and an Unsigned32 (1..4), collapsing pktcSigDevToneFirstFrequency, pktcSigDevToneSecondFrequency, pktcSigDevToneThirdFrequency, and pktcSigDevToneFourthFrequency into pktSigDevTonesFrequency, collapsing pktcSigDevToneFirstToneOn, pktcSigDevToneSecondToneOn, pktcSigDevToneThirdToneOn, and pktcSigDevToneFourthToneOn into pktcSigDevTonesOn, and collapsing pktcSigDevToneFirstToneOff, pktcSigDevToneSecondToneOff, pktcSigDevToneThirdToneOff, and pktcSigDevToneFourthToneOff into pktSigDevTonesOff. This is only a suggestion. =20 Also: 4. pktcSigDevToneTable (pending) - 12 new objects to be proposed per findings from international trials that the current MIB defintion does not support. I have not posted these to the reflector yet as the work is still in progress. =20 [sumanth] The above suggestion is not incorporated in this version.=20 This requires more work and perhaps a future revision will address this. 41) pktcSigDevToneTable: The DESCRIPTION says "Any definition of the tones callWaiting1-4 in this table should just contain the audible tone itself and NOT contain the delay between tones or the tone repeat count." In those cases, how will pktcSigDevToneWholeToneRepeatCount behave on get/set? =20 AI: Changed. Added the following text to the description: =20 If the pktcSigDevToneType is callWaiting1-4, the pktcSigDevToneWholeToneRepeatCount does not apply and MUST be ignored on SNMP set/get operations. =20 42) pktcSigDevToneEntry: the DESCRIPTION has the text that should be on pktcSigDevToneType. The phrase "that are being supported" appears to be at odds with the language in pktcSigDevToneTable that says "for each possible index, an entry MUST be defined". =20 AI: Moved description. =20 43) pktcSigDevToneType: what is meant by "triggered"? This sounds at odds with the language in pktcSigDevToneTable that says "for each possible index, an entry MUST be defined". =20 AI: Changed "triggered" to "used in". =20 44) pktcSigDevTone*Frequency: "could" seems odd in these four. Is this intended to mean that the device might do something else? =20 AI: Changed "could be" to "are". =20 45) pktcSigDevTone*ToneOn and pktcSigDevTone*ToneOff: the DESCRIPTIONS are unclear. For example, does pktcSigDevFirstToneOn represent the length of time that the tone will be on, or does it represent the amount of time that must pass before the tone is turned on? For pktSigDevFirstToneOff, for example, does its value represent the length of time that the tone will be off, or does is represent the amount of time that must elapse after the tone is turned on before it is turned off, or does it represent the amount of time from the beginning of the cadence that must elapse before the tone is turned off? =20 AI: Changed description. ToneOn =3D length of time tone is on. ToneOff = =3D length of time tone is off. =20 46) pktcNcsEndPntConfigTable: there is something wrong with this sentence in the DESCRIPTION: "Each endpoint can be assigned to a its own CMS." =20 AI: Deleted "a". =20 47) pktcNcsEndPntConfigEntry: punctuation in DESCRIPTION: "Entries in pktcNcsEndPntConfigTable ? Each entry" =20 AI: Changed. =20 48) pktcNcsEndPntConfigCallAgentId: "it is highly recommended not to change this object's value through management station during normal operations." Do you mean "during normal operation, using SNMP to change this object's value is NOT RECOMMENDED" or "during normal operation, the use of management operations to change this object's value is NOT RECOMMENDED"? =20 AI: Changed "through management station" to "using SNMP". =20 49) pktcNcsEndPntConfigCallAgentUdpPort: why the limited port range? Where did 2727 come from? =20 AI: No change. Duplicate, see above. 2727 is the IANA default for the MGCP CA port: mgcp-callagent 2727/tcp Media Gateway Control Protocol Call Agent mgcp-callagent 2727/udp Media Gateway Control Protocol Call Agent =20 50) pktcNcsEndPntConfigCallAgentUdpPort: "it is highly recommended not to change this object's value through management station during normal operations." Do you mean "during normal operation, using SNMP to change this object's value is NOT RECOMMENDED" or "during normal operation, the use of management operations to change this object's value is NOT RECOMMENDED"? =20 AI: Changed "through management station" to "using SNMP". =20 51) pktcNcsEndPntConfigPartialDialTO: "contains maximum" -> "contains the maximum" (The description and the descriptor make it sound like the device may use any timeout value, as long as that timeout value is less than this object's value. Is that really the intent? Compare the DESCRIPTIONs of this, pktcNcsEndPntConfigBusyToneTO, and pktcNcsEndPntConfigCriticalDialTO. =20 AI: Added "the". Remainder of comment is unclear. =20 52) pktcNcsEndPntConfigTSMax: "max" -> "maximum" It's not clear from the description what this object controls. It defines a period that is bounded on one end by "the sending of the initial datagram" (whatever that is) but does not say what event is at the other end of the interval. =20 AI: Changed max to maximum. Changed description per PC NCS spec. =20 53) pktcNcsEndPntConfigMax1: the description says this is a threshold, but doesn't say what object or delta/interval it is compared to, and doesn't say what happens when the threshold is crossed. =20 AI: Changed description. Max1 is defined in the PC MGCP spec. =20 54) pktcNcsEndPntConfigMax2: same as (53) =20 AI: Changed description. Max2 is defined in the PC MGCP spec. =20 55) pktcNcsEndPntConfigMax1QEnable: the description is unclear. Where is timer Max1 defined? The only other Max1 in this document is a threshold, rather than a timer. Also, there is an ambiguity in the sentence. It can be read to mean "when Max1 expires, this object will enable or disable the query operation" as well as to mean "the query operation initiated whenever Max1 expires is enabled/disabled by this object." =20 AI: Changed description to refer to thresholds. Max1 and Max2 are thresholds defined in the PC MGCP spec.=20 =20 56) pktcNcsEndPntConfigMax2QEnable: same as (55) =20 AI: Changed description to refer to thresholds. See above (55). =20 57) pktcNcsEndPntConfigMWD: the first and second sentences of the description don't work well together. Taken together, they say the MTA will restart every MWD seconds (or less). This is probably not what is intended. =20 AI: Changed description to refer to initial power on and restart procedure per the PC NCS spec. =20 58) pktcNcsEndPntConfigTdinit: same problem as (57) Could be fixed by changing "after" to "before", but I'm not sure that's what was intended. =20 AI: Changed description to refer to initiating the disconnect procedure with the call agent per PC NCS spec. =20 59) pktcNcsEndPntConfigTdmin, pktcNcsEndPntConfigTdmax, and pktcNcsEndPntConfigTdinit don't work well together. As currently written, the disconnected procedure will be initiated three times, once for each of these three timers. Furthermore, are there any constraints on their relative values? For example, is it OK to set pktcNcsEndPntConfigTdmin to a value larger than that of pktcNcsEndPntConfigTdmax? =20 AI: No change. These values and their relationships are defined in detail in the PC NCS spec. =20 60) pktcNcsEndPntConfigRtoMax / pktcNcsEndPntConfigRtoInit: is there any relationship between these two objects? Why do they have different units? =20 AI: No change. MGCP uses exponentially increasing timers for retransmission. RTO init is the configured initial retransmission timer value in milliseconds (per PC MGCP 4.4.2). =20 61) pktcNcsEndPntConfigStatus: RFC 2579 (page 8, "NOTE WELL") requires any use of RowStatus to specify whether columns may be modified when the row is active, and (page 17) under what circumstance it should/may be taken out of service. See MIB review guidelines section 4.6.4 for details. =20 [sumanth]=20 No restrictions. Made changes to reflect guidelines posted in section 4.6.4 of: http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines -03.txt =20 ---------------------------------------------------------------- See comment posted from NCS reflector dated 9/3 from Eugene. [Eugene's comments =20 > 1. Is the intent for the read-create objects in this table to > be modified while the row is active? =20 Currently, there are no restrictions on the on the modification of any of the exesting conceptual columns. Some implementations may enforce the cross reference integrity of the value in the CallAgentID column with the CMS table. But it's not a mandatory behavior. =20 > 2. If telephony service is canceled or the endpoint is > disconnected, MAY (or MUST) the MTA set the row to inactive? I am not sure what particular is meant by "telephony service is canceled" but there are several conditions which are making the endpoint disabled: CallAgentID can be set to "" (empty), the row can be completely deleted, ifAdminStatus is set to down(2), MtaDisabled is set to true(1), "pktcNcsEndPntConfigStatus" is set to "notInService" by the NMS (for whatever reason). =20 If the endpoint becomes "disconnect", the "pktcNcsEndPntStatusError" MIB Object must be set to disconnected(3) state.=20 =20 Both of these scenarios do not require the MTA to change the "pktcNcsEndPntConfigStatus" value, and the row is still in "active" state (if it exists). =20 In all other respects, handling of "pktcNcsEndPntConfigStatus" object is goverened by SNMPv2-TC SMI. =20 Eugene. ] =20 ------------------------------------------------------------------------ - =20 63) pktcNcsEndPntStatusError: the DESCRIPTION says "Otherwise, the state is unused." Is "state" the same thing as "status" in the rest of the DESCRIPTION? What value does this object have when it is "unused"? =20 AI: Replaced "Othewise the state is unused." with "If pktcMtaDevCmsIpsecCtrl is disabled for the associated Call Agent, the noSecurityAssociation status is not applicable and should not be used by the MTA." =20 64) pktcNcsEndPntStatusError: suggest changing "Otherwise, pktcMtaDevCmsIpsecCtrl is enabled," -> "Otherwise, when pktcMtaDevCmsIpsecCtrl is enabled," =20 AI: Changed. =20 65) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash: are there any constraints on the relationship of the values of these two? =20 AI: Changed description to indicate the max hook flash must be greater than min hook flash. =20 66) pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash, etc.: "This object must only be set via the configuration file during the provisioning process." Is this intended to prohibit provisioning by means other than a configuration file? =20 AI: Yes. =20 67) pktcNcsEndPntConfigPulseDialMinMakeTime, pktcNcsEndPntConfigPulseDialMaxMakeTime, pktcNcsEndPntConfigPulseDialMinBreakTime, pktcNcsEndPntConfigPulseDialMaxBreakTime, and pktcNcsEndPntConfigPulseDialInterdigitTime: constraints with respect to each other? with respect to Hook Flash? =20 AI: Changed descriptions to indicate the max must be greater than min. No formal relationship between min/max make/break. Hook flash is generally longer duration than dial pulse but there is no formal spec. =20 68) Problems in object descriptors (review guidelines =20 AI: No change. Comment about object descriptors is not clear. =20 69) MIB review guidelines appendix C. These are only *suggested* naming conventions, but they're worth considering, especially since the current draft is mostly consistant. Current aberrations that I noticed: =20 PKTC-IETF-SIG-MIB DEFINITIONS ::=3D BEGIN but pktcSigMib MODULE-IDENTITY =20 pktcSigMib MODULE-IDENTITY and PktcSigType ::=3D TEXTUAL-CONVENTION but PktcCodecType ::=3D TEXTUAL-CONVENTION PktcRingCadence ::=3D TEXTUAL-CONVENTION =20 (Assuming TenthdBm ::=3D TEXTUAL-CONVENTION is intended for external use.) =20 pktcSigMib MODULE-IDENTITY and pktcSigMibObjects OBJECT IDENTIFIER ::=3D { pktcSigMib 1 } pktcSigDevConfigObjects OBJECT IDENTIFIER ::=3D pktcSigNotification OBJECT IDENTIFIER ::=3D { pktcSigMib 0 } pktcSigConformance OBJECT IDENTIFIER ::=3D { pktcSigMib 2 } pktcSigCompliances OBJECT IDENTIFIER ::=3D { pktcSigConformance 1 } pktcSigGroups OBJECT IDENTIFIER ::=3D { pktcSigConformance 2 } but pktcNcsEndPntConfigObjects OBJECT IDENTIFIER ::=3D =20 pktcSigCapabilityEntry OBJECT-TYPE but pktcSignalingIndex Unsigned32, pktcSignalingType PktcSigType, pktcSignalingVersion SnmpAdminString, pktcSignalingVendorExtension SnmpAdminString =20 pktcSigMib MODULE-IDENTITY but pktcNcsEndPntConfigTable OBJECT-TYPE and pktcNcsEndPntConfigCallAgentId SnmpAdminString, pktcNcsEndPntConfigCallAgentUdpPort InetPortNumber, pktcNcsEndPntConfigPartialDialTO Unsigned32, pktcNcsEndPntConfigCriticalDialTO Unsigned32, pktcNcsEndPntConfigBusyToneTO Unsigned32, pktcNcsEndPntConfigDialToneTO Unsigned32, pktcNcsEndPntConfigMessageWaitingTO Unsigned32, pktcNcsEndPntConfigOffHookWarnToneTO Unsigned32, pktcNcsEndPntConfigRingingTO Unsigned32, pktcNcsEndPntConfigRingBackTO Unsigned32, pktcNcsEndPntConfigReorderToneTO Unsigned32, pktcNcsEndPntConfigStutterDialToneTO Unsigned32, pktcNcsEndPntConfigTSMax Unsigned32, pktcNcsEndPntConfigMax1 Unsigned32, pktcNcsEndPntConfigMax2 Unsigned32, pktcNcsEndPntConfigMax1QEnable TruthValue, pktcNcsEndPntConfigMax2QEnable TruthValue, pktcNcsEndPntConfigMWD Unsigned32, pktcNcsEndPntConfigTdinit Unsigned32, pktcNcsEndPntConfigTdmin Unsigned32, pktcNcsEndPntConfigTdmax Unsigned32, pktcNcsEndPntConfigRtoMax Unsigned32, pktcNcsEndPntConfigRtoInit Unsigned32, pktcNcsEndPntConfigLongDurationKeepAlive Unsigned32, pktcNcsEndPntConfigThist Unsigned32, pktcNcsEndPntConfigStatus RowStatus, pktcNcsEndPntConfigCallWaitingMaxRep Unsigned32, pktcNcsEndPntConfigCallWaitingDelay Unsigned32, pktcNcsEndPntStatusCallIpAddressType InetAddressType, pktcNcsEndPntStatusCallIpAddress InetAddress, pktcNcsEndPntStatusError INTEGER, pktcNcsEndPntConfigMinHookFlash Unsigned32, pktcNcsEndPntConfigMaxHookFlash Unsigned32, pktcNcsEndPntConfigPulseDialInterdigitTime Unsigned32, pktcNcsEndPntConfigPulseDialMinMakeTime Unsigned32, pktcNcsEndPntConfigPulseDialMaxMakeTime Unsigned32, pktcNcsEndPntConfigPulseDialMinBreakTime Unsigned32, pktcNcsEndPntConfigPulseDialMaxBreakTime Unsigned32 =20 AI: Changed MIB module name to pktcIetfSigMib. No other name changes made.=20 =20 70) MIB review guidelines section 3.2 second paragraph =20 AI: Duplicate, see above. Overview section changed to include narrative on MIB modules. =20 71) MIB review guidelines section 3.7.2 =20 AI: Duplicate, see above. IANA section added. ************************************************ Sumanth's collection: ********************************************************* In the DESCRIPTION of a number of MIB objects, the term "international systems" has been replaced by "E package" in draft 6. This introduces the side-effect that a number of MIB objects that have nothing to do with E package support, now only have to be supported when the E package is supported. The following MIB objects are the ones I believe have nothing to do with the E package, since the caller ID and VMWI transmissions are triggered using the L package: pktcSigDevCIDMode pktcSigDevCIDFskAfterRing pktcSigDevCIDFskAfterDTAS pktcSigDevCIDFskAfterRPAS pktcSigDevCIDRingAfterFSK pktcSigDevCIDDTASAfterLR pktcSigDevVmwiFskAfterDTAS pktcSigDevVmwiFskAfterRPAS pktcSigDevVmwiDTASAfterLR An MTA for the international market that does however not support the E package, will want to support the above MIB objects. Maybe we can revert to the description of "international systems"? Thanks, Regards, David [Sumanth] This was turned down since 'International Systems' is not=20 defined. Changed it to be 'Euro-PacketCable' instead. *********************************************************=20 **************************************************** Reflector Comments **************************************************** =20 1. Changed default value of pktcNcsEndPntConfigMaxHookFlash from 500 to 800. =20 2. Added text to description to indicate wholetonerepeatcount and pktcSigDevToneSteady do not override the duration in an associated timeout (TO) object. =20 **************************************************** Other **************************************************** * Added ilbc and bv16 to PktcCodecType. * Deleted pktcSigDevCodecType object from the pktcSigGroup group - this clears a compile error for some MIB compilers. * Posted and updated text for pktcSigDevToneWholeToneRepeatCount and pktcSigDevToneSteady per issue raised by Satish. * Reverted changes to objects identified by tcomlabs in posting dated 9/30. Shame on me for late night editing and not checking package compliance. * pktcSigDevToneTable (pending) - 12 new objects to be proposed per findings from international trials that the current MIB defintion does not support. I have not posted these to the reflector yet as the work is still in progress. Regards Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 28 22:07:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21112 for ; Thu, 28 Oct 2004 22:07:47 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMPL-0007qu-PR for ipcdn-archive@ietf.org; Thu, 28 Oct 2004 22:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNJgw-0004xY-04; Thu, 28 Oct 2004 19:28:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNGyc-00086H-GL for ipcdn@megatron.ietf.org; Thu, 28 Oct 2004 16:34:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05711 for ; Thu, 28 Oct 2004 16:34:29 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNHCl-0001m4-AE for ipcdn@ietf.org; Thu, 28 Oct 2004 16:49:07 -0400 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 i9SKXt1e022634; Thu, 28 Oct 2004 14:33:56 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-05.txt Date: Thu, 28 Oct 2004 14:33:55 -0600 Message-ID: Thread-Topic: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-05.txt Thread-Index: AcS9FB7vh/1FoHfQR7KSZDP46kiCXQAGSonw From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: enechamkin@broadcom.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable The ipcdn mtamib draft 05 addresses all the 'MUST fix' comments received = from Dave Thaler, see my email response from 8/19. Jean-Fran=E7ois=20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Thursday, October 28, 2004 8:58 AM > To: i-d-announce@ietf.org > Cc: ipcdn@ietf.org > Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. This draft is a work item of the=20 > IP over Cable Data Network Working Group of the IETF. >=20 > Title : Multimedia Terminal Adapter (MTA)=20 > Management Information > Base for PacketCable and IPCablecom=20 > compliant devices > Author(s) : E. Nechamkin, J. Mule > Filename : draft-ietf-ipcdn-pktc-mtamib-05.txt > Pages : 51 > Date : 2004-10-27 > =09 > This memo defines a portion of the Management Information Base (MIB)=20 > for use with network management protocols in the Internet community.=20 > In particular, it defines a basic set of managed objects for=20 > SNMP- based management of PacketCable and IPCablecom=20 > compliant Multimedia=20 > Terminal Adapter devices. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtam ib-05.txt To remove yourself from the I-D Announcement list, send a message to=20 i-d-announce-request@ietf.org with the word unsubscribe in the body of = the message. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce=20 to change your subscription settings. 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-05.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html=20 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-05.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader = implementation to automatically retrieve the ASCII version of the = Internet-Draft. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Oct 28 22:22:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23361 for ; Thu, 28 Oct 2004 22:22:54 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNMe0-0008P4-4v for ipcdn-archive@ietf.org; Thu, 28 Oct 2004 22:37:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNK1j-0006RP-Vf; Thu, 28 Oct 2004 19:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNIEh-00021m-Jc for ipcdn@megatron.ietf.org; Thu, 28 Oct 2004 17:55:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21712 for ; Thu, 28 Oct 2004 17:55:09 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNISq-0006T0-T0 for ipcdn@ietf.org; Thu, 28 Oct 2004 18:09:49 -0400 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 i9SLsb1e009218; Thu, 28 Oct 2004 15:54:38 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis Date: Thu, 28 Oct 2004 15:54:37 -0600 Message-ID: Thread-Topic: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis Thread-Index: AcSr3pOlXSLjo5geSsqj7YH6bRjMFwRTzfUQ From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: Eduardo Cardona , david.raftus@terayon.com, bwijnen@lucent.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Just to close the loop on this mib, we received no comments on this post. It is therefore our intent to request its publication. -- Rich and Jean-Francois. > -----Original Message----- > From: Jean-Francois Mule=20 > Sent: Wednesday, October 06, 2004 1:57 PM > To: ipcdn@ietf.org > Cc: Eduardo Cardona; david.raftus@terayon.com > Subject: [ipcdn] status of ipcdn DOCSIS RFIv2 mib - 2670bis >=20 >=20 >=20 > This note provides a brief status update on the ipcdn DOCSIS RFIv2 > mib Internet-Draft. It is also a follow-up from the IETF=20 > meeting #60 in > San Diego. >=20 > --- Brief status > The current ID is draft-ietf-ipcdn-docs-rfmibv2-11.=20 > =20 ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt A working group last call was issued on 1/23/2004 and ended on 2/6/2004. The authors believe that draft 11 does address all the wg comments as well as AD review comments from Bert. Based on the input received this week from the authors and the current editor Eduardo, no new comments have been received since the ID was revised at the end of July 2004. --- San Diego wg meeting follow-up Based on our meeting minutes at http://www.ietf.org/proceedings/04aug/171.htm#rfimib , we wanted to ping the mailing list to see if another WGLC is needed. If you think a second WGLC should be issued, please let the ipcdn wg know by sending an email to the list by Wednesday October 13, 5pm ET. --- Next steps Pending wg consensus that a new WGLC is not needed and no objection to move this ID forward, it is the wg chairs intent to submit the ID for publication/IESG review to Bert. Rich and Jean-Francois. IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Oct 29 17:21:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14220 for ; Fri, 29 Oct 2004 17:21:25 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNePx-0002gu-VG for ipcdn-archive@ietf.org; Fri, 29 Oct 2004 17:36:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdkP-0004aA-16; Fri, 29 Oct 2004 16:53:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdCz-0004Ez-2V for ipcdn@megatron.ietf.org; Fri, 29 Oct 2004 16:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03223 for ; Fri, 29 Oct 2004 16:18:46 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdRK-00084j-74 for ipcdn@ietf.org; Fri, 29 Oct 2004 16:33:38 -0400 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 i9TKIC1e002257 for ; Fri, 29 Oct 2004 14:18:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Draft Agenda for the IETF#61 IPCDN Nov 9 2004 meeting in Washington DC Date: Fri, 29 Oct 2004 14:18:12 -0600 Message-ID: Thread-Topic: [ipcdn] Draft Agenda for the IETF#61 IPCDN Nov 9 2004 meeting in Washington DC Thread-Index: AcR4uuU8rfQDBRxZSKK+nsZFvvTiKRFMBYZQ From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Here's a proposed agenda for the IPCDN WG meeting in Washington DC. Comments appreciated. =20 IP over Cable Data Network WG (ipcdn) IETF #61 =20 TUESDAY, November 9, 2004, from 1300 to 1400 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 Chairs: Richard Woundy Jean-Francois Mule =20 AGENDA: =20 I. Agenda Bashing =20 II. Administration Review WG Charter & milestones update http://www.ietf.org/html.charters/ipcdn-charter.html=20 Except may be for the PacketCable/IPCableCom MTA event MIB, we have met or are very close to meet our wg milestones for September 2004. III. IPCDN DOCSIS mibs =20 Discuss latest status of all DOCSIS mibs Discuss IESG comments o DOCSIS BPI+ MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-14.txt o DOCSIS QoS MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt o RF MIB v2 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt o DOCSIS Event Notification MIB=20 http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-04. txt o DOCSIS Cable Device MIB version 2 We are hitting a roadblock on the cable dev mib and need a new ID editor. http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-06.txt IV. IPCablecom/PacketCable Submissions o MTA MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-05.txt o Signaling MIB http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.t xt=20 V. Next steps Let us know what else you would like to see covered in our 1h meeting (in addition to, or in lieu of the current proposed items). -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Oct 29 17:45:30 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16942 for ; Fri, 29 Oct 2004 17:45:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNenG-0003OI-5B for ipcdn-archive@ietf.org; Fri, 29 Oct 2004 18:00:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNe56-0003H2-LL; Fri, 29 Oct 2004 17:14:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNdbJ-0000tp-1A for ipcdn@megatron.ietf.org; Fri, 29 Oct 2004 16:43:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09070 for ; Fri, 29 Oct 2004 16:43:54 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNdpd-0001KN-DE for ipcdn@ietf.org; Fri, 29 Oct 2004 16:58:46 -0400 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 i9TKhL1e007964; Fri, 29 Oct 2004 14:43:21 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] status of ipcdn draft-ietf-ipcdn-docsisevent-mib-04 Date: Fri, 29 Oct 2004 14:43:21 -0600 Message-ID: Thread-Topic: [ipcdn] status of ipcdn draft-ietf-ipcdn-docsisevent-mib-04 Thread-Index: AcSr3pOlXSLjo5geSsqj7YH6bRjMFwRTzfUQADIX42A= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Cc: gnakanishi@motorola.com, azlina@protegonetworks.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Re: draft-ietf-ipcdn-docsisevent-mib-04.txt, a WGLC ended on 8/26/2004. http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docsisevent-mib-04. txt No comments were received by the ID authors or on the list. Based on the authors' requests, we will request IETF publication. Rich and Jean-Francois. IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Oct 29 21:00:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01128 for ; Fri, 29 Oct 2004 21:00:42 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNhqB-00071q-HZ for ipcdn-archive@ietf.org; Fri, 29 Oct 2004 21:15:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNhTg-00075S-VJ; Fri, 29 Oct 2004 20:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNhNt-0004nh-BV for ipcdn@megatron.ietf.org; Fri, 29 Oct 2004 20:46:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00271 for ; Fri, 29 Oct 2004 20:46:19 -0400 (EDT) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNhcG-0006oZ-Hk for ipcdn@ietf.org; Fri, 29 Oct 2004 21:01:13 -0400 Received: from h-66-167-205-76.snvacaid.dynamic.covad.net ([66.167.205.76] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CNhNm-0004fn-00 for ipcdn@ietf.org; Fri, 29 Oct 2004 17:46:14 -0700 Message-ID: <008a01c4be1a$0216eae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Submission: IETF NCS Signaling MIB draft 7 (Update) Date: Fri, 29 Oct 2004 17:47:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi - > From: "Sumanth Channabasappa" > To: > Sent: Thursday, October 28, 2004 12:54 PM > Subject: [ipcdn] Submission: IETF NCS Signaling MIB draft 7 (Update) ... > 51) pktcNcsEndPntConfigPartialDialTO: > "contains maximum" -> "contains the maximum" (The description and the > descriptor make it sound like the device may use any timeout value, as > long as that timeout value is less than this object's value. Is that > really the intent? Compare the DESCRIPTIONs of this, > pktcNcsEndPntConfigBusyToneTO, and pktcNcsEndPntConfigCriticalDialTO. > > AI: Added "the". Remainder of comment is unclear. Here's an example. If I set this object to 100, and the device times out at 50, that's a conformant implementation, according to this wording. Is that really what you want? Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Sat Oct 30 14:23:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09003 for ; Sat, 30 Oct 2004 14:23:10 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CNy7B-00075K-KK for ipcdn-archive@ietf.org; Sat, 30 Oct 2004 14:38:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNxhQ-0005jl-Ps; Sat, 30 Oct 2004 14:11:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CNxbC-00037N-Rv; Sat, 30 Oct 2004 14:05:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08077; Sat, 30 Oct 2004 14:05:09 -0400 (EDT) Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CNxph-0006le-7E; Sat, 30 Oct 2004 14:20:12 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jma4183dfe9; Sun, 31 Oct 2004 02:06:40 +0800 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmd417eea6e; Wed, 27 Oct 2004 06:56:55 +0800 Received: from megatron.ietf.org([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm4417ed7d1; Wed, 27 Oct 2004 06:56:55 +0800 Received: from megatron.ietf.org([132.151.6.71]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 27 Oct 2004 06:56:55 +0800 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMYp3-0000aI-Jv; Tue, 26 Oct 2004 17:25:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CMY1y-0006HF-Hf; Tue, 26 Oct 2004 16:34:58 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14172; Tue, 26 Oct 2004 16:34:56 -0400 (EDT) Message-Id: <200410262034.QAA14172@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 26 Oct 2004 16:34:56 -0400 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-07.txt X-BeenThere: ipcdn@ietf.org Reply-To: internet-drafts@ietf.org List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Network-Based Call Signaling (NCS) Signaling MIB for PacketCable and IPCablecom Multimedia Terminal Adapters (MTAs) Author(s) : G. Beacham, et al. Filename : draft-ietf-ipcdn-pktc-signaling-07.txt Pages : 60 Date : 2004-10-26 This memo defines the Signaling Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it provides a common data and format representation for PacketCable/IPCablecom compliant Multimedia Terminal Adapter devices. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2. The set of objects are consistent with the SNMP framework and existing SNMP standards. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-pktc-signaling-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.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-10-26160944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-26160944.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart--