From mailman-bounces@ietf.org Thu Jul 1 06:51:12 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13777 for ; Thu, 1 Jul 2004 06:51:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bfz9s-0002SM-Dc for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 06:51:12 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bfz96-00024V-00 for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 06:50:24 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bfz8M-0001e1-00 for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 06:49:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bfxee-00015s-NE for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 05:14:52 -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: Thu, 01 Jul 2004 05:03:26 -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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 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 Thu Jul 1 13:19:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18713 for ; Thu, 1 Jul 2004 13:19:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg5E2-0006GZ-UL for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 13:19:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg5Bs-0005Uc-00 for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 13:17:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bg5BF-00056F-01 for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 13:17:02 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bg4Hy-0001eT-6G for ipcdn-archive@ietf.org; Thu, 01 Jul 2004 12:19:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4td-0004Oi-DB; Thu, 01 Jul 2004 12:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg4V6-0006z2-1Q for ipcdn@megatron.ietf.org; Thu, 01 Jul 2004 12:33:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15383 for ; Thu, 1 Jul 2004 12:33:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg4V5-00032H-5Q for ipcdn@ietf.org; Thu, 01 Jul 2004 12:33:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg4U6-0002dG-00 for ipcdn@ietf.org; Thu, 01 Jul 2004 12:32:27 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx with esmtp (Exim 4.12) id 1Bg4TB-0002Ed-00 for ipcdn@ietf.org; Thu, 01 Jul 2004 12:31:29 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id i61GRGJE020494 for ; Thu, 1 Jul 2004 09:27:16 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id i61GVAf7017285 for ; Thu, 1 Jul 2004 11:31:10 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 1 Jul 2004 09:31:23 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Date: Thu, 1 Jul 2004 09:31:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Subject: [ipcdn] re: pktcSigPulseSignalDbLevel range 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="===============0069339291==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE, MIME_BASE64_TEXT,MIME_HTML_NO_CHARSET autolearn=no version=2.60 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. --===============0069339291== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45F88.D72B59F0" 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_01C45F88.D72B59F0 Content-Type: text/plain In reviewing the ipcdn archives I note we did not achieve resolution on the revised syntax range for the pktcSigPulseSignalDbLevel object. See: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01077.html >In looking at the meter pulse range for this object, the max value specified in 300 001 is for Sweden (-30 dBm). >Motorola recommends setting the range of this object to (-350..0) to accommodate Sweden and to allow some margin for other international countries. Comments? Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com ------_=_NextPart_001_01C45F88.D72B59F0 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0MDAiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFz cz0yOTcyMDU5MTUtMDEwNzIwMDQ+SW4gcmV2aWV3aW5nIHRoZSANCmlwY2RuIGFyY2hpdmVzIEkg bm90ZSB3ZSBkaWQgbm90IGFjaGlldmUgcmVzb2x1dGlvbiBvbiB0aGUgcmV2aXNlZCBzeW50YXgg cmFuZ2UgDQpmb3IgdGhlIHBrdGNTaWdQdWxzZVNpZ25hbERiTGV2ZWwgb2JqZWN0LiBTZWU6IDxB IA0KaHJlZj0iaHR0cDovL3d3dzEuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9pcGNkbi9jdXJy ZW50L21zZzAxMDc3Lmh0bWwiPmh0dHA6Ly93d3cxLmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv aXBjZG4vY3VycmVudC9tc2cwMTA3Ny5odG1sPC9BPjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9Mjk3MjA1OTE1LTAxMDcyMDA0 PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UPjxTUEFOIGNsYXNzPTI5NzIw NTkxNS0wMTA3MjAwND4mZ3Q7SW4gbG9va2luZyBhdCB0aGUgbWV0ZXIgcHVsc2UgDQpyYW5nZSBm b3IgdGhpcyBvYmplY3QsIHRoZSBtYXggdmFsdWUgc3BlY2lmaWVkIGluIDMwMCAwMDEgaXMgZm9y IFN3ZWRlbiAoLTMwIA0KZEJtKS48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVD48U1BB TiBjbGFzcz0yOTcyMDU5MTUtMDEwNzIwMDQ+Jmd0O01vdG9yb2xhIHJlY29tbWVuZHMgc2V0dGlu ZyB0aGUgDQpyYW5nZSBvZiB0aGlzIG9iamVjdCB0byAoLTM1MC4uMCkgdG8gYWNjb21tb2RhdGUg U3dlZGVuIGFuZCB0byBhbGxvdyBzb21lIG1hcmdpbiANCmZvciBvdGhlciBpbnRlcm5hdGlvbmFs IGNvdW50cmllcy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVD48U1BBTiBjbGFzcz0y OTcyMDU5MTUtMDEwNzIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz0yOTcyMDU5MTUtMDEwNzIwMDQ+Q29tbWVu dHM/PC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQ QU4gDQpjbGFzcz0yOTcyMDU5MTUtMDEwNzIwMDQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+R29yZG9uIEJlYWNoYW08QlI+RGlnaXRhbCBD b3JlIEdhdGV3YXlzLCANCkJDUzxCUj5Nb3Rvcm9sYSwgDQpJbmMuPEJSPjg1OC00MDQtMjMzNTxC Uj5nb3Jkb24uYmVhY2hhbUBtb3Rvcm9sYS5jb208L0ZPTlQ+PEJSPjwvRElWPjwvQk9EWT48L0hU TUw+DQo= ------_=_NextPart_001_01C45F88.D72B59F0-- --===============0069339291== 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 --===============0069339291==-- From ipcdn-bounces@ietf.org Fri Jul 2 05:44:27 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21235 for ; Fri, 2 Jul 2004 05:44:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgKaq-0007HI-27 for ipcdn-archive@ietf.org; Fri, 02 Jul 2004 05:44:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgKZa-0006on-00 for ipcdn-archive@ietf.org; Fri, 02 Jul 2004 05:43:11 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BgKYN-00069H-00 for ipcdn-archive@ietf.org; Fri, 02 Jul 2004 05:41:56 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BgKYM-0003dX-FQ for ipcdn-archive@ietf.org; Fri, 02 Jul 2004 05:41:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgKOE-0005B3-Br; Fri, 02 Jul 2004 05:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgK7a-0005jr-DB for ipcdn@megatron.ietf.org; Fri, 02 Jul 2004 05:14:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19266 for ; Fri, 2 Jul 2004 05:14:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgK7V-0003mW-RH for ipcdn@ietf.org; Fri, 02 Jul 2004 05:14:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgK6W-0003QN-00 for ipcdn@ietf.org; Fri, 02 Jul 2004 05:13:09 -0400 Received: from astra.telenet-ops.be ([195.130.132.58]) by ietf-mx with esmtp (Exim 4.12) id 1BgK5V-00034B-00 for ipcdn@ietf.org; Fri, 02 Jul 2004 05:12:05 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id BB7CC388089 for ; Fri, 2 Jul 2004 11:12:05 +0200 (MEST) Received: from tcomlabs.com (D5E00496.kabel.telenet.be [213.224.4.150]) by astra.telenet-ops.be (Postfix) with ESMTP id 5DFA8388141 for ; Fri, 2 Jul 2004 11:12:05 +0200 (MEST) Received: (qmail 22048 invoked from network); 2 Jul 2004 11:06:12 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 2 Jul 2004 11:06:12 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 2 Jul 2004 11:06:12 +0200 (CEST) From: "David De Reu" To: "Beacham Gordon-CGB005" , Subject: RE: [ipcdn] re: pktcSigPulseSignalDbLevel range Date: Fri, 2 Jul 2004 11:12:04 +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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 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="===============0390886195==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --===============0390886195== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C46025.67F6A3D0" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C46025.67F6A3D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message>In looking at the meter pulse range for this object, the max value specified in 300 001 is for Sweden (-30 dBm). >Motorola recommends setting the range of this object to (-350..0) to accommodate Sweden and to allow some margin for other international countries. Comments? Since there doesn't seem to be a reason to keep the old (large) range, and since the proposed restriction can only facilitate MTA design, we agree with the (-350..0) range. 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 _____________________________________________________ ------=_NextPart_000_000C_01C46025.67F6A3D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
>In looking = at the meter=20 pulse range for this object, the max value specified in 300 001 is for = Sweden=20 (-30 dBm).
>Motorola = recommends=20 setting the range of this object to (-350..0) to accommodate Sweden = and to=20 allow some margin for other international = countries.
 
Comments? 
 
Since=20 there doesn't seem to be a reason to keep the old (large) range, and = since the=20 proposed restriction can only facilitate MTA design, we agree with the = (-350..0)=20 range.
 
Regards,
 
David

_____________________________________________________ 
D= avid De=20 Reu
tComLabs
Stapelplein 70/004 – 9000 Ghent – = Belgium
Tel: +32 9 269=20 22 91 – Fax: +32 9 329 31=20 74
www.tComLabs.com
_______________________________________________= ______=20

------=_NextPart_000_000C_01C46025.67F6A3D0-- --===============0390886195== 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 --===============0390886195==-- From ipcdn-bounces@ietf.org Mon Jul 5 12:33:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05779 for ; Mon, 5 Jul 2004 12:33:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhWPG-0006AS-K3 for ipcdn-archive@ietf.org; Mon, 05 Jul 2004 12:33:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhWOH-0005so-00 for ipcdn-archive@ietf.org; Mon, 05 Jul 2004 12:32:26 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhWNc-0005Ks-00 for ipcdn-archive@ietf.org; Mon, 05 Jul 2004 12:31:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhW4W-0001PQ-Kx; Mon, 05 Jul 2004 12:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3j4-0004zo-9R for ipcdn@megatron.ietf.org; Thu, 01 Jul 2004 11:43:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12167 for ; Thu, 1 Jul 2004 11:43:48 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg3j3-0006U6-FK for ipcdn@ietf.org; Thu, 01 Jul 2004 11:43:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3iJ-00064a-00 for ipcdn@ietf.org; Thu, 01 Jul 2004 11:43:04 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3hN-0005e9-00; Thu, 01 Jul 2004 11:42:05 -0400 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i61FeftH025948; Thu, 1 Jul 2004 11:40:41 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i61FectH025839; Thu, 1 Jul 2004 11:40:39 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Jul 2004 18:41:59 +0300 Message-ID: Thread-Topic: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Thread-Index: AcRUoQrzrk2YeJA3Ri+90L5skCPcRgK3+QSg From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 05 Jul 2004 12:11:59 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable I have some concerns with respect to the Security Considerations = section. It is not aligned with the latest guidelines = (http://www.ops.ietf.org/mib-security.html), probably reflecting the = style or the guidelines that were in place by the time RFC 2925 was = published. However, I miss the clarity of the current text, and = especially the enumeration of the security sensitive objects in the MIB = modules, the explicit description of the risks associated with their = mis-configuration or disclosure, and the explicit recommendation to = deploy SNMPv3 and to enable cryptographic security. Regards, Dan > -----Original Message----- > From: disman-bounces@ietf.org=20 > [mailto:disman-bounces@ietf.org]On Behalf Of Randy Presuhn > Sent: 17 June, 2004 9:55 PM > To: disman@ietf.org > Cc: ipcdn@ietf.org > Subject: [Disman] Disman WG last call=20 > ondraft-ietf-disman-remops-mib-v2-02.txt >=20 >=20 > Hi - >=20 > As disman WG chair, I'm announcing the start of a two-week=20 > working group > last call on the Remote Operations MIBs. The latest version=20 > is available at > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-m > ib-v2-02.txt > Our objective is to advance to Draft Standard. Off-line I've received > word that that we will have at least two implementation reports. I'm > fairly sure there are more out there, so please speak up if=20 > you know of > an implementation. >=20 > I'm CC:ing the ipcdn WG mailing list, since we've incorporated some > additional conformance material to meet (I hope) their needs. Please > send any comments, including "I've read it and don't object" comments, > to the disman WG mailing list at disman@ietf.org. >=20 > The last call will end on Friday, July second, 2004. If=20 > anyone is committed > to reviewing it but would need additional time, let me know=20 > and I'll see what > we can work out. >=20 > Randy >=20 >=20 >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jul 5 12:33:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05797 for ; Mon, 5 Jul 2004 12:33:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhWPH-0006Ac-TF for ipcdn-archive@ietf.org; Mon, 05 Jul 2004 12:33:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhWOJ-0005t4-00 for ipcdn-archive@ietf.org; Mon, 05 Jul 2004 12:32:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BhWNn-0005bN-00 for ipcdn-archive@ietf.org; Mon, 05 Jul 2004 12:31:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhW4W-0001PV-Rd; Mon, 05 Jul 2004 12:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQAB-0002Ca-D8 for ipcdn@megatron.ietf.org; Mon, 05 Jul 2004 05:53:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17337 for ; Mon, 5 Jul 2004 05:53:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhQA4-0000q6-9z for ipcdn@ietf.org; Mon, 05 Jul 2004 05:53:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQ98-0000Y5-00 for ipcdn@ietf.org; Mon, 05 Jul 2004 05:52:24 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1BhQ8G-0007ll-00; Mon, 05 Jul 2004 05:51:28 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A77271BAC4D; Mon, 5 Jul 2004 11:50:55 +0200 (CEST) Date: Mon, 05 Jul 2004 11:51:18 +0200 From: Juergen Quittek To: Eduardo Cardona , Randy Presuhn , disman@ietf.org Subject: RE: [ipcdn] Re: [Disman] WG last call ondraft-ietf-disman-remops-mib-v2-01.txt Part1 Message-ID: <2147483647.1089028278@[10.1.1.171]> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 05 Jul 2004 12:11:59 -0400 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Eduardo, Many thanks for your comments. Please find some replies inline. --On 22.06.2004 11:42 Uhr -0600 Eduardo Cardona wrote: > Thanks Jurgen for adding the Minimal compliance in the new draft > > Few comments: > > Draft is not indicating in upper header that is obsoleting RFC 2925 I think the RFC editor will take care of this issue. I did not dare yet using an "Obsoletes:" entry in the header while having an "Expires:" entry in the line below :-) > DISMAN-PING-MIB > > Since the objects are carried from a previous RFC, The extra comments I > got for objects are not critical, although I went to the exercise of > understanding and may worth for direct clarifications to me if I > misunderstood them > > Please pay special attention to the new minimum compliance modules > comments (under ****) > > > pingCtlTrapGeneration > I see a lot of overlapping in between probeFailures and TestFailures > because both are within a ping Test. Making that very punctual for > notification stand point > > One approach (two layers) could be that TestFailure notification is only > sent after multiple Test Failures Exactly this is the case, see pingCtlTrapTestFailureFilter. Or did I get something wrong? > ( based on the Frequency object may > indicate reasonable periods of hosts disconnection) so you can avoid > getting ProbeFailure notification but use this counter for accumulate > Test failures, then collect notifications only for Test failures periods > -probeFailure(0) set to '0'. In the other hand setting probeFailure(0) > to '1' will get the time details of the probe failures that constitute a > Test failure. I don't really get this. We have a counter for probe failures and a counter for test failures. Both can be switched on and off independently by setting the corresponding bits in pingCtlTrapGeneration. > - also does "sucessive" means consecutive? Let's replace "sucessive" by "consecutive". Any objection from native English speakers? > If Filter is set to 3 > 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7) > reply > Means ProbeFailure happen between 4) and 6) As far as I understand the current DESCRIPTION clause, the notification is triggered by 6). > I think the testFailure(1) BIT should indicate that a Test Failure is > reached by the threshold of pingCtlTrapProbeFailure rather than > pingCtlTrapTestFailure. Moreover the definitions of > pingCtlTrapGeneration and > pingCtlTrapProbeFailureFilter/pingCtlTrapTestFailureFilter are > overlapping and probably redundant. The bit testFailure(1) does not indicate that any failure happened, it indicates that generation of notification in such a case is enabled. As far as I understood the descriptions so far, a test is failed only if all probes failed. I must admit that this is not explicitly specified. Any comment from an implementer? > A possible wording to illustrate the comment could be: > "... > For > pingCtlTrapGeneration > DESCRIPTION > "The value of this object determines when and if > to generate a notification for this entry: > > probeFailure(0) - Generate a pingProbeFailed > notification subject to the value of > pingCtlTrapProbeFailureFilter. > testFailure(1) - Generate a pingTestFailed > notification. A Test Failure condition is defined > if within a test the number of probe failures > reaches the value of pingCtlTrapProbeFailureFilter > testCompletion(2) - Generate a pingTestCompleted > notification. > > By default, no bits are set, indicating that > none of the above options are selected." > > pingCtlTrapProbeFailureFilter/TestFailureFilter > the description of pingCtlTrapProbeFailureFilter is not Clear to me if > after the # of probe failures of the ProbeFailureFilter object are > reached a notification is sent and if the counter is cleared > > e.g. > pingCtlTrapProbeFailureFilter = 5 > pingCtlProbeCount = 15 > Supposed all ping probes timed out, > Will it send notification after attempts 5, 10 and 15 > or > After attempts 5,6,7,....15 > A possible wording could be ( only sending notifications after attempts > 5, 10 and 15: You are right. This case is not well specified. > pingCtlTrapProbeFailureFilter > "The value of this object is used to determine when > to generate a pingProbeFailed NOTIFICATION. > > Setting pingCtlTrapGeneration BIT probeFailure(0) > to '1' implies that a pingProbeFailed I think we can omit "to '1'". > NOTIFICATION is generated only when a number of > successive ping probes equal to the value of > pingCtlTrapPrbefailureFilter fail within > a given ping test. Then a Test failure condition is > reached and the probe failure count is > reset for the following attempts within the > given ping test." I disagree with the first part of the last sentence "Then a Test failure condition is reached", but I agree to the rest. > Similar for pingCtlTrapTestFailureFilter > "The value of this object is used to determine when > to generate a pingTestFailed NOTIFICATION. > > Setting pingCtlTrapGeneration BIT testFailure(1) > to '1' implies that a pingTestFailed NOTIFICATION is > generated only when the number of test failures > within a test exceed the value of > pingCtlTrapTestFailureFilter." He also need to add a statement on reseeting the test failure counter when the notification is sent. > Above is also included a small wording for the BIT sets > > pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to > conform with RFC3291 bis draft 03 Fine with me. Any objections from the "Who needs IPv6?" community? > > MinimumCompliance > ***************** > > PingCtlRowStatus has a compliance SYNTAX read-only; some clarifications > in how the minimum compliance default entry > All time with value 'active' ? > Regularly a 'notReady' entry when filled all the minimum object sets > becomes 'notInService' and need to be set to 'active' via SNMP to > complete the operation In read-only mode it has three possible values: - 'notReady' as long as pingCtlTargetAddress is not specified. - 'notInService' starting when pingCtlTargetAddress specified until pingCtlAdminStatus is set to enabled(1). - 'active' after pingCtlAdminStatus has been set to enabled(1) in state 'notInService'. - again 'notInService' after pingCtlAdminStatus has been set to disabled(1) in stat 'active'. > a) Will the compliance statement should say that a 'notReady' is > automatically set to 'active' when all fields (specially when > pingCtlTargetAddress is set?) No, it will automatically be set to 'notInService'. > would that be valid request? -not included > in the state diagram of RowStatus TC- >From 'notInService', transitions to 'active' can only be reached by setting pingCtlAdminStatus. (as specified in the DESCRIPTION clause of pingCtlRowStatus). Note, that setting pingCtlTargetAddress and pingCtlAdminStatus should still be possible with just a single SNMP PDU. > Or > b) more general the pingCtlAdminStatus should indicate an error when > attempting to start (enabled(1) the test and the entry is notReady(2) / > notInService(1) ? > > And probably the MinumimCompliance may need a SYNTAX clause like Yes, this is missing. > SYNTAX RowStatus { notReady(3), active(1)} It should look like SYNTAX RowStatus { active(1), notInService(2), notReady(3)} Probably it would be a good idea to explain the state transitions (as described above) in the corresponding DESCRIPTION clause. > Object Compliances > pingCtlFrequency r-o; last sentence "A value zero means... " may not be > needed any case, the test is not repeated and 0 value already defined In > the object description I agree that the sentence is redundant. I thought it would help understanding the compliancy more quickly, but I have no strong feeling about keeping or removing the sentence. Any further opinions? > Normalization of SYNTAX sub-typing as in other objects. -- Just a > comment Up to MIB doctor for style normalization in the compliances.. > pingCtlStorateType can have a SYNTAX clause > SYNTAX StorageType { volatile(2)} I think this is more strict. I did not intend to exclude. for example, 'permanent' entries. >> From RFC 2925 the Compliance statement has under pingGroup the objects > of Ctl, Results, History and the Notification Group > > Since the minimal compliance has only Ctl, Results objects I think is > better to define a MANDATORY-GROUP pingMinGroup including Ctl and > Results Objects. So the original group is left intact (unless specific > compliances are needed as pingComplianceV2 (if there are important > differences with the original Compliance) What about just renaming the new pingGroup to pingMinimumGroup? > - Will be ok with MIB doctor perception of this compliances > ramifications > > > > DISMAN-TRACEROUTE-MIB > > > MinumumCompliance > ***************** > Same as ping Compliances From RFC 2925 and new draft the > traceRouteGroup has originally Ctl, Results and Probehistory Objects. > > The minimal compliance will just have a traceReouteMinimumGroup with Ctl > and Results objects and leave the original group (fully compliant) > intact. > > > Same comments for traceRouteCtlFrequency and traceRouteCtlStorageType as > for the PING minimum compliance. OK, however we decide on the PING MIB, I will change the TRACEROUTE MIB analogously. Thanks, Juergen > > DISMAN-NSLOOKUP-MIB > No issues. > > > Thanks > > Eduardo > > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Wednesday, June 16, 2004 3:47 PM > To: Randy Presuhn; disman@ietf.org > Cc: ipcdn@ietf.org > Subject: [ipcdn] Re: [Disman] WG last call > ondraft-ietf-disman-remops-mib-v2-01.txt > > > Dear all, > > I just posted a new version of the remote operation MIB modules. > Following Eduardo's suggestion I added Minimum Compliancy statements in > addition to the existing full compliancy statements to each of the three > MIB modules. > > I also had to (syntactically) modify the existing compliancy statements. > Please have a close look at all six MODULE-COMPLIANCE macros. Until the > document becomes available at the I-D repository, you can preview it at > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib- > v2-02.txt > > There was not much response on my questions on how to define the minimum > compliance statements. I preferred leaving read-only objects in place > to creating non-consecutive numbering of objects in table entries. I am > not dogmatic about this and suggestions for changes are very welcome. > > For simplifying the review here is a list of objects and groups for > which the full and minimum compliance statements differ: > > pingHistoryGroup, > pingNotificationsGroup > pingCtlDataFill > pingCtlFrequency > pingCtlMaxRows > pingCtlTrapGeneration > pingCtlProbeFailureFilter > pingCtlTestFailureFilter > pingCtlDescr > pingCtlByPassRouteTable > pingProbeHistoryTime > > traceRouteHistoryGroup > traceRouteCtlByPassRouteTable > traceRouteCtlDontFragment > traceRouteCtlInitialTtl > traceRouteCtlFrequency > traceRouteCtlDescr > traceRouteCtlMaxRows > traceRouteCtlTrapGeneration > traceRouteCtlCreateHopsEntries > traceRouteCtlRowStatus > traceRouteHopsLastGoodProbe > > lookupCtlRowStatus > > Beyond the compliance statement I just made two changes to the document: > > 1. Added new section 3.4 introducing the compliance statement > > 2. Extended DESCRIPTION clause of object lookupPurgeTime by one > sentence: > > "A value of 0 indicates that automatic deletion > of entries is disabled." > > Thanks, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 > 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 > 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.ccrle.nec.de > > > --On 29.04.2004 14:29 h -0700 Randy Presuhn wrote: > >> Hi - >> >> Are there any objections to proceding as Juergen and Eduardo suggest? >> I'd like to see comment (pro or contra) on the specific questions >> Juergen raised below. >> >> Randy, disman WG chair >> >>> From: "Juergen Quittek" >>> To: "Eduardo Cardona" ; "Randy Presuhn" >>> ; >>> Cc: "Ipcdn List (E-mail)" >>> Sent: Monday, April 26, 2004 1:11 AM >>> Subject: RE: [Disman] WG last call on >>> draft-ietf-disman-remops-mib-v2-01.txt >>> >> >>> Eduardo, >>> >>> Thank you for raising this issue and my apologies for this very late >>> reply. >>> >>> I ran into similar problems several times where a well designed >>> technology was too mighty or too general for being implemented at >>> small devices. >>> >>> Your suggestions aim at introducing additional MODULE-COMPLIANCE >>> clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules >>> for allowing simpler implementations with smaller footprints. >>> >>> I support your proposal, but have a few comments, see below. I am >>> willing to make suggestions for minimalCompliance clauses for the MIB > >>> modules, but first the WG should agree on two issues: >>> >>> - Is it agreed to add such clauses, that definitely require >>> less funtionality to be implemented? >>> >>> - what is the preferred procedure for columnar objects that >>> are not required for minimal compliancy? We can either >>> allow them to be missing completely. But this would result >>> in non-consecutive numbering of the remaining objects in >>> the minimal tables. Or we require them to be implemented >>> as read-only indicating that the feature that they would >>> serve in full compliancy is not supported. >>> >>> Please find further comments inline. >>> >>> Juergen >>> -- >>> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 > 90511-15 >>> NEC Europe Ltd., Network Laboratories Fax: +49 6221 > 90511-55 >>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.ccrle.nec.de >>> >>> >>> --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: >>> > Randy, >>> > >>> > Few comments, >>> > >>> > I review the MIB and appears compelling respect to previous RFC >>> > >>> > Just one comment >>> > >>> > >>> > (*) traceRouteCtlMiscOptions >>> > It appears to me an uncanny object and rather implementations may >>> > opt to extend the capabilities in the private branch, could leave >>> > with that to avoid deprecation, of if there are field >>> > implementations. >>> >>> Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests > >>> implementation of this object, but it may be implemented as read-only > >>> and returning always a value of zero, if there is not further >>> semantics defined for it. Do you suggest to completely remove the >>> object or to state in the MODULE-COMPLIANCE clause that it does not >>> need to be implemented? >>> >>> > Regardless of the additions to the MIB I apologize for the late >>> > notice, >>> > >>> > Before sending a complete proposal and get your concept of the best > >>> > approach, below is the proposal to add a simplified Compliance >>> > statement for devices not requiring to keep constant status of >>> > PING/TRACEROUTE operations, only remote operation per operator >>> > request. >>> > >>> > >>> > We are looking at your comments about the clear overlap in >>> > draft-ietf-disman-remops-mib-v2-01.txt >>> > With IPCDN draft >>> > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mi >>> > b-00. >>> > txt ( currently out of date in IETF drafts site) which is clearly a >>> > subset of the DISMAN-PING-MIB >>> > Lectors refer to >>> > > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. >>> > html >>> > >>> > Should the proposal below being include in the remops MIB or should > >>> > we update IPCDN cable gateway Tools MIB module to be just the >>> > compliance statement outlined below? >>> >>> I doubt that it is a good idea to replicate large portions of the >>> PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done >>> right now. >>> >>> > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null >>> > named log" default entry for devices not supporting the named log >>> > Named log is analog to disman remops draft for "OwnerIndex" and >>> > "TestName" where default entries are created (null owner, null >>> > TestName) for a manager requested operation of PING/ TRACEROUTE, >>> > NSLOOKUP, mostly for small foot-print devices with no network >>> > monitoring role at the connectivity level as pretended with this >>> > updated RFC. >>> >>> I don't think the remops MIB modules forbid null-named entries in the > >>> respective tables. But currently the support of a read-write >>> pingCtlRowStatus is mandatory. >>> >>> Is your concrete suggestion to add something like >>> >>> OBJECT XXRowStatus >>> MIN-ACCESS read-only >>> DESCRIPTION >>> "Implementations may disallow the creation of named >>> entries." >>> >>> with XX=pingCtl,traceRouteCtl,lookupCtl? >>> >>> > In summary A new Compliance Statement for small devices with no >>> > monitoring capabilities to : >>> > 1) remove the constant pulling and login information >>> > 2) remove the test row creation >>> > - CTL* Results* tables only default entries (null owner, null >>> > TestName) >>> > 3) History* tables not required. >>> > - New basicGroups to exclude History* objects and other objects >>> > which are not relevant to the simplified >>> > system. >>> > - Create an additional set of Compliance statements to >>> > require the new Groups and other objects Compliance >>> > requirements MIN-ACCESS clauses mainly >>> > >>> > Schema of the content of the new Compliance statement: >>> > >>> > List of objects not to include in basicPingGroupOBJECT-GROUP >>> > clause qnd/or hints for OBJECT Compliances: >>> > pingMaxConcurrentRequests -- remove >>> >>> Could also be read-only returning 1. >>> >>> > pingCtlDataFill -- remove or MIN-ACCESS read-only > default >>> > value is OK >>> > pingCtlFrequency -- remove Only one test >>> >>> Could also be read-only returning 0. >>> >>> > pingCtlType -- remove or MIN-ACCESS read-only >>> > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only >>> > pingCtlDSField -- MIN-ACCESS read-only >>> > pingCtlStorageType -- remove >>> > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) >>> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >>> >>> Why don't you consider removing this object? >>> >>> > pingCtlIfIndex -- not to include >>> > pingProbeHistory* -- not to include. >>> > >>> > List of objects not to include in basicTraceRouteGroup >>> > OBJECT-GROUP clause and/or hints for OBJECT Compliances: >>> > traceRouteMaxConcurrentRequests -- remove >>> > traceRouteCtlType -- remove or MIN-ACCESS read-only >>> > traceRouteCtlDSField -- MIN-ACCESS read-only >>> > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only >>> > traceRouteCtlIfIndex -- not to include >>> > traceRouteCtlMiscOptions -- not to include >>> > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only >>> > traceRouteCtlInitialTtl -- remove or MIN-ACCESS >>> > traceRouteCtlFrequency -- remove only one test >>> > traceRouteCtlDescr -- remove >>> > traceRouteCtlCreateHopsEntries -- remove HopsEntries not > required. >>> > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) >>> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >>> > traceRouteCtlStorageType -- remove >>> > traceRouteProbeHistory* -- not to include. >>> > >>> > List of objects not to include in basicLookupGroup OBJECT-GROUP >>> > clause and/or hints for OBJECT Compliances: >>> > lookupMaxConcurrentRequests -- remove >>> > lookupPurgeTime -- remove >>> > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) >>> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >>> > >>> > >>> > Best Regards >>> > >>> > Eduardo >>> > >>> > -----Original Message----- >>> > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >>> > Sent: Monday, March 01, 2004 6:44 PM >>> > To: disman@ietf.org >>> > Subject: RE: [Disman] WG last call on >>> > draft-ietf-disman-remops-mib-v2-01.txt >>> > >>> > >>> > >>> > Hi - >>> > >>> >> From: Eduardo Cardona >>> >> Sent: Mar 2, 2004 9:25 AM >>> >> To: Randy Presuhn , disman@ietf.org >>> >> Subject: RE: [Disman] WG last call on >>> >> draft-ietf-disman-remops-mib-v2-01.txt >>> > ... >>> >> One simple note, I tough last call was March 5th >>> > >>> > No, it was supposed to end March 2. However, I'm not going to hand > >>> > it to our AD until I can be reasonably sure that it has received >>> > adequate review. >>> > >>> >> We at Cablelabs are interested in adding a simplified compliance >>> >> statement for ad-hoc procedure call instead of a user entry >>> >> schecule entry, so an user can do a one time execution e.g PING >>> > >>> > It would have been nice to have learned of this earlier, rather >>> > than during WG last call. >>> > >>> >> The draft we had is almost complete, >>> >> Would be that an opportunity to add that? I can post that tomorrow > >>> >> in the list if compeling >>> > ... >>> > >>> > I'd like to have this discussion sooner rather than later, so >>> > please make your specific proposal as quickly as you can. My >>> > opinion as a technical contributor is that the case for these >>> > changes would need to be fairly compelling if they would result in >>> > the remote operations MIB cycling at proposed rather than advancing > >>> > to draft standard. As working group chair, I want to ensure that >>> > whatever course we take reflects WG consensus. So, balancing the >>> > need for bringing this to a conclusion with the need to ensure that > >>> > the technical issues are properly considered, I'll entertain >>> > discussion of this issue ("ad hoc procedure call") until Friday >>> > noon (Korean Time). Shortly thereafter I'll make a call on whether > >>> > there is consensus to modify the draft regarding this specific >>> > proposal. >>> > >>> > Randy >>> > >>> > >>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 8 18:28:53 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08904 for ; Thu, 8 Jul 2004 18:28:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BihNv-00069s-AR for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:28:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BihN2-0005ne-00 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:28:01 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BihM6-00054I-00 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bift9-0002hP-Pz; Thu, 08 Jul 2004 16:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BidAa-0006eD-VL for ipcdn@megatron.ietf.org; Thu, 08 Jul 2004 13:58:53 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13793 for ; Thu, 8 Jul 2004 13:58:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BidAU-000697-R8 for ipcdn@ietf.org; Thu, 08 Jul 2004 13:58:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bid9W-0005ip-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 13:57:47 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Bid8F-0004q6-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 13:56:27 -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 i68HtYcA023120; Thu, 8 Jul 2004 11:55:52 -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, NCS SF Objects -1: CM it is Date: Thu, 8 Jul 2004 11:55:50 -0600 Message-ID: Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -1: CM it is Thread-Index: AcQ8oPmTkOITiaSyRaCFIW+1o2AuMgAeqW3gAJbDqhAJZmYM8A== From: "Jean-Francois Mule" To: , "David De Reu" , "Beacham Gordon-CGB005" , , "Thomas Anders" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Cc: PacketCable Provisioning and OSS Majordomo List , Kevin Johns , Venkatesh Sunkad 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable This note provides the IPCDN wg consensus on the MTA Signaling MIB objects related to the establishment of NCS Service Flows. It took me longer than I thought to summarize the input we received from CableLabs MSOs on how to address the Sig MIB NCS SF related mib objects and in the meantime, we also received input from ETSI. Apologies for the delay. In brief, the CableLabs MSO operators' feedback was: a) Deprecate MTA Sig MIB objects to set up NCS Service Flows via MTA config file. The preferred mechanism for establishing DOCSIS Service Flows for the MTA NCS traffic is via the CM config file. While some operators like having the choice and the option to do this in the MTA, practically, most are using the CM config file today and they have no plans to migrate to using the MTA Sig MIB for that, hence the decision to deprecate those objects. (Note that "deprecate" is to be read here in the context of the MTA Sig MIB currently defined under CableLabs; for the IETF IPCDN Signaling MIB ID, this means CableLabs' members are in favor of object deletions). b) CableLabs should add new CMTS requirements to mitigate the potential security risks related to DOCSIS Service Class Name provisioning and Service Class Name policy authorizations. A PacketCable DQoS Engineering Change has been opened. This addresses some of the concerns some of you raised on the IPCDN list as well. Therefore, based on the comments received on the IETF IPCDN list from Wim De Ketelaere, David De Reu, Rich Woundy, Gordon Beacham, Thomas Anders of Blue Cable and many others, the input from ETSI via the recent liaison statement and the above input from operators members of CableLabs, I believe we have reached IPCDN wg consensus to delete the following MIB objects from the IPCDN MTA Sig MIB ID: pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, and pktcSigServiceClassNameMask objects. Any objections? Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 8 18:57:58 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11526 for ; Thu, 8 Jul 2004 18:57:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bihq3-0007n1-LI for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:57:59 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bihom-0006zp-00 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:56:40 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bihnk-0006X0-01 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:55:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BihfT-0000Eh-MA for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:47:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiftS-0003Gy-Uh; Thu, 08 Jul 2004 16:53:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BidQv-00087j-Ig for ipcdn@megatron.ietf.org; Thu, 08 Jul 2004 14:15:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14948 for ; Thu, 8 Jul 2004 14:15:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BidQp-0004v3-EI for ipcdn@ietf.org; Thu, 08 Jul 2004 14:15:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BidPt-0004Ye-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:14:42 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BidOx-0003qn-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:13:43 -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 i68IDBbw027764; Thu, 8 Jul 2004 12:13:11 -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] RE: Liaison from ETSI AT-Digital re. packet Cable MIBs Date: Thu, 8 Jul 2004 12:13:11 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Liaison from ETSI AT-Digital re. packet Cable MIBs Thread-Index: AcRaD5O/L6y01F4HSWuxQlFeRRx4BQLBwkhA From: "Jean-Francois Mule" To: "David De Reu" , "Beacham Gordon-CGB005" , X-Approved: ondar 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable On June 22nd, Gordon asked: > Note: ETSI has also recommended the=20 > pktcSigNcsServiceFlowState object be deleted. I don't recall=20 > a separate discussion regarding the=20 > pktcSigNcsServiceFlowState object specifically on the=20 > reflector. Perhaps it always intended to be associated with=20 > the SCN objects and the deletion discussion. Comments?=20 On June 24th, David wrote: > Hi all, >=20 > The way I understand it, is that the=20 > pktcSigNcsServiceFlowState object is indeed related to the=20 > pktcSigServiceClassNameUS, pktcSigServiceClassNameDS and=20 > pktcSigServiceClassNameMask objects. So if you delete the=20 > latter objects, you also have to delete the=20 > pktcSigNcsServiceFlowState object because it doesn't seem=20 > useful on it's own. Re: the pktcSigNcsServiceFlowState mib object, when the SF is = established via the CM, the MTA has no knowledge of the SF state so this = object is not relevant anymore. I did not include it in the summary as = this was not raised when we started the initial threads. I concur with you: delete it. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 8 18:58:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11555 for ; Thu, 8 Jul 2004 18:58:01 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bihq7-0007nS-FM for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:58:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bihoq-00070q-00 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:56:45 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bihnk-0006XY-02 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:55:36 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bihej-0000Ct-M6 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:46:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiftS-0003Fe-7U; Thu, 08 Jul 2004 16:53:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BidQ1-0007wS-JI for ipcdn@megatron.ietf.org; Thu, 08 Jul 2004 14:14:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14897 for ; Thu, 8 Jul 2004 14:14:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BidPv-0004Ys-EM for ipcdn@ietf.org; Thu, 08 Jul 2004 14:14:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BidP7-0004Cm-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:13:54 -0400 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1BidOF-0003qd-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:13:00 -0400 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 08 Jul 2004 11:12:47 -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-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA10006; Thu, 8 Jul 2004 11:12:09 -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); Thu, 8 Jul 2004 11:12:43 -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); Thu, 8 Jul 2004 11:12:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM it is Date: Thu, 8 Jul 2004 11:12:40 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2D8E8@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -1: CM it is thread-index: AcQ8oPmTkOITiaSyRaCFIW+1o2AuMgAeqW3gAJbDqhAJZmYM8AABqA3g From: "Eugene Nechamkin" To: "Jean-Francois Mule" , ipcdn@ietf.org, "David De Reu" , "Beacham Gordon-CGB005" , skang@upctechnology.com, "Thomas Anders" X-OriginalArrivalTime: 08 Jul 2004 18:12:42.0238 (UTC) FILETIME=[292859E0:01C46517] X-WSS-ID: 6CF351142QW17966819-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Cc: PacketCable Provisioning and OSS Majordomo List , Kevin Johns , Venkatesh Sunkad 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Small addition: the object pktcSigNcsServiceFlowState should also be deleted as functionally only related to the NCS SF. Eugene. -----Original Message----- From: owner-packetcable-prov-oss@cablelabs.com [mailto:owner-packetcable-prov-oss@cablelabs.com] On Behalf Of Jean-Francois Mule Sent: Thursday, July 08, 2004 10:56 AM To: ipcdn@ietf.org; David De Reu; Beacham Gordon-CGB005; skang@upctechnology.com; Thomas Anders Cc: PacketCable Provisioning and OSS Majordomo List; Kevin Johns; Venkatesh Sunkad Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM it is This note provides the IPCDN wg consensus on the MTA Signaling MIB objects related to the establishment of NCS Service Flows. It took me longer than I thought to summarize the input we received from CableLabs MSOs on how to address the Sig MIB NCS SF related mib objects and in the meantime, we also received input from ETSI. Apologies for the delay. In brief, the CableLabs MSO operators' feedback was: a) Deprecate MTA Sig MIB objects to set up NCS Service Flows via MTA config file. The preferred mechanism for establishing DOCSIS Service Flows for the MTA NCS traffic is via the CM config file. While some operators like having the choice and the option to do this in the MTA, practically, most are using the CM config file today and they have no plans to migrate to using the MTA Sig MIB for that, hence the decision to deprecate those objects. (Note that "deprecate" is to be read here in the context of the MTA Sig MIB currently defined under CableLabs; for the IETF IPCDN Signaling MIB ID, this means CableLabs' members are in favor of object deletions). b) CableLabs should add new CMTS requirements to mitigate the potential security risks related to DOCSIS Service Class Name provisioning and Service Class Name policy authorizations. A PacketCable DQoS Engineering Change has been opened. This addresses some of the concerns some of you raised on the IPCDN list as well. Therefore, based on the comments received on the IETF IPCDN list from Wim De Ketelaere, David De Reu, Rich Woundy, Gordon Beacham, Thomas Anders of Blue Cable and many others, the input from ETSI via the recent liaison statement and the above input from operators members of CableLabs, I believe we have reached IPCDN wg consensus to delete the following MIB objects from the IPCDN MTA Sig MIB ID: pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, and pktcSigServiceClassNameMask objects. Any objections? Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 8 18:58:06 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11586 for ; Thu, 8 Jul 2004 18:58:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BihqC-00000F-He for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:58:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bihov-00072C-00 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:56:50 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bihnl-0006X0-03 for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:55:37 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BihXs-0008VM-Hq for ipcdn-archive@ietf.org; Thu, 08 Jul 2004 18:39:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiftO-0003Aj-NR; Thu, 08 Jul 2004 16:53:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BidFb-0007AP-MO for ipcdn@megatron.ietf.org; Thu, 08 Jul 2004 14:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14287 for ; Thu, 8 Jul 2004 14:03:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BidFV-0000Md-J8 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:03:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BidEc-0007k7-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:03:04 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BidD1-0006yO-00 for ipcdn@ietf.org; Thu, 08 Jul 2004 14:01:23 -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 i68I0oc1024664; Thu, 8 Jul 2004 12:00:51 -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] Sig MIB, NCS SF Objects -1: CM or MTA config? Date: Thu, 8 Jul 2004 12:00:51 -0600 Message-ID: Thread-Topic: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? Thread-Index: AcRYmAYBuIMX+cnORIatKmubSrab2AMfN48Q From: "Jean-Francois Mule" To: "Beacham Gordon-CGB005" , X-Approved: ondar 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Gordon, See msg I just sent summarizing the input from CableLabs' MSOs. You asked: > Please advise as I would like to include these=20 > changes in Sig MIB draft 4. Thanks. Unless I mistated the wg consensus and someone raises an objection, = yes, please reflect those changes in draft04. Thank you, Jean-Fran=E7ois=20 PS: sorry for the delay in responding to you. I was on vacation and you = should have received the automatic "out-of-office" reply. Next time, if = you address me directly as you did, please put me in the To: field = instead of the Cc: field so that my email rules can catch and flag the = message as a priority one. Thanks. > -----Original Message----- > From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 > Sent: Tuesday, June 22, 2004 2:31 PM > To: 'ipcdn@ietf.org' > Cc: Jean-Francois Mule > Subject: RE: [ipcdn] Sig MIB, NCS SF Objects -1: CM or MTA config? >=20 >=20 > Jean-Francois, >=20 > Did you obtain any feedback on deleting the=20 > pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, and=20 > pktcSigServiceClassNameMask objects from the MSOs? ETSI has=20 > also recommended these objects be deleted and there does not=20 > appear to be any WG objection to removing these objects from=20 > the Sig MIB. Please advise as I would like to include these=20 > changes in Sig MIB draft 4. Thanks. >=20 > Gordon >=20 > >Fyi, I am trying to get formal input from some MSOs on whether they=20 > >want to use the MTA NCS SF mechanism in the future. If I=20 > don't get any=20 > >positive responses, I see no reason why we should keep these=20 > objects at=20 > >this point in the development of this mib. >=20 > >I don't expect much until June 9. > >Jean-Fran=E7ois >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jul 9 06:47:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16876 for ; Fri, 9 Jul 2004 06:47:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BisuV-0001vh-Ru for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 06:47:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bistc-0001dt-00 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 06:46:25 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bissq-00013m-00 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 06:45:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BisaE-000058-HZ; Fri, 09 Jul 2004 06:26:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BisD4-0004Kk-Iu for ipcdn@megatron.ietf.org; Fri, 09 Jul 2004 06:02:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14632 for ; Fri, 9 Jul 2004 06:02:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BisCx-0003tD-5T for ipcdn@ietf.org; Fri, 09 Jul 2004 06:02:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BisBu-0003Z6-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 06:01:15 -0400 Received: from mid-1.inet.it ([213.92.5.18]) by ietf-mx with esmtp (Exim 4.12) id 1BisAt-00034Q-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 06:00:11 -0400 Received: from hhazewinkel.inet.it [::ffff:213.92.1.191] by mid-1.inet.it via I-SMTP-5.1.10-51A id ::ffff:213.92.1.191+trDJmW2tAOSJ; Fri, 09 Jul 2004 12:00:07 +0200 Message-ID: <40EE6CA6.6030503@inet.it> Date: Fri, 09 Jul 2004 12:00:06 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipcdn@ietf.org Content-Type: multipart/mixed; boundary="------------050207090108080609050403" Subject: [ipcdn] [Fwd: Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03] 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 This is a multi-part message in MIME format. --------------050207090108080609050403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit HI, Forwarded, since my email for the mib-doctors is different from the ipcdn mailinglist. regards, Harrie --------------050207090108080609050403 Content-Type: message/rfc822; name="Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03" Content-Disposition: inline; filename="Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03" Return-Path: Received: from vsmtp15.tin.it (192.168.70.119) by ims4d.cp.tin.it (7.0.027) id 40C9F04400F74CF4 for h.hazewinkel@tin.it; Fri, 9 Jul 2004 10:48:14 +0200 Received: from rietveld.vanzoest.com (209.132.96.42) by vsmtp15.tin.it (7.0.027) id 40CEF67C021DB5CF for h.hazewinkel@tin.it; Fri, 9 Jul 2004 10:48:14 +0200 Received: (qmail 72609 invoked by uid 2504); 9 Jul 2004 08:48:12 -0000 Delivered-To: lisanza-harrie@lisanza.net Received: (qmail 72604 invoked by uid 208); 9 Jul 2004 08:48:12 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: rietveld.vanzoest.com Received: from skutsje.san.webweaving.org (HELO skutsje.san.webweaving.org) (209.132.96.45) by rietveld.vanzoest.com (qpsmtpd/0.28) with ESMTP; Fri, 09 Jul 2004 01:48:12 -0700 Received: from lisanza.net (localhost [127.0.0.1]) by skutsje.san.webweaving.org (8.12.9/8.12.9) with ESMTP id i698bX7L044510; Fri, 9 Jul 2004 01:37:36 -0700 (PDT) (envelope-from harrie@lisanza.net) Message-ID: <40EE5BA1.2080407@lisanza.net> Date: Fri, 09 Jul 2004 10:47:29 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nakanishi Greg-MGI8179 CC: "'Jean-Francois Mule'" , ipcdn@ietf.org, rt+mib-doctors@rt.psg.com, "Raftus, David" , "Azlina Ahmad (E-mail)" , "Richard Woundy @ Comcast" Subject: Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit HI, SOrry for a late response, but cleaning up todo list for a wek vacation. -)) Some comments needed or agreements below. (no agreement of agreements :-) Harrie Nakanishi Greg-MGI8179 wrote: > > I presume you the 2 above stated terms are attempted to be described > briefly. I am not getting any of it. 'A term referring to the DOCSIS for > enabling....' > 1) I already know it is a term. :-) > 2) Without the reference it looses all info. > > Upon rereading, they are the same, with a different explaination. :-) > > [AA,GN] How about the following words: > > 2.1 BPI - Baseline Privacy Interface > > A mechanism for providing data privacy over the HFC network in DOCSIS 1.0 > systems. > > 2.2 BPI - Baseline Privacy Plus Interface > A mechanism that extend the Baseline Privacy Interface with the addition > of CM authentication over the HFC network in DOCSIS1.1/2.0 system and > beyond. OK. >>2.12 Upstream >> >> The direction from the subscriber towards the head-end. > > > > > SUBJECTIVE: > Is the term subscriber not needed as definition? > > Quit clear, but to be complete. > > [AA,GN] How about "The direction from the CM to the CMTS" ? We need to > change the definition of 'downstream' to match, as well. OK >> available. This notification MIB in conjunction with [10] and [11] >> provide a minimum set of standard DOCSIS Traps that DOCSIS devices > > > OLD: > DOCSIS Traps > > NEW: > SNMP Notifications > > [AA,GN] OK > > NOTE: The notifications are DOCSIS related, but are SNMP. Agreed, it is where you put the impartance maybe. > [AA,GN] I think this is mainly historical. Other DOCSIS related MIBs are > named similarly. E.g. RFC 2669, RFC 26670, RFC 3083. I believe the > thinking was, rather than using DOCSIS, to use DOCS which stands for > "Data-Over-Cable Service" and drop the IS ("Interface Specification") > since it's a MIB module not an Interface Specification. At this point we > prefer to keep the name consistent with the other DOCSIS MIBs. OK. > > >> Two groups of SNMP notification objects are defined in this document. >> One group defines notifications for cable modem events, and the other >> group defines notifications for cable modem termination system >> events. >> >> Common to all CM notification objects (traps) is that in their >> OBJECTS statements, a CM trap contains information about the event >> priority, the event Id, the event message body, the CM DOCSIS > > > > > I have some difficulty to understand what you mean by the event message > body. Would that be some kind of description? If so, I would suggest > adjusting the naming. > > [AA,GN] How about replacing 'the event message body' with 'a textual > description of the event' ? Same wording is used (in two places) in the > MIB module description and would need to be changed there as well. agreed. > >> address. >> >> These objects are docsDevEvLevel, docsDevId, > > > > > Where does 'These objects are' refer to? > > [AA,GN] How about "Common objects returned in the varbinding list of > CMTS notifications are docsDevEvLevel, docsDevId," ? Similar text is also > used in the CM notification description and also in Module description and > should be updated as well. Agreed. > >> " >> DEFVAL { {} } >> ::= { docsDevTrapControl 1 } > > >> docsDevCmInitTLVUnknownTrap NOTIFICATION-TYPE >> OBJECTS { >> docsDevEvLevel, >> docsDevEvId, > > > > Why is this object added? Is this value not retrieved from the OID used > for the docsDevEvLevel and docsDevEvText. In that case one can omit it. > > [AA,GN] docsDevEvId is a numeric identifier for an the event that occurred > for which there are hundreds defined by DOCSIS. These events are > categorized and allocated to a specific notification. docsDevEvLevel is > the priority level of the event, docsDevEvText is a textual description of > the event. OK. > >> The values of docsDevEvLevel, docsDevId, and >> docsDevEvText are from the entry which logs this event >> in the docsDevEventTable. > > > > > Are these 3 values uniquely identifying the event? If so, please indicate > that. > > [AA, GN] docsDevId is sufficient to identify the event. One could > determine docsDevEvLevel and docsDevEvText from the id. But, the > application would need some type of lookup table to do this. So, I think > the intent was have the agent provide all the info so that a lookup table > wouldn't be needed. One can do indeed this, how about the manager needs to collect this table sepeartely and can cache it. I presume this information will not change over the life time of the device. That would require once the collection of the table and no repeating data in the notification. NOTE: I am note sure how big this table can be. > > >> The docsIfDocsisBaseCapability >> indicates the DOCSIS version information. > > > > The DOCSIS version information of what? > > [AA,GN] Will replace with: "indicates the highest version of the DOCSIS > specification (1.0, 1.1, or 2.0) that the device is capable of > supporting." OK > > What is ment by 'uniform accross all CM traps'? > > [AA,GN]I think the intent here was to say that the objects previously > described are also used in the subsequent CM notifications. This sentence > will be deleted, since we'll repeat the description in each notification > definition. OK > > DESIGN-CHOICE [snip] > > [AA,GN] OK, we'll repeat the description of the objects (and describe it > better) in each notification. > > We prefer not to merge all the notifications even if the same objects are > returned in many of these notifications. Essentially, each notification > definition serves as a category for a set of events. DOCSIS defines > hundreds of events which are categorized and mapped to a particular > notification for reporting the event. This enables the NMS to more easily > find events associated with a particular category. OK. As a design choice it is wise to add wording in the descriptive text of the RFC. Otherwise would have similar remarks I presume. > > > >> docsDevCmSwUpgradeInitTrap NOTIFICATION-TYPE >> OBJECTS { >> docsDevEvLevel, >> docsDevEvId, >> docsDevEvText, >> ifPhysAddress, >> docsIfCmCmtsAddress, >> docsDevSwFilename, >> docsDevSwServer, >> docsIfDocsisBaseCapability, >> docsIfCmStatusDocsisOperMode, >> docsIfCmStatusModulationType >> } >> STATUS current >> DESCRIPTION >> "An event to report a software upgrade initiated >> event. > > > > > Weird sentence. > > [AA,GN] Will change to: "A notification to indicate that a software > upgrade has been intiated on the device" OK --------------050207090108080609050403 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 --------------050207090108080609050403-- From ipcdn-bounces@ietf.org Fri Jul 9 10:58:32 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04052 for ; Fri, 9 Jul 2004 10:58:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Biwpd-0001TQ-T0 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 10:58:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biwok-0001AW-00 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 10:57:39 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BiwoI-0000qM-00 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 10:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiwMG-0004Cc-2g; Fri, 09 Jul 2004 10:28:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bir5G-0001Ml-1S for ipcdn@megatron.ietf.org; Fri, 09 Jul 2004 04:50:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11923 for ; Fri, 9 Jul 2004 04:50:10 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bir58-0005Uw-OG for ipcdn@ietf.org; Fri, 09 Jul 2004 04:50:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bir4A-0005Cz-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 04:49:10 -0400 Received: from skutsje.san.webweaving.org ([209.132.96.45]) by ietf-mx with esmtp (Exim 4.12) id 1Bir3A-0004eO-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 04:48:08 -0400 Received: from lisanza.net (localhost [127.0.0.1]) by skutsje.san.webweaving.org (8.12.9/8.12.9) with ESMTP id i698bX7L044510; Fri, 9 Jul 2004 01:37:36 -0700 (PDT) (envelope-from harrie@lisanza.net) Message-ID: <40EE5BA1.2080407@lisanza.net> Date: Fri, 09 Jul 2004 10:47:29 +0200 From: Harrie Hazewinkel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nakanishi Greg-MGI8179 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 09 Jul 2004 10:28:11 -0400 Cc: "'Jean-Francois Mule'" , rt+mib-doctors@rt.psg.com, "Raftus, David" , "Richard Woundy @ Comcast" , ipcdn@ietf.org, "Azlina Ahmad \(E-mail\)" Subject: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit HI, SOrry for a late response, but cleaning up todo list for a wek vacation. -)) Some comments needed or agreements below. (no agreement of agreements :-) Harrie Nakanishi Greg-MGI8179 wrote: > > I presume you the 2 above stated terms are attempted to be described > briefly. I am not getting any of it. 'A term referring to the DOCSIS for > enabling....' > 1) I already know it is a term. :-) > 2) Without the reference it looses all info. > > Upon rereading, they are the same, with a different explaination. :-) > > [AA,GN] How about the following words: > > 2.1 BPI - Baseline Privacy Interface > > A mechanism for providing data privacy over the HFC network in DOCSIS 1.0 > systems. > > 2.2 BPI - Baseline Privacy Plus Interface > A mechanism that extend the Baseline Privacy Interface with the addition > of CM authentication over the HFC network in DOCSIS1.1/2.0 system and > beyond. OK. >>2.12 Upstream >> >> The direction from the subscriber towards the head-end. > > > > > SUBJECTIVE: > Is the term subscriber not needed as definition? > > Quit clear, but to be complete. > > [AA,GN] How about "The direction from the CM to the CMTS" ? We need to > change the definition of 'downstream' to match, as well. OK >> available. This notification MIB in conjunction with [10] and [11] >> provide a minimum set of standard DOCSIS Traps that DOCSIS devices > > > OLD: > DOCSIS Traps > > NEW: > SNMP Notifications > > [AA,GN] OK > > NOTE: The notifications are DOCSIS related, but are SNMP. Agreed, it is where you put the impartance maybe. > [AA,GN] I think this is mainly historical. Other DOCSIS related MIBs are > named similarly. E.g. RFC 2669, RFC 26670, RFC 3083. I believe the > thinking was, rather than using DOCSIS, to use DOCS which stands for > "Data-Over-Cable Service" and drop the IS ("Interface Specification") > since it's a MIB module not an Interface Specification. At this point we > prefer to keep the name consistent with the other DOCSIS MIBs. OK. > > >> Two groups of SNMP notification objects are defined in this document. >> One group defines notifications for cable modem events, and the other >> group defines notifications for cable modem termination system >> events. >> >> Common to all CM notification objects (traps) is that in their >> OBJECTS statements, a CM trap contains information about the event >> priority, the event Id, the event message body, the CM DOCSIS > > > > > I have some difficulty to understand what you mean by the event message > body. Would that be some kind of description? If so, I would suggest > adjusting the naming. > > [AA,GN] How about replacing 'the event message body' with 'a textual > description of the event' ? Same wording is used (in two places) in the > MIB module description and would need to be changed there as well. agreed. > >> address. >> >> These objects are docsDevEvLevel, docsDevId, > > > > > Where does 'These objects are' refer to? > > [AA,GN] How about "Common objects returned in the varbinding list of > CMTS notifications are docsDevEvLevel, docsDevId," ? Similar text is also > used in the CM notification description and also in Module description and > should be updated as well. Agreed. > >> " >> DEFVAL { {} } >> ::= { docsDevTrapControl 1 } > > >> docsDevCmInitTLVUnknownTrap NOTIFICATION-TYPE >> OBJECTS { >> docsDevEvLevel, >> docsDevEvId, > > > > Why is this object added? Is this value not retrieved from the OID used > for the docsDevEvLevel and docsDevEvText. In that case one can omit it. > > [AA,GN] docsDevEvId is a numeric identifier for an the event that occurred > for which there are hundreds defined by DOCSIS. These events are > categorized and allocated to a specific notification. docsDevEvLevel is > the priority level of the event, docsDevEvText is a textual description of > the event. OK. > >> The values of docsDevEvLevel, docsDevId, and >> docsDevEvText are from the entry which logs this event >> in the docsDevEventTable. > > > > > Are these 3 values uniquely identifying the event? If so, please indicate > that. > > [AA, GN] docsDevId is sufficient to identify the event. One could > determine docsDevEvLevel and docsDevEvText from the id. But, the > application would need some type of lookup table to do this. So, I think > the intent was have the agent provide all the info so that a lookup table > wouldn't be needed. One can do indeed this, how about the manager needs to collect this table sepeartely and can cache it. I presume this information will not change over the life time of the device. That would require once the collection of the table and no repeating data in the notification. NOTE: I am note sure how big this table can be. > > >> The docsIfDocsisBaseCapability >> indicates the DOCSIS version information. > > > > The DOCSIS version information of what? > > [AA,GN] Will replace with: "indicates the highest version of the DOCSIS > specification (1.0, 1.1, or 2.0) that the device is capable of > supporting." OK > > What is ment by 'uniform accross all CM traps'? > > [AA,GN]I think the intent here was to say that the objects previously > described are also used in the subsequent CM notifications. This sentence > will be deleted, since we'll repeat the description in each notification > definition. OK > > DESIGN-CHOICE [snip] > > [AA,GN] OK, we'll repeat the description of the objects (and describe it > better) in each notification. > > We prefer not to merge all the notifications even if the same objects are > returned in many of these notifications. Essentially, each notification > definition serves as a category for a set of events. DOCSIS defines > hundreds of events which are categorized and mapped to a particular > notification for reporting the event. This enables the NMS to more easily > find events associated with a particular category. OK. As a design choice it is wise to add wording in the descriptive text of the RFC. Otherwise would have similar remarks I presume. > > > >> docsDevCmSwUpgradeInitTrap NOTIFICATION-TYPE >> OBJECTS { >> docsDevEvLevel, >> docsDevEvId, >> docsDevEvText, >> ifPhysAddress, >> docsIfCmCmtsAddress, >> docsDevSwFilename, >> docsDevSwServer, >> docsIfDocsisBaseCapability, >> docsIfCmStatusDocsisOperMode, >> docsIfCmStatusModulationType >> } >> STATUS current >> DESCRIPTION >> "An event to report a software upgrade initiated >> event. > > > > > Weird sentence. > > [AA,GN] Will change to: "A notification to indicate that a software > upgrade has been intiated on the device" OK _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jul 9 23:52:28 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02470 for ; Fri, 9 Jul 2004 23:52:28 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj8ub-0006US-Oi for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 23:52:29 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj8pO-0005Of-00 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 23:47:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bj8lF-0004Re-00 for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 23:42:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7bI-0007Ku-II; Fri, 09 Jul 2004 22:28:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj2pG-0007nj-C5 for ipcdn@megatron.ietf.org; Fri, 09 Jul 2004 17:22:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01672 for ; Fri, 9 Jul 2004 17:22:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj2pA-0002cH-0n for ipcdn@ietf.org; Fri, 09 Jul 2004 17:22:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj2nX-00026A-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 17:20:48 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1Bj2mR-0001Uy-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 17:19:39 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id i69LJc7b016425 for ; Fri, 9 Jul 2004 14:19:38 -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 i69LI0bi021581 for ; Fri, 9 Jul 2004 16:18:00 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Fri, 9 Jul 2004 14:19:36 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: "'Harrie Hazewinkel'" Subject: RE: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ie tf-ipcdn-doc sisevent-mib-03 Date: Fri, 9 Jul 2004 14:19:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Cc: "'Jean-Francois Mule'" , "Raftus, David" , "Richard Woundy @ Comcast" , rt+mib-doctors@rt.psg.com, ipcdn@ietf.org, "'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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Harrie, Thanks for the response. I think we have consensus on all but one item. Specifically, the issue on whether to include just the event id instead of (event id, event level, and event text) in the varbinding list. I'd like to solicit comments from the working group on this issue get a consensus on which way to go. There are two options to consider: 1) Send event id, event level, and event text in the notification. The application gets required info from the notification, no lookup table is needed. The message size is larger than option 2. 2) Send just the event id in the notification. The application uses some type of lookup table to determine the event level and event text. The message size is smaller than option 1. I've extracted the comments on this issue so people don't have to scroll through all the other comments. >> [AA, GN] docsDevId is sufficient to identify the event. One could >> determine docsDevEvLevel and docsDevEvText from the id. But, the >> application would need some type of lookup table to do this. So, I >> think the intent was have the agent provide all the info so that a >> lookup table wouldn't be needed. > > One can do indeed this, how about the manager needs to collect this table > sepeartely and can cache it. I presume this information will not change > over the life time of the device. That would require once the collection > of the table and no repeating data in the notification. > > NOTE: I am note sure how big this table can be. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Harrie Hazewinkel Sent: Friday, July 09, 2004 1:47 AM To: Nakanishi Greg-MGI8179 Cc: 'Jean-Francois Mule'; rt+mib-doctors@rt.psg.com; Raftus, David; Richard Woundy @ Comcast; ipcdn@ietf.org; Azlina Ahmad \(E-mail\) Subject: [ipcdn] Re: [psg.com #471] Expert review comments on draft-ietf-ipcdn-doc sisevent-mib-03 HI, SOrry for a late response, but cleaning up todo list for a wek vacation. -)) Some comments needed or agreements below. (no agreement of agreements :-) Harrie Nakanishi Greg-MGI8179 wrote: > > I presume you the 2 above stated terms are attempted to be described > briefly. I am not getting any of it. 'A term referring to the DOCSIS > for enabling....' > 1) I already know it is a term. :-) > 2) Without the reference it looses all info. > > Upon rereading, they are the same, with a different explaination. :-) > > [AA,GN] How about the following words: > > 2.1 BPI - Baseline Privacy Interface > > A mechanism for providing data privacy over the HFC network in DOCSIS > 1.0 systems. > > 2.2 BPI - Baseline Privacy Plus Interface > A mechanism that extend the Baseline Privacy Interface with the > addition of CM authentication over the HFC network in DOCSIS1.1/2.0 > system and beyond. OK. >>2.12 Upstream >> >> The direction from the subscriber towards the head-end. > > > > > SUBJECTIVE: > Is the term subscriber not needed as definition? > > Quit clear, but to be complete. > > [AA,GN] How about "The direction from the CM to the CMTS" ? We need > to change the definition of 'downstream' to match, as well. OK >> available. This notification MIB in conjunction with [10] and [11] >> provide a minimum set of standard DOCSIS Traps that DOCSIS devices > > > OLD: > DOCSIS Traps > > NEW: > SNMP Notifications > > [AA,GN] OK > > NOTE: The notifications are DOCSIS related, but are SNMP. Agreed, it is where you put the impartance maybe. > [AA,GN] I think this is mainly historical. Other DOCSIS related MIBs > are named similarly. E.g. RFC 2669, RFC 26670, RFC 3083. I believe > the thinking was, rather than using DOCSIS, to use DOCS which stands > for "Data-Over-Cable Service" and drop the IS ("Interface > Specification") since it's a MIB module not an Interface > Specification. At this point we prefer to keep the name consistent > with the other DOCSIS MIBs. OK. > > >> Two groups of SNMP notification objects are defined in this document. >> One group defines notifications for cable modem events, and the other >> group defines notifications for cable modem termination system >> events. >> >> Common to all CM notification objects (traps) is that in their >> OBJECTS statements, a CM trap contains information about the event >> priority, the event Id, the event message body, the CM DOCSIS > > > > > I have some difficulty to understand what you mean by the event > message body. Would that be some kind of description? If so, I would > suggest adjusting the naming. > > [AA,GN] How about replacing 'the event message body' with 'a textual > description of the event' ? Same wording is used (in two places) in > the MIB module description and would need to be changed there as well. agreed. > >> address. >> >> These objects are docsDevEvLevel, docsDevId, > > > > > Where does 'These objects are' refer to? > > [AA,GN] How about "Common objects returned in the varbinding list of > CMTS notifications are docsDevEvLevel, docsDevId," ? Similar text is > also used in the CM notification description and also in Module > description and should be updated as well. Agreed. > >> " >> DEFVAL { {} } >> ::= { docsDevTrapControl 1 } > > >> docsDevCmInitTLVUnknownTrap NOTIFICATION-TYPE >> OBJECTS { >> docsDevEvLevel, >> docsDevEvId, > > > > Why is this object added? Is this value not retrieved from the OID > used for the docsDevEvLevel and docsDevEvText. In that case one can > omit it. > > [AA,GN] docsDevEvId is a numeric identifier for an the event that > occurred for which there are hundreds defined by DOCSIS. These events > are categorized and allocated to a specific notification. > docsDevEvLevel is the priority level of the event, docsDevEvText is a > textual description of the event. OK. > >> The values of docsDevEvLevel, docsDevId, and >> docsDevEvText are from the entry which logs this event >> in the docsDevEventTable. > > > > > Are these 3 values uniquely identifying the event? If so, please > indicate that. > > [AA, GN] docsDevId is sufficient to identify the event. One could > determine docsDevEvLevel and docsDevEvText from the id. But, the > application would need some type of lookup table to do this. So, I > think the intent was have the agent provide all the info so that a > lookup table wouldn't be needed. One can do indeed this, how about the manager needs to collect this table sepeartely and can cache it. I presume this information will not change over the life time of the device. That would require once the collection of the table and no repeating data in the notification. NOTE: I am note sure how big this table can be. > > >> The docsIfDocsisBaseCapability >> indicates the DOCSIS version information. > > > > The DOCSIS version information of what? > > [AA,GN] Will replace with: "indicates the highest version of the > DOCSIS specification (1.0, 1.1, or 2.0) that the device is capable of > supporting." OK > > What is ment by 'uniform accross all CM traps'? > > [AA,GN]I think the intent here was to say that the objects previously > described are also used in the subsequent CM notifications. This > sentence will be deleted, since we'll repeat the description in each > notification definition. OK > > DESIGN-CHOICE [snip] > > [AA,GN] OK, we'll repeat the description of the objects (and describe > it > better) in each notification. > > We prefer not to merge all the notifications even if the same objects > are returned in many of these notifications. Essentially, each > notification definition serves as a category for a set of events. > DOCSIS defines hundreds of events which are categorized and mapped to > a particular notification for reporting the event. This enables the > NMS to more easily find events associated with a particular category. OK. As a design choice it is wise to add wording in the descriptive text of the RFC. Otherwise would have similar remarks I presume. > > > >> docsDevCmSwUpgradeInitTrap NOTIFICATION-TYPE >> OBJECTS { >> docsDevEvLevel, >> docsDevEvId, >> docsDevEvText, >> ifPhysAddress, >> docsIfCmCmtsAddress, >> docsDevSwFilename, >> docsDevSwServer, >> docsIfDocsisBaseCapability, >> docsIfCmStatusDocsisOperMode, >> docsIfCmStatusModulationType >> } >> STATUS current >> DESCRIPTION >> "An event to report a software upgrade initiated >> event. > > > > > Weird sentence. > > [AA,GN] Will change to: "A notification to indicate that a software > upgrade has been intiated on the device" OK _______________________________________________ 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 Sat Jul 10 00:28:01 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05186 for ; Sat, 10 Jul 2004 00:28:00 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj9T0-0004fy-83 for ipcdn-archive@ietf.org; Sat, 10 Jul 2004 00:28:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj9Gl-0002j8-00 for ipcdn-archive@ietf.org; Sat, 10 Jul 2004 00:15:32 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bj96Y-0000rS-00 for ipcdn-archive@ietf.org; Sat, 10 Jul 2004 00:04:50 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bj8pM-0003kD-GD for ipcdn-archive@ietf.org; Fri, 09 Jul 2004 23:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7gj-0004xJ-AL; Fri, 09 Jul 2004 22:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj554-0006UM-0m for ipcdn@megatron.ietf.org; Fri, 09 Jul 2004 19:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13879 for ; Fri, 9 Jul 2004 19:46:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj54x-0000yB-8x for ipcdn@ietf.org; Fri, 09 Jul 2004 19:46:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj548-0000eY-00 for ipcdn@ietf.org; Fri, 09 Jul 2004 19:46:07 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Bj53T-0000H7-00; Fri, 09 Jul 2004 19:45:23 -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 i69Nimbw014400; Fri, 9 Jul 2004 17:44:49 -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] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Date: Fri, 9 Jul 2004 17:44:48 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E592@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Thread-Index: AcRirwV22L3ge7KCR5athhHXaMl7ygCSd3Yw From: "Eduardo Cardona" To: "Juergen Quittek" , "Randy Presuhn" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Juergen,=20 Thanks for the detail responses, Please find some extra comments inline Thanks Eduardo -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 Sent: Monday, July 05, 2004 3:51 AM To: Eduardo Cardona; Randy Presuhn; disman@ietf.org Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Eduardo, Many thanks for your comments. Please find some replies inline. --On 22.06.2004 11:42 Uhr -0600 Eduardo Cardona wrote: > Thanks Jurgen for adding the Minimal compliance in the new draft > > Few comments: > > Draft is not indicating in upper header that is obsoleting RFC 2925 I think the RFC editor will take care of this issue. I did not dare yet using an "Obsoletes:" entry in the header while having an "Expires:" entry in the line below :-) - OK=20 > DISMAN-PING-MIB > > Since the objects are carried from a previous RFC, The extra comments > I got for objects are not critical, although I went to the exercise of > understanding and may worth for direct clarifications to me if I=20 > misunderstood them > > Please pay special attention to the new minimum compliance modules > comments (under ****) > > > pingCtlTrapGeneration > I see a lot of overlapping in between probeFailures and TestFailures > because both are within a ping Test. Making that very punctual for=20 > notification stand point > > One approach (two layers) could be that TestFailure notification is > only sent after multiple Test Failures Exactly this is the case, see pingCtlTrapTestFailureFilter. Or did I get something wrong? - See next comment > ( based on the Frequency object may > indicate reasonable periods of hosts disconnection) so you can avoid > getting ProbeFailure notification but use this counter for accumulate=20 > Test failures, then collect notifications only for Test failures=20 > periods > -probeFailure(0) set to '0'. In the other hand setting probeFailure(0) > to '1' will get the time details of the probe failures that constitute a > Test failure. I don't really get this. We have a counter for probe failures and a counter for test failures. Both can be switched on and off independently by setting the corresponding bits in pingCtlTrapGeneration. - I agree that this should be the intention; probably some terms are not used exactly pingCtlTrapTestFailureFilter says=20 "...a pingTestFailed NOTIFICATION is generated only when the number of ping failures within a test exceed the value of pingCtlTrapTestFailureFilter." pingCtlFrequency says: "... A value of 0 for this object implies that the test as defined by the corresponding entry will not be repeated." "within a test" above seems to be associated to a "test" (a set of ping probes) not a consecutive number of tests as per CtlFrequency > 0 will imply Another variant will be that instead of saying ProbeFailures =3D 3 TestFailures =3D 4=20 Japanesse notation: O ok X fail ( with your assumption below that all probes in test means failure ? ) Test 1: probe1: O, probe2: X, probe3: X Test 2: probe1: X, -> TestFailure NOTIFICATION Test1: O Test2: X Test3: X Test4: X Test5: X -> TestFailure NOTIFICATION I think will be more interested if consecutive N Test Failed: It also remove the otherwise required constrain that TestFailure > probeFailure "...a pingTestFailed NOTIFICATION is generated only when a number of consecutive=20 test failures exceed the value of pingCtlTrapTestFailureFilter. After a NOTIFICATION is generated the test failure counter is reinitialized." - it is an internal implicit counter with no MIB representation, which I think is ok The third alternative is=20 # probes per test is very long and all TestFailure and ping Probes are within a particular test. Which I think Does not scale well for time intervals flexibility (test vs test frequency). / different sort of SLA needs. But if that is the case the definitions are ok but with the hiden constrain that TestFailure > Ping Probe (within a test) =20 =20 > - also does "sucessive" means consecutive? Let's replace "sucessive" by "consecutive". Any objection from native English speakers? > If Filter is set to 3 > 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7) > reply Means ProbeFailure happen between 4) and 6) As far as I understand the current DESCRIPTION clause, the notification is triggered by 6). > I think the testFailure(1) BIT should indicate that a Test Failure is > reached by the threshold of pingCtlTrapProbeFailure rather than=20 > pingCtlTrapTestFailure. Moreover the definitions of=20 > pingCtlTrapGeneration and=20 > pingCtlTrapProbeFailureFilter/pingCtlTrapTestFailureFilter are=20 > overlapping and probably redundant. The bit testFailure(1) does not indicate that any failure happened, it indicates that generation of notification in such a case is enabled. As far as I understood the descriptions so far, a test is failed only if all probes failed. I must admit that this is not explicitly specified. Any comment from an implementer? > A possible wording to illustrate the comment could be: > "... > For > pingCtlTrapGeneration > DESCRIPTION > "The value of this object determines when and if > to generate a notification for this entry: > > probeFailure(0) - Generate a pingProbeFailed > notification subject to the value of > pingCtlTrapProbeFailureFilter. > testFailure(1) - Generate a pingTestFailed > notification. A Test Failure condition is defined > if within a test the number of probe failures > reaches the value of pingCtlTrapProbeFailureFilter > testCompletion(2) - Generate a pingTestCompleted > notification. > > By default, no bits are set, indicating that > none of the above options are selected." > > pingCtlTrapProbeFailureFilter/TestFailureFilter > the description of pingCtlTrapProbeFailureFilter is not Clear to me > if after the # of probe failures of the ProbeFailureFilter object are=20 > reached a notification is sent and if the counter is cleared > > e.g. > pingCtlTrapProbeFailureFilter =3D 5 > pingCtlProbeCount =3D 15 > Supposed all ping probes timed out, > Will it send notification after attempts 5, 10 and 15 > or > After attempts 5,6,7,....15 > A possible wording could be ( only sending notifications after > attempts 5, 10 and 15: You are right. This case is not well specified. > pingCtlTrapProbeFailureFilter > "The value of this object is used to determine when > to generate a pingProbeFailed NOTIFICATION. > > Setting pingCtlTrapGeneration BIT probeFailure(0) > to '1' implies that a pingProbeFailed I think we can omit "to '1'". - but what it mean setting BIT probeFailure(0) setting to '1' or setting to '0'? Both values are valid so I do not see that setting BITs means to UP, ON or '1' eventually I missed that from SMI but I have been see other MIB MODULES defining setting=20 BIT X to '1' or '0' =20 > NOTIFICATION is generated only when a number of > successive ping probes equal to the value of > pingCtlTrapPrbefailureFilter fail within > a given ping test. Then a Test failure condition is > reached and the probe failure count is > reset for the following attempts within the > given ping test." I disagree with the first part of the last sentence "Then a Test failure condition is reached", but I agree to the rest. - Ok, aligned with my other clarifications proposed above > Similar for pingCtlTrapTestFailureFilter > "The value of this object is used to determine when > to generate a pingTestFailed NOTIFICATION. > > Setting pingCtlTrapGeneration BIT testFailure(1) > to '1' implies that a pingTestFailed NOTIFICATION is > generated only when the number of test failures > within a test exceed the value of > pingCtlTrapTestFailureFilter." He also need to add a statement on reseeting the test failure counter when the notification is sent. - as proposed above .... But still unsure if the intention is to keep this "within a test" as commented above (alternative 3) "...a pingTestFailed NOTIFICATION is generated only when a number of consecutive=20 test failures exceed the value of pingCtlTrapTestFailureFilter. After a NOTIFICATION is generated the test failure counter is reinitialized." - See the proposed=20 > Above is also included a small wording for the BIT sets > > pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to > conform with RFC3291 bis draft 03 Fine with me. Any objections from the "Who needs IPv6?" community? > > MinimumCompliance > ***************** > > PingCtlRowStatus has a compliance SYNTAX read-only; some > clarifications in how the minimum compliance default entry All time=20 > with value 'active' ? Regularly a 'notReady' entry when filled all the > minimum object sets becomes 'notInService' and need to be set to=20 > 'active' via SNMP to complete the operation In read-only mode it has three possible values: - 'notReady' as long as pingCtlTargetAddress is not specified. - 'notInService' starting when pingCtlTargetAddress specified until pingCtlAdminStatus is set to enabled(1). - 'active' after pingCtlAdminStatus has been set to enabled(1) in state 'notInService'. - again 'notInService' after pingCtlAdminStatus has been set to disabled(1) in stat 'active'. - About=20 "'active' after pingCtlAdminStatus has been set to enabled(1) in state 'notInService'" -I do not think that RowStatus TC can transition automatically from 'notInService' to 'active' >From RowStatus State Diagram=20 >From State C "setting other column to some value" -> C - My view was that because the pre-created entry with zero indexes was already there No need to have to set RowStatus to active afterwards,=20 I see any way the value of RowStatus as an indicator the the test configuration is not ready, Just quite expensive to always have to turn active,=20 > a) Will the compliance statement should say that a 'notReady' is > automatically set to 'active' when all fields (specially when=20 > pingCtlTargetAddress is set?) No, it will automatically be set to 'notInService'. Yes, see above=20 > would that be valid request? -not included > in the state diagram of RowStatus TC- >From 'notInService', transitions to 'active' can only be reached by setting pingCtlAdminStatus. (as specified in the DESCRIPTION clause of pingCtlRowStatus). Note, that setting pingCtlTargetAddress and pingCtlAdminStatus should still be possible with just a single SNMP PDU. > Or > b) more general the pingCtlAdminStatus should indicate an error when > attempting to start (enabled(1) the test and the entry is notReady(2)=20 > / > notInService(1) ? > > And probably the MinumimCompliance may need a SYNTAX clause like Yes, this is missing. > SYNTAX RowStatus { notReady(3), active(1)} It should look like SYNTAX RowStatus { active(1), notInService(2), notReady(3)} Probably it would be a good idea to explain the state transitions (as described above) in the corresponding DESCRIPTION clause. Yes, I agree just verify the RFC 2579 transition from notInService' to active ( I may miss something) > Object Compliances > pingCtlFrequency r-o; last sentence "A value zero means... " may not > be needed any case, the test is not repeated and 0 value already=20 > defined In the object description I agree that the sentence is redundant. I thought it would help understanding the compliancy more quickly, but I have no strong feeling about keeping or removing the sentence. Any further opinions? - OK, >From the comment in the security section redundancy is less expensive than ambiguity=20 > Normalization of SYNTAX sub-typing as in other objects. -- Just a > comment Up to MIB doctor for style normalization in the compliances..=20 > pingCtlStorateType can have a SYNTAX clause SYNTAX StorageType {=20 > volatile(2)} I think this is more strict. I did not intend to exclude. for example, 'permanent' entries. - OK, no need for that >> From RFC 2925 the Compliance statement has under pingGroup the >> objects > of Ctl, Results, History and the Notification Group > > Since the minimal compliance has only Ctl, Results objects I think is > better to define a MANDATORY-GROUP pingMinGroup including Ctl and=20 > Results Objects. So the original group is left intact (unless specific > compliances are needed as pingComplianceV2 (if there are important=20 > differences with the original Compliance) What about just renaming the new pingGroup to pingMinimumGroup? - OK with me > - Will be ok with MIB doctor perception of this compliances > ramifications > > > > DISMAN-TRACEROUTE-MIB > > > MinumumCompliance > ***************** > Same as ping Compliances From RFC 2925 and new draft the > traceRouteGroup has originally Ctl, Results and Probehistory Objects. > > The minimal compliance will just have a traceReouteMinimumGroup with > Ctl and Results objects and leave the original group (fully compliant) > intact. > > > Same comments for traceRouteCtlFrequency and traceRouteCtlStorageType > as for the PING minimum compliance. OK, however we decide on the PING MIB, I will change the TRACEROUTE MIB analogously. Thanks, Juergen > > DISMAN-NSLOOKUP-MIB > No issues. > > > Thanks > > Eduardo > > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > Sent: Wednesday, June 16, 2004 3:47 PM > To: Randy Presuhn; disman@ietf.org > Cc: ipcdn@ietf.org > Subject: [ipcdn] Re: [Disman] WG last call > ondraft-ietf-disman-remops-mib-v2-01.txt > > > Dear all, > > I just posted a new version of the remote operation MIB modules. > Following Eduardo's suggestion I added Minimum Compliancy statements=20 > in addition to the existing full compliancy statements to each of the=20 > three MIB modules. > > I also had to (syntactically) modify the existing compliancy > statements. Please have a close look at all six MODULE-COMPLIANCE=20 > macros. Until the document becomes available at the I-D repository,=20 > you can preview it at > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib- > v2-02.txt > > There was not much response on my questions on how to define the > minimum compliance statements. I preferred leaving read-only objects=20 > in place to creating non-consecutive numbering of objects in table=20 > entries. I am not dogmatic about this and suggestions for changes are > very welcome. > > For simplifying the review here is a list of objects and groups for > which the full and minimum compliance statements differ: > > pingHistoryGroup, > pingNotificationsGroup > pingCtlDataFill > pingCtlFrequency > pingCtlMaxRows > pingCtlTrapGeneration > pingCtlProbeFailureFilter > pingCtlTestFailureFilter > pingCtlDescr > pingCtlByPassRouteTable > pingProbeHistoryTime > > traceRouteHistoryGroup > traceRouteCtlByPassRouteTable > traceRouteCtlDontFragment > traceRouteCtlInitialTtl > traceRouteCtlFrequency > traceRouteCtlDescr > traceRouteCtlMaxRows > traceRouteCtlTrapGeneration > traceRouteCtlCreateHopsEntries > traceRouteCtlRowStatus > traceRouteHopsLastGoodProbe > > lookupCtlRowStatus > > Beyond the compliance statement I just made two changes to the > document: > > 1. Added new section 3.4 introducing the compliance statement > > 2. Extended DESCRIPTION clause of object lookupPurgeTime by one > sentence: > > "A value of 0 indicates that automatic deletion > of entries is disabled." > > Thanks, > > Juergen > -- > Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 > 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 > 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.ccrle.nec.de > > > --On 29.04.2004 14:29 h -0700 Randy Presuhn wrote: > >> Hi - >> >> Are there any objections to proceding as Juergen and Eduardo suggest? >> I'd like to see comment (pro or contra) on the specific questions=20 >> Juergen raised below. >> >> Randy, disman WG chair >> >>> From: "Juergen Quittek" >>> To: "Eduardo Cardona" ; "Randy Presuhn" >>> ; >>> Cc: "Ipcdn List (E-mail)" >>> Sent: Monday, April 26, 2004 1:11 AM >>> Subject: RE: [Disman] WG last call on=20 >>> draft-ietf-disman-remops-mib-v2-01.txt >>> >> >>> Eduardo, >>> >>> Thank you for raising this issue and my apologies for this very late >>> reply. >>> >>> I ran into similar problems several times where a well designed >>> technology was too mighty or too general for being implemented at=20 >>> small devices. >>> >>> Your suggestions aim at introducing additional MODULE-COMPLIANCE >>> clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules=20 >>> for allowing simpler implementations with smaller footprints. >>> >>> I support your proposal, but have a few comments, see below. I am >>> willing to make suggestions for minimalCompliance clauses for the=20 >>> MIB > >>> modules, but first the WG should agree on two issues: >>> >>> - Is it agreed to add such clauses, that definitely require >>> less funtionality to be implemented? >>> >>> - what is the preferred procedure for columnar objects that >>> are not required for minimal compliancy? We can either >>> allow them to be missing completely. But this would result >>> in non-consecutive numbering of the remaining objects in >>> the minimal tables. Or we require them to be implemented >>> as read-only indicating that the feature that they would >>> serve in full compliancy is not supported. >>> >>> Please find further comments inline. >>> >>> Juergen >>> -- >>> Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 > 90511-15 >>> NEC Europe Ltd., Network Laboratories Fax: +49 6221 > 90511-55 >>> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.ccrle.nec.de >>> >>> >>> --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: >>> > Randy, >>> > >>> > Few comments, >>> > >>> > I review the MIB and appears compelling respect to previous RFC >>> > >>> > Just one comment >>> > >>> > >>> > (*) traceRouteCtlMiscOptions >>> > It appears to me an uncanny object and rather implementations may >>> > opt to extend the capabilities in the private branch, could leave=20 >>> > with that to avoid deprecation, of if there are field=20 >>> > implementations. >>> >>> Currently, the MODULE-COMPLIANCE clause traceRouteCompliance >>> requests > >>> implementation of this object, but it may be implemented as >>> read-only > >>> and returning always a value of zero, if there is not further >>> semantics defined for it. Do you suggest to completely remove the=20 >>> object or to state in the MODULE-COMPLIANCE clause that it does not=20 >>> need to be implemented? >>> >>> > Regardless of the additions to the MIB I apologize for the late >>> > notice, >>> > >>> > Before sending a complete proposal and get your concept of the >>> > best > >>> > approach, below is the proposal to add a simplified Compliance >>> > statement for devices not requiring to keep constant status of=20 >>> > PING/TRACEROUTE operations, only remote operation per operator=20 >>> > request. >>> > >>> > >>> > We are looking at your comments about the clear overlap in >>> > draft-ietf-disman-remops-mib-v2-01.txt >>> > With IPCDN draft=20 >>> > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-m >>> > i >>> > b-00. >>> > txt ( currently out of date in IETF drafts site) which is clearly a >>> > subset of the DISMAN-PING-MIB >>> > Lectors refer to >>> > > http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg0081 > 8. >>> > html >>> > >>> > Should the proposal below being include in the remops MIB or >>> > should > >>> > we update IPCDN cable gateway Tools MIB module to be just the >>> > compliance statement outlined below? >>> >>> I doubt that it is a good idea to replicate large portions of the >>> PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done=20 >>> right now. >>> >>> > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null >>> > named log" default entry for devices not supporting the named log=20 >>> > Named log is analog to disman remops draft for "OwnerIndex" and=20 >>> > "TestName" where default entries are created (null owner, null >>> > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 >>> > NSLOOKUP, mostly for small foot-print devices with no network=20 >>> > monitoring role at the connectivity level as pretended with this=20 >>> > updated RFC. >>> >>> I don't think the remops MIB modules forbid null-named entries in >>> the > >>> respective tables. But currently the support of a read-write >>> pingCtlRowStatus is mandatory. >>> >>> Is your concrete suggestion to add something like >>> >>> OBJECT XXRowStatus >>> MIN-ACCESS read-only >>> DESCRIPTION >>> "Implementations may disallow the creation of named >>> entries." >>> >>> with XX=3DpingCtl,traceRouteCtl,lookupCtl? >>> >>> > In summary A new Compliance Statement for small devices with no >>> > monitoring capabilities to : >>> > 1) remove the constant pulling and login information >>> > 2) remove the test row creation >>> > - CTL* Results* tables only default entries (null owner, null >>> > TestName) >>> > 3) History* tables not required. >>> > - New basicGroups to exclude History* objects and other objects=20 >>> > which are not relevant to the simplified >>> > system. >>> > - Create an additional set of Compliance statements to=20 >>> > require the new Groups and other objects Compliance >>> > requirements MIN-ACCESS clauses mainly >>> > >>> > Schema of the content of the new Compliance statement: >>> > >>> > List of objects not to include in basicPingGroupOBJECT-GROUP >>> > clause qnd/or hints for OBJECT Compliances: >>> > pingMaxConcurrentRequests -- remove >>> >>> Could also be read-only returning 1. >>> >>> > pingCtlDataFill -- remove or MIN-ACCESS read-only > default >>> > value is OK >>> > pingCtlFrequency -- remove Only one test >>> >>> Could also be read-only returning 0. >>> >>> > pingCtlType -- remove or MIN-ACCESS read-only >>> > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only >>> > pingCtlDSField -- MIN-ACCESS read-only >>> > pingCtlStorageType -- remove >>> > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) >>> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >>> >>> Why don't you consider removing this object? >>> >>> > pingCtlIfIndex -- not to include >>> > pingProbeHistory* -- not to include. >>> > >>> > List of objects not to include in basicTraceRouteGroup >>> > OBJECT-GROUP clause and/or hints for OBJECT Compliances: >>> > traceRouteMaxConcurrentRequests -- remove >>> > traceRouteCtlType -- remove or MIN-ACCESS read-only >>> > traceRouteCtlDSField -- MIN-ACCESS read-only >>> > traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only >>> > traceRouteCtlIfIndex -- not to include >>> > traceRouteCtlMiscOptions -- not to include >>> > traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only >>> > traceRouteCtlInitialTtl -- remove or MIN-ACCESS >>> > traceRouteCtlFrequency -- remove only one test >>> > traceRouteCtlDescr -- remove >>> > traceRouteCtlCreateHopsEntries -- remove HopsEntries not > required. >>> > traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) >>> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >>> > traceRouteCtlStorageType -- remove >>> > traceRouteProbeHistory* -- not to include. >>> > >>> > List of objects not to include in basicLookupGroup OBJECT-GROUP >>> > clause and/or hints for OBJECT Compliances: >>> > lookupMaxConcurrentRequests -- remove >>> > lookupPurgeTime -- remove >>> > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) >>> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >>> > >>> > >>> > Best Regards >>> > >>> > Eduardo >>> > >>> > -----Original Message----- >>> > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >>> > Sent: Monday, March 01, 2004 6:44 PM >>> > To: disman@ietf.org >>> > Subject: RE: [Disman] WG last call on >>> > draft-ietf-disman-remops-mib-v2-01.txt >>> > >>> > >>> > >>> > Hi - >>> > >>> >> From: Eduardo Cardona >>> >> Sent: Mar 2, 2004 9:25 AM >>> >> To: Randy Presuhn , disman@ietf.org >>> >> Subject: RE: [Disman] WG last call on >>> >> draft-ietf-disman-remops-mib-v2-01.txt >>> > ... >>> >> One simple note, I tough last call was March 5th >>> > >>> > No, it was supposed to end March 2. However, I'm not going to >>> > hand > >>> > it to our AD until I can be reasonably sure that it has received >>> > adequate review. >>> > >>> >> We at Cablelabs are interested in adding a simplified compliance >>> >> statement for ad-hoc procedure call instead of a user entry=20 >>> >> schecule entry, so an user can do a one time execution e.g PING >>> > >>> > It would have been nice to have learned of this earlier, rather >>> > than during WG last call. >>> > >>> >> The draft we had is almost complete, >>> >> Would be that an opportunity to add that? I can post that >>> >> tomorrow > >>> >> in the list if compeling >>> > ... >>> > >>> > I'd like to have this discussion sooner rather than later, so >>> > please make your specific proposal as quickly as you can. My=20 >>> > opinion as a technical contributor is that the case for these=20 >>> > changes would need to be fairly compelling if they would result in >>> > the remote operations MIB cycling at proposed rather than=20 >>> > advancing > >>> > to draft standard. As working group chair, I want to ensure that >>> > whatever course we take reflects WG consensus. So, balancing the=20 >>> > need for bringing this to a conclusion with the need to ensure=20 >>> > that > >>> > the technical issues are properly considered, I'll entertain >>> > discussion of this issue ("ad hoc procedure call") until Friday=20 >>> > noon (Korean Time). Shortly thereafter I'll make a call on=20 >>> > whether > >>> > there is consensus to modify the draft regarding this specific >>> > proposal. >>> > >>> > Randy >>> > >>> > >>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 13 09:18:33 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08828 for ; Tue, 13 Jul 2004 09:18:33 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkNB4-0001us-C9 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 09:18:34 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkNA4-0001Zx-00 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 09:17:33 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkN96-0000vs-00 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 09:16:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkN1i-0005kG-5H; Tue, 13 Jul 2004 09:08:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkMvf-0004GS-7q for ipcdn@megatron.ietf.org; Tue, 13 Jul 2004 09:02:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07661 for ; Tue, 13 Jul 2004 09:02:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkMve-0004mR-FD for ipcdn@ietf.org; Tue, 13 Jul 2004 09:02:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkMui-0004R7-00 for ipcdn@ietf.org; Tue, 13 Jul 2004 09:01:41 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BkMtf-0003oD-00 for ipcdn@ietf.org; Tue, 13 Jul 2004 09:00:35 -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 i6DD02bw023705 for ; Tue, 13 Jul 2004 07:00:03 -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: [ipcdn] Draft Submissions - Important note about boilerplate Date: Tue, 13 Jul 2004 07:00:02 -0600 Message-ID: Thread-Topic: [ipcdn] Draft Submissions - Important note about boilerplate Thread-Index: AcRaD5O/L6y01F4HSWuxQlFeRRx4BQLBwkhAAM0D+GA= From: "Jean-Francois Mule" To: X-Approved: ondar 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Hi Everyone, If you are submitting new or revised Internet Drafts now, please ensure = that the drafts have the correct boilerplate, "status of this memo" and = "copyright notice" sections.=20 See details in=20 the ID guidelines: http://www.ietf.org/ietf/1id-guidelines.txt=20 and the ID checklist: http://www.ietf.org/ID-Checklist.html Otherwise the risk is high that the IETF secretary will reject your = submission. This practice has recently begun being enforced. Thank you, Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 13 11:14:36 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17505 for ; Tue, 13 Jul 2004 11:14:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkOzN-0000Mw-GS for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 11:14:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkOyT-00004D-00 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 11:13:43 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkOxn-0007Wd-00 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 11:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkOob-0006Dz-WC; Tue, 13 Jul 2004 11:03:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkOlO-0005Qm-Le for ipcdn@megatron.ietf.org; Tue, 13 Jul 2004 11:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16896 for ; Tue, 13 Jul 2004 11:00:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkOlN-0003Vr-KN for ipcdn@ietf.org; Tue, 13 Jul 2004 11:00:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkOkT-00039z-00 for ipcdn@ietf.org; Tue, 13 Jul 2004 10:59:15 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BkOiq-0002bj-00 for ipcdn@ietf.org; Tue, 13 Jul 2004 10:57:33 -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 i6DEusc1017972; Tue, 13 Jul 2004 08:56:56 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ipcdn] Draft response to ETSI liaison for wg comments by 7/20 Date: Tue, 13 Jul 2004 08:56:55 -0600 Message-ID: Thread-Topic: [ipcdn] Draft response to ETSI liaison for wg comments by 7/20 Thread-Index: AcRaD5O/L6y01F4HSWuxQlFeRRx4BQLBwkhAAPGivzA= From: "Jean-Francois Mule" To: X-Approved: ondar Cc: Bill Utlaut , Beacham Gordon-CGB005 , David De Reu , Christie Poland , "Richard Woundy @ Comcast" , Thomas Anders , skang@upctechnology.com, Wim De Ketelaere , 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: , Content-Type: multipart/mixed; boundary="===============1128843299==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_FONTCOLOR_BLUE, HTML_FONTCOLOR_GREEN,HTML_FONTCOLOR_RED,HTML_FONTCOLOR_UNSAFE, HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. --===============1128843299== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C468E9.A3AC5BD1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C468E9.A3AC5BD1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This note provides a draft response to the ETSI liaison statement. The = ETSI liaison was sent to the ipcdn list on June 16. The wg response is = based on previous contributions & email exchanges from many = participants. It is submitted for wg review & comments. We would like to send our = response back to ETSI next week; please send any comments by July 20 = 11am Easter Time. Thanks to all of you who have contributed in the past months on these = topics, Jean-Fran=E7ois=20 ---=20 To: ETSI AT working group Digital Cc: Simon Kang (UPC) Wim De Ketelaere (tComLabs) Gordon Beacham (Motorola BCS) Bill Utlaut (CableLabs) RE: ETSI liaison from ETSI AT-Digital, AT-D AT#9(2004)D_25 We would like to thank ETSI and Simon Kang of UPC, Rapporteur of the ETSI AT-D IPCablecom MIB requirements for your continued support of the work of the IETF IP over Cable Data Network (IPCDN) working group in creating one common set of MIBs standardized in IETF. We have received the ETSI liaison statement dated from June 8 2004 regarding the IPCablecom MIB requirements. This note constitutes the IPCDN working group response. It first provides some information on the ipcdn schedule and timeline to publish the RFCs. It also documents the IPCDN working group consensus on the ETSI technical comments. Best regards, Rich Woundy and Jean-Francois Mule IETF IPCDN co-chairs --- 1. Request for information about the ipcdn schedule for the --- approval of the ietf ipcdn packetcable mibs to published RFC --- status taking account of all ETSI comments as summarised in the --- liaison statement AT-D AT#9(2004)D_25 As of July 2004, the 3 IPCDN wg Internet-Drafts in question are "work in progress" documents: draft-ietf-ipcdn-pktc-mtamib-03, draft-ietf-ipcdn-pktc-signaling-03, draft-ietf-ipcdn-pktc-eventmess-03. The procedures for advancing IETF Internet-Drafts are described in BCP 9, RFC2026 (and some procedures are explained in RFC 3160). It is the intent of the IPCDN wg chairs to advance those Internet-Drafts to publication via a formal "publication request" to the IETF Operations and Management Area Directors and our Area Advisor for ipcdn, Bert Wijnen after the following conditions are met: a) all the ETSI comments received in the liaison have been addressed and integrated in revised drafts; Based on the information we have received from the authors and editors of those drafts, we believe that draft04 revisions will be submitted by July 19 and will appear on the IETF Internet-Draft repository by August 2004. b) Working group last call is passed We will issue a 2-week Working Group Last Call notice once the draft04 revisions are published. c) Expert MIB doctor reviews are complete and revised drafts published The assignment of MIB doctors will occur once the draft04s are released and a timeline for completion of MIB doctor reviews will be defined then. We expect that revised drafts addressing all the MIB doctor comments will be published in September 2004. Following the wg chair formal "publication request" to the Area Directors, the work of the working group is usually considered complete. As stated above, we expect to conclude our work on the IPCDN PacketCable/IPCablecom MIBs in September 2004. The standard IETF process will then follow its course with IESG Review and approval (including IETF Last Call) and, upon successful completion of the last call announcement, the final documents will be sent to the RFC Editors. A rough timeline for the final IETF steps is difficult to predict and we will have a better estimate once the IETF Last Call is complete. --- 2. Response to ETSI technical recommendations We note that all the ETSI recommendations relate to one IPCDN Internet-Draft: ID: draft-ietf-ipcdn-pktc-signaling-03. We assume the other drafts have been reviewed by ETSI and meet your requirements. 2.1) NCS service flow mechanism: The IPCDN working group is in agreement with the ETSI recommendation to delete the following 4 MIB objects from draft-ietf-ipcdn-pktc-signaling-03: pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask, and pktcSigNcsServiceFlowState. 2.2) Ringing cadences:=20 The IPCDN working group is in agreement with the ETSI recommendation to change the definition of the PktcRingCadence textual-convention and its use for every ring cadence defined in the MIB. Note that this topic had already been discussed on IPCDN in March 2004 and that we had reached agreement to change the SYNTAX of the textual-convention. The ETSI liaison makes some additional editorial suggestions in the DESCRIPTION clause of the textual convention and we accept those comments. See ipcdn email references at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01119.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01122.html 2.3) Value Ranges: We note that ETSI supports the IPCDN discussions to change the value range of the pktcSigDevToneDbLevel object to pktcSigDevToneDbLevel OBJECT-TYPE SYNTAX TenthdBm (-250..-30) The IPCDN wg has reached consensus on the above change and the new value range (-250..-30) will be reflected in the revised draft04. Note that the value range of some other MIB objects were also discussed on the IPCDN list and that some changes will be reflected in the upcoming draft04, for e.g., the range of pktcSigPulseSignalDbLevel is changed from (-250..152) to (-350...0). --- end of response to the ETSI liaison statement ------_=_NextPart_001_01C468E9.A3AC5BD1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ipcdn] Draft response to ETSI liaison for wg comments by = 7/20

  This = note provides a draft response to the ETSI liaison statement. The ETSI = liaison was sent to the ipcdn list on June 16. The wg response is based = on previous contributions & email exchanges from many = participants.

  It is = submitted for wg review & comments. We would like to send our = response back to ETSI next week; please send any comments by July 20 = 11am Easter Time.

Thanks to = all of you who have contributed in the past months on these = topics,
Jean-Fran=E7ois

---
To:  ETSI AT working group = Digital
Cc:  Simon Kang (UPC)
     Wim De Ketelaere (tComLabs)
     Gordon Beacham (Motorola BCS)
     Bill Utlaut (CableLabs)

RE:  ETSI liaison from ETSI AT-Digital, AT-D AT#9(2004)D_25

  We would like to thank ETSI and Simon Kang of UPC, Rapporteur of = the
ETSI AT-D IPCablecom MIB requirements for your continued support of
the work of the IETF IP over Cable Data Network (IPCDN) working = group
in creating one common set of MIBs standardized in IETF.
  We have received the ETSI liaison statement dated from June 8 = 2004
regarding the IPCablecom MIB requirements.
  This note constitutes the IPCDN working group response. It = first
provides some information on the ipcdn schedule and timeline to
publish the RFCs. It also documents the IPCDN working group = consensus
on the ETSI technical comments.

Best regards,
Rich Woundy and Jean-Francois Mule
 IETF IPCDN co-chairs

--- 1. = Request for information about the ipcdn schedule for the
---    approval of the ietf ipcdn packetcable mibs = to published RFC
---    status taking account of all ETSI comments as = summarised in the
---    liaison statement AT-D = AT#9(2004)D_25

As of July 2004, the 3 IPCDN wg = Internet-Drafts in question are
"work in progress" documents:
   draft-ietf-ipcdn-pktc-mtamib-03,
   draft-ietf-ipcdn-pktc-signaling-03,
   draft-ietf-ipcdn-pktc-eventmess-03.
The procedures for advancing IETF Internet-Drafts are described in
BCP 9, RFC2026 (and some procedures are explained in RFC 3160).

It is the intent of the IPCDN wg chairs to advance those
Internet-Drafts to publication via a formal "publication = request" to
the IETF Operations and Management Area Directors and our Area = Advisor
for ipcdn, Bert Wijnen after the following conditions are met:
   a) all the ETSI comments received in the liaison have = been
      addressed and integrated in revised = drafts;
Based on the information we have received from the authors and
editors of those drafts, we believe that draft04 revisions will be
submitted by July 19 and will appear on the IETF Internet-Draft
repository by August 2004.

   b) Working group last call is passed
We will issue a 2-week Working Group Last Call notice once the = draft04
revisions are published.

   c) Expert MIB doctor reviews are complete and revised = drafts
      published
The assignment of MIB doctors will occur once the draft04s are = released
and a timeline for completion of MIB doctor reviews will be defined
then. We expect that revised drafts addressing all the MIB doctor
comments will be published in September 2004.

Following the wg chair formal "publication request" to the = Area
Directors, the work of the working group is usually considered
complete. As stated above, we expect to conclude our work on the = IPCDN
PacketCable/IPCablecom MIBs in September 2004.
The standard IETF process will then follow its course with IESG = Review
and approval (including IETF Last Call) and, upon successful
completion of the last call announcement, the final documents will = be
sent to the RFC Editors. A rough timeline for the final IETF steps = is
 difficult to predict and we will have a better estimate once the = IETF
Last Call is complete.


--- 2. = Response to ETSI technical recommendations
We note that all the ETSI = recommendations relate to one IPCDN
Internet-Draft: ID: draft-ietf-ipcdn-pktc-signaling-03. We assume = the
other drafts have been reviewed by ETSI and meet your requirements.

2.1) = NCS service flow mechanism:
The IPCDN working group is in = agreement with the ETSI recommendation
to delete the following 4 MIB objects from
draft-ietf-ipcdn-pktc-signaling-03:
  pktcSigServiceClassNameUS,
  pktcSigServiceClassNameDS,
  pktcSigServiceClassNameMask, and
  pktcSigNcsServiceFlowState.

2.2) = Ringing cadences:
The IPCDN working group is in = agreement with the ETSI recommendation
to change the definition of the PktcRingCadence textual-convention = and
its use for every ring cadence defined in the MIB.
Note that this topic had already been discussed on IPCDN in March = 2004
and that we had reached agreement to change the SYNTAX of the
textual-convention.
The ETSI liaison makes some additional editorial
suggestions in the DESCRIPTION clause of the textual convention and = we
accept those comments.
See ipcdn email references at:
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01119.html
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01122.html


2.3) = Value Ranges:
We note that ETSI supports the IPCDN = discussions to change the
value range of the pktcSigDevToneDbLevel object to
   pktcSigDevToneDbLevel    OBJECT-TYPE
       = SYNTAX       TenthdBm (-250..-30)
The IPCDN wg has reached consensus on the above change and the new
value range (-250..-30) will be reflected in the revised draft04.
Note that the value range of some other MIB objects were also
discussed on the IPCDN list and that some changes will be reflected = in
the upcoming draft04, for e.g., the range of = pktcSigPulseSignalDbLevel
is changed from (-250..152) to (-350...0).


--- end = of response = to the ETSI liaison statement

------_=_NextPart_001_01C468E9.A3AC5BD1-- --===============1128843299== 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 --===============1128843299==-- From ipcdn-bounces@ietf.org Tue Jul 13 22:12:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27633 for ; Tue, 13 Jul 2004 22:12:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkZGI-0006Jr-Aj for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 22:12:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkYrd-0001Sw-00 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 21:47:18 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkYT9-0004O3-00 for ipcdn-archive@ietf.org; Tue, 13 Jul 2004 21:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkV0D-0004Mg-Al; Tue, 13 Jul 2004 17:39:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkTSt-0001vz-MX; Tue, 13 Jul 2004 16:01:23 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10039; Tue, 13 Jul 2004 16:01:21 -0400 (EDT) Message-Id: <200407132001.QAA10039@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, 13 Jul 2004 16:01:21 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-04.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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --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-04.txt Pages : 53 Date : 2004-7-13 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-04.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-04.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-04.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-7-13145129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-13145129.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 Wed Jul 14 09:30:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16113 for ; Wed, 14 Jul 2004 09:30:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkjq7-0006oO-Mx for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 09:30:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkjoq-00067C-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 09:29:09 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BkjnF-0005KR-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 09:27:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BkjZm-0005Dm-0o for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 09:13:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkjVx-0000pG-77; Wed, 14 Jul 2004 09:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkjRB-00079y-No for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 09:04:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14022 for ; Wed, 14 Jul 2004 09:04:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkjRB-0005EO-0p for ipcdn@ietf.org; Wed, 14 Jul 2004 09:04:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkjQ5-0004sY-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 09:03:34 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx with esmtp (Exim 4.12) id 1BkjPT-0004TA-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 09:02:55 -0400 Message-ID: From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Wed, 14 Jul 2004 08:59:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] FW: ADMIN: outage today 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Apologies if you weren't able to reach www.ipcdn.org on Tuesday. >From my network provider: >Sorry about the outage earlier today. There was a major fibre cut >in Boston today. This outage took out both our primary and backup >internet connectivity. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 10:38:20 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20987 for ; Wed, 14 Jul 2004 10:38:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkktq-0006OH-9v for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 10:38:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkkss-00062N-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 10:37:23 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bkks2-0005P4-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 10:36:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkknW-0002zx-UA; Wed, 14 Jul 2004 10:31:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkkYc-0005IW-NB for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 10:16:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19026 for ; Wed, 14 Jul 2004 10:16:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkkYb-0006KG-EW for ipcdn@ietf.org; Wed, 14 Jul 2004 10:16:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkkXa-0005xv-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 10:15:23 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx with esmtp (Exim 4.12) id 1BkkWh-0005c5-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 10:14:27 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6EEEOTp000356 for ; Wed, 14 Jul 2004 09:14:25 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jul 2004 16:14:24 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504BEAD80@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: wsawyer@ieee.org, sawyerwd@comcast.net, "Ipcdn (E-mail)" Date: Wed, 14 Jul 2004 16:14:22 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: Harrie Hazewinkel Subject: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Wilson (and WG). Sorry that it took long (again) to do another good check of this MIB document. I think this doc is basically OK now. I did find some small things as per below, and it would be good to fix those at some point. I propose that I issue an IETF Last Call, and that the below comments are considered as the initial comments on such an IETF Last Call and that you address them (or answer them) as part of any other comments that may come up from IETF Last Call. Wilson/WG-chair(s), pls let me know if that sounds like a plan or if you ratehr address/answer the below first. What I did find is: >From SMICng (strict checking). I thought I had reported this before ( see I did, but you probably opted to not do it since it is not mandatory). Oh well, I am including it anayway (again), because I really belive it is betetr to include them. E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be IMPORTed E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be IMPORTed E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be IMPORTed E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be IMPORTed E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed According to our MIB review guidelines (draft-ietf-ops-mib-review-guidelines-03.txt) section 4.4, 3rd para: Note that exemptions to this general requirement are granted by RFC 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in the OBJECT clause of a MODULE-COMPLIANCE statement or in the VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB compilers also grant exemptions to descriptors of notifications appearing in a VARIATION clause and to descriptors of object groups and notification groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or an INCLUDES clause, although RFC 2580 (through apparent oversight) does not mention those cases. The exemptions are sometimes seen as unhelpful because they make IMPORTS rules more complicated and inter-module dependencies less obvious than they otherwise would be. External symbols referenced by compliance statements and capabilities statements MAY therefore be listed in the IMPORTS statement; if this is done, it SHOULD be done consistently. So it is not mandatory to do the IMPORTs, but in my view it will help in many places with less warning/errors. So may I suggest to add the IMPORT statement for the above. Also, all documents from whihc you IMPORT (implied or explicit) you must put in normative reference section (which you have done). But all such references MUST have a citation in the text (see MIB review guidelines, (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5): 3.5. References Sections Section 4.7f of [RFC2223bis] specifies the requirements for the references sections. In particular, there MUST be separate lists of normative and informative references, each in a separate section. The style SHOULD follow that of recently published RFCs. The standard MIB boilerplate available at http://www.ops.ietf.org/mib-boilerplate.html includes lists of normative and informative references that MUST appear in all IETF specifications that contain MIB modules. If items from other MIB modules appear in an IMPORTS statement in the Definitions section, then the specifications containing those MIB modules MUST be included in the list of normative references. When items are imported from an IANA-maintained MIB module the corresponding normative reference SHALL point to the on-line version of that MIB module. It is the policy of the RFC Editor that all references must be cited in the text; such citations MUST appear in the overview section where documents containing imported definitions (other those already mentioned in the MIB boilerplate) are required to be mentioned (cf. Section 3.2). You have such a reference for RFC3291 (as required), but no citation to [RFC3291] anywhere in the document. Can you pls add it at some point in the text. I have some other nits/questions: 1. Desription clause of docsSubMgtCpeIpIndex states, towards the end: the table and the packet is forwarded. If the number of entries equals the docsSubMgtCpeControlMaxCpeIp, AND docsSubMgtCpeControlActive is true, then the packet is dropped. Otherwise the packet is forwarded. " In the case that the packet is forwarded, will then also an entry be created? That is not clear to me. May I suggest to add some text to make that 100% clear? 2. In description clause of docsSubMgtCmFilterTable it states: Zero is a distinguished value, indicating that the default filtering action is to be taken, rather than that associated Mmm... a value for the table? I guess you mean that such a zero value "in any of the columns of the table has a special maening. Right? Might want to make that clearer. 3. I see: 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream I think that for naming consistency, it might be better to rename 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream into something like: 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream so as to make it clearer (from the name/descriptor) that these 2 objects exists in the docsSubMgtCmFilterTable. 4. I am a bit worried about the hard limit (range) of 1-255 for FilterGroupIndex. Is this enough forever in the future? Or would it be wiser to use a larger range (and limit via MODULE-COMPLIANCE, as you already do)? I see it was larger before, and that you changed it to this smaller range. So I guess you are doing this consciously. 5. In description clause of docsSubMgtFilterGroupIndex I see: the four. Because this is the only field in this table, it is read-only, contrary to the usual SNMP custom of making indices not-accessible. Probably better to change SNMP into SMI. 6. In the Security Considerations, I think I would change the 2nd para to make a positive statement, namely that you MUST follow recommendations in sect 2.2.6 in order to deploy an effective filtering. Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 11:18:25 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23544 for ; Wed, 14 Jul 2004 11:18:25 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BklWc-0004MV-Vd for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:18:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BklVd-00042E-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:17:27 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BklUr-0003Qy-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:16:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BklMR-0002ra-VW; Wed, 14 Jul 2004 11:07:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkl6T-0007rA-7d for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 10:51:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21862 for ; Wed, 14 Jul 2004 10:51:22 -0400 (EDT) From: sawyerwd@comcast.net Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkl6R-0002um-LE for ipcdn@ietf.org; Wed, 14 Jul 2004 10:51:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkl5m-0002bh-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 10:50:43 -0400 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1Bkl4x-0002Ex-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 10:49:51 -0400 Received: from 204.127.205.144 ([204.127.205.144]) by comcast.net (sccrmhc11) with SMTP id <2004071414491101100t5bobe>; Wed, 14 Jul 2004 14:49:21 +0000 Received: from [63.160.138.53] by 204.127.205.144; Wed, 14 Jul 2004 14:49:09 +0000 To: "Wijnen, Bert (Bert)" , wsawyer@ieee.org, "Ipcdn (E-mail)" Subject: Re: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Wed, 14 Jul 2004 14:49:09 +0000 Message-Id: <071420041449.17493.40F547E500072BD60000445522007348400B999D0A97990E9C@comcast.net> X-Mailer: AT&T Message Center Version 1 (Jun 24 2004) X-Authenticated-Sender: c2F3eWVyd2RAY29tY2FzdC5uZXQ= MIME-Version: 1.0 Cc: Harrie Hazewinkel 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="===============0610135582==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,HTML_MESSAGE, MIME_HTML_NO_CHARSET,NO_REAL_NAME autolearn=no version=2.60 --===============0610135582== Content-Type: multipart/alternative; boundary="NextPart_Webmail_9m3u9jl4l_17493_1089816549_0" --NextPart_Webmail_9m3u9jl4l_17493_1089816549_0 Content-Type: text/plain Content-Transfer-Encoding: 8bit I won't be able to respond to these immediately, so my preference would be to go ahead with the Last Call as Bert proposes. - Wilson -------------- Original message -------------- > Wilson (and WG). Sorry that it took long (again) to do another > good check of this MIB document. > > I think this doc is basically OK now. I did find some small things > as per below, and it would be good to fix those at some point. > I propose that I issue an IETF Last Call, and that the below comments > are considered as the initial comments on such an IETF Last Call > and that you address them (or answer them) as part of any other comments > that may come up from IETF Last Call. > > Wilson/WG-chair(s), pls let me know if that sounds like a plan or if > you ratehr address/answer the below first. > > What I did find is: > > >From SMICng (strict checking). I thought I had reported this before ( see I > did, but you probably opted to not do it since it is not mandatory). > Oh well, I am including it anayway (again), because I really belive it > is betetr to include them. > > E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be > IMPORTed > E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be > IMPORTed > E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be > IMPORTed > E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed > E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be > IMPORTed > E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be > IMPORTed > E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be > IMPORTed > E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be > IMPORTed > E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed > E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be > IMPORTed > E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be > IMPORTed > E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed > > According to our MIB review guidelines > (draft-ietf-ops-mib-review-guidelines-03.txt) > section 4.4, 3rd para: > Note that exemptions to this general requirement are granted by RFC > 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in > the OBJECT clause of a MODULE-COMPLIANCE statement or in the > VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB > compilers also grant exemptions to descriptors of notifications > appearing in a VARIATION clause and to descriptors of object groups > and notification groups referenced by a MANDATORY-GROUPS clause, a > GROUP clause, or an INCLUDES clause, although RFC 2580 (through > apparent oversight) does not mention those cases. The exemptions are > sometimes seen as unhelpful because they make IMPORTS rules more > complicated and inter-module dependencies less obvious than they > otherwise would be. External symbols referenced by compliance > statements and capabilities statements MAY therefore be listed in the > IMPORTS statement; if this is done, it SHOULD be done consistently. > > So it is not mandatory to do the IMPORTs, but in my view it will help in > many places with less warning/errors. So may I suggest to add the IMPORT > statement for the above. > > Also, all documents from whihc you IMPORT (implied or explicit) you must > put in normative reference section (which you have done). But all such > references MUST have a citation in the text (see MIB review guidelines, > (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5): > 3.5. References Sections > > Section 4.7f of [RFC2223bis] specifies the requirements for the > references sections. In particular, there MUST be separate lists of > normative and informative references, each in a separate section. > The style SHOULD follow that of recently published RFCs. > > The standard MIB boilerplate available at > http://www.ops.ietf.org/mib-boilerplate.html includes lists of > normative and informative references that MUST appear in all IETF > specifications that contain MIB modules. If items from other MIB > modules appear in an IMPORTS statement in the Definitions section, > then the specifications containing those MIB modules MUST be included > in the list of normative references. When items are imported from an > IANA-maintained MIB module the corresponding normative reference > SHALL point to the on-line version of that MIB module. It is the > policy of the RFC Editor that all references must be cited in the > text; such citations MUST appear in the overview section where > documents containing imported definitions (other those already > mentioned in the MIB boilerplate) are required to be mentioned (cf. > Section 3.2). > > You have such a reference for RFC3291 (as required), but no citation > to [RFC3291] anywhere in the document. Can you pls add it at > some point in the text. > > > I have some other nits/questions: > > 1. Desription clause of docsSubMgtCpeIpIndex states, towards the end: > > the table and the packet is forwarded. If the number of entries > equals the docsSubMgtCpeControlMaxCpeIp, AND > docsSubMgtCpeControlActive is true, then the packet is dropped. > Otherwise the packet is forwarded. " > > In the case that the packet is forwarded, will then also an entry be > created? That is not clear to me. May I suggest to add some text to > make that 100% clear? > > 2. In description clause of docsSubMgtCmFilterTable it states: > > Zero is a distinguished value, indicating that the default > filtering action is to be taken, rather than that associated > > Mmm... a value for the table? I guess you mean that such a zero > value "in any of the columns of the table has a special maening. > Right? Might want to make that clearer. > > 3. I see: > 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable > 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream > I think that for naming consistency, it might be better to rename > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > into something like: > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream > so as to make it clearer (from the name/descriptor) that these 2 > objects exists in the docsSubMgtCmFilterTable. > > 4. I am a bit worried about the hard limit (range) of 1-255 for > FilterGroupIndex. > Is this enough forever in the future? Or would it be wiser to use a larger > range (and limit via MODULE-COMPLIANCE, as you already do)? > I see it was larger before, and that you changed it to this smaller range. > So I guess you are doing this consciously. > > 5. In description clause of docsSubMgtFilterGroupIndex I see: > > the four. Because this is the only field in this table, it is > read-only, contrary to the usual SNMP custom of making indices > not-accessible. > > Probably better to change SNMP into SMI. > > 6. In the Security Considerations, I think I would change the 2nd para > to make a positive statement, namely that you MUST follow recommendations > in sect 2.2.6 in order to deploy an effective filtering. > > Thanks, > Bert > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn --NextPart_Webmail_9m3u9jl4l_17493_1089816549_0 Content-Type: text/html Content-Transfer-Encoding: 8bit

I won't be able to respond to these immediately, so my preference would be to go ahead with the Last Call as Bert proposes.

- Wilson

-------------- Original message --------------

> Wilson (and WG). Sorry that it took long (again) to do another
> good check of this MIB document.
>
> I think this doc is basically OK now. I did find some small things
> as per below, and it would be good to fix those at some point.
> I propose that I issue an IETF Last Call, and that the below comments
> are considered as the initial comments on such an IETF Last Call
> and that you address them (or answer them) as part of any other comments
> that may come up from IETF Last Call.
>
> Wilson/WG-chair(s), pls let me know if that sounds like a plan or if
> you ratehr address/answer the below first.
>
> What I did find is:
>
> >From SMICng (strict checking). I thought I had reported this before ( see I
> did, but you ! probably opted to not do it since it is not mandatory).
> Oh well, I am including it anayway (again), because I really belive it
> is betetr to include them.
>
> E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed
> E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed
> E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed
> E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed
> E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed
> E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" shoul! d be IMPORTed
> E: f(ipcdnsub.mi2), (499,11) Item "diffServClfr ElementStatus" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed
> E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed
> E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed
> E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be
> IMPORTed
> E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed
> E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed > E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed
> E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed
>
> According to our MIB review guidelines
> (draft-ietf-ops-mib-review-guidelines-03.txt)
> section 4.4, 3rd para:
> Note that exemptions to this general requirement are granted by RFC
> 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in
> the OBJECT clause of a MODULE-COMPLIANCE statement or in the
> VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB
> compilers also grant exemptions to descriptors of notifications
> appearing in a VARIATION clause and to descriptors of object groups
> and notification groups referenced by a MANDATORY-GROUPS clause, a
> GROUP clause, or an INCLUDES clause, although RFC 2580 (through
> apparent oversight) does not mention those cases. The exemptions are !
> sometimes seen as unhelpful because they make IMPORTS rules m ore
> complicated and inter-module dependencies less obvious than they
> otherwise would be. External symbols referenced by compliance
> statements and capabilities statements MAY therefore be listed in the
> IMPORTS statement; if this is done, it SHOULD be done consistently.
>
> So it is not mandatory to do the IMPORTs, but in my view it will help in
> many places with less warning/errors. So may I suggest to add the IMPORT
> statement for the above.
>
> Also, all documents from whihc you IMPORT (implied or explicit) you must
> put in normative reference section (which you have done). But all such
> references MUST have a citation in the text (see MIB review guidelines,
> (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5):
> 3.5. References Sections
>
> Section 4.7f of [RFC2223bis] specifies the requirements for the
> references sections. In particular! , there MUST be separate lists of
> normative and informative references, each in a separate section.
> The style SHOULD follow that of recently published RFCs.
>
> The standard MIB boilerplate available at
> http://www.ops.ietf.org/mib-boilerplate.html includes lists of
> normative and informative references that MUST appear in all IETF
> specifications that contain MIB modules. If items from other MIB
> modules appear in an IMPORTS statement in the Definitions section,
> then the specifications containing those MIB modules MUST be included
> in the list of normative references. When items are imported from an
> IANA-maintained MIB module the corresponding normative reference
> SHALL point to the on-line version of that MIB module. It is the
> policy of the RFC Editor that all references must be cited in the
> text; such citations MUST appear in the overview section where
! > documents containing imported definitions (other those already > mentioned in the MIB boilerplate) are required to be mentioned (cf.
> Section 3.2).
>
> You have such a reference for RFC3291 (as required), but no citation
> to [RFC3291] anywhere in the document. Can you pls add it at
> some point in the text.
>
>
> I have some other nits/questions:
>
> 1. Desription clause of docsSubMgtCpeIpIndex states, towards the end:
>
> the table and the packet is forwarded. If the number of entries
> equals the docsSubMgtCpeControlMaxCpeIp, AND
> docsSubMgtCpeControlActive is true, then the packet is dropped.
> Otherwise the packet is forwarded. "
>
> In the case that the packet is forwarded, will then also an entry be
> created? That is not clear to me. May I suggest to add some text to
> make that 100% clear?
>
> 2. In description clause of docsSubMgtCmFilterTable it states:
>
> Zer! o is a distinguished value, indicating that the default
> filtering action is to be taken, rather than that associated
>
> Mmm... a value for the table? I guess you mean that such a zero
> value "in any of the columns of the table has a special maening.
> Right? Might want to make that clearer.
>
> 3. I see:
> 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable
> 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry
> 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream
> 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream
> 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream
> 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream
> I think that for naming consistency, it might be better to rename
> 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream
> 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream
> into something like:
> 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterD! ownstream
> 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstrea m
> so as to make it clearer (from the name/descriptor) that these 2
> objects exists in the docsSubMgtCmFilterTable.
>
> 4. I am a bit worried about the hard limit (range) of 1-255 for
> FilterGroupIndex.
> Is this enough forever in the future? Or would it be wiser to use a larger
> range (and limit via MODULE-COMPLIANCE, as you already do)?
> I see it was larger before, and that you changed it to this smaller range.
> So I guess you are doing this consciously.
>
> 5. In description clause of docsSubMgtFilterGroupIndex I see:
>
> the four. Because this is the only field in this table, it is
> read-only, contrary to the usual SNMP custom of making indices
> not-accessible.
>
> Probably better to change SNMP into SMI.
>
> 6. In the Security Considerations, I think I would change the 2nd para
> to make a positive statement, namely that you! MUST follow recommendations
> in sect 2.2.6 in order to deploy an effective filtering.
>
> Thanks,
> Bert
>
> _______________________________________________
> IPCDN mailing list
> IPCDN@ietf.org
> https://www1.ietf.org/mailman/listinfo/ipcdn
--NextPart_Webmail_9m3u9jl4l_17493_1089816549_0-- --===============0610135582== 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 --===============0610135582==-- From ipcdn-bounces@ietf.org Wed Jul 14 11:24:19 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23853 for ; Wed, 14 Jul 2004 11:24:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BklcL-0006Mm-3e for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:24:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BklbN-00060V-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:23:22 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BklaW-0005Nl-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:22:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BklNw-00033n-K6; Wed, 14 Jul 2004 11:09:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BklGH-0001jQ-AT for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 11:01:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22299 for ; Wed, 14 Jul 2004 11:01:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BklGG-00066a-Cz for ipcdn@ietf.org; Wed, 14 Jul 2004 11:01:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BklFN-0005kz-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 11:00:37 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BklEc-0005OD-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 10:59:50 -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 i6EEuPbw021476; Wed, 14 Jul 2004 08:56:25 -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] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Wed, 14 Jul 2004 08:56:25 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F06A1DE@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Thread-Index: AcRpsCE8D5TV2wxdTsS68hIEA8aX5wAAkHsC From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , , , "Ipcdn (E-mail)" X-Approved: ondar Cc: Harrie Hazewinkel 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="===============0892228619==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. --===============0892228619== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469B2.BBF761B3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C469B2.BBF761B3 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVydCwgDQpGb3IgdGhlIGJlbmVmb3Qgb2Ygb3RoZXIgYXV0aG9ycy9lZGl0b3JzIGluIHRoZSBz YW1lIHBhdGggb2YgQUQgZXZhbHVhdGlvbiwgDQpJIHNlZSB5b3VyIGNvbW1lbnQgMyBhIGxpdHRs ZSBkZXZpYXRpb24gb2YgT1BTIGd1aWRlbGluZXMgQXBwZW5kaXggQzoNCi0gVGhlIGRlc2NyaXB0 b3IgYXNzb2NpYXRlZCB3aXRoIGEgY29uY2VwdHVhbCB0YWJsZSBzaG91bGQgYmUgb2YgdGhlDQog ICAgIGZvcm0geHh4Wnp6VGFibGU7ICB0aGUgZGVzY3JpcHRvciBhc3NvY2lhdGVkIHdpdGggdGhl IGNvcnJlc3BvbmRpbmcNCiAgICAgY29uY2VwdHVhbCByb3cgc2hvdWxkIGJlIG9mIHRoZSBmb3Jt IHh4eFp6ekVudHJ5OyAgdGhlIG5hbWUgb2YgdGhlDQogICAgIGFzc29jaWF0ZWQgU0VRVUVOQ0Ug dHlwZSBzaG91bGQgYmUgb2YgdGhlIGZvcm0gWHh4Wnp6RW50cnk7ICBhbmQNCiAgICAgdGhlIGRl c2NyaXB0b3JzIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3Vib3JkaW5hdGUgY29sdW1uYXIgb2JqZWN0 cw0KICAgICBzaG91bGQgYmUgb2YgdGhlIGZvcm0geHh4Wnp6U29tZW90aGVyTmFtZS4NCiANCkkg cHJlc3VtZSBpdCBpcyBhIHR5cG8gYW5kIHlvdSB3b3VsZCBsaWtlIHNlZSBleHRyaWN0IGNvbXBs aWFuY2UgdG8gdGhvc2UgcmVjb21tZW5kYXRpb25zDQpBbnkgY29tbWVudHM/DQogDQogDQpUaGFu a3MgDQogDQpFZHVhcmRvDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBX aWpuZW4sIEJlcnQgKEJlcnQpIFttYWlsdG86Yndpam5lbkBsdWNlbnQuY29tXSANCglTZW50OiBX ZWQgNy8xNC8yMDA0IDg6MTQgQU0gDQoJVG86IHdzYXd5ZXJAaWVlZS5vcmc7IHNhd3llcndkQGNv bWNhc3QubmV0OyBJcGNkbiAoRS1tYWlsKSANCglDYzogSGFycmllIEhhemV3aW5rZWwgDQoJU3Vi amVjdDogW2lwY2RuXSBBRCByZXZpZXcgb2Y6IGRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1t aWItMTQudHh0DQoJDQoJDQoNCglXaWxzb24gKGFuZCBXRykuIFNvcnJ5IHRoYXQgaXQgdG9vayBs b25nIChhZ2FpbikgdG8gZG8gYW5vdGhlcg0KCWdvb2QgY2hlY2sgb2YgdGhpcyBNSUIgZG9jdW1l bnQuDQoJDQoJSSB0aGluayB0aGlzIGRvYyBpcyBiYXNpY2FsbHkgT0sgbm93LiBJIGRpZCBmaW5k IHNvbWUgc21hbGwgdGhpbmdzDQoJYXMgcGVyIGJlbG93LCBhbmQgaXQgd291bGQgYmUgZ29vZCB0 byBmaXggdGhvc2UgYXQgc29tZSBwb2ludC4NCglJIHByb3Bvc2UgdGhhdCBJIGlzc3VlIGFuIElF VEYgTGFzdCBDYWxsLCBhbmQgdGhhdCB0aGUgYmVsb3cgY29tbWVudHMNCglhcmUgY29uc2lkZXJl ZCBhcyB0aGUgaW5pdGlhbCBjb21tZW50cyBvbiBzdWNoIGFuIElFVEYgTGFzdCBDYWxsDQoJYW5k IHRoYXQgeW91IGFkZHJlc3MgdGhlbSAob3IgYW5zd2VyIHRoZW0pIGFzIHBhcnQgb2YgYW55IG90 aGVyIGNvbW1lbnRzDQoJdGhhdCBtYXkgY29tZSB1cCBmcm9tIElFVEYgTGFzdCBDYWxsLg0KCQ0K CVdpbHNvbi9XRy1jaGFpcihzKSwgcGxzIGxldCBtZSBrbm93IGlmIHRoYXQgc291bmRzIGxpa2Ug YSBwbGFuIG9yIGlmDQoJeW91IHJhdGVociBhZGRyZXNzL2Fuc3dlciB0aGUgYmVsb3cgZmlyc3Qu DQoJDQoJV2hhdCBJIGRpZCBmaW5kIGlzOg0KCQ0KCT5Gcm9tIFNNSUNuZyAoc3RyaWN0IGNoZWNr aW5nKS4gSSB0aG91Z2h0IEkgaGFkIHJlcG9ydGVkIHRoaXMgYmVmb3JlICggc2VlIEkNCglkaWQs IGJ1dCB5b3UgcHJvYmFibHkgb3B0ZWQgdG8gbm90IGRvIGl0IHNpbmNlIGl0IGlzIG5vdCBtYW5k YXRvcnkpLg0KCU9oIHdlbGwsIEkgYW0gaW5jbHVkaW5nIGl0IGFuYXl3YXkgKGFnYWluKSwgYmVj YXVzZSBJIHJlYWxseSBiZWxpdmUgaXQNCglpcyBiZXRldHIgdG8gaW5jbHVkZSB0aGVtLg0KCQ0K CSAgRTogZihpcGNkbnN1Yi5taTIpLCAoNDc4LDE1KSBJdGVtICJkaWZmU2Vydk1JQkRhdGFQYXRo R3JvdXAiIHNob3VsZCBiZSBJTVBPUlRlZA0KCSAgRTogZihpcGNkbnN1Yi5taTIpLCAoNDc5LDE1 KSBJdGVtICJkaWZmU2Vydk1JQkNsZnJHcm91cCIgc2hvdWxkIGJlIElNUE9SVGVkDQoJICBFOiBm KGlwY2Ruc3ViLm1pMiksICg0ODAsMTUpIEl0ZW0gImRpZmZTZXJ2TUlCQ2xmckVsZW1lbnRHcm91 cCIgc2hvdWxkIGJlIElNUE9SVGVkDQoJICBFOiBmKGlwY2Ruc3ViLm1pMiksICg0ODEsMTUpIEl0 ZW0gImRpZmZTZXJ2TUlCTXVsdGlGaWVsZENsZnJHcm91cCIgc2hvdWxkIGJlIElNUE9SVGVkDQoJ ICBFOiBmKGlwY2Ruc3ViLm1pMiksICg0ODIsMTUpIEl0ZW0gImRpZmZTZXJ2TUlCQWN0aW9uR3Jv dXAiIHNob3VsZCBiZSBJTVBPUlRlZA0KCSAgRTogZihpcGNkbnN1Yi5taTIpLCAoNDgzLDE1KSBJ dGVtICJkaWZmU2Vydk1JQkFsZ0Ryb3BHcm91cCIgc2hvdWxkIGJlIElNUE9SVGVkDQoJICBFOiBm KGlwY2Ruc3ViLm1pMiksICg0ODQsMTUpIEl0ZW0gImRpZmZTZXJ2TUlCQ291bnRlckdyb3VwIiBz aG91bGQgYmUgSU1QT1JUZWQNCgkgIEU6IGYoaXBjZG5zdWIubWkyKSwgKDQ4NywxMSkgSXRlbSAi ZGlmZlNlcnZEYXRhUGF0aFN0YXR1cyIgc2hvdWxkIGJlIElNUE9SVGVkDQoJICBFOiBmKGlwY2Ru c3ViLm1pMiksICg0OTMsMTEpIEl0ZW0gImRpZmZTZXJ2Q2xmclN0YXR1cyIgc2hvdWxkIGJlIElN UE9SVGVkDQoJICBFOiBmKGlwY2Ruc3ViLm1pMiksICg0OTksMTEpIEl0ZW0gImRpZmZTZXJ2Q2xm ckVsZW1lbnRTdGF0dXMiIHNob3VsZCBiZSBJTVBPUlRlZA0KCSAgRTogZihpcGNkbnN1Yi5taTIp LCAoNTA2LDExKSBJdGVtICJkaWZmU2Vydk11bHRpRmllbGRDbGZyQWRkclR5cGUiIHNob3VsZCBi ZSBJTVBPUlRlZA0KCSAgRTogZihpcGNkbnN1Yi5taTIpLCAoNTEyLDExKSBJdGVtICJkaWZmU2Vy dk11bHRpRmllbGRDbGZyU3JjQWRkciIgc2hvdWxkIGJlIElNUE9SVGVkDQoJICBFOiBmKGlwY2Ru c3ViLm1pMiksICg1MTgsMTEpIEl0ZW0gImRpZmZTZXJ2TXVsdGlGaWVsZENsZnJEc3RBZGRyIiBz aG91bGQgYmUgSU1QT1JUZWQNCgkgIEU6IGYoaXBjZG5zdWIubWkyKSwgKDUyNCwxMSkgSXRlbSAi ZGlmZlNlcnZBbGdEcm9wU3RhdHVzIiBzaG91bGQgYmUgSU1QT1JUZWQNCgkgIEU6IGYoaXBjZG5z dWIubWkyKSwgKDUzMCwxMSkgSXRlbSAiZGlmZlNlcnZEYXRhUGF0aFN0b3JhZ2UiIHNob3VsZCBi ZSBJTVBPUlRlZA0KCSAgRTogZihpcGNkbnN1Yi5taTIpLCAoNTM2LDExKSBJdGVtICJkaWZmU2Vy dkNsZnJTdG9yYWdlIiBzaG91bGQgYmUgSU1QT1JUZWQNCgkgIEU6IGYoaXBjZG5zdWIubWkyKSwg KDU0MiwxMSkgSXRlbSAiZGlmZlNlcnZDbGZyRWxlbWVudFN0b3JhZ2UiIHNob3VsZCBiZSBJTVBP UlRlZA0KCSAgRTogZihpcGNkbnN1Yi5taTIpLCAoNTQ4LDExKSBJdGVtICJkaWZmU2Vydk11bHRp RmllbGRDbGZyU3RvcmFnZSIgc2hvdWxkIGJlIElNUE9SVGVkDQoJICBFOiBmKGlwY2Ruc3ViLm1p MiksICg1NTQsMTEpIEl0ZW0gImRpZmZTZXJ2QWN0aW9uU3RvcmFnZSIgc2hvdWxkIGJlIElNUE9S VGVkDQoJICBFOiBmKGlwY2Ruc3ViLm1pMiksICg1NjAsMTEpIEl0ZW0gImRpZmZTZXJ2Q291bnRB Y3RTdG9yYWdlIiBzaG91bGQgYmUgSU1QT1JUZWQNCgkgIEU6IGYoaXBjZG5zdWIubWkyKSwgKDU2 NiwxMSkgSXRlbSAiZGlmZlNlcnZBbGdEcm9wU3RvcmFnZSIgc2hvdWxkIGJlIElNUE9SVGVkDQoJ ICBFOiBmKGlwY2Ruc3ViLm1pMiksICg1NzIsMTEpIEl0ZW0gImRpZmZTZXJ2QWxnRHJvcFR5cGUi IHNob3VsZCBiZSBJTVBPUlRlZA0KCQ0KCUFjY29yZGluZyB0byBvdXIgTUlCIHJldmlldyBndWlk ZWxpbmVzIChkcmFmdC1pZXRmLW9wcy1taWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0KQ0KCXNl Y3Rpb24gNC40LCAzcmQgcGFyYToNCgkgICBOb3RlIHRoYXQgZXhlbXB0aW9ucyB0byB0aGlzIGdl bmVyYWwgcmVxdWlyZW1lbnQgYXJlIGdyYW50ZWQgYnkgUkZDDQoJICAgMjU4MCBTZWN0aW9ucyA1 LjQuMyBhbmQgNi41LjIgZm9yIGRlc2NyaXB0b3JzIG9mIG9iamVjdHMgYXBwZWFyaW5nIGluDQoJ ICAgdGhlIE9CSkVDVCBjbGF1c2Ugb2YgYSBNT0RVTEUtQ09NUExJQU5DRSBzdGF0ZW1lbnQgb3Ig aW4gdGhlDQoJICAgVkFSSUFUSU9OIGNsYXVzZSBvZiBhbiBBR0VOVC1DQVBBQklMSVRJRVMgc3Rh dGVtZW50LiAgU29tZSBNSUINCgkgICBjb21waWxlcnMgYWxzbyBncmFudCBleGVtcHRpb25zIHRv IGRlc2NyaXB0b3JzIG9mIG5vdGlmaWNhdGlvbnMNCgkgICBhcHBlYXJpbmcgaW4gYSBWQVJJQVRJ T04gY2xhdXNlIGFuZCB0byBkZXNjcmlwdG9ycyBvZiBvYmplY3QgZ3JvdXBzDQoJICAgYW5kIG5v dGlmaWNhdGlvbiBncm91cHMgcmVmZXJlbmNlZCBieSBhIE1BTkRBVE9SWS1HUk9VUFMgY2xhdXNl LCBhDQoJICAgR1JPVVAgY2xhdXNlLCBvciBhbiBJTkNMVURFUyBjbGF1c2UsIGFsdGhvdWdoIFJG QyAyNTgwICh0aHJvdWdoDQoJICAgYXBwYXJlbnQgb3ZlcnNpZ2h0KSBkb2VzIG5vdCBtZW50aW9u IHRob3NlIGNhc2VzLiAgVGhlIGV4ZW1wdGlvbnMgYXJlDQoJICAgc29tZXRpbWVzIHNlZW4gYXMg dW5oZWxwZnVsIGJlY2F1c2UgdGhleSBtYWtlIElNUE9SVFMgcnVsZXMgbW9yZQ0KCSAgIGNvbXBs aWNhdGVkIGFuZCBpbnRlci1tb2R1bGUgZGVwZW5kZW5jaWVzIGxlc3Mgb2J2aW91cyB0aGFuIHRo ZXkNCgkgICBvdGhlcndpc2Ugd291bGQgYmUuICBFeHRlcm5hbCBzeW1ib2xzIHJlZmVyZW5jZWQg YnkgY29tcGxpYW5jZQ0KCSAgIHN0YXRlbWVudHMgYW5kIGNhcGFiaWxpdGllcyBzdGF0ZW1lbnRz IE1BWSB0aGVyZWZvcmUgYmUgbGlzdGVkIGluIHRoZQ0KCSAgIElNUE9SVFMgc3RhdGVtZW50OyAg aWYgdGhpcyBpcyBkb25lLCBpdCBTSE9VTEQgYmUgZG9uZSBjb25zaXN0ZW50bHkuDQoJDQoJU28g aXQgaXMgbm90IG1hbmRhdG9yeSB0byBkbyB0aGUgSU1QT1JUcywgYnV0IGluIG15IHZpZXcgaXQg d2lsbCBoZWxwIGluDQoJbWFueSBwbGFjZXMgd2l0aCBsZXNzIHdhcm5pbmcvZXJyb3JzLiBTbyBt YXkgSSBzdWdnZXN0IHRvIGFkZCB0aGUgSU1QT1JUDQoJc3RhdGVtZW50IGZvciB0aGUgYWJvdmUu DQoJDQoJQWxzbywgYWxsIGRvY3VtZW50cyBmcm9tIHdoaWhjIHlvdSBJTVBPUlQgKGltcGxpZWQg b3IgZXhwbGljaXQpIHlvdSBtdXN0DQoJcHV0IGluIG5vcm1hdGl2ZSByZWZlcmVuY2Ugc2VjdGlv biAod2hpY2ggeW91IGhhdmUgZG9uZSkuIEJ1dCBhbGwgc3VjaA0KCXJlZmVyZW5jZXMgTVVTVCBo YXZlIGEgY2l0YXRpb24gaW4gdGhlIHRleHQgKHNlZSBNSUIgcmV2aWV3IGd1aWRlbGluZXMsDQoJ KGRyYWZ0LWlldGYtb3BzLW1pYi1yZXZpZXctZ3VpZGVsaW5lcy0wMy50eHQsIHNlY3QgMy41KToN CgkgICAzLjUuICBSZWZlcmVuY2VzIFNlY3Rpb25zDQoJDQoJICAgU2VjdGlvbiA0LjdmIG9mIFtS RkMyMjIzYmlzXSBzcGVjaWZpZXMgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlDQoJICAgcmVmZXJl bmNlcyBzZWN0aW9ucy4gIEluIHBhcnRpY3VsYXIsIHRoZXJlIE1VU1QgYmUgc2VwYXJhdGUgbGlz dHMgb2YNCgkgICBub3JtYXRpdmUgYW5kIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMsIGVhY2ggaW4g YSBzZXBhcmF0ZSBzZWN0aW9uLg0KCSAgIFRoZSBzdHlsZSBTSE9VTEQgZm9sbG93IHRoYXQgb2Yg cmVjZW50bHkgcHVibGlzaGVkIFJGQ3MuDQoJDQoJICAgVGhlIHN0YW5kYXJkIE1JQiBib2lsZXJw bGF0ZSBhdmFpbGFibGUgYXQNCgkgICBodHRwOi8vd3d3Lm9wcy5pZXRmLm9yZy9taWItYm9pbGVy cGxhdGUuaHRtbCBpbmNsdWRlcyBsaXN0cyBvZg0KCSAgIG5vcm1hdGl2ZSBhbmQgaW5mb3JtYXRp dmUgcmVmZXJlbmNlcyB0aGF0IE1VU1QgYXBwZWFyIGluIGFsbCBJRVRGDQoJICAgc3BlY2lmaWNh dGlvbnMgdGhhdCBjb250YWluIE1JQiBtb2R1bGVzLiAgSWYgaXRlbXMgZnJvbSBvdGhlciBNSUIN CgkgICBtb2R1bGVzIGFwcGVhciBpbiBhbiBJTVBPUlRTIHN0YXRlbWVudCBpbiB0aGUgRGVmaW5p dGlvbnMgc2VjdGlvbiwNCgkgICB0aGVuIHRoZSBzcGVjaWZpY2F0aW9ucyBjb250YWluaW5nIHRo b3NlIE1JQiBtb2R1bGVzIE1VU1QgYmUgaW5jbHVkZWQNCgkgICBpbiB0aGUgbGlzdCBvZiBub3Jt YXRpdmUgcmVmZXJlbmNlcy4gIFdoZW4gaXRlbXMgYXJlIGltcG9ydGVkIGZyb20gYW4NCgkgICBJ QU5BLW1haW50YWluZWQgTUlCIG1vZHVsZSB0aGUgY29ycmVzcG9uZGluZyBub3JtYXRpdmUgcmVm ZXJlbmNlDQoJICAgU0hBTEwgcG9pbnQgdG8gdGhlIG9uLWxpbmUgdmVyc2lvbiBvZiB0aGF0IE1J QiBtb2R1bGUuICBJdCBpcyB0aGUNCgkgICBwb2xpY3kgb2YgdGhlIFJGQyBFZGl0b3IgdGhhdCBh bGwgcmVmZXJlbmNlcyBtdXN0IGJlIGNpdGVkIGluIHRoZQ0KCSAgIHRleHQ7ICBzdWNoIGNpdGF0 aW9ucyBNVVNUIGFwcGVhciBpbiB0aGUgb3ZlcnZpZXcgc2VjdGlvbiB3aGVyZQ0KCSAgIGRvY3Vt ZW50cyBjb250YWluaW5nIGltcG9ydGVkIGRlZmluaXRpb25zIChvdGhlciB0aG9zZSBhbHJlYWR5 DQoJICAgbWVudGlvbmVkIGluIHRoZSBNSUIgYm9pbGVycGxhdGUpIGFyZSByZXF1aXJlZCB0byBi ZSBtZW50aW9uZWQgKGNmLg0KCSAgIFNlY3Rpb24gMy4yKS4NCgkNCglZb3UgaGF2ZSBzdWNoIGEg cmVmZXJlbmNlIGZvciBSRkMzMjkxIChhcyByZXF1aXJlZCksIGJ1dCBubyBjaXRhdGlvbg0KCXRv IFtSRkMzMjkxXSBhbnl3aGVyZSBpbiB0aGUgZG9jdW1lbnQuIENhbiB5b3UgcGxzIGFkZCBpdCBh dA0KCXNvbWUgcG9pbnQgaW4gdGhlIHRleHQuDQoJDQoJDQoJSSBoYXZlIHNvbWUgb3RoZXIgbml0 cy9xdWVzdGlvbnM6DQoJDQoJMS4gRGVzcmlwdGlvbiBjbGF1c2Ugb2YgZG9jc1N1Yk1ndENwZUlw SW5kZXggc3RhdGVzLCB0b3dhcmRzIHRoZSBlbmQ6DQoJDQoJICAgICAgIHRoZSB0YWJsZSBhbmQg dGhlIHBhY2tldCBpcyBmb3J3YXJkZWQuICBJZiB0aGUgbnVtYmVyIG9mIGVudHJpZXMNCgkgICAg ICAgZXF1YWxzIHRoZSBkb2NzU3ViTWd0Q3BlQ29udHJvbE1heENwZUlwLCBBTkQNCgkgICAgICAg ZG9jc1N1Yk1ndENwZUNvbnRyb2xBY3RpdmUgaXMgdHJ1ZSwgdGhlbiB0aGUgcGFja2V0IGlzIGRy b3BwZWQuDQoJICAgICAgIE90aGVyd2lzZSB0aGUgcGFja2V0IGlzIGZvcndhcmRlZC4gIg0KCQ0K CSAgIEluIHRoZSBjYXNlIHRoYXQgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQsIHdpbGwgdGhlbiBh bHNvIGFuIGVudHJ5IGJlDQoJICAgY3JlYXRlZD8gVGhhdCBpcyBub3QgY2xlYXIgdG8gbWUuIE1h eSBJIHN1Z2dlc3QgdG8gYWRkIHNvbWUgdGV4dCB0bw0KCSAgIG1ha2UgdGhhdCAxMDAlIGNsZWFy Pw0KCQ0KCTIuIEluIGRlc2NyaXB0aW9uIGNsYXVzZSBvZiBkb2NzU3ViTWd0Q21GaWx0ZXJUYWJs ZSBpdCBzdGF0ZXM6DQoJDQoJICAgICAgIFplcm8gaXMgYSBkaXN0aW5ndWlzaGVkIHZhbHVlLCBp bmRpY2F0aW5nIHRoYXQgdGhlIGRlZmF1bHQNCgkgICAgICAgZmlsdGVyaW5nIGFjdGlvbiBpcyB0 byBiZSB0YWtlbiwgcmF0aGVyIHRoYW4gdGhhdCBhc3NvY2lhdGVkDQoJDQoJICAgTW1tLi4uIGEg dmFsdWUgZm9yIHRoZSB0YWJsZT8gSSBndWVzcyB5b3UgbWVhbiB0aGF0IHN1Y2ggYSB6ZXJvDQoJ ICAgdmFsdWUgImluIGFueSBvZiB0aGUgY29sdW1ucyBvZiB0aGUgdGFibGUgaGFzIGEgc3BlY2lh bCBtYWVuaW5nLg0KCSAgIFJpZ2h0PyBNaWdodCB3YW50IHRvIG1ha2UgdGhhdCBjbGVhcmVyLg0K CQ0KCTMuIEkgc2VlOg0KCSAgICAgMS4zLjYuMS4yLjEueHguMS42ICAgICAgZG9jc1N1Yk1ndENt RmlsdGVyVGFibGUNCgkgICAgIDEuMy42LjEuMi4xLnh4LjEuNi4xICAgIGRvY3NTdWJNZ3RDbUZp bHRlckVudHJ5DQoJICAgICAxLjMuNi4xLjIuMS54eC4xLjYuMS4xICBkb2NzU3ViTWd0U3ViRmls dGVyRG93bnN0cmVhbQ0KCSAgICAgMS4zLjYuMS4yLjEueHguMS42LjEuMiAgZG9jc1N1Yk1ndFN1 YkZpbHRlclVwc3RyZWFtDQoJICAgICAxLjMuNi4xLjIuMS54eC4xLjYuMS4zICBkb2NzU3ViTWd0 Q21GaWx0ZXJEb3duc3RyZWFtDQoJICAgICAxLjMuNi4xLjIuMS54eC4xLjYuMS40ICBkb2NzU3Vi TWd0Q21GaWx0ZXJVcHN0cmVhbQ0KCSAgIEkgdGhpbmsgdGhhdCBmb3IgbmFtaW5nIGNvbnNpc3Rl bmN5LCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gcmVuYW1lDQoJICAgICAxLjMuNi4xLjIuMS54eC4x LjYuMS4xICBkb2NzU3ViTWd0U3ViRmlsdGVyRG93bnN0cmVhbQ0KCSAgICAgMS4zLjYuMS4yLjEu eHguMS42LjEuMiAgZG9jc1N1Yk1ndFN1YkZpbHRlclVwc3RyZWFtDQoJICAgaW50byBzb21ldGhp bmcgbGlrZToNCgkgICAgIDEuMy42LjEuMi4xLnh4LjEuNi4xLjEgIGRvY3NTdWJNZ3RDbVN1YkZp bHRlckRvd25zdHJlYW0NCgkgICAgIDEuMy42LjEuMi4xLnh4LjEuNi4xLjIgIGRvY3NTdWJNZ3RD TW11YkZpbHRlclVwc3RyZWFtDQoJICAgc28gYXMgdG8gbWFrZSBpdCBjbGVhcmVyIChmcm9tIHRo ZSBuYW1lL2Rlc2NyaXB0b3IpIHRoYXQgdGhlc2UgMg0KCSAgIG9iamVjdHMgZXhpc3RzIGluIHRo ZSBkb2NzU3ViTWd0Q21GaWx0ZXJUYWJsZS4NCgkNCgk0LiBJIGFtIGEgYml0IHdvcnJpZWQgYWJv dXQgdGhlIGhhcmQgbGltaXQgKHJhbmdlKSBvZiAxLTI1NSBmb3IgRmlsdGVyR3JvdXBJbmRleC4N CgkgICBJcyB0aGlzIGVub3VnaCBmb3JldmVyIGluIHRoZSBmdXR1cmU/IE9yIHdvdWxkIGl0IGJl IHdpc2VyIHRvIHVzZSBhIGxhcmdlcg0KCSAgIHJhbmdlIChhbmQgbGltaXQgdmlhIE1PRFVMRS1D T01QTElBTkNFLCBhcyB5b3UgYWxyZWFkeSBkbyk/DQoJICAgSSBzZWUgaXQgd2FzIGxhcmdlciBi ZWZvcmUsIGFuZCB0aGF0IHlvdSBjaGFuZ2VkIGl0IHRvIHRoaXMgc21hbGxlciByYW5nZS4NCgkg ICBTbyBJIGd1ZXNzIHlvdSBhcmUgZG9pbmcgdGhpcyBjb25zY2lvdXNseS4NCgkNCgk1LiBJbiBk ZXNjcmlwdGlvbiBjbGF1c2Ugb2YgZG9jc1N1Yk1ndEZpbHRlckdyb3VwSW5kZXggSSBzZWU6DQoJ DQoJICAgICAgIHRoZSBmb3VyLiBCZWNhdXNlIHRoaXMgaXMgdGhlIG9ubHkgZmllbGQgaW4gdGhp cyB0YWJsZSwgaXQgaXMNCgkgICAgICAgcmVhZC1vbmx5LCBjb250cmFyeSB0byB0aGUgdXN1YWwg U05NUCBjdXN0b20gb2YgbWFraW5nIGluZGljZXMNCgkgICAgICAgbm90LWFjY2Vzc2libGUuDQoJ DQoJICAgUHJvYmFibHkgYmV0dGVyIHRvIGNoYW5nZSBTTk1QIGludG8gU01JLg0KCQ0KCTYuIElu IHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucywgSSB0aGluayBJIHdvdWxkIGNoYW5nZSB0aGUg Mm5kIHBhcmENCgkgICB0byBtYWtlIGEgcG9zaXRpdmUgc3RhdGVtZW50LCBuYW1lbHkgdGhhdCB5 b3UgTVVTVCBmb2xsb3cgcmVjb21tZW5kYXRpb25zDQoJICAgaW4gc2VjdCAyLjIuNiBpbiBvcmRl ciB0byBkZXBsb3kgYW4gZWZmZWN0aXZlIGZpbHRlcmluZy4NCgkNCglUaGFua3MsDQoJQmVydA0K CQ0KCV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJSVBD RE4gbWFpbGluZyBsaXN0DQoJSVBDRE5AaWV0Zi5vcmcNCglodHRwczovL3d3dzEuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcGNkbg0KCQ0KCQ0KDQo= ------_=_NextPart_001_01C469B2.BBF761B3 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5baXBjZG5dIEFEIHJldmll dyBvZjogZHJhZnQtaWV0Zi1pcGNkbi1zdWJzY3JpYmVyLW1pYi0xNC50eHQ8L1RJVExFPgo8L0hF QUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+QmVydCwgPC9ESVY+CjxESVY+Rm9yIHRoZSBiZW5lZm90 IG9mIG90aGVyIGF1dGhvcnMvZWRpdG9ycyBpbiB0aGUgc2FtZSBwYXRoIG9mIEFEIGV2YWx1YXRp b24sIAo8L0RJVj4KPERJVj5JIHNlZSB5b3VyIGNvbW1lbnQgMyBhIGxpdHRsZSBkZXZpYXRpb24g b2YgT1BTIGd1aWRlbGluZXMgQXBwZW5kaXggQzo8L0RJVj4KPERJVj4tIFRoZSBkZXNjcmlwdG9y IGFzc29jaWF0ZWQgd2l0aCBhIGNvbmNlcHR1YWwgdGFibGUgc2hvdWxkIGJlIG9mIAp0aGU8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvcm0geHh4Wnp6VGFibGU7Jm5ic3A7IHRoZSBkZXNj cmlwdG9yIAphc3NvY2lhdGVkIHdpdGggdGhlIGNvcnJlc3BvbmRpbmc8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IGNvbmNlcHR1YWwgcm93IApzaG91bGQgYmUgb2YgdGhlIGZvcm0geHh4Wnp6 RW50cnk7Jm5ic3A7IHRoZSBuYW1lIG9mIAp0aGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IGFzc29jaWF0ZWQgU0VRVUVOQ0UgdHlwZSBzaG91bGQgYmUgb2YgdGhlIGZvcm0gClh4eFp6ekVu dHJ5OyZuYnNwOyBhbmQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBkZXNjcmlwdG9y cyBhc3NvY2lhdGVkIAp3aXRoIHRoZSBzdWJvcmRpbmF0ZSBjb2x1bW5hciBvYmplY3RzPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzaG91bGQgYmUgb2YgCnRoZSBmb3JtIHh4eFp6elNvbWVv dGhlck5hbWUuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SSBwcmVzdW1lIGl0IGlzIGEg dHlwbyBhbmQgeW91IHdvdWxkIGxpa2Ugc2VlIGV4dHJpY3QgY29tcGxpYW5jZSB0byB0aG9zZSAK cmVjb21tZW5kYXRpb25zPC9ESVY+CjxESVY+QW55IGNvbW1lbnRzPzwvRElWPgo8RElWPiZuYnNw OzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPlRoYW5rcyA8L0RJVj4KPERJVj4mbmJzcDs8 L0RJVj4KPERJVj5FZHVhcmRvPC9ESVY+CjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJ Ti1SSUdIVDogMHB4Ij4KICA8RElWPjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLSA8QlI+PEI+RnJvbTo8L0I+IFdpam5lbiwgQmVydCAKICAoQmVydCkgW21haWx0bzpid2lq bmVuQGx1Y2VudC5jb21dIDxCUj48Qj5TZW50OjwvQj4gV2VkIDcvMTQvMjAwNCA4OjE0IEFNIAog IDxCUj48Qj5Ubzo8L0I+IHdzYXd5ZXJAaWVlZS5vcmc7IHNhd3llcndkQGNvbWNhc3QubmV0OyBJ cGNkbiAoRS1tYWlsKSAKICA8QlI+PEI+Q2M6PC9CPiBIYXJyaWUgSGF6ZXdpbmtlbCA8QlI+PEI+ U3ViamVjdDo8L0I+IFtpcGNkbl0gQUQgcmV2aWV3IG9mOiAKICBkcmFmdC1pZXRmLWlwY2RuLXN1 YnNjcmliZXItbWliLTE0LnR4dDxCUj48QlI+PC9GT05UPjwvRElWPgogIDxQPjxGT05UIHNpemU9 Mj5XaWxzb24gKGFuZCBXRykuIFNvcnJ5IHRoYXQgaXQgdG9vayBsb25nIChhZ2FpbikgdG8gZG8g CiAgYW5vdGhlcjxCUj5nb29kIGNoZWNrIG9mIHRoaXMgTUlCIGRvY3VtZW50LjxCUj48QlI+SSB0 aGluayB0aGlzIGRvYyBpcyAKICBiYXNpY2FsbHkgT0sgbm93LiBJIGRpZCBmaW5kIHNvbWUgc21h bGwgdGhpbmdzPEJSPmFzIHBlciBiZWxvdywgYW5kIGl0IHdvdWxkIAogIGJlIGdvb2QgdG8gZml4 IHRob3NlIGF0IHNvbWUgcG9pbnQuPEJSPkkgcHJvcG9zZSB0aGF0IEkgaXNzdWUgYW4gSUVURiBM YXN0IAogIENhbGwsIGFuZCB0aGF0IHRoZSBiZWxvdyBjb21tZW50czxCUj5hcmUgY29uc2lkZXJl ZCBhcyB0aGUgaW5pdGlhbCBjb21tZW50cyBvbiAKICBzdWNoIGFuIElFVEYgTGFzdCBDYWxsPEJS PmFuZCB0aGF0IHlvdSBhZGRyZXNzIHRoZW0gKG9yIGFuc3dlciB0aGVtKSBhcyBwYXJ0IAogIG9m IGFueSBvdGhlciBjb21tZW50czxCUj50aGF0IG1heSBjb21lIHVwIGZyb20gSUVURiBMYXN0IAog IENhbGwuPEJSPjxCUj5XaWxzb24vV0ctY2hhaXIocyksIHBscyBsZXQgbWUga25vdyBpZiB0aGF0 IHNvdW5kcyBsaWtlIGEgcGxhbiBvciAKICBpZjxCUj55b3UgcmF0ZWhyIGFkZHJlc3MvYW5zd2Vy IHRoZSBiZWxvdyBmaXJzdC48QlI+PEJSPldoYXQgSSBkaWQgZmluZCAKICBpczo8QlI+PEJSPiZn dDtGcm9tIFNNSUNuZyAoc3RyaWN0IGNoZWNraW5nKS4gSSB0aG91Z2h0IEkgaGFkIHJlcG9ydGVk IHRoaXMgCiAgYmVmb3JlICggc2VlIEk8QlI+ZGlkLCBidXQgeW91IHByb2JhYmx5IG9wdGVkIHRv IG5vdCBkbyBpdCBzaW5jZSBpdCBpcyBub3QgCiAgbWFuZGF0b3J5KS48QlI+T2ggd2VsbCwgSSBh bSBpbmNsdWRpbmcgaXQgYW5heXdheSAoYWdhaW4pLCBiZWNhdXNlIEkgcmVhbGx5IAogIGJlbGl2 ZSBpdDxCUj5pcyBiZXRldHIgdG8gaW5jbHVkZSB0aGVtLjxCUj48QlI+Jm5ic3A7IEU6IGYoaXBj ZG5zdWIubWkyKSwgCiAgKDQ3OCwxNSkgSXRlbSAiZGlmZlNlcnZNSUJEYXRhUGF0aEdyb3VwIiBz aG91bGQgYmUgSU1QT1JUZWQ8QlI+Jm5ic3A7IEU6IAogIGYoaXBjZG5zdWIubWkyKSwgKDQ3OSwx NSkgSXRlbSAiZGlmZlNlcnZNSUJDbGZyR3JvdXAiIHNob3VsZCBiZSAKICBJTVBPUlRlZDxCUj4m bmJzcDsgRTogZihpcGNkbnN1Yi5taTIpLCAoNDgwLDE1KSBJdGVtIAogICJkaWZmU2Vydk1JQkNs ZnJFbGVtZW50R3JvdXAiIHNob3VsZCBiZSBJTVBPUlRlZDxCUj4mbmJzcDsgRTogZihpcGNkbnN1 Yi5taTIpLCAKICAoNDgxLDE1KSBJdGVtICJkaWZmU2Vydk1JQk11bHRpRmllbGRDbGZyR3JvdXAi IHNob3VsZCBiZSBJTVBPUlRlZDxCUj4mbmJzcDsgRTogCiAgZihpcGNkbnN1Yi5taTIpLCAoNDgy LDE1KSBJdGVtICJkaWZmU2Vydk1JQkFjdGlvbkdyb3VwIiBzaG91bGQgYmUgCiAgSU1QT1JUZWQ8 QlI+Jm5ic3A7IEU6IGYoaXBjZG5zdWIubWkyKSwgKDQ4MywxNSkgSXRlbSAiZGlmZlNlcnZNSUJB bGdEcm9wR3JvdXAiIAogIHNob3VsZCBiZSBJTVBPUlRlZDxCUj4mbmJzcDsgRTogZihpcGNkbnN1 Yi5taTIpLCAoNDg0LDE1KSBJdGVtIAogICJkaWZmU2Vydk1JQkNvdW50ZXJHcm91cCIgc2hvdWxk IGJlIElNUE9SVGVkPEJSPiZuYnNwOyBFOiBmKGlwY2Ruc3ViLm1pMiksIAogICg0ODcsMTEpIEl0 ZW0gImRpZmZTZXJ2RGF0YVBhdGhTdGF0dXMiIHNob3VsZCBiZSBJTVBPUlRlZDxCUj4mbmJzcDsg RTogCiAgZihpcGNkbnN1Yi5taTIpLCAoNDkzLDExKSBJdGVtICJkaWZmU2VydkNsZnJTdGF0dXMi IHNob3VsZCBiZSAKICBJTVBPUlRlZDxCUj4mbmJzcDsgRTogZihpcGNkbnN1Yi5taTIpLCAoNDk5 LDExKSBJdGVtIAogICJkaWZmU2VydkNsZnJFbGVtZW50U3RhdHVzIiBzaG91bGQgYmUgSU1QT1JU ZWQ8QlI+Jm5ic3A7IEU6IGYoaXBjZG5zdWIubWkyKSwgCiAgKDUwNiwxMSkgSXRlbSAiZGlmZlNl cnZNdWx0aUZpZWxkQ2xmckFkZHJUeXBlIiBzaG91bGQgYmUgSU1QT1JUZWQ8QlI+Jm5ic3A7IEU6 IAogIGYoaXBjZG5zdWIubWkyKSwgKDUxMiwxMSkgSXRlbSAiZGlmZlNlcnZNdWx0aUZpZWxkQ2xm clNyY0FkZHIiIHNob3VsZCBiZSAKICBJTVBPUlRlZDxCUj4mbmJzcDsgRTogZihpcGNkbnN1Yi5t aTIpLCAoNTE4LDExKSBJdGVtIAogICJkaWZmU2Vydk11bHRpRmllbGRDbGZyRHN0QWRkciIgc2hv dWxkIGJlIElNUE9SVGVkPEJSPiZuYnNwOyBFOiAKICBmKGlwY2Ruc3ViLm1pMiksICg1MjQsMTEp IEl0ZW0gImRpZmZTZXJ2QWxnRHJvcFN0YXR1cyIgc2hvdWxkIGJlIAogIElNUE9SVGVkPEJSPiZu YnNwOyBFOiBmKGlwY2Ruc3ViLm1pMiksICg1MzAsMTEpIEl0ZW0gImRpZmZTZXJ2RGF0YVBhdGhT dG9yYWdlIiAKICBzaG91bGQgYmUgSU1QT1JUZWQ8QlI+Jm5ic3A7IEU6IGYoaXBjZG5zdWIubWky KSwgKDUzNiwxMSkgSXRlbSAKICAiZGlmZlNlcnZDbGZyU3RvcmFnZSIgc2hvdWxkIGJlIElNUE9S VGVkPEJSPiZuYnNwOyBFOiBmKGlwY2Ruc3ViLm1pMiksIAogICg1NDIsMTEpIEl0ZW0gImRpZmZT ZXJ2Q2xmckVsZW1lbnRTdG9yYWdlIiBzaG91bGQgYmUgSU1QT1JUZWQ8QlI+Jm5ic3A7IEU6IAog IGYoaXBjZG5zdWIubWkyKSwgKDU0OCwxMSkgSXRlbSAiZGlmZlNlcnZNdWx0aUZpZWxkQ2xmclN0 b3JhZ2UiIHNob3VsZCBiZSAKICBJTVBPUlRlZDxCUj4mbmJzcDsgRTogZihpcGNkbnN1Yi5taTIp LCAoNTU0LDExKSBJdGVtICJkaWZmU2VydkFjdGlvblN0b3JhZ2UiIAogIHNob3VsZCBiZSBJTVBP UlRlZDxCUj4mbmJzcDsgRTogZihpcGNkbnN1Yi5taTIpLCAoNTYwLDExKSBJdGVtIAogICJkaWZm U2VydkNvdW50QWN0U3RvcmFnZSIgc2hvdWxkIGJlIElNUE9SVGVkPEJSPiZuYnNwOyBFOiBmKGlw Y2Ruc3ViLm1pMiksIAogICg1NjYsMTEpIEl0ZW0gImRpZmZTZXJ2QWxnRHJvcFN0b3JhZ2UiIHNo b3VsZCBiZSBJTVBPUlRlZDxCUj4mbmJzcDsgRTogCiAgZihpcGNkbnN1Yi5taTIpLCAoNTcyLDEx KSBJdGVtICJkaWZmU2VydkFsZ0Ryb3BUeXBlIiBzaG91bGQgYmUgCiAgSU1QT1JUZWQ8QlI+PEJS PkFjY29yZGluZyB0byBvdXIgTUlCIHJldmlldyBndWlkZWxpbmVzIAogIChkcmFmdC1pZXRmLW9w cy1taWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0KTxCUj5zZWN0aW9uIDQuNCwgM3JkIAogIHBh cmE6PEJSPiZuYnNwOyZuYnNwOyBOb3RlIHRoYXQgZXhlbXB0aW9ucyB0byB0aGlzIGdlbmVyYWwg cmVxdWlyZW1lbnQgYXJlIAogIGdyYW50ZWQgYnkgUkZDPEJSPiZuYnNwOyZuYnNwOyAyNTgwIFNl Y3Rpb25zIDUuNC4zIGFuZCA2LjUuMiBmb3IgZGVzY3JpcHRvcnMgCiAgb2Ygb2JqZWN0cyBhcHBl YXJpbmcgaW48QlI+Jm5ic3A7Jm5ic3A7IHRoZSBPQkpFQ1QgY2xhdXNlIG9mIGEgCiAgTU9EVUxF LUNPTVBMSUFOQ0Ugc3RhdGVtZW50IG9yIGluIHRoZTxCUj4mbmJzcDsmbmJzcDsgVkFSSUFUSU9O IGNsYXVzZSBvZiBhbiAKICBBR0VOVC1DQVBBQklMSVRJRVMgc3RhdGVtZW50LiZuYnNwOyBTb21l IE1JQjxCUj4mbmJzcDsmbmJzcDsgY29tcGlsZXJzIGFsc28gCiAgZ3JhbnQgZXhlbXB0aW9ucyB0 byBkZXNjcmlwdG9ycyBvZiBub3RpZmljYXRpb25zPEJSPiZuYnNwOyZuYnNwOyBhcHBlYXJpbmcg aW4gCiAgYSBWQVJJQVRJT04gY2xhdXNlIGFuZCB0byBkZXNjcmlwdG9ycyBvZiBvYmplY3QgZ3Jv dXBzPEJSPiZuYnNwOyZuYnNwOyBhbmQgCiAgbm90aWZpY2F0aW9uIGdyb3VwcyByZWZlcmVuY2Vk IGJ5IGEgTUFOREFUT1JZLUdST1VQUyBjbGF1c2UsIGE8QlI+Jm5ic3A7Jm5ic3A7IAogIEdST1VQ IGNsYXVzZSwgb3IgYW4gSU5DTFVERVMgY2xhdXNlLCBhbHRob3VnaCBSRkMgMjU4MCAKICAodGhy b3VnaDxCUj4mbmJzcDsmbmJzcDsgYXBwYXJlbnQgb3ZlcnNpZ2h0KSBkb2VzIG5vdCBtZW50aW9u IHRob3NlIAogIGNhc2VzLiZuYnNwOyBUaGUgZXhlbXB0aW9ucyBhcmU8QlI+Jm5ic3A7Jm5ic3A7 IHNvbWV0aW1lcyBzZWVuIGFzIHVuaGVscGZ1bCAKICBiZWNhdXNlIHRoZXkgbWFrZSBJTVBPUlRT IHJ1bGVzIG1vcmU8QlI+Jm5ic3A7Jm5ic3A7IGNvbXBsaWNhdGVkIGFuZCAKICBpbnRlci1tb2R1 bGUgZGVwZW5kZW5jaWVzIGxlc3Mgb2J2aW91cyB0aGFuIHRoZXk8QlI+Jm5ic3A7Jm5ic3A7IG90 aGVyd2lzZSAKICB3b3VsZCBiZS4mbmJzcDsgRXh0ZXJuYWwgc3ltYm9scyByZWZlcmVuY2VkIGJ5 IGNvbXBsaWFuY2U8QlI+Jm5ic3A7Jm5ic3A7IAogIHN0YXRlbWVudHMgYW5kIGNhcGFiaWxpdGll cyBzdGF0ZW1lbnRzIE1BWSB0aGVyZWZvcmUgYmUgbGlzdGVkIGluIAogIHRoZTxCUj4mbmJzcDsm bmJzcDsgSU1QT1JUUyBzdGF0ZW1lbnQ7Jm5ic3A7IGlmIHRoaXMgaXMgZG9uZSwgaXQgU0hPVUxE IGJlIAogIGRvbmUgY29uc2lzdGVudGx5LjxCUj48QlI+U28gaXQgaXMgbm90IG1hbmRhdG9yeSB0 byBkbyB0aGUgSU1QT1JUcywgYnV0IGluIG15IAogIHZpZXcgaXQgd2lsbCBoZWxwIGluPEJSPm1h bnkgcGxhY2VzIHdpdGggbGVzcyB3YXJuaW5nL2Vycm9ycy4gU28gbWF5IEkgc3VnZ2VzdCAKICB0 byBhZGQgdGhlIElNUE9SVDxCUj5zdGF0ZW1lbnQgZm9yIHRoZSBhYm92ZS48QlI+PEJSPkFsc28s IGFsbCBkb2N1bWVudHMgZnJvbSAKICB3aGloYyB5b3UgSU1QT1JUIChpbXBsaWVkIG9yIGV4cGxp Y2l0KSB5b3UgbXVzdDxCUj5wdXQgaW4gbm9ybWF0aXZlIHJlZmVyZW5jZSAKICBzZWN0aW9uICh3 aGljaCB5b3UgaGF2ZSBkb25lKS4gQnV0IGFsbCBzdWNoPEJSPnJlZmVyZW5jZXMgTVVTVCBoYXZl IGEgY2l0YXRpb24gCiAgaW4gdGhlIHRleHQgKHNlZSBNSUIgcmV2aWV3IAogIGd1aWRlbGluZXMs PEJSPihkcmFmdC1pZXRmLW9wcy1taWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0LCBzZWN0IAog IDMuNSk6PEJSPiZuYnNwOyZuYnNwOyAzLjUuJm5ic3A7IFJlZmVyZW5jZXMgU2VjdGlvbnM8QlI+ PEJSPiZuYnNwOyZuYnNwOyAKICBTZWN0aW9uIDQuN2Ygb2YgW1JGQzIyMjNiaXNdIHNwZWNpZmll cyB0aGUgcmVxdWlyZW1lbnRzIGZvciAKICB0aGU8QlI+Jm5ic3A7Jm5ic3A7IHJlZmVyZW5jZXMg c2VjdGlvbnMuJm5ic3A7IEluIHBhcnRpY3VsYXIsIHRoZXJlIE1VU1QgYmUgCiAgc2VwYXJhdGUg bGlzdHMgb2Y8QlI+Jm5ic3A7Jm5ic3A7IG5vcm1hdGl2ZSBhbmQgaW5mb3JtYXRpdmUgcmVmZXJl bmNlcywgZWFjaCAKICBpbiBhIHNlcGFyYXRlIHNlY3Rpb24uPEJSPiZuYnNwOyZuYnNwOyBUaGUg c3R5bGUgU0hPVUxEIGZvbGxvdyB0aGF0IG9mIAogIHJlY2VudGx5IHB1Ymxpc2hlZCBSRkNzLjxC Uj48QlI+Jm5ic3A7Jm5ic3A7IFRoZSBzdGFuZGFyZCBNSUIgYm9pbGVycGxhdGUgCiAgYXZhaWxh YmxlIGF0PEJSPiZuYnNwOyZuYnNwOyA8QSAKICBocmVmPSJodHRwOi8vd3d3Lm9wcy5pZXRmLm9y Zy9taWItYm9pbGVycGxhdGUuaHRtbCI+aHR0cDovL3d3dy5vcHMuaWV0Zi5vcmcvbWliLWJvaWxl cnBsYXRlLmh0bWw8L0E+IAogIGluY2x1ZGVzIGxpc3RzIG9mPEJSPiZuYnNwOyZuYnNwOyBub3Jt YXRpdmUgYW5kIGluZm9ybWF0aXZlIHJlZmVyZW5jZXMgdGhhdCAKICBNVVNUIGFwcGVhciBpbiBh bGwgSUVURjxCUj4mbmJzcDsmbmJzcDsgc3BlY2lmaWNhdGlvbnMgdGhhdCBjb250YWluIE1JQiAK ICBtb2R1bGVzLiZuYnNwOyBJZiBpdGVtcyBmcm9tIG90aGVyIE1JQjxCUj4mbmJzcDsmbmJzcDsg bW9kdWxlcyBhcHBlYXIgaW4gYW4gCiAgSU1QT1JUUyBzdGF0ZW1lbnQgaW4gdGhlIERlZmluaXRp b25zIHNlY3Rpb24sPEJSPiZuYnNwOyZuYnNwOyB0aGVuIHRoZSAKICBzcGVjaWZpY2F0aW9ucyBj b250YWluaW5nIHRob3NlIE1JQiBtb2R1bGVzIE1VU1QgYmUgaW5jbHVkZWQ8QlI+Jm5ic3A7Jm5i c3A7IAogIGluIHRoZSBsaXN0IG9mIG5vcm1hdGl2ZSByZWZlcmVuY2VzLiZuYnNwOyBXaGVuIGl0 ZW1zIGFyZSBpbXBvcnRlZCBmcm9tIAogIGFuPEJSPiZuYnNwOyZuYnNwOyBJQU5BLW1haW50YWlu ZWQgTUlCIG1vZHVsZSB0aGUgY29ycmVzcG9uZGluZyBub3JtYXRpdmUgCiAgcmVmZXJlbmNlPEJS PiZuYnNwOyZuYnNwOyBTSEFMTCBwb2ludCB0byB0aGUgb24tbGluZSB2ZXJzaW9uIG9mIHRoYXQg TUlCIAogIG1vZHVsZS4mbmJzcDsgSXQgaXMgdGhlPEJSPiZuYnNwOyZuYnNwOyBwb2xpY3kgb2Yg dGhlIFJGQyBFZGl0b3IgdGhhdCBhbGwgCiAgcmVmZXJlbmNlcyBtdXN0IGJlIGNpdGVkIGluIHRo ZTxCUj4mbmJzcDsmbmJzcDsgdGV4dDsmbmJzcDsgc3VjaCBjaXRhdGlvbnMgCiAgTVVTVCBhcHBl YXIgaW4gdGhlIG92ZXJ2aWV3IHNlY3Rpb24gd2hlcmU8QlI+Jm5ic3A7Jm5ic3A7IGRvY3VtZW50 cyBjb250YWluaW5nIAogIGltcG9ydGVkIGRlZmluaXRpb25zIChvdGhlciB0aG9zZSBhbHJlYWR5 PEJSPiZuYnNwOyZuYnNwOyBtZW50aW9uZWQgaW4gdGhlIE1JQiAKICBib2lsZXJwbGF0ZSkgYXJl IHJlcXVpcmVkIHRvIGJlIG1lbnRpb25lZCAoY2YuPEJSPiZuYnNwOyZuYnNwOyBTZWN0aW9uIAog IDMuMikuPEJSPjxCUj5Zb3UgaGF2ZSBzdWNoIGEgcmVmZXJlbmNlIGZvciBSRkMzMjkxIChhcyBy ZXF1aXJlZCksIGJ1dCBubyAKICBjaXRhdGlvbjxCUj50byBbUkZDMzI5MV0gYW55d2hlcmUgaW4g dGhlIGRvY3VtZW50LiBDYW4geW91IHBscyBhZGQgaXQgCiAgYXQ8QlI+c29tZSBwb2ludCBpbiB0 aGUgdGV4dC48QlI+PEJSPjxCUj5JIGhhdmUgc29tZSBvdGhlciAKICBuaXRzL3F1ZXN0aW9uczo8 QlI+PEJSPjEuIERlc3JpcHRpb24gY2xhdXNlIG9mIGRvY3NTdWJNZ3RDcGVJcEluZGV4IHN0YXRl cywgCiAgdG93YXJkcyB0aGUgZW5kOjxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRoZSB0YWJsZSBhbmQgdGhlIAogIHBhY2tldCBpcyBmb3J3YXJkZWQuJm5ic3A7 IElmIHRoZSBudW1iZXIgb2YgCiAgZW50cmllczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgZXF1YWxzIHRoZSAKICBkb2NzU3ViTWd0Q3BlQ29udHJvbE1heENwZUlwLCBB TkQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NTdWJNZ3RD cGVDb250cm9sQWN0aXZlIGlzIHRydWUsIHRoZW4gdGhlIHBhY2tldCBpcyAKICBkcm9wcGVkLjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT3RoZXJ3aXNlIHRoZSBwYWNr ZXQgaXMgCiAgZm9yd2FyZGVkLiAiPEJSPjxCUj4mbmJzcDsmbmJzcDsgSW4gdGhlIGNhc2UgdGhh dCB0aGUgcGFja2V0IGlzIGZvcndhcmRlZCwgCiAgd2lsbCB0aGVuIGFsc28gYW4gZW50cnkgYmU8 QlI+Jm5ic3A7Jm5ic3A7IGNyZWF0ZWQ/IFRoYXQgaXMgbm90IGNsZWFyIHRvIG1lLiAKICBNYXkg SSBzdWdnZXN0IHRvIGFkZCBzb21lIHRleHQgdG88QlI+Jm5ic3A7Jm5ic3A7IG1ha2UgdGhhdCAx MDAlIAogIGNsZWFyPzxCUj48QlI+Mi4gSW4gZGVzY3JpcHRpb24gY2xhdXNlIG9mIGRvY3NTdWJN Z3RDbUZpbHRlclRhYmxlIGl0IAogIHN0YXRlczo8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBaZXJvIGlzIGEgZGlzdGluZ3Vpc2hlZCAKICB2YWx1ZSwgaW5kaWNh dGluZyB0aGF0IHRoZSBkZWZhdWx0PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICBmaWx0ZXJpbmcgYWN0aW9uIGlzIHRvIGJlIHRha2VuLCByYXRoZXIgdGhhbiB0aGF0 IAogIGFzc29jaWF0ZWQ8QlI+PEJSPiZuYnNwOyZuYnNwOyBNbW0uLi4gYSB2YWx1ZSBmb3IgdGhl IHRhYmxlPyBJIGd1ZXNzIHlvdSBtZWFuIAogIHRoYXQgc3VjaCBhIHplcm88QlI+Jm5ic3A7Jm5i c3A7IHZhbHVlICJpbiBhbnkgb2YgdGhlIGNvbHVtbnMgb2YgdGhlIHRhYmxlIGhhcyAKICBhIHNw ZWNpYWwgbWFlbmluZy48QlI+Jm5ic3A7Jm5ic3A7IFJpZ2h0PyBNaWdodCB3YW50IHRvIG1ha2Ug dGhhdCAKICBjbGVhcmVyLjxCUj48QlI+My4gSSBzZWU6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICAxLjMuNi4xLjIuMS54eC4xLjYmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg CiAgZG9jc1N1Yk1ndENtRmlsdGVyVGFibGU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAog IDEuMy42LjEuMi4xLnh4LjEuNi4xJm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NTdWJNZ3RDbUZp bHRlckVudHJ5PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAxLjMuNi4xLjIuMS54eC4x LjYuMS4xJm5ic3A7IAogIGRvY3NTdWJNZ3RTdWJGaWx0ZXJEb3duc3RyZWFtPEJSPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAKICAxLjMuNi4xLjIuMS54eC4xLjYuMS4yJm5ic3A7IAogIGRvY3NT dWJNZ3RTdWJGaWx0ZXJVcHN0cmVhbTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgMS4z LjYuMS4yLjEueHguMS42LjEuMyZuYnNwOyAKICBkb2NzU3ViTWd0Q21GaWx0ZXJEb3duc3RyZWFt PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAxLjMuNi4xLjIuMS54eC4xLjYuMS40Jm5i c3A7IGRvY3NTdWJNZ3RDbUZpbHRlclVwc3RyZWFtPEJSPiZuYnNwOyZuYnNwOyBJIAogIHRoaW5r IHRoYXQgZm9yIG5hbWluZyBjb25zaXN0ZW5jeSwgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIAogIHJl bmFtZTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMS4zLjYuMS4yLjEueHguMS42LjEuMSZu YnNwOyAKICBkb2NzU3ViTWd0U3ViRmlsdGVyRG93bnN0cmVhbTxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgCiAgMS4zLjYuMS4yLjEueHguMS42LjEuMiZuYnNwOyBkb2NzU3ViTWd0U3ViRmls dGVyVXBzdHJlYW08QlI+Jm5ic3A7Jm5ic3A7IGludG8gCiAgc29tZXRoaW5nIGxpa2U6PEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxLjMuNi4xLjIuMS54eC4xLjYuMS4xJm5ic3A7IAogIGRv Y3NTdWJNZ3RDbVN1YkZpbHRlckRvd25zdHJlYW08QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IAogIDEuMy42LjEuMi4xLnh4LjEuNi4xLjImbmJzcDsgZG9jc1N1Yk1ndENNbXViRmlsdGVyVXBz dHJlYW08QlI+Jm5ic3A7Jm5ic3A7IHNvIAogIGFzIHRvIG1ha2UgaXQgY2xlYXJlciAoZnJvbSB0 aGUgbmFtZS9kZXNjcmlwdG9yKSB0aGF0IHRoZXNlIDI8QlI+Jm5ic3A7Jm5ic3A7IAogIG9iamVj dHMgZXhpc3RzIGluIHRoZSBkb2NzU3ViTWd0Q21GaWx0ZXJUYWJsZS48QlI+PEJSPjQuIEkgYW0g YSBiaXQgd29ycmllZCAKICBhYm91dCB0aGUgaGFyZCBsaW1pdCAocmFuZ2UpIG9mIDEtMjU1IGZv ciBGaWx0ZXJHcm91cEluZGV4LjxCUj4mbmJzcDsmbmJzcDsgSXMgCiAgdGhpcyBlbm91Z2ggZm9y ZXZlciBpbiB0aGUgZnV0dXJlPyBPciB3b3VsZCBpdCBiZSB3aXNlciB0byB1c2UgYSAKICBsYXJn ZXI8QlI+Jm5ic3A7Jm5ic3A7IHJhbmdlIChhbmQgbGltaXQgdmlhIE1PRFVMRS1DT01QTElBTkNF LCBhcyB5b3UgYWxyZWFkeSAKICBkbyk/PEJSPiZuYnNwOyZuYnNwOyBJIHNlZSBpdCB3YXMgbGFy Z2VyIGJlZm9yZSwgYW5kIHRoYXQgeW91IGNoYW5nZWQgaXQgdG8gCiAgdGhpcyBzbWFsbGVyIHJh bmdlLjxCUj4mbmJzcDsmbmJzcDsgU28gSSBndWVzcyB5b3UgYXJlIGRvaW5nIHRoaXMgCiAgY29u c2Npb3VzbHkuPEJSPjxCUj41LiBJbiBkZXNjcmlwdGlvbiBjbGF1c2Ugb2YgZG9jc1N1Yk1ndEZp bHRlckdyb3VwSW5kZXggSSAKICBzZWU6PEJSPjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgdGhlIGZvdXIuIEJlY2F1c2UgdGhpcyBpcyB0aGUgCiAgb25seSBmaWVsZCBp biB0aGlzIHRhYmxlLCBpdCBpczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgCiAgcmVhZC1vbmx5LCBjb250cmFyeSB0byB0aGUgdXN1YWwgU05NUCBjdXN0b20gb2YgbWFr aW5nIAogIGluZGljZXM8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAog IG5vdC1hY2Nlc3NpYmxlLjxCUj48QlI+Jm5ic3A7Jm5ic3A7IFByb2JhYmx5IGJldHRlciB0byBj aGFuZ2UgU05NUCBpbnRvIAogIFNNSS48QlI+PEJSPjYuIEluIHRoZSBTZWN1cml0eSBDb25zaWRl cmF0aW9ucywgSSB0aGluayBJIHdvdWxkIGNoYW5nZSB0aGUgMm5kIAogIHBhcmE8QlI+Jm5ic3A7 Jm5ic3A7IHRvIG1ha2UgYSBwb3NpdGl2ZSBzdGF0ZW1lbnQsIG5hbWVseSB0aGF0IHlvdSBNVVNU IGZvbGxvdyAKICByZWNvbW1lbmRhdGlvbnM8QlI+Jm5ic3A7Jm5ic3A7IGluIHNlY3QgMi4yLjYg aW4gb3JkZXIgdG8gZGVwbG95IGFuIGVmZmVjdGl2ZSAKICBmaWx0ZXJpbmcuPEJSPjxCUj5UaGFu a3MsPEJSPkJlcnQ8QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPEJSPklQQ0ROIAogIG1haWxpbmcgbGlzdDxCUj5JUENETkBpZXRmLm9yZzxCUj48 QSAKICBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbiI+ aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBjZG48L0E+PEJSPjxCUj48 L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KCjwvQk9EWT4KPC9IVE1MPg== ------_=_NextPart_001_01C469B2.BBF761B3-- --===============0892228619== 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 --===============0892228619==-- From ipcdn-bounces@ietf.org Wed Jul 14 11:36:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24324 for ; Wed, 14 Jul 2004 11:36:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bklo3-0002T2-Og for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:36:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bklmw-000285-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:35:19 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bklly-0001Wd-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 11:34:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkljR-0006E9-Bg; Wed, 14 Jul 2004 11:31:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkleH-0005eS-KN for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 11:26:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24002 for ; Wed, 14 Jul 2004 11:26:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkleG-00071M-MT for ipcdn@ietf.org; Wed, 14 Jul 2004 11:26:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkldG-0006h6-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 11:25:18 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BklcC-00062L-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 11:24:12 -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 i6EFMgbw028021; Wed, 14 Jul 2004 09:22:43 -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] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Wed, 14 Jul 2004 09:22:42 -0600 Message-ID: Thread-Topic: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Thread-Index: AcRptaFlxgoDwwHhQPKfdYT+R8TZVAAAFdVg From: "Jean-Francois Mule" To: , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Cc: Harrie Hazewinkel , wsawyer@ieee.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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Bert asked: > > Wilson/WG-chair(s), pls let me know if that sounds like a plan or if > > you ratehr address/answer the below first.=20 Wilson wrote: > I won't be able to respond to these immediately, so my=20 > preference would be to go ahead with the Last Call as Bert proposes. > - Wilson Your proposal Bert sounds like a plan and that we should do a Last Call asap (based on the nature of your comments Bert, and the upcoming cut-off ID date). Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 12:35:26 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27131 for ; Wed, 14 Jul 2004 12:35:26 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkmjA-0005iL-EP for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 12:35:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkmiB-0005OS-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 12:34:28 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkmhP-0004lp-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 12:33:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkmYe-0005nk-3D; Wed, 14 Jul 2004 12:24:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkmG0-0001r4-9A for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 12:05:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25587 for ; Wed, 14 Jul 2004 12:05:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkmFz-0003kD-5A for ipcdn@ietf.org; Wed, 14 Jul 2004 12:05:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkmF4-0003Rx-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 12:04:23 -0400 Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx with esmtp (Exim 4.12) id 1BkmEO-0002vG-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 12:03:40 -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 i6EG38P7006228 for ; Wed, 14 Jul 2004 11:03:09 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jul 2004 18:03:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504BEADD3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Wed, 14 Jul 2004 18:03:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 1 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sorry, it took too long to finally get this done. Not sure this document is ready for IETF Last Call. Actaully I think it is not. This is part 1. Mainly serious things. I may have more nits/admin stuff later. Here are my findings. More or less serious: 1. I see various read-write and/or read-create objects and I do not see any text in the DESCRIPTION clauses (non STorageType objects) that tell me what the expected behaviour is w.r.t. persistency of such objects. SO what happens after a restart/reboot? 2. I see a number of ZeroBasedCOunter32 objects that have text aka: (for example docsBpi2CmAuthentInfos) DESCRIPTION "The value of this object is the count of times the CM has transmitted an Authentication Information message, since reboot." It is OK to tell us that a ZeroBasedCOunter32 object must start with zero at (re-)boot time or at row creation. But from that point on, a ZeroBasedCounter32 behaves exactly the same as a Counter32, and so it is incorrect to say "count of X since reboot" because the Counter32 may have wrapped!. Possibly this is not gonna happen in practice, but literally the claim is incorrect. 3. For these ZeroBasedCounter32 objects, I also see no word about a possible discontinuity timer. Why not. Can there NEVER be a discontinuity? Of if there is one does that mean ALL counters experience a discontionuity? The latter is what you basically state (or cause) by not pointing to a specific discontinuity timer. Because then by default it is sysUpTime, and so that means that when you DO experience a discontinuity, then you MUST reset sysUpTime and that means that a discontinuity for EVERYONE (object) that assumes the default. If such is intended, then fine, but it would be good to then state that sysUpTime is the discontinuity timer. 4. I see that for some objects you speak about a "null string" or "NULL string". The base data type for such objects is OCTET STRING. In all those cases I suspect (but I am not sure) that you mean the zero-length octet string. Otherwise I do not understand what "null string" means. Pls explain and fix. 5. For docsBpi2CmtsAuthCmExpiresOld I see: Note: For CMs running in BPI mode, implementation of this object is optional and MAY vary." Mmm... that sounds like a MODULE-COMPLIANCE aspect and I would rather see such things in MODULE-COMPLIANCE and not in object DESCRIPTION clauses. 6. I see: -- Note: the following object has been obsoleted docsBpi2CmtsAuthCmReset OBJECT-TYPE SYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3), invalidateTeks(4) } MAX-ACCESS read-write STATUS current So the --Note: is out of sync with the actual status!? What is it? If it IS obsoleted, then status should sya so, And DESCRIPTION clause should explain why it was obsoleted. And the ASN.1 comment line then of course is no longer needed. 7. I see: docsBpi2CmtsAuthCACertIndexPtr OBJECT-TYPE SYNTAX Integer32 (0..10000) And find that a strange limit (range). And nowhere, not even in the docsBpi2CmtsCACertTable do I see an explanation why that range makes sense (assuming that it does). 8. When I see: docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastMaskType InetAddressType, docsBpi2CmtsIpMulticastMask InetAddress, I wonder if (in the same row) docsBpi2CmtsIpMulticastMaskType will ever have a different value then docsBpi2CmtsIpMulticastAddressType !?? It seems to me that should NOT be allowed, cause otherwise I am not sure how the ANDing of the Mask is going to work/happen. So the next question then is why you do not do: docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastMask InetAddress, And let docsBpi2CmtsIpMulticastAddressType be the discriminator for both InetAddresses. One less object, and less change for error/conflict. But thinking even further, Possibly the best thing to do is to use docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastPrefixLength InetAddressPrefixLength, Are not such masks always setup that they basically specify a prefix length? If so, then this is the way to do it with the TCs from INET-ADDRESS-MIB. 9. I see various uses of InetAddress as for example here: docsBpi2CmtsIpMulticastAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the IP multicast address to be mapped, in conjunction with docsBpi2CmtsIpMulticastMask." The TC for InetAddress (in RFC3291 or its follow on) clearly state that you MUST specify which InetAddressType controls the format of this object as per DESCRIPTION from InetAddress TC: An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object which provides the context. ... 10. I see: docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not be timed out." Mmm... that "need not be timed out" seems in conflict with the RowStatus TC DESCRIPTION clause in RFC2579. Can you explain why this is? Also, a RowSTatus object MUST specify in its DESCRIPTION clause under which conditions - the row can be activated - which columns (if any) can bve changed while in the active state. I am missing the first. 11. You specify: -- -- The BPI+ MIB Conformance Statements (with a placeholder for -- notifications) -- docsBpi2Notification OBJECT IDENTIFIER ::= { docsBpi2MIB 2 } docsBpi2Conformance OBJECT IDENTIFIER ::= { docsBpi2MIB 3 } docsBpi2Compliances OBJECT IDENTIFIER ::= { docsBpi2Conformance 1 } docsBpi2Groups OBJECT IDENTIFIER ::= { docsBpi2Conformance 2 } Why not be (more) consistent with other MIB modules and follow the suggested OID subtrees as per MIB guidelines, draft-ietf-ops-mib-review-guidelines-03.txt, appendix D: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) This is not mandatiory, but consistency is always useful/helpful Nits/administrativia: 1. The RFC editor wants all references to have at least one citation in the document. ALso for the normative references to RFCs from which you import. See MIB review guidelines, sect 3.5 You need to add a citation somehwere for [RFC3411], [RFC2021], [RFC3291], [RFC2670] Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 14:05:40 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02357 for ; Wed, 14 Jul 2004 14:05:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bko8S-0003yY-Q9 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 14:05:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bko7Z-0003fA-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 14:04:46 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bko6r-0003I1-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 14:04:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bko1k-0005Qf-MY; Wed, 14 Jul 2004 13:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bknsi-0003jX-Hh for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 13:49:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01450 for ; Wed, 14 Jul 2004 13:49:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bknsh-0006bJ-9z for ipcdn@ietf.org; Wed, 14 Jul 2004 13:49:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bknrn-0006Hr-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 13:48:28 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Bknqg-0005dI-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 13:47:18 -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 i6EHkkbw002469; Wed, 14 Jul 2004 11:46:46 -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] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 1 Date: Wed, 14 Jul 2004 11:46:46 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F06A1E9@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 1 Thread-Index: AcRpwGuw2f66BB6OQs+qQ70b5xsqHwACe9tZ From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar 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="===============1895742245==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. --===============1895742245== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469CA.886DCC56" This is a multi-part message in MIME format. ------_=_NextPart_001_01C469CA.886DCC56 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEJlcnQgZm9yIHRoZSBkZXRhaWwgcmV2aXNpb24uDQogDQpJIHdpbGwgcmV2aWV3IGFu ZCBwcm9wb3NlIHRoZSBjb3JyZXNwb25kaW5nIGFjdGlvbnMgc2hvcnRseQ0KIA0KVGhhbmtzDQog DQpFZHVhcmRvDQogDQogDQogDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglG cm9tOiBXaWpuZW4sIEJlcnQgKEJlcnQpIFttYWlsdG86Yndpam5lbkBsdWNlbnQuY29tXSANCglT ZW50OiBXZWQgNy8xNC8yMDA0IDEwOjAzIEFNIA0KCVRvOiBJcGNkbiAoRS1tYWlsKSANCglDYzog DQoJU3ViamVjdDogW2lwY2RuXSBBRCByZXZpZXcgb2Y6IGRyYWZ0LWlldGYtaXBjZG4tYnBpcGx1 cy1taWItMTIudHh0IC0gcGFydCAxDQoJDQoJDQoNCglTb3JyeSwgaXQgdG9vayB0b28gbG9uZyAg dG8gZmluYWxseSBnZXQgdGhpcyBkb25lLg0KCQ0KCU5vdCBzdXJlIHRoaXMgZG9jdW1lbnQgaXMg cmVhZHkgZm9yIElFVEYgTGFzdCBDYWxsLg0KCUFjdGF1bGx5IEkgdGhpbmsgaXQgaXMgbm90Lg0K CQ0KCVRoaXMgaXMgcGFydCAxLiBNYWlubHkgc2VyaW91cyB0aGluZ3MuDQoJSSBtYXkgaGF2ZSBt b3JlIG5pdHMvYWRtaW4gc3R1ZmYgbGF0ZXIuDQoJDQoJSGVyZSBhcmUgbXkgZmluZGluZ3MuDQoJ DQoJTW9yZSBvciBsZXNzIHNlcmlvdXM6DQoJMS4gSSBzZWUgdmFyaW91cyByZWFkLXdyaXRlIGFu ZC9vciByZWFkLWNyZWF0ZSBvYmplY3RzIGFuZCBJIGRvDQoJICAgbm90IHNlZSBhbnkgdGV4dCBp biB0aGUgREVTQ1JJUFRJT04gY2xhdXNlcyAobm9uIFNUb3JhZ2VUeXBlIG9iamVjdHMpDQoJICAg dGhhdCB0ZWxsIG1lIHdoYXQgdGhlIGV4cGVjdGVkIGJlaGF2aW91ciBpcyB3LnIudC4gcGVyc2lz dGVuY3kgb2Ygc3VjaA0KCSAgIG9iamVjdHMuIFNPIHdoYXQgaGFwcGVucyBhZnRlciBhIHJlc3Rh cnQvcmVib290Pw0KCQ0KCTIuIEkgc2VlIGEgbnVtYmVyIG9mIFplcm9CYXNlZENPdW50ZXIzMiBv YmplY3RzIHRoYXQgaGF2ZSB0ZXh0IGFrYToNCgkgICAoZm9yIGV4YW1wbGUgZG9jc0JwaTJDbUF1 dGhlbnRJbmZvcykNCgkgICAgICAgICAgICBERVNDUklQVElPTg0KCSAgICAgICAgICAgICAgICAg IlRoZSB2YWx1ZSBvZiB0aGlzIG9iamVjdCBpcyB0aGUgY291bnQgb2YgdGltZXMgdGhlIENNDQoJ ICAgICAgICAgICAgaGFzIHRyYW5zbWl0dGVkIGFuIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9u IG1lc3NhZ2UsDQoJICAgICAgICAgICAgc2luY2UgcmVib290LiINCgkgICBJdCBpcyBPSyB0byB0 ZWxsIHVzIHRoYXQgYSBaZXJvQmFzZWRDT3VudGVyMzIgb2JqZWN0IG11c3Qgc3RhcnQgd2l0aCB6 ZXJvDQoJICAgYXQgKHJlLSlib290IHRpbWUgb3IgYXQgcm93IGNyZWF0aW9uLg0KCSAgIEJ1dCBm cm9tIHRoYXQgcG9pbnQgb24sIGEgWmVyb0Jhc2VkQ291bnRlcjMyIGJlaGF2ZXMgZXhhY3RseSB0 aGUgc2FtZQ0KCSAgIGFzIGEgQ291bnRlcjMyLCBhbmQgc28gaXQgaXMgaW5jb3JyZWN0IHRvIHNh eSAiY291bnQgb2YgWCBzaW5jZSByZWJvb3QiDQoJICAgYmVjYXVzZSB0aGUgQ291bnRlcjMyIG1h eSBoYXZlIHdyYXBwZWQhLiBQb3NzaWJseSB0aGlzIGlzIG5vdCBnb25uYQ0KCSAgIGhhcHBlbiBp biBwcmFjdGljZSwgYnV0IGxpdGVyYWxseSB0aGUgY2xhaW0gaXMgaW5jb3JyZWN0Lg0KCQ0KCTMu IEZvciB0aGVzZSBaZXJvQmFzZWRDb3VudGVyMzIgb2JqZWN0cywgSSBhbHNvIHNlZSBubyB3b3Jk IGFib3V0IGEgcG9zc2libGUNCgkgICBkaXNjb250aW51aXR5IHRpbWVyLiBXaHkgbm90LiBDYW4g dGhlcmUgTkVWRVIgYmUgYSBkaXNjb250aW51aXR5PyBPZiBpZg0KCSAgIHRoZXJlIGlzIG9uZSBk b2VzIHRoYXQgbWVhbiBBTEwgY291bnRlcnMgZXhwZXJpZW5jZSBhIGRpc2NvbnRpb251aXR5Pw0K CSAgIFRoZSBsYXR0ZXIgaXMgd2hhdCB5b3UgYmFzaWNhbGx5IHN0YXRlIChvciBjYXVzZSkgYnkg bm90IHBvaW50aW5nIHRvIGENCgkgICBzcGVjaWZpYyBkaXNjb250aW51aXR5IHRpbWVyLiBCZWNh dXNlIHRoZW4gYnkgZGVmYXVsdCBpdCBpcyBzeXNVcFRpbWUsIGFuZA0KCSAgIHNvIHRoYXQgbWVh bnMgdGhhdCB3aGVuIHlvdSBETyBleHBlcmllbmNlIGEgZGlzY29udGludWl0eSwgdGhlbiB5b3Ug TVVTVA0KCSAgIHJlc2V0IHN5c1VwVGltZSBhbmQgdGhhdCBtZWFucyB0aGF0IGEgZGlzY29udGlu dWl0eSBmb3IgRVZFUllPTkUgKG9iamVjdCkNCgkgICB0aGF0IGFzc3VtZXMgdGhlIGRlZmF1bHQu IElmIHN1Y2ggaXMgaW50ZW5kZWQsIHRoZW4gZmluZSwgYnV0IGl0IHdvdWxkIGJlDQoJICAgZ29v ZCB0byB0aGVuIHN0YXRlIHRoYXQgc3lzVXBUaW1lIGlzIHRoZSBkaXNjb250aW51aXR5IHRpbWVy Lg0KCQ0KCTQuIEkgc2VlIHRoYXQgZm9yIHNvbWUgb2JqZWN0cyB5b3Ugc3BlYWsgYWJvdXQgYSAi bnVsbCBzdHJpbmciIG9yICJOVUxMIHN0cmluZyIuDQoJICAgVGhlIGJhc2UgZGF0YSB0eXBlIGZv ciBzdWNoIG9iamVjdHMgaXMgT0NURVQgU1RSSU5HLiBJbiBhbGwgdGhvc2UgY2FzZXMNCgkgICBJ IHN1c3BlY3QgKGJ1dCBJIGFtIG5vdCBzdXJlKSB0aGF0IHlvdSBtZWFuIHRoZSB6ZXJvLWxlbmd0 aCBvY3RldCBzdHJpbmcuDQoJICAgT3RoZXJ3aXNlIEkgZG8gbm90IHVuZGVyc3RhbmQgd2hhdCAi bnVsbCBzdHJpbmciIG1lYW5zLg0KCSAgIFBscyBleHBsYWluIGFuZCBmaXguDQoJDQoJNS4gRm9y IGRvY3NCcGkyQ210c0F1dGhDbUV4cGlyZXNPbGQgSSBzZWU6DQoJICAgICAgICAgICAgTm90ZTog Rm9yIENNcyBydW5uaW5nIGluIEJQSSBtb2RlLCBpbXBsZW1lbnRhdGlvbiBvZiB0aGlzDQoJICAg ICAgICAgICAgb2JqZWN0IGlzIG9wdGlvbmFsIGFuZCBNQVkgdmFyeS4iDQoJICAgTW1tLi4uIHRo YXQgc291bmRzIGxpa2UgYSBNT0RVTEUtQ09NUExJQU5DRSBhc3BlY3QgYW5kIEkgd291bGQgcmF0 aGVyDQoJICAgc2VlIHN1Y2ggdGhpbmdzIGluIE1PRFVMRS1DT01QTElBTkNFIGFuZCBub3QgaW4g b2JqZWN0IERFU0NSSVBUSU9OIGNsYXVzZXMuDQoJDQoJNi4gSSBzZWU6DQoJICAgICAgLS0gTm90 ZTogdGhlIGZvbGxvd2luZyBvYmplY3QgaGFzIGJlZW4gb2Jzb2xldGVkDQoJDQoJICAgICAgZG9j c0JwaTJDbXRzQXV0aENtUmVzZXQgIE9CSkVDVC1UWVBFDQoJICAgICAgICAgICBTWU5UQVggICAg SU5URUdFUiAgIHsNCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9SZXNldFJlcXVl c3RlZCgxKSwNCgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW52YWxpZGF0ZUF1dGgo MiksDQoJICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNlbmRBdXRoSW52YWxpZCgzKSwN CgkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgaW52YWxpZGF0ZVRla3MoNCkNCgkgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KCSAgICAgICAgICAgTUFYLUFDQ0VTUyAgICAg cmVhZC13cml0ZQ0KCSAgICAgICAgICAgU1RBVFVTICAgICAgICAgY3VycmVudA0KCQ0KCSAgICBT byB0aGUgLS1Ob3RlOiBpcyBvdXQgb2Ygc3luYyB3aXRoIHRoZSBhY3R1YWwgc3RhdHVzIT8NCgkg ICAgV2hhdCBpcyBpdD8gSWYgaXQgSVMgb2Jzb2xldGVkLCB0aGVuIHN0YXR1cyBzaG91bGQgc3lh IHNvLA0KCSAgICBBbmQgREVTQ1JJUFRJT04gY2xhdXNlIHNob3VsZCBleHBsYWluIHdoeSBpdCB3 YXMgb2Jzb2xldGVkLg0KCSAgICBBbmQgdGhlIEFTTi4xIGNvbW1lbnQgbGluZSB0aGVuIG9mIGNv dXJzZSBpcyBubyBsb25nZXIgbmVlZGVkLg0KCQ0KCTcuIEkgc2VlOg0KCSAgICAgIGRvY3NCcGky Q210c0F1dGhDQUNlcnRJbmRleFB0ciAgICBPQkpFQ1QtVFlQRQ0KCSAgICAgICAgICAgIFNZTlRB WCAgICAgICAgIEludGVnZXIzMiAoMC4uMTAwMDApDQoJICAgQW5kIGZpbmQgdGhhdCBhIHN0cmFu Z2UgbGltaXQgKHJhbmdlKS4gQW5kIG5vd2hlcmUsIG5vdCBldmVuIGluIHRoZQ0KCSAgIGRvY3NC cGkyQ210c0NBQ2VydFRhYmxlIGRvIEkgc2VlIGFuIGV4cGxhbmF0aW9uIHdoeSB0aGF0IHJhbmdl IG1ha2VzDQoJICAgc2Vuc2UgKGFzc3VtaW5nIHRoYXQgaXQgZG9lcykuDQoJDQoJOC4gV2hlbiBJ IHNlZToNCgkgICAgICAgICAgICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdEFkZHJlc3NUeXBlICAg ICAgSW5ldEFkZHJlc3NUeXBlLA0KCSAgICAgICAgICAgIGRvY3NCcGkyQ210c0lwTXVsdGljYXN0 QWRkcmVzcyAgICAgICAgICBJbmV0QWRkcmVzcywNCgkgICAgICAgICAgICBkb2NzQnBpMkNtdHNJ cE11bHRpY2FzdE1hc2tUeXBlICAgICAgICAgSW5ldEFkZHJlc3NUeXBlLA0KCSAgICAgICAgICAg IGRvY3NCcGkyQ210c0lwTXVsdGljYXN0TWFzayAgICAgICAgICAgICBJbmV0QWRkcmVzcywNCgkg ICBJIHdvbmRlciBpZiAoaW4gdGhlIHNhbWUgcm93KSBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdE1h c2tUeXBlIHdpbGwgZXZlcg0KCSAgIGhhdmUgYSBkaWZmZXJlbnQgdmFsdWUgdGhlbiBkb2NzQnBp MkNtdHNJcE11bHRpY2FzdEFkZHJlc3NUeXBlICE/Pw0KCSAgIEl0IHNlZW1zIHRvIG1lIHRoYXQg c2hvdWxkIE5PVCBiZSBhbGxvd2VkLCBjYXVzZSBvdGhlcndpc2UgSSBhbSBub3QNCgkgICBzdXJl IGhvdyB0aGUgQU5EaW5nIG9mIHRoZSBNYXNrIGlzIGdvaW5nIHRvIHdvcmsvaGFwcGVuLg0KCSAg IFNvIHRoZSBuZXh0IHF1ZXN0aW9uIHRoZW4gaXMgd2h5IHlvdSBkbyBub3QgZG86DQoJICAgICAg ICAgICAgZG9jc0JwaTJDbXRzSXBNdWx0aWNhc3RBZGRyZXNzVHlwZSAgICAgIEluZXRBZGRyZXNz VHlwZSwNCgkgICAgICAgICAgICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdEFkZHJlc3MgICAgICAg ICAgSW5ldEFkZHJlc3MsDQoJICAgICAgICAgICAgZG9jc0JwaTJDbXRzSXBNdWx0aWNhc3RNYXNr ICAgICAgICAgICAgIEluZXRBZGRyZXNzLA0KCSAgIEFuZCBsZXQgZG9jc0JwaTJDbXRzSXBNdWx0 aWNhc3RBZGRyZXNzVHlwZSBiZSB0aGUgZGlzY3JpbWluYXRvciBmb3IgYm90aA0KCSAgIEluZXRB ZGRyZXNzZXMuIE9uZSBsZXNzIG9iamVjdCwgYW5kIGxlc3MgY2hhbmdlIGZvciBlcnJvci9jb25m bGljdC4NCgkNCgkgICBCdXQgdGhpbmtpbmcgZXZlbiBmdXJ0aGVyLCBQb3NzaWJseSB0aGUgYmVz dCB0aGluZyB0byBkbyBpcyB0byB1c2UNCgkgICAgICAgICAgICBkb2NzQnBpMkNtdHNJcE11bHRp Y2FzdEFkZHJlc3NUeXBlICAgICAgSW5ldEFkZHJlc3NUeXBlLA0KCSAgICAgICAgICAgIGRvY3NC cGkyQ210c0lwTXVsdGljYXN0QWRkcmVzcyAgICAgICAgICBJbmV0QWRkcmVzcywNCgkgICAgICAg ICAgICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdFByZWZpeExlbmd0aCAgICAgSW5ldEFkZHJlc3NQ cmVmaXhMZW5ndGgsDQoJICAgQXJlIG5vdCBzdWNoIG1hc2tzIGFsd2F5cyBzZXR1cCB0aGF0IHRo ZXkgYmFzaWNhbGx5IHNwZWNpZnkgYSBwcmVmaXggbGVuZ3RoPw0KCSAgIElmIHNvLCB0aGVuIHRo aXMgaXMgdGhlIHdheSB0byBkbyBpdCB3aXRoIHRoZSBUQ3MgZnJvbSBJTkVULUFERFJFU1MtTUlC Lg0KCQ0KCTkuIEkgc2VlIHZhcmlvdXMgdXNlcyBvZiBJbmV0QWRkcmVzcyBhcyBmb3IgZXhhbXBs ZSBoZXJlOg0KCSAgICAgICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdEFkZHJlc3MgICAgICAgICAg T0JKRUNULVRZUEUNCgkgICAgICAgICAgICBTWU5UQVggICAgICAgICBJbmV0QWRkcmVzcw0KCSAg ICAgICAgICAgIE1BWC1BQ0NFU1MgICAgIHJlYWQtY3JlYXRlDQoJICAgICAgICAgICAgU1RBVFVT ICAgICAgICAgY3VycmVudA0KCSAgICAgICAgICAgIERFU0NSSVBUSU9ODQoJICAgICAgICAgICAg ICAgICAiVGhpcyBvYmplY3QgcmVwcmVzZW50cyB0aGUgSVAgbXVsdGljYXN0IGFkZHJlc3MNCgkg ICAgICAgICAgICB0byBiZSBtYXBwZWQsIGluIGNvbmp1bmN0aW9uIHdpdGgNCgkgICAgICAgICAg ICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdE1hc2suIg0KCSAgIFRoZSBUQyBmb3IgSW5ldEFkZHJl c3MgKGluIFJGQzMyOTEgb3IgaXRzIGZvbGxvdyBvbikgY2xlYXJseSBzdGF0ZSB0aGF0DQoJICAg eW91IE1VU1Qgc3BlY2lmeSB3aGljaCBJbmV0QWRkcmVzc1R5cGUgY29udHJvbHMgdGhlIGZvcm1h dCBvZiB0aGlzIG9iamVjdA0KCSAgIGFzIHBlciBERVNDUklQVElPTiBmcm9tIEluZXRBZGRyZXNz IFRDOg0KCSAgICAgICAgIEFuIEluZXRBZGRyZXNzIHZhbHVlIGlzIGFsd2F5cyBpbnRlcnByZXRl ZCB3aXRoaW4gdGhlIGNvbnRleHQNCgkgICAgICAgICBvZiBhbiBJbmV0QWRkcmVzc1R5cGUgdmFs dWUuIEV2ZXJ5IHVzYWdlIG9mIHRoZSBJbmV0QWRkcmVzcw0KCSAgICAgICAgIHRleHR1YWwgY29u dmVudGlvbiBpcyByZXF1aXJlZCB0byBzcGVjaWZ5IHRoZSBJbmV0QWRkcmVzc1R5cGUNCgkgICAg ICAgICBvYmplY3Qgd2hpY2ggcHJvdmlkZXMgdGhlIGNvbnRleHQuIC4uLg0KCQ0KCTEwLiBJIHNl ZToNCgkgICAgICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdE1hcENvbnRyb2wgIE9CSkVDVC1UWVBF DQoJICAgICAgICAgICBTWU5UQVggICAgICAgICBSb3dTdGF0dXMNCgkgICAgICAgICAgIE1BWC1B Q0NFU1MgICAgIHJlYWQtY3JlYXRlDQoJICAgICAgICAgICBTVEFUVVMgICAgICAgICBjdXJyZW50 DQoJICAgICAgICAgICBERVNDUklQVElPTg0KCSAgICAgICAgICAgICAgICAiVGhpcyBvYmplY3Qg Y29udHJvbHMgYW5kIHJlZmxlY3RzIHRoZSBJUCBtdWx0aWNhc3QNCgkgICAgICAgICAgIGFkZHJl c3MgbWFwcGluZyBlbnRyeS4gIFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uIG9uIHRoZQ0KCSAgICAg ICAgICAgYWJpbGl0eSB0byBjaGFuZ2UgdmFsdWVzIGluIHRoaXMgcm93IHdoaWxlIHRoZSByb3cg aXMNCgkgICAgICAgICAgIGFjdGl2ZS4gIEluYWN0aXZlIHJvd3MgbmVlZCBub3QgYmUgdGltZWQg b3V0LiINCgkgICAgTW1tLi4uIHRoYXQgIm5lZWQgbm90IGJlIHRpbWVkIG91dCIgc2VlbXMgaW4g Y29uZmxpY3Qgd2l0aCB0aGUgUm93U3RhdHVzDQoJICAgIFRDIERFU0NSSVBUSU9OIGNsYXVzZSBp biBSRkMyNTc5LiBDYW4geW91IGV4cGxhaW4gd2h5IHRoaXMgaXM/DQoJDQoJICAgIEFsc28sIGEg Um93U1RhdHVzIG9iamVjdCBNVVNUIHNwZWNpZnkgaW4gaXRzIERFU0NSSVBUSU9OIGNsYXVzZSB1 bmRlcg0KCSAgICB3aGljaCBjb25kaXRpb25zDQoJICAgIC0gdGhlIHJvdyBjYW4gYmUgYWN0aXZh dGVkDQoJICAgIC0gd2hpY2ggY29sdW1ucyAoaWYgYW55KSBjYW4gYnZlIGNoYW5nZWQgd2hpbGUg aW4gdGhlIGFjdGl2ZSBzdGF0ZS4NCgkgICAgSSBhbSBtaXNzaW5nIHRoZSBmaXJzdC4NCgkNCgkx MS4gWW91IHNwZWNpZnk6DQoJICAgICAgIC0tDQoJICAgICAgIC0tIFRoZSBCUEkrIE1JQiBDb25m b3JtYW5jZSBTdGF0ZW1lbnRzICh3aXRoIGEgcGxhY2Vob2xkZXIgZm9yDQoJICAgICAgIC0tIG5v dGlmaWNhdGlvbnMpDQoJICAgICAgIC0tDQoJDQoJICAgICAgIGRvY3NCcGkyTm90aWZpY2F0aW9u ICAgICBPQkpFQ1QgSURFTlRJRklFUg0KCSAgICAgICAgICAgIDo6PSB7IGRvY3NCcGkyTUlCIDIg fQ0KCSAgICAgICBkb2NzQnBpMkNvbmZvcm1hbmNlIE9CSkVDVCBJREVOVElGSUVSDQoJICAgICAg ICAgICAgOjo9IHsgZG9jc0JwaTJNSUIgMyB9DQoJICAgICAgIGRvY3NCcGkyQ29tcGxpYW5jZXMg T0JKRUNUIElERU5USUZJRVINCgkgICAgICAgICAgICA6Oj0geyBkb2NzQnBpMkNvbmZvcm1hbmNl IDEgfQ0KCSAgICAgICBkb2NzQnBpMkdyb3VwcyAgICAgIE9CSkVDVCBJREVOVElGSUVSDQoJICAg ICAgICAgICAgOjo9IHsgZG9jc0JwaTJDb25mb3JtYW5jZSAyIH0NCgkNCgkgICBXaHkgbm90IGJl IChtb3JlKSBjb25zaXN0ZW50IHdpdGggb3RoZXIgTUlCIG1vZHVsZXMgYW5kIGZvbGxvdyB0aGUN CgkgICBzdWdnZXN0ZWQgT0lEIHN1YnRyZWVzIGFzIHBlciBNSUIgZ3VpZGVsaW5lcywNCgkgICBk cmFmdC1pZXRmLW9wcy1taWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0LCBhcHBlbmRpeCBEOg0K CSAgICAgICAgeHh4TUlCDQoJICAgICAgICB8DQoJICAgICAgICArLS0geHh4Tm90aWZpY2F0aW9u cygwKQ0KCSAgICAgICAgKy0tIHh4eE9iamVjdHMoMSkNCgkgICAgICAgICstLSB4eHhDb25mb3Jt YW5jZSgyKQ0KCSAgICAgICAgICAgIHwNCgkgICAgICAgICAgICArLS0geHh4Q29tcGxpYW5jZXMo MSkNCgkgICAgICAgICAgICArLS0geHh4R3JvdXBzKDIpDQoJICAgVGhpcyBpcyBub3QgbWFuZGF0 aW9yeSwgYnV0IGNvbnNpc3RlbmN5IGlzIGFsd2F5cyB1c2VmdWwvaGVscGZ1bA0KCQ0KCQ0KCU5p dHMvYWRtaW5pc3RyYXRpdmlhOg0KCQ0KCTEuIFRoZSBSRkMgZWRpdG9yIHdhbnRzIGFsbCByZWZl cmVuY2VzIHRvIGhhdmUgYXQgbGVhc3Qgb25lIGNpdGF0aW9uDQoJICAgaW4gdGhlIGRvY3VtZW50 LiBBTHNvIGZvciB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gUkZDcyBmcm9tDQoJICAgd2hp Y2ggeW91IGltcG9ydC4gU2VlIE1JQiByZXZpZXcgZ3VpZGVsaW5lcywgc2VjdCAzLjUNCgkNCgkg ICBZb3UgbmVlZCB0byBhZGQgYSBjaXRhdGlvbiBzb21laHdlcmUgZm9yIFtSRkMzNDExXSwgW1JG QzIwMjFdLA0KCSAgIFtSRkMzMjkxXSwgW1JGQzI2NzBdDQoJDQoJVGhhbmtzLA0KCUJlcnQNCgkN CglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCUlQQ0RO IG1haWxpbmcgbGlzdA0KCUlQQ0ROQGlldGYub3JnDQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBjZG4NCgkNCgkNCg0K ------_=_NextPart_001_01C469CA.886DCC56 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5baXBjZG5dIEFEIHJldmll dyBvZjogZHJhZnQtaWV0Zi1pcGNkbi1icGlwbHVzLW1pYi0xMi50eHQgLSBwYXJ0IDE8L1RJVExF Pgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+VGhhbmtzIEJlcnQgZm9yIHRoZSBkZXRhaWwg cmV2aXNpb24uPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SSB3aWxsIHJldmlldyBhbmQg cHJvcG9zZSB0aGUgY29ycmVzcG9uZGluZyBhY3Rpb25zIHNob3J0bHk8L0RJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj5UaGFua3M8L0RJVj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj5FZHVhcmRv PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9E SVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxCTE9DS1FVT1RFIGRpcj1sdHIgc3R5bGU9Ik1BUkdJTi1S SUdIVDogMHB4Ij4KICA8RElWPjxGT05UIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSA8QlI+PEI+RnJvbTo8L0I+IFdpam5lbiwgQmVydCAKICAoQmVydCkgW21haWx0bzpid2lqbmVu QGx1Y2VudC5jb21dIDxCUj48Qj5TZW50OjwvQj4gV2VkIDcvMTQvMjAwNCAxMDowMyBBTSAKICA8 QlI+PEI+VG86PC9CPiBJcGNkbiAoRS1tYWlsKSA8QlI+PEI+Q2M6PC9CPiA8QlI+PEI+U3ViamVj dDo8L0I+IFtpcGNkbl0gQUQgCiAgcmV2aWV3IG9mOiBkcmFmdC1pZXRmLWlwY2RuLWJwaXBsdXMt bWliLTEyLnR4dCAtIHBhcnQgMTxCUj48QlI+PC9GT05UPjwvRElWPgogIDxQPjxGT05UIHNpemU9 Mj5Tb3JyeSwgaXQgdG9vayB0b28gbG9uZyZuYnNwOyB0byBmaW5hbGx5IGdldCB0aGlzIAogIGRv bmUuPEJSPjxCUj5Ob3Qgc3VyZSB0aGlzIGRvY3VtZW50IGlzIHJlYWR5IGZvciBJRVRGIExhc3Qg Q2FsbC48QlI+QWN0YXVsbHkgSSAKICB0aGluayBpdCBpcyBub3QuPEJSPjxCUj5UaGlzIGlzIHBh cnQgMS4gTWFpbmx5IHNlcmlvdXMgdGhpbmdzLjxCUj5JIG1heSBoYXZlIAogIG1vcmUgbml0cy9h ZG1pbiBzdHVmZiBsYXRlci48QlI+PEJSPkhlcmUgYXJlIG15IGZpbmRpbmdzLjxCUj48QlI+TW9y ZSBvciBsZXNzIAogIHNlcmlvdXM6PEJSPjEuIEkgc2VlIHZhcmlvdXMgcmVhZC13cml0ZSBhbmQv b3IgcmVhZC1jcmVhdGUgb2JqZWN0cyBhbmQgSSAKICBkbzxCUj4mbmJzcDsmbmJzcDsgbm90IHNl ZSBhbnkgdGV4dCBpbiB0aGUgREVTQ1JJUFRJT04gY2xhdXNlcyAobm9uIAogIFNUb3JhZ2VUeXBl IG9iamVjdHMpPEJSPiZuYnNwOyZuYnNwOyB0aGF0IHRlbGwgbWUgd2hhdCB0aGUgZXhwZWN0ZWQg YmVoYXZpb3VyIAogIGlzIHcuci50LiBwZXJzaXN0ZW5jeSBvZiBzdWNoPEJSPiZuYnNwOyZuYnNw OyBvYmplY3RzLiBTTyB3aGF0IGhhcHBlbnMgYWZ0ZXIgYSAKICByZXN0YXJ0L3JlYm9vdD88QlI+ PEJSPjIuIEkgc2VlIGEgbnVtYmVyIG9mIFplcm9CYXNlZENPdW50ZXIzMiBvYmplY3RzIHRoYXQg CiAgaGF2ZSB0ZXh0IGFrYTo8QlI+Jm5ic3A7Jm5ic3A7IChmb3IgZXhhbXBsZSAKICBkb2NzQnBp MkNtQXV0aGVudEluZm9zKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgREVTQ1JJUFRJT048QlI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogICJUaGUgdmFsdWUgb2YgdGhpcyBvYmpl Y3QgaXMgdGhlIGNvdW50IG9mIHRpbWVzIHRoZSAKICBDTTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaGFzIAogIHRy YW5zbWl0dGVkIGFuIEF1dGhlbnRpY2F0aW9uIEluZm9ybWF0aW9uIAogIG1lc3NhZ2UsPEJSPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKICBzaW5jZSByZWJvb3QuIjxCUj4mbmJzcDsmbmJzcDsgSXQgaXMgT0sgdG8gdGVs bCB1cyB0aGF0IGEgWmVyb0Jhc2VkQ091bnRlcjMyIAogIG9iamVjdCBtdXN0IHN0YXJ0IHdpdGgg emVybzxCUj4mbmJzcDsmbmJzcDsgYXQgKHJlLSlib290IHRpbWUgb3IgYXQgcm93IAogIGNyZWF0 aW9uLjxCUj4mbmJzcDsmbmJzcDsgQnV0IGZyb20gdGhhdCBwb2ludCBvbiwgYSBaZXJvQmFzZWRD b3VudGVyMzIgYmVoYXZlcyAKICBleGFjdGx5IHRoZSBzYW1lPEJSPiZuYnNwOyZuYnNwOyBhcyBh IENvdW50ZXIzMiwgYW5kIHNvIGl0IGlzIGluY29ycmVjdCB0byBzYXkgCiAgImNvdW50IG9mIFgg c2luY2UgcmVib290IjxCUj4mbmJzcDsmbmJzcDsgYmVjYXVzZSB0aGUgQ291bnRlcjMyIG1heSBo YXZlIAogIHdyYXBwZWQhLiBQb3NzaWJseSB0aGlzIGlzIG5vdCBnb25uYTxCUj4mbmJzcDsmbmJz cDsgaGFwcGVuIGluIHByYWN0aWNlLCBidXQgCiAgbGl0ZXJhbGx5IHRoZSBjbGFpbSBpcyBpbmNv cnJlY3QuPEJSPjxCUj4zLiBGb3IgdGhlc2UgWmVyb0Jhc2VkQ291bnRlcjMyIAogIG9iamVjdHMs IEkgYWxzbyBzZWUgbm8gd29yZCBhYm91dCBhIHBvc3NpYmxlPEJSPiZuYnNwOyZuYnNwOyBkaXNj b250aW51aXR5IAogIHRpbWVyLiBXaHkgbm90LiBDYW4gdGhlcmUgTkVWRVIgYmUgYSBkaXNjb250 aW51aXR5PyBPZiBpZjxCUj4mbmJzcDsmbmJzcDsgCiAgdGhlcmUgaXMgb25lIGRvZXMgdGhhdCBt ZWFuIEFMTCBjb3VudGVycyBleHBlcmllbmNlIGEgCiAgZGlzY29udGlvbnVpdHk/PEJSPiZuYnNw OyZuYnNwOyBUaGUgbGF0dGVyIGlzIHdoYXQgeW91IGJhc2ljYWxseSBzdGF0ZSAob3IgCiAgY2F1 c2UpIGJ5IG5vdCBwb2ludGluZyB0byBhPEJSPiZuYnNwOyZuYnNwOyBzcGVjaWZpYyBkaXNjb250 aW51aXR5IHRpbWVyLiAKICBCZWNhdXNlIHRoZW4gYnkgZGVmYXVsdCBpdCBpcyBzeXNVcFRpbWUs IGFuZDxCUj4mbmJzcDsmbmJzcDsgc28gdGhhdCBtZWFucyAKICB0aGF0IHdoZW4geW91IERPIGV4 cGVyaWVuY2UgYSBkaXNjb250aW51aXR5LCB0aGVuIHlvdSBNVVNUPEJSPiZuYnNwOyZuYnNwOyAK ICByZXNldCBzeXNVcFRpbWUgYW5kIHRoYXQgbWVhbnMgdGhhdCBhIGRpc2NvbnRpbnVpdHkgZm9y IEVWRVJZT05FIAogIChvYmplY3QpPEJSPiZuYnNwOyZuYnNwOyB0aGF0IGFzc3VtZXMgdGhlIGRl ZmF1bHQuIElmIHN1Y2ggaXMgaW50ZW5kZWQsIHRoZW4gCiAgZmluZSwgYnV0IGl0IHdvdWxkIGJl PEJSPiZuYnNwOyZuYnNwOyBnb29kIHRvIHRoZW4gc3RhdGUgdGhhdCBzeXNVcFRpbWUgaXMgdGhl IAogIGRpc2NvbnRpbnVpdHkgdGltZXIuPEJSPjxCUj40LiBJIHNlZSB0aGF0IGZvciBzb21lIG9i amVjdHMgeW91IHNwZWFrIGFib3V0IGEgCiAgIm51bGwgc3RyaW5nIiBvciAiTlVMTCBzdHJpbmci LjxCUj4mbmJzcDsmbmJzcDsgVGhlIGJhc2UgZGF0YSB0eXBlIGZvciBzdWNoIAogIG9iamVjdHMg aXMgT0NURVQgU1RSSU5HLiBJbiBhbGwgdGhvc2UgY2FzZXM8QlI+Jm5ic3A7Jm5ic3A7IEkgc3Vz cGVjdCAoYnV0IEkgCiAgYW0gbm90IHN1cmUpIHRoYXQgeW91IG1lYW4gdGhlIHplcm8tbGVuZ3Ro IG9jdGV0IHN0cmluZy48QlI+Jm5ic3A7Jm5ic3A7IAogIE90aGVyd2lzZSBJIGRvIG5vdCB1bmRl cnN0YW5kIHdoYXQgIm51bGwgc3RyaW5nIiBtZWFucy48QlI+Jm5ic3A7Jm5ic3A7IFBscyAKICBl eHBsYWluIGFuZCBmaXguPEJSPjxCUj41LiBGb3IgZG9jc0JwaTJDbXRzQXV0aENtRXhwaXJlc09s ZCBJIAogIHNlZTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIE5vdGU6IEZvciBDTXMgcnVubmluZyBpbiBCUEkg bW9kZSwgaW1wbGVtZW50YXRpb24gb2YgCiAgdGhpczxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgb2JqZWN0IGlz IG9wdGlvbmFsIGFuZCBNQVkgdmFyeS4iPEJSPiZuYnNwOyZuYnNwOyBNbW0uLi4gdGhhdCBzb3Vu ZHMgbGlrZSBhIAogIE1PRFVMRS1DT01QTElBTkNFIGFzcGVjdCBhbmQgSSB3b3VsZCByYXRoZXI8 QlI+Jm5ic3A7Jm5ic3A7IHNlZSBzdWNoIHRoaW5ncyBpbiAKICBNT0RVTEUtQ09NUExJQU5DRSBh bmQgbm90IGluIG9iamVjdCBERVNDUklQVElPTiBjbGF1c2VzLjxCUj48QlI+Ni4gSSAKICBzZWU6 PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBOb3RlOiB0aGUgZm9sbG93aW5n IG9iamVjdCBoYXMgYmVlbiAKICBvYnNvbGV0ZWQ8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBkb2NzQnBpMkNtdHNBdXRoQ21SZXNldCZuYnNwOyAKICBPQkpFQ1QtVFlQRTxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgCiAgU1lOVEFYJm5ic3A7Jm5ic3A7Jm5ic3A7IElOVEVHRVImbmJzcDsmbmJzcDsgCiAg ezxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgCiAgbm9SZXNldFJlcXVlc3RlZCgxKSw8QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGlu dmFsaWRhdGVBdXRoKDIpLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgc2VuZEF1dGhJbnZhbGlkKDMpLDxCUj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgCiAgaW52YWxpZGF0ZVRla3MoNCk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIH08QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAog IE1BWC1BQ0NFU1MmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgcmVhZC13cml0ZTxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg CiAgU1RBVFVTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IAogIGN1cnJlbnQ8QlI+PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyBTbyB0aGUgLS1Ob3RlOiBpcyBv dXQgb2Ygc3luYyB3aXRoIHRoZSAKICBhY3R1YWwgc3RhdHVzIT88QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IFdoYXQgaXMgaXQ/IElmIGl0IElTIG9ic29sZXRlZCwgdGhlbiAKICBzdGF0dXMgc2hvdWxk IHN5YSBzbyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuZCBERVNDUklQVElPTiBjbGF1c2Ugc2hv dWxkIAogIGV4cGxhaW4gd2h5IGl0IHdhcyBvYnNvbGV0ZWQuPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyBBbmQgdGhlIEFTTi4xIGNvbW1lbnQgbGluZSAKICB0aGVuIG9mIGNvdXJzZSBpcyBubyBsb25n ZXIgbmVlZGVkLjxCUj48QlI+Ny4gSSAKICBzZWU6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKICBkb2NzQnBpMkNtdHNBdXRoQ0FDZXJ0SW5kZXhQdHImbmJzcDsmbmJzcDsmbmJz cDsgCiAgT0JKRUNULVRZUEU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIFNZTlRBWCZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJbnRlZ2VyMzIgCiAgKDAuLjEwMDAwKTxC Uj4mbmJzcDsmbmJzcDsgQW5kIGZpbmQgdGhhdCBhIHN0cmFuZ2UgbGltaXQgKHJhbmdlKS4gQW5k IG5vd2hlcmUsIAogIG5vdCBldmVuIGluIHRoZTxCUj4mbmJzcDsmbmJzcDsgZG9jc0JwaTJDbXRz Q0FDZXJ0VGFibGUgZG8gSSBzZWUgYW4gCiAgZXhwbGFuYXRpb24gd2h5IHRoYXQgcmFuZ2UgbWFr ZXM8QlI+Jm5ic3A7Jm5ic3A7IHNlbnNlIChhc3N1bWluZyB0aGF0IGl0IAogIGRvZXMpLjxCUj48 QlI+OC4gV2hlbiBJIAogIHNlZTo8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NCcGkyQ210c0lwTXVsdGlj YXN0QWRkcmVzc1R5cGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgSW5ldEFkZHJl c3NUeXBlLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgZG9jc0JwaTJDbXRzSXBNdWx0aWNhc3RBZGRyZXNzJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIElu ZXRBZGRyZXNzLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgZG9jc0JwaTJDbXRzSXBNdWx0aWNhc3RNYXNrVHlw ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBJbmV0 QWRkcmVzc1R5cGUsPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdE1hc2sm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgCiAgSW5ldEFkZHJlc3MsPEJSPiZuYnNwOyZuYnNwOyBJIHdvbmRlciBp ZiAoaW4gdGhlIHNhbWUgcm93KSAKICBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdE1hc2tUeXBlIHdp bGwgZXZlcjxCUj4mbmJzcDsmbmJzcDsgaGF2ZSBhIGRpZmZlcmVudCAKICB2YWx1ZSB0aGVuIGRv Y3NCcGkyQ210c0lwTXVsdGljYXN0QWRkcmVzc1R5cGUgIT8/PEJSPiZuYnNwOyZuYnNwOyBJdCBz ZWVtcyB0byAKICBtZSB0aGF0IHNob3VsZCBOT1QgYmUgYWxsb3dlZCwgY2F1c2Ugb3RoZXJ3aXNl IEkgYW0gbm90PEJSPiZuYnNwOyZuYnNwOyBzdXJlIAogIGhvdyB0aGUgQU5EaW5nIG9mIHRoZSBN YXNrIGlzIGdvaW5nIHRvIHdvcmsvaGFwcGVuLjxCUj4mbmJzcDsmbmJzcDsgU28gdGhlIAogIG5l eHQgcXVlc3Rpb24gdGhlbiBpcyB3aHkgeW91IGRvIG5vdCAKICBkbzo8QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAog IGRvY3NCcGkyQ210c0lwTXVsdGljYXN0QWRkcmVzc1R5cGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgCiAgSW5ldEFkZHJlc3NUeXBlLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgZG9jc0JwaTJDbXRz SXBNdWx0aWNhc3RBZGRyZXNzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IAogIEluZXRBZGRyZXNzLDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgZG9jc0JwaTJD bXRzSXBNdWx0aWNhc3RNYXNrJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIEluZXRBZGRyZXNzLDxCUj4mbmJz cDsmbmJzcDsgQW5kIGxldCBkb2NzQnBpMkNtdHNJcE11bHRpY2FzdEFkZHJlc3NUeXBlIGJlIHRo ZSAKICBkaXNjcmltaW5hdG9yIGZvciBib3RoPEJSPiZuYnNwOyZuYnNwOyBJbmV0QWRkcmVzc2Vz LiBPbmUgbGVzcyBvYmplY3QsIGFuZCAKICBsZXNzIGNoYW5nZSBmb3IgZXJyb3IvY29uZmxpY3Qu PEJSPjxCUj4mbmJzcDsmbmJzcDsgQnV0IHRoaW5raW5nIGV2ZW4gZnVydGhlciwgCiAgUG9zc2li bHkgdGhlIGJlc3QgdGhpbmcgdG8gZG8gaXMgdG8gCiAgdXNlPEJSPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBkb2Nz QnBpMkNtdHNJcE11bHRpY2FzdEFkZHJlc3NUeXBlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IAogIEluZXRBZGRyZXNzVHlwZSw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NCcGkyQ210c0lwTXVs dGljYXN0QWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAKICBJbmV0QWRkcmVzcyw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NCcGkyQ210c0lw TXVsdGljYXN0UHJlZml4TGVuZ3RoJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIEluZXRBZGRy ZXNzUHJlZml4TGVuZ3RoLDxCUj4mbmJzcDsmbmJzcDsgQXJlIG5vdCBzdWNoIG1hc2tzIGFsd2F5 cyBzZXR1cCB0aGF0IAogIHRoZXkgYmFzaWNhbGx5IHNwZWNpZnkgYSBwcmVmaXggbGVuZ3RoPzxC Uj4mbmJzcDsmbmJzcDsgSWYgc28sIHRoZW4gdGhpcyBpcyAKICB0aGUgd2F5IHRvIGRvIGl0IHdp dGggdGhlIFRDcyBmcm9tIElORVQtQUREUkVTUy1NSUIuPEJSPjxCUj45LiBJIHNlZSB2YXJpb3Vz IAogIHVzZXMgb2YgSW5ldEFkZHJlc3MgYXMgZm9yIGV4YW1wbGUgCiAgaGVyZTo8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NCcGkyQ210c0lwTXVsdGljYXN0 QWRkcmVzcyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICBPQkpFQ1QtVFlQRTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgU1lOVEFYJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIEluZXRBZGRyZXNzPEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAKICBNQVgtQUNDRVNTJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIHJlYWQtY3JlYXRl PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAKICBTVEFUVVMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgCiAgY3VycmVudDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgREVTQ1JJUFRJT048QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogICJUaGlzIG9iamVjdCBy ZXByZXNlbnRzIHRoZSBJUCBtdWx0aWNhc3QgCiAgYWRkcmVzczxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgdG8g YmUgbWFwcGVkLCBpbiBjb25qdW5jdGlvbiAKICB3aXRoPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBkb2NzQnBp MkNtdHNJcE11bHRpY2FzdE1hc2suIjxCUj4mbmJzcDsmbmJzcDsgVGhlIFRDIGZvciBJbmV0QWRk cmVzcyAoaW4gCiAgUkZDMzI5MSBvciBpdHMgZm9sbG93IG9uKSBjbGVhcmx5IHN0YXRlIHRoYXQ8 QlI+Jm5ic3A7Jm5ic3A7IHlvdSBNVVNUIHNwZWNpZnkgCiAgd2hpY2ggSW5ldEFkZHJlc3NUeXBl IGNvbnRyb2xzIHRoZSBmb3JtYXQgb2YgdGhpcyBvYmplY3Q8QlI+Jm5ic3A7Jm5ic3A7IGFzIAog IHBlciBERVNDUklQVElPTiBmcm9tIEluZXRBZGRyZXNzIAogIFRDOjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQW4gSW5ldEFkZHJlc3MgdmFsdWUg CiAgaXMgYWx3YXlzIGludGVycHJldGVkIHdpdGhpbiB0aGUgCiAgY29udGV4dDxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2YgYW4gCiAgSW5ldEFk ZHJlc3NUeXBlIHZhbHVlLiBFdmVyeSB1c2FnZSBvZiB0aGUgCiAgSW5ldEFkZHJlc3M8QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRleHR1YWwgCiAg Y29udmVudGlvbiBpcyByZXF1aXJlZCB0byBzcGVjaWZ5IHRoZSAKICBJbmV0QWRkcmVzc1R5cGU8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9iamVj dCAKICB3aGljaCBwcm92aWRlcyB0aGUgY29udGV4dC4gLi4uPEJSPjxCUj4xMC4gSSAKICBzZWU6 PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkb2NzQnBpMkNtdHNJcE11bHRpY2Fz dE1hcENvbnRyb2wmbmJzcDsgCiAgT0JKRUNULVRZUEU8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIFNZTlRBWCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBSb3dTdGF0dXM8QlI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IAogIE1BWC1BQ0NFU1MmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgcmVhZC1jcmVhdGU8 QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IAogIFNUQVRVUyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKICBjdXJyZW50PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBERVNDUklQVElPTjxCUj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgIlRoaXMgb2JqZWN0IGNvbnRyb2xzIGFuZCByZWZsZWN0 cyB0aGUgSVAgCiAgbXVsdGljYXN0PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICBhZGRyZXNzIG1hcHBpbmcgZW50cnkuJm5i c3A7IFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uIG9uIAogIHRoZTxCUj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWJpbGl0eSB0byAK ICBjaGFuZ2UgdmFsdWVzIGluIHRoaXMgcm93IHdoaWxlIHRoZSByb3cgCiAgaXM8QlI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAog IGFjdGl2ZS4mbmJzcDsgSW5hY3RpdmUgcm93cyBuZWVkIG5vdCBiZSB0aW1lZCBvdXQuIjxCUj4m bmJzcDsmbmJzcDsmbmJzcDsgCiAgTW1tLi4uIHRoYXQgIm5lZWQgbm90IGJlIHRpbWVkIG91dCIg c2VlbXMgaW4gY29uZmxpY3Qgd2l0aCB0aGUgCiAgUm93U3RhdHVzPEJSPiZuYnNwOyZuYnNwOyZu YnNwOyBUQyBERVNDUklQVElPTiBjbGF1c2UgaW4gUkZDMjU3OS4gQ2FuIHlvdSAKICBleHBsYWlu IHdoeSB0aGlzIGlzPzxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsc28sIGEgUm93U1RhdHVz IG9iamVjdCBNVVNUIAogIHNwZWNpZnkgaW4gaXRzIERFU0NSSVBUSU9OIGNsYXVzZSB1bmRlcjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsgd2hpY2ggCiAgY29uZGl0aW9uczxCUj4mbmJzcDsmbmJzcDsm bmJzcDsgLSB0aGUgcm93IGNhbiBiZSAKICBhY3RpdmF0ZWQ8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IC0gd2hpY2ggY29sdW1ucyAoaWYgYW55KSBjYW4gYnZlIGNoYW5nZWQgd2hpbGUgCiAgaW4gdGhl IGFjdGl2ZSBzdGF0ZS48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgYW0gbWlzc2luZyB0aGUgZmly c3QuPEJSPjxCUj4xMS4gCiAgWW91IHNwZWNpZnk6PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAKICAtLTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgLS0gVGhlIEJQSSsgTUlCIENvbmZvcm1hbmNlIAogIFN0YXRlbWVudHMgKHdpdGggYSBwbGFj ZWhvbGRlciBmb3I8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIAog IG5vdGlmaWNhdGlvbnMpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAK ICAtLTxCUj48QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NC cGkyTm90aWZpY2F0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9CSkVDVCAKICBJREVOVElG SUVSPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAKICA6Oj0geyBkb2NzQnBpMk1JQiAyIH08QlI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NCcGkyQ29uZm9ybWFuY2UgT0JKRUNUIAog IElERU5USUZJRVI8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIDo6PSB7IGRvY3NCcGkyTUlCIDMgfTxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgZG9jc0JwaTJDb21wbGlhbmNlcyBP QkpFQ1QgCiAgSURFTlRJRklFUjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgOjo9IHsgZG9jc0JwaTJDb25mb3Jt YW5jZSAxIH08QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NC cGkyR3JvdXBzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9CSkVDVCAKICBJREVOVElG SUVSPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAKICA6Oj0geyBkb2NzQnBpMkNvbmZvcm1hbmNlIDIgfTxCUj48QlI+ Jm5ic3A7Jm5ic3A7IFdoeSBub3QgYmUgKG1vcmUpIGNvbnNpc3RlbnQgCiAgd2l0aCBvdGhlciBN SUIgbW9kdWxlcyBhbmQgZm9sbG93IHRoZTxCUj4mbmJzcDsmbmJzcDsgc3VnZ2VzdGVkIE9JRCBz dWJ0cmVlcyAKICBhcyBwZXIgTUlCIGd1aWRlbGluZXMsPEJSPiZuYnNwOyZuYnNwOyAKICBkcmFm dC1pZXRmLW9wcy1taWItcmV2aWV3LWd1aWRlbGluZXMtMDMudHh0LCBhcHBlbmRpeCAKICBEOjxC Uj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgeHh4TUlCPEJS PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICB8PEJSPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS0gCiAgeHh4Tm90aWZpY2F0 aW9ucygwKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0t IAogIHh4eE9iamVjdHMoMSk8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICstLSAKICB4eHhDb25mb3JtYW5jZSgyKTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgfDxCUj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgKy0tIAogIHh4eENvbXBsaWFuY2VzKDEpPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICArLS0geHh4R3Jv dXBzKDIpPEJSPiZuYnNwOyZuYnNwOyBUaGlzIGlzIG5vdCBtYW5kYXRpb3J5LCBidXQgY29uc2lz dGVuY3kgaXMgCiAgYWx3YXlzIHVzZWZ1bC9oZWxwZnVsPEJSPjxCUj48QlI+Tml0cy9hZG1pbmlz dHJhdGl2aWE6PEJSPjxCUj4xLiBUaGUgUkZDIAogIGVkaXRvciB3YW50cyBhbGwgcmVmZXJlbmNl cyB0byBoYXZlIGF0IGxlYXN0IG9uZSBjaXRhdGlvbjxCUj4mbmJzcDsmbmJzcDsgaW4gCiAgdGhl IGRvY3VtZW50LiBBTHNvIGZvciB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gUkZDcyBmcm9t PEJSPiZuYnNwOyZuYnNwOyAKICB3aGljaCB5b3UgaW1wb3J0LiBTZWUgTUlCIHJldmlldyBndWlk ZWxpbmVzLCBzZWN0IDMuNTxCUj48QlI+Jm5ic3A7Jm5ic3A7IFlvdSAKICBuZWVkIHRvIGFkZCBh IGNpdGF0aW9uIHNvbWVod2VyZSBmb3IgW1JGQzM0MTFdLCBbUkZDMjAyMV0sPEJSPiZuYnNwOyZu YnNwOyAKICBbUkZDMzI5MV0sIAogIFtSRkMyNjcwXTxCUj48QlI+VGhhbmtzLDxCUj5CZXJ0PEJS PjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj5J UENETiAKICBtYWlsaW5nIGxpc3Q8QlI+SVBDRE5AaWV0Zi5vcmc8QlI+PEEgCiAgaHJlZj0iaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBjZG4iPmh0dHBzOi8vd3d3MS5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwY2RuPC9BPjxCUj48QlI+PC9GT05UPjwvUD48L0JM T0NLUVVPVEU+Cgo8L0JPRFk+CjwvSFRNTD4= ------_=_NextPart_001_01C469CA.886DCC56-- --===============1895742245== 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 --===============1895742245==-- From ipcdn-bounces@ietf.org Wed Jul 14 14:26:44 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04565 for ; Wed, 14 Jul 2004 14:26:44 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkoSr-0003HI-2x for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 14:26:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkoRn-0002wf-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 14:25:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1BkoRH-0002bW-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 14:25:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkoH0-0007eJ-57; Wed, 14 Jul 2004 14:14:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkoCA-0006kk-Vq for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 14:09:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02504 for ; Wed, 14 Jul 2004 14:09:29 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkoC9-0005CY-UW for ipcdn@ietf.org; Wed, 14 Jul 2004 14:09:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkoBC-0004tR-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 14:08:31 -0400 Received: from pacdcoavas10.cable.comcast.com ([208.17.33.59]) by ietf-mx with esmtp (Exim 4.12) id 1BkoAN-0004IW-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 14:07:39 -0400 Message-ID: From: "Woundy, Richard" To: "'Wijnen, Bert (Bert)'" , wsawyer@ieee.org, sawyerwd@comcast.net, Harrie Hazewinkel Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Wed, 14 Jul 2004 14:02:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Cc: "Ipcdn \(E-mail\)" 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 >Wilson/WG-chair(s), pls let me know if that sounds like a plan or >if you ratehr address/answer the below first. Going to IETF Last Call sounds like a good plan to me. -- Rich -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org]On Behalf Of Wijnen, Bert (Bert) Sent: Wednesday, July 14, 2004 10:14 AM To: wsawyer@ieee.org; sawyerwd@comcast.net; Ipcdn (E-mail) Cc: Harrie Hazewinkel Subject: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Wilson (and WG). Sorry that it took long (again) to do another good check of this MIB document. I think this doc is basically OK now. I did find some small things as per below, and it would be good to fix those at some point. I propose that I issue an IETF Last Call, and that the below comments are considered as the initial comments on such an IETF Last Call and that you address them (or answer them) as part of any other comments that may come up from IETF Last Call. Wilson/WG-chair(s), pls let me know if that sounds like a plan or if you ratehr address/answer the below first. What I did find is: >From SMICng (strict checking). I thought I had reported this before ( see I did, but you probably opted to not do it since it is not mandatory). Oh well, I am including it anayway (again), because I really belive it is betetr to include them. E: f(ipcdnsub.mi2), (478,15) Item "diffServMIBDataPathGroup" should be IMPORTed E: f(ipcdnsub.mi2), (479,15) Item "diffServMIBClfrGroup" should be IMPORTed E: f(ipcdnsub.mi2), (480,15) Item "diffServMIBClfrElementGroup" should be IMPORTed E: f(ipcdnsub.mi2), (481,15) Item "diffServMIBMultiFieldClfrGroup" should be IMPORTed E: f(ipcdnsub.mi2), (482,15) Item "diffServMIBActionGroup" should be IMPORTed E: f(ipcdnsub.mi2), (483,15) Item "diffServMIBAlgDropGroup" should be IMPORTed E: f(ipcdnsub.mi2), (484,15) Item "diffServMIBCounterGroup" should be IMPORTed E: f(ipcdnsub.mi2), (487,11) Item "diffServDataPathStatus" should be IMPORTed E: f(ipcdnsub.mi2), (493,11) Item "diffServClfrStatus" should be IMPORTed E: f(ipcdnsub.mi2), (499,11) Item "diffServClfrElementStatus" should be IMPORTed E: f(ipcdnsub.mi2), (506,11) Item "diffServMultiFieldClfrAddrType" should be IMPORTed E: f(ipcdnsub.mi2), (512,11) Item "diffServMultiFieldClfrSrcAddr" should be IMPORTed E: f(ipcdnsub.mi2), (518,11) Item "diffServMultiFieldClfrDstAddr" should be IMPORTed E: f(ipcdnsub.mi2), (524,11) Item "diffServAlgDropStatus" should be IMPORTed E: f(ipcdnsub.mi2), (530,11) Item "diffServDataPathStorage" should be IMPORTed E: f(ipcdnsub.mi2), (536,11) Item "diffServClfrStorage" should be IMPORTed E: f(ipcdnsub.mi2), (542,11) Item "diffServClfrElementStorage" should be IMPORTed E: f(ipcdnsub.mi2), (548,11) Item "diffServMultiFieldClfrStorage" should be IMPORTed E: f(ipcdnsub.mi2), (554,11) Item "diffServActionStorage" should be IMPORTed E: f(ipcdnsub.mi2), (560,11) Item "diffServCountActStorage" should be IMPORTed E: f(ipcdnsub.mi2), (566,11) Item "diffServAlgDropStorage" should be IMPORTed E: f(ipcdnsub.mi2), (572,11) Item "diffServAlgDropType" should be IMPORTed According to our MIB review guidelines (draft-ietf-ops-mib-review-guidelines-03.txt) section 4.4, 3rd para: Note that exemptions to this general requirement are granted by RFC 2580 Sections 5.4.3 and 6.5.2 for descriptors of objects appearing in the OBJECT clause of a MODULE-COMPLIANCE statement or in the VARIATION clause of an AGENT-CAPABILITIES statement. Some MIB compilers also grant exemptions to descriptors of notifications appearing in a VARIATION clause and to descriptors of object groups and notification groups referenced by a MANDATORY-GROUPS clause, a GROUP clause, or an INCLUDES clause, although RFC 2580 (through apparent oversight) does not mention those cases. The exemptions are sometimes seen as unhelpful because they make IMPORTS rules more complicated and inter-module dependencies less obvious than they otherwise would be. External symbols referenced by compliance statements and capabilities statements MAY therefore be listed in the IMPORTS statement; if this is done, it SHOULD be done consistently. So it is not mandatory to do the IMPORTs, but in my view it will help in many places with less warning/errors. So may I suggest to add the IMPORT statement for the above. Also, all documents from whihc you IMPORT (implied or explicit) you must put in normative reference section (which you have done). But all such references MUST have a citation in the text (see MIB review guidelines, (draft-ietf-ops-mib-review-guidelines-03.txt, sect 3.5): 3.5. References Sections Section 4.7f of [RFC2223bis] specifies the requirements for the references sections. In particular, there MUST be separate lists of normative and informative references, each in a separate section. The style SHOULD follow that of recently published RFCs. The standard MIB boilerplate available at http://www.ops.ietf.org/mib-boilerplate.html includes lists of normative and informative references that MUST appear in all IETF specifications that contain MIB modules. If items from other MIB modules appear in an IMPORTS statement in the Definitions section, then the specifications containing those MIB modules MUST be included in the list of normative references. When items are imported from an IANA-maintained MIB module the corresponding normative reference SHALL point to the on-line version of that MIB module. It is the policy of the RFC Editor that all references must be cited in the text; such citations MUST appear in the overview section where documents containing imported definitions (other those already mentioned in the MIB boilerplate) are required to be mentioned (cf. Section 3.2). You have such a reference for RFC3291 (as required), but no citation to [RFC3291] anywhere in the document. Can you pls add it at some point in the text. I have some other nits/questions: 1. Desription clause of docsSubMgtCpeIpIndex states, towards the end: the table and the packet is forwarded. If the number of entries equals the docsSubMgtCpeControlMaxCpeIp, AND docsSubMgtCpeControlActive is true, then the packet is dropped. Otherwise the packet is forwarded. " In the case that the packet is forwarded, will then also an entry be created? That is not clear to me. May I suggest to add some text to make that 100% clear? 2. In description clause of docsSubMgtCmFilterTable it states: Zero is a distinguished value, indicating that the default filtering action is to be taken, rather than that associated Mmm... a value for the table? I guess you mean that such a zero value "in any of the columns of the table has a special maening. Right? Might want to make that clearer. 3. I see: 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream I think that for naming consistency, it might be better to rename 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream into something like: 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream so as to make it clearer (from the name/descriptor) that these 2 objects exists in the docsSubMgtCmFilterTable. 4. I am a bit worried about the hard limit (range) of 1-255 for FilterGroupIndex. Is this enough forever in the future? Or would it be wiser to use a larger range (and limit via MODULE-COMPLIANCE, as you already do)? I see it was larger before, and that you changed it to this smaller range. So I guess you are doing this consciously. 5. In description clause of docsSubMgtFilterGroupIndex I see: the four. Because this is the only field in this table, it is read-only, contrary to the usual SNMP custom of making indices not-accessible. Probably better to change SNMP into SMI. 6. In the Security Considerations, I think I would change the 2nd para to make a positive statement, namely that you MUST follow recommendations in sect 2.2.6 in order to deploy an effective filtering. Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 16:03:08 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12844 for ; Wed, 14 Jul 2004 16:03:08 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkpy9-00048V-GE for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 16:03:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpuZ-00035A-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 15:59:28 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Bkpsr-0002Xf-02 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 15:57:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bkpno-0005LY-ET for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 15:52:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkpW3-0006G0-Nj; Wed, 14 Jul 2004 15: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 1BkpJ0-0003RN-Ed for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 15:20:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08999 for ; Wed, 14 Jul 2004 15:20:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkpIz-0005D1-6e for ipcdn@ietf.org; Wed, 14 Jul 2004 15:20:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkpI3-0004tJ-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 15:19:40 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx with esmtp (Exim 4.12) id 1BkpH8-0004a9-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 15:18:42 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6EJIeGK013380 for ; Wed, 14 Jul 2004 14:18:41 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jul 2004 21:18:40 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504BEAE07@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , wsawyer@ieee.org, sawyerwd@comcast.net, "Ipcdn (E-mail)" Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Wed, 14 Jul 2004 21:18:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" Cc: Harrie Hazewinkel 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Eduardo writes: > > Bert, > For the benefot of other authors/editors in the same path of > AD evaluation, > I see your comment 3 a little deviation of OPS guidelines Appendix C: > - The descriptor associated with a conceptual table should be of the > form xxxZzzTable; the descriptor associated with the corresponding > conceptual row should be of the form xxxZzzEntry; the name of the > associated SEQUENCE type should be of the form XxxZzzEntry; and > the descriptors associated with the subordinate columnar objects > should be of the form xxxZzzSomeotherName. > > I presume it is a typo and you would like see extrict > compliance to those recommendations > Any comments? > Not sure I understand. The idea of the Guidelines is to show that (ideally) all columns wthin one table have a common prefix (that sets them apart from other objects in the same (or even otehr) MIB module(s) ). So by inserting the "Cm" for the two objects I listed, that seems to do the trick. What did you think that the Guidelines are suggesting? > > Thanks > > Eduardo .. snip > 3. I see: > 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable > 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream > I think that for naming consistency, it might be better to rename > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > into something like: > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream > so as to make it clearer (from the name/descriptor) that these 2 > objects exists in the docsSubMgtCmFilterTable. > .. snip Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 21:03:55 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21316 for ; Wed, 14 Jul 2004 21:03:54 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkufD-0000xk-6i for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 21:03:55 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bku5h-0002TW-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 20:27:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BktWu-0003ic-03 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 19:51:17 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BktU2-00083M-BX for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 19:48:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkruH-0000ce-Ne; Wed, 14 Jul 2004 18:07:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkq8I-0001kc-Vd for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 16:13:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14290 for ; Wed, 14 Jul 2004 16:13:36 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkq8H-0007Du-Lq for ipcdn@ietf.org; Wed, 14 Jul 2004 16:13:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkq4Y-0006C0-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 16:09:47 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx with esmtp (Exim 4.12) id 1Bkq0x-00056c-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 16:06:03 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6EK61N3011157 for ; Wed, 14 Jul 2004 15:06:02 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 14 Jul 2004 22:06:00 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504BEAE0C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Date: Wed, 14 Jul 2004 22:05:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 2 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 OK, here is part 2. AT the bottom I also have repreated part 1, so you have it all in one email in case that is handy. more or less serious (I continue with number 12): 12. I see: docsBpi2CmtsProvisionedCmCertStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Standard RowStatus object except: a) if a row has ever been activated, a set to docsBpi2CmtsProvisionedCmCert need not succeed, b) inactive rows need not be timed out." So you are changing the rules of the RowStatus TC? Seems not allowed to me. nits/administrative/questions (continue with muber 2): 2. I see: docsBpi2CmtsCACertSubject OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The subject name exactly as it is encoded in the X509 certificate. The organizationName portion of the certificate's subject name must be present. All other fields are optional. Any optional field present must be prepended with (carriage return) (line feed) ASCII characters. Ordering of fields present must conform to: organizationName countryName A 7-bit ASCII character (which CR and LF are) does get represented exactly the same when UTF-8 encoded. But it is kind of weird to speak about ASCII characters when discussing the content of a UTF-8 based OCTET STRING. I checked with our UTF-8 and Unicode expert (Patrik Faltstrom) and he comes up with this suggestion: Replace sentence: Any optional field present must be prepended with (carriage return) (line feed) ASCII characters. with: Any optional field present must be prepended with (carriage return, U+000D) and (line feed, U+000A). You have this in a number of objects, pls check them all. 3. I see: docsBpi2CmDeviceCmCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-write STATUS current DESCRIPTION "The X509 DER-encoded cable modem certificate. Note: This object can be set only when the value is the null string. Once the object contains the certificate, its access MUST be read-only." Maybe this is just wording. - First, I already discussed the "null string" issue. I think you mean a zero length string or maybe better "zero length certificate" or "zero length OCTET STRING" or "zero length value". - Now, it seems to me that if the requirement is that the object has a zero length value in order for a SET to be accepted, then, when someone tries a SET while there is already a value, that then the system ought to return a error that explains what is wrong. I.e. an error that would otherwise not occur. If you get a notWritable, then the management station does not necassarily know why that is, see bullet 2 page 20 of RFC3416 or point 9 on page 21. Maybe a better error would be a inconsistentValue, point 10 on page 21 of RFC3416?? Does that not seem a better way to indicate this error? 4. I see: docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE SYNTAX INTEGER { none(0), des56CbcMode(1), des40CbcMode(2) } MAX-ACCESS read-only I understand that this is read-only and so can only report what is in the Cm. But I would not be surprised if this will cause questions from the security folk. Is this the only envryption that is supported? 5. I see: docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE SYNTAX INTEGER { trusted (1), untrusted (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines the default trust of self-signed manufacturer certificate entries, contained in docsBpi2CmtsCACertTable, created after setting the object." I cannot say that I understand what "afetr setting the object" means. which object? Thanks, Bert > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 14 juli 2004 18:03 > To: Ipcdn (E-mail) > Subject: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - > part 1 > > > Sorry, it took too long to finally get this done. > > Not sure this document is ready for IETF Last Call. > Actaully I think it is not. > > This is part 1. Mainly serious things. > I may have more nits/admin stuff later. > > Here are my findings. > > More or less serious: > 1. I see various read-write and/or read-create objects and I do > not see any text in the DESCRIPTION clauses (non > STorageType objects) > that tell me what the expected behaviour is w.r.t. > persistency of such > objects. SO what happens after a restart/reboot? > > 2. I see a number of ZeroBasedCOunter32 objects that have text aka: > (for example docsBpi2CmAuthentInfos) > DESCRIPTION > "The value of this object is the count of > times the CM > has transmitted an Authentication Information message, > since reboot." > It is OK to tell us that a ZeroBasedCOunter32 object must > start with zero > at (re-)boot time or at row creation. > But from that point on, a ZeroBasedCounter32 behaves > exactly the same > as a Counter32, and so it is incorrect to say "count of X > since reboot" > because the Counter32 may have wrapped!. Possibly this is not gonna > happen in practice, but literally the claim is incorrect. > > 3. For these ZeroBasedCounter32 objects, I also see no word > about a possible > discontinuity timer. Why not. Can there NEVER be a > discontinuity? Of if > there is one does that mean ALL counters experience a > discontionuity? > The latter is what you basically state (or cause) by not > pointing to a > specific discontinuity timer. Because then by default it > is sysUpTime, and > so that means that when you DO experience a discontinuity, > then you MUST > reset sysUpTime and that means that a discontinuity for > EVERYONE (object) > that assumes the default. If such is intended, then fine, > but it would be > good to then state that sysUpTime is the discontinuity timer. > > 4. I see that for some objects you speak about a "null > string" or "NULL string". > The base data type for such objects is OCTET STRING. In > all those cases > I suspect (but I am not sure) that you mean the > zero-length octet string. > Otherwise I do not understand what "null string" means. > Pls explain and fix. > > 5. For docsBpi2CmtsAuthCmExpiresOld I see: > Note: For CMs running in BPI mode, implementation of this > object is optional and MAY vary." > Mmm... that sounds like a MODULE-COMPLIANCE aspect and I > would rather > see such things in MODULE-COMPLIANCE and not in object > DESCRIPTION clauses. > > 6. I see: > -- Note: the following object has been obsoleted > > docsBpi2CmtsAuthCmReset OBJECT-TYPE > SYNTAX INTEGER { > noResetRequested(1), > invalidateAuth(2), > sendAuthInvalid(3), > invalidateTeks(4) > } > MAX-ACCESS read-write > STATUS current > > So the --Note: is out of sync with the actual status!? > What is it? If it IS obsoleted, then status should sya so, > And DESCRIPTION clause should explain why it was obsoleted. > And the ASN.1 comment line then of course is no longer needed. > > 7. I see: > docsBpi2CmtsAuthCACertIndexPtr OBJECT-TYPE > SYNTAX Integer32 (0..10000) > And find that a strange limit (range). And nowhere, not > even in the > docsBpi2CmtsCACertTable do I see an explanation why that > range makes > sense (assuming that it does). > > 8. When I see: > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastMaskType InetAddressType, > docsBpi2CmtsIpMulticastMask InetAddress, > I wonder if (in the same row) > docsBpi2CmtsIpMulticastMaskType will ever > have a different value then docsBpi2CmtsIpMulticastAddressType !?? > It seems to me that should NOT be allowed, cause otherwise I am not > sure how the ANDing of the Mask is going to work/happen. > So the next question then is why you do not do: > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastMask InetAddress, > And let docsBpi2CmtsIpMulticastAddressType be the > discriminator for both > InetAddresses. One less object, and less change for error/conflict. > > But thinking even further, Possibly the best thing to do is to use > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastPrefixLength > InetAddressPrefixLength, > Are not such masks always setup that they basically > specify a prefix length? > If so, then this is the way to do it with the TCs from > INET-ADDRESS-MIB. > > 9. I see various uses of InetAddress as for example here: > docsBpi2CmtsIpMulticastAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object represents the IP multicast address > to be mapped, in conjunction with > docsBpi2CmtsIpMulticastMask." > The TC for InetAddress (in RFC3291 or its follow on) > clearly state that > you MUST specify which InetAddressType controls the format > of this object > as per DESCRIPTION from InetAddress TC: > An InetAddress value is always interpreted within the context > of an InetAddressType value. Every usage of the InetAddress > textual convention is required to specify the InetAddressType > object which provides the context. ... > > 10. I see: > docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object controls and reflects the IP multicast > address mapping entry. There is no restriction on the > ability to change values in this row while the row is > active. Inactive rows need not be timed out." > Mmm... that "need not be timed out" seems in conflict > with the RowStatus > TC DESCRIPTION clause in RFC2579. Can you explain why this is? > > Also, a RowSTatus object MUST specify in its DESCRIPTION > clause under > which conditions > - the row can be activated > - which columns (if any) can bve changed while in the > active state. > I am missing the first. > > 11. You specify: > -- > -- The BPI+ MIB Conformance Statements (with a placeholder for > -- notifications) > -- > > docsBpi2Notification OBJECT IDENTIFIER > ::= { docsBpi2MIB 2 } > docsBpi2Conformance OBJECT IDENTIFIER > ::= { docsBpi2MIB 3 } > docsBpi2Compliances OBJECT IDENTIFIER > ::= { docsBpi2Conformance 1 } > docsBpi2Groups OBJECT IDENTIFIER > ::= { docsBpi2Conformance 2 } > > Why not be (more) consistent with other MIB modules and follow the > suggested OID subtrees as per MIB guidelines, > draft-ietf-ops-mib-review-guidelines-03.txt, appendix D: > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > This is not mandatiory, but consistency is always useful/helpful > > > Nits/administrativia: > > 1. The RFC editor wants all references to have at least one citation > in the document. ALso for the normative references to RFCs from > which you import. See MIB review guidelines, sect 3.5 > > You need to add a citation somehwere for [RFC3411], [RFC2021], > [RFC3291], [RFC2670] > > Thanks, > Bert > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Jul 14 21:04:15 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21439 for ; Wed, 14 Jul 2004 21:04:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkufX-00011h-Vd for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 21:04:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bku6F-0002Z1-00 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 20:27:49 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BktWy-0003ic-01 for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 19:51:20 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BktRj-0007uG-MR for ipcdn-archive@ietf.org; Wed, 14 Jul 2004 19:45:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkrn5-0002mI-DN; Wed, 14 Jul 2004 17:59:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bkpu2-0004XI-43 for ipcdn@megatron.ietf.org; Wed, 14 Jul 2004 15:58:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12507 for ; Wed, 14 Jul 2004 15:58:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bkpu0-0002yp-TM for ipcdn@ietf.org; Wed, 14 Jul 2004 15:58:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bkpsi-0002Wq-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 15:57:32 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Bkprd-0001tV-00 for ipcdn@ietf.org; Wed, 14 Jul 2004 15:56:25 -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 i6EJtlbw004039; Wed, 14 Jul 2004 13:55:47 -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] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Wed, 14 Jul 2004 13:55:46 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F06A1EA@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Thread-Index: AcRp12R4eSVkcbafRUaUCmjyeKzYdQAAdz4H From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , , , "Ipcdn (E-mail)" X-Approved: ondar Cc: Harrie Hazewinkel 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="===============2096819045==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 This is a multi-part message in MIME format. --===============2096819045== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C469DC.8DFA9FFA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C469DC.8DFA9FFA Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SnVzdCBsb29raW5nIGZvciBhIGNsYXJpZmljYXRpb24gb2YgaG93IHRvIGludGVycHJldCB0aGUg T1BTIGd1aWRlbGluZXMuDQogDQoiU2hvdWxkIGJlLi4uICIgaXMgYmVpbmcgb2JzY3VyZSBmb3Ig bWUgY29tcGFyZWQgd2l0aCAiUkVDT01NRU5ERUQiIGFsc28gIHRoYXQgaXMgYXQgc29tZSBwb2lu dCAicXVhc3ktbWFuZGF0b3J5IiBieSBNSUIgZG9jdG9ycyByZXZpZXdzLCBUaGF0J3Mgd2h5IEkg YXNrIHRoZSBxdWVzdGlvbiBpbiBhIGdlbmVyaWMgd2F5IGZvciBtdWx0aXBsZSBlZGl0b3JzL2F1 dGhvcnMgLSBnb29kIHRvIGhhdmUgeW91ciBwZXJzcGVjdGl2ZS4NCiANCk15IG9ubHkgcmVjb2xs ZWN0aW9uIG9mIHRoZW9yZXRpY2FsIHByZWZpeCBjb21wbGFpbnMgaXMgaW4gc21pbGliIGZvciB0 aGUgY29tbW9uIG1vZGVsICB0b29sIHRoYXQgdXNlcyBoZXVyaXN0aWNzIGZvciBkZXBlbmRlbmNp ZXMgZGlzY292ZXJ5ICg/KSANCiANCkkgZ290IGNvbmZ1c2VkIGlmIHRoZSAnQ00nIHNob3VsZCBi ZSBhZGRlZCAoIHJlY29tbWVuZGVkKSB0byB0aGUgU29tZU90aGVyTmFtZSBwYXJ0IG9mIHh4eFp6 elNvbWVvdGhlck5hbWUgIA0KIA0KVGhhbmtzDQogDQpFZHVhcmRvDQoNCgktLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLSANCglGcm9tOiBXaWpuZW4sIEJlcnQgKEJlcnQpIFttYWlsdG86Yndpam5l bkBsdWNlbnQuY29tXSANCglTZW50OiBXZWQgNy8xNC8yMDA0IDE6MTggUE0gDQoJVG86IEVkdWFy ZG8gQ2FyZG9uYTsgd3Nhd3llckBpZWVlLm9yZzsgc2F3eWVyd2RAY29tY2FzdC5uZXQ7IElwY2Ru IChFLW1haWwpIA0KCUNjOiBIYXJyaWUgSGF6ZXdpbmtlbCANCglTdWJqZWN0OiBSRTogW2lwY2Ru XSBBRCByZXZpZXcgb2Y6IGRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1taWItMTQudHh0DQoJ DQoJDQoNCglFZHVhcmRvIHdyaXRlczoNCgkNCgk+DQoJPiBCZXJ0LA0KCT4gRm9yIHRoZSBiZW5l Zm90IG9mIG90aGVyIGF1dGhvcnMvZWRpdG9ycyBpbiB0aGUgc2FtZSBwYXRoIG9mDQoJPiBBRCBl dmFsdWF0aW9uLA0KCT4gSSBzZWUgeW91ciBjb21tZW50IDMgYSBsaXR0bGUgZGV2aWF0aW9uIG9m IE9QUyBndWlkZWxpbmVzIEFwcGVuZGl4IEM6DQoJPiAtIFRoZSBkZXNjcmlwdG9yIGFzc29jaWF0 ZWQgd2l0aCBhIGNvbmNlcHR1YWwgdGFibGUgc2hvdWxkIGJlIG9mIHRoZQ0KCT4gICAgICBmb3Jt IHh4eFp6elRhYmxlOyAgdGhlIGRlc2NyaXB0b3IgYXNzb2NpYXRlZCB3aXRoIHRoZSBjb3JyZXNw b25kaW5nDQoJPiAgICAgIGNvbmNlcHR1YWwgcm93IHNob3VsZCBiZSBvZiB0aGUgZm9ybSB4eHha enpFbnRyeTsgIHRoZSBuYW1lIG9mIHRoZQ0KCT4gICAgICBhc3NvY2lhdGVkIFNFUVVFTkNFIHR5 cGUgc2hvdWxkIGJlIG9mIHRoZSBmb3JtIFh4eFp6ekVudHJ5OyAgYW5kDQoJPiAgICAgIHRoZSBk ZXNjcmlwdG9ycyBhc3NvY2lhdGVkIHdpdGggdGhlIHN1Ym9yZGluYXRlIGNvbHVtbmFyIG9iamVj dHMNCgk+ICAgICAgc2hvdWxkIGJlIG9mIHRoZSBmb3JtIHh4eFp6elNvbWVvdGhlck5hbWUuDQoJ Pg0KCT4gSSBwcmVzdW1lIGl0IGlzIGEgdHlwbyBhbmQgeW91IHdvdWxkIGxpa2Ugc2VlIGV4dHJp Y3QNCgk+IGNvbXBsaWFuY2UgdG8gdGhvc2UgcmVjb21tZW5kYXRpb25zDQoJPiBBbnkgY29tbWVu dHM/DQoJPg0KCU5vdCBzdXJlIEkgdW5kZXJzdGFuZC4gVGhlIGlkZWEgb2YgdGhlIEd1aWRlbGlu ZXMgaXMgdG8gc2hvdyB0aGF0IChpZGVhbGx5KQ0KCWFsbCBjb2x1bW5zIHd0aGluIG9uZSB0YWJs ZSBoYXZlIGEgY29tbW9uIHByZWZpeCAodGhhdCBzZXRzIHRoZW0gYXBhcnQNCglmcm9tIG90aGVy IG9iamVjdHMgaW4gdGhlIHNhbWUgKG9yIGV2ZW4gb3RlaHIpIE1JQiBtb2R1bGUocykgKS4NCgkN CglTbyBieSBpbnNlcnRpbmcgdGhlICJDbSIgZm9yIHRoZSB0d28gb2JqZWN0cyBJIGxpc3RlZCwg dGhhdCBzZWVtcyB0byBkbw0KCXRoZSB0cmljay4gV2hhdCBkaWQgeW91IHRoaW5rIHRoYXQgdGhl IEd1aWRlbGluZXMgYXJlIHN1Z2dlc3Rpbmc/DQoJDQoJPg0KCT4gVGhhbmtzDQoJPg0KCT4gRWR1 YXJkbw0KCQ0KCS4uIHNuaXANCgkNCgk+IDMuIEkgc2VlOg0KCT4gICAgICAxLjMuNi4xLjIuMS54 eC4xLjYgICAgICBkb2NzU3ViTWd0Q21GaWx0ZXJUYWJsZQ0KCT4gICAgICAxLjMuNi4xLjIuMS54 eC4xLjYuMSAgICBkb2NzU3ViTWd0Q21GaWx0ZXJFbnRyeQ0KCT4gICAgICAxLjMuNi4xLjIuMS54 eC4xLjYuMS4xICBkb2NzU3ViTWd0U3ViRmlsdGVyRG93bnN0cmVhbQ0KCT4gICAgICAxLjMuNi4x LjIuMS54eC4xLjYuMS4yICBkb2NzU3ViTWd0U3ViRmlsdGVyVXBzdHJlYW0NCgk+ICAgICAgMS4z LjYuMS4yLjEueHguMS42LjEuMyAgZG9jc1N1Yk1ndENtRmlsdGVyRG93bnN0cmVhbQ0KCT4gICAg ICAxLjMuNi4xLjIuMS54eC4xLjYuMS40ICBkb2NzU3ViTWd0Q21GaWx0ZXJVcHN0cmVhbQ0KCT4g ICAgSSB0aGluayB0aGF0IGZvciBuYW1pbmcgY29uc2lzdGVuY3ksIGl0IG1pZ2h0IGJlIGJldHRl ciB0byByZW5hbWUNCgk+ICAgICAgMS4zLjYuMS4yLjEueHguMS42LjEuMSAgZG9jc1N1Yk1ndFN1 YkZpbHRlckRvd25zdHJlYW0NCgk+ICAgICAgMS4zLjYuMS4yLjEueHguMS42LjEuMiAgZG9jc1N1 Yk1ndFN1YkZpbHRlclVwc3RyZWFtDQoJPiAgICBpbnRvIHNvbWV0aGluZyBsaWtlOg0KCT4gICAg ICAxLjMuNi4xLjIuMS54eC4xLjYuMS4xICBkb2NzU3ViTWd0Q21TdWJGaWx0ZXJEb3duc3RyZWFt DQoJPiAgICAgIDEuMy42LjEuMi4xLnh4LjEuNi4xLjIgIGRvY3NTdWJNZ3RDTW11YkZpbHRlclVw c3RyZWFtDQoJPiAgICBzbyBhcyB0byBtYWtlIGl0IGNsZWFyZXIgKGZyb20gdGhlIG5hbWUvZGVz Y3JpcHRvcikgdGhhdCB0aGVzZSAyDQoJPiAgICBvYmplY3RzIGV4aXN0cyBpbiB0aGUgZG9jc1N1 Yk1ndENtRmlsdGVyVGFibGUuDQoJPg0KCQ0KCS4uIHNuaXANCgkNCglCZXJ0DQoJDQoJDQoNCg== ------_=_NextPart_001_01C469DC.8DFA9FFA Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5SRTogW2lwY2RuXSBBRCBy ZXZpZXcgb2Y6IGRyYWZ0LWlldGYtaXBjZG4tc3Vic2NyaWJlci1taWItMTQudHh0PC9USVRMRT4K PC9IRUFEPgo8Qk9EWSBkaXI9bHRyPgo8RElWPkp1c3QgbG9va2luZyBmb3IgYSZuYnNwO2NsYXJp ZmljYXRpb24gb2YgaG93IHRvIGludGVycHJldCB0aGUgT1BTIApndWlkZWxpbmVzLjwvRElWPgo8 RElWPiZuYnNwOzwvRElWPgo8RElWPiJTaG91bGQgYmUuLi4gIiBpcyBiZWluZyZuYnNwO29ic2N1 cmUgZm9yIG1lJm5ic3A7Y29tcGFyZWQgCndpdGgmbmJzcDsiUkVDT01NRU5ERUQiIGFsc28gJm5i c3A7dGhhdCBpcyBhdCBzb21lIHBvaW50ICJxdWFzeS1tYW5kYXRvcnkiIGJ5IApNSUIgZG9jdG9y cyByZXZpZXdzLCBUaGF0J3Mgd2h5IEkgYXNrIHRoZSBxdWVzdGlvbiBpbiBhIGdlbmVyaWMgd2F5 IGZvciBtdWx0aXBsZSAKZWRpdG9ycy9hdXRob3JzIC0gZ29vZCB0byBoYXZlIHlvdXIgcGVyc3Bl Y3RpdmUuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+TXkgb25seSByZWNvbGxlY3Rpb24g b2YgdGhlb3JldGljYWwgcHJlZml4Jm5ic3A7Y29tcGxhaW5zIGlzIGluIHNtaWxpYiBmb3IgCnRo ZSBjb21tb24gbW9kZWwmbmJzcDsgdG9vbCB0aGF0IHVzZXMgaGV1cmlzdGljcyBmb3IgZGVwZW5k ZW5jaWVzIGRpc2NvdmVyeSAKKD8pJm5ic3A7PC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+ SSBnb3QgY29uZnVzZWQgaWYgdGhlICdDTScgc2hvdWxkIGJlIGFkZGVkICggcmVjb21tZW5kZWQp IHRvIHRoZSAKU29tZU90aGVyTmFtZSBwYXJ0IG9mJm5ic3A7PEZPTlQgc2l6ZT0yPnh4eFp6elNv bWVvdGhlck5hbWUmbmJzcDsgPC9GT05UPjwvRElWPgo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+CjxESVY+PEZPTlQgc2l6ZT0yPlRoYW5rczwvRk9OVD48L0RJVj4KPERJVj48 Rk9OVCBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPgo8RElWPjxGT05UIHNpemU9Mj5FZHVhcmRv PC9GT05UPjwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxlPSJNQVJHSU4tUklHSFQ6IDBw eCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gPEJSPjxC PkZyb206PC9CPiBXaWpuZW4sIEJlcnQgCiAgKEJlcnQpIFttYWlsdG86Yndpam5lbkBsdWNlbnQu Y29tXSA8QlI+PEI+U2VudDo8L0I+IFdlZCA3LzE0LzIwMDQgMToxOCBQTSAKICA8QlI+PEI+VG86 PC9CPiBFZHVhcmRvIENhcmRvbmE7IHdzYXd5ZXJAaWVlZS5vcmc7IHNhd3llcndkQGNvbWNhc3Qu bmV0OyBJcGNkbiAKICAoRS1tYWlsKSA8QlI+PEI+Q2M6PC9CPiBIYXJyaWUgSGF6ZXdpbmtlbCA8 QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBbaXBjZG5dIEFEIAogIHJldmlldyBvZjogZHJhZnQtaWV0 Zi1pcGNkbi1zdWJzY3JpYmVyLW1pYi0xNC50eHQ8QlI+PEJSPjwvRk9OVD48L0RJVj4KICA8UD48 Rk9OVCBzaXplPTI+RWR1YXJkbyB3cml0ZXM6PEJSPjxCUj4mZ3Q7PEJSPiZndDsgQmVydCw8QlI+ Jmd0OyBGb3IgdGhlIAogIGJlbmVmb3Qgb2Ygb3RoZXIgYXV0aG9ycy9lZGl0b3JzIGluIHRoZSBz YW1lIHBhdGggb2Y8QlI+Jmd0OyBBRCAKICBldmFsdWF0aW9uLDxCUj4mZ3Q7IEkgc2VlIHlvdXIg Y29tbWVudCAzIGEgbGl0dGxlIGRldmlhdGlvbiBvZiBPUFMgZ3VpZGVsaW5lcyAKICBBcHBlbmRp eCBDOjxCUj4mZ3Q7IC0gVGhlIGRlc2NyaXB0b3IgYXNzb2NpYXRlZCB3aXRoIGEgY29uY2VwdHVh bCB0YWJsZSBzaG91bGQgCiAgYmUgb2YgdGhlPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgZm9ybSB4eHhaenpUYWJsZTsmbmJzcDsgdGhlIAogIGRlc2NyaXB0b3IgYXNzb2Np YXRlZCB3aXRoIHRoZSAKICBjb3JyZXNwb25kaW5nPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY29uY2VwdHVhbCByb3cgc2hvdWxkIGJlIAogIG9mIHRoZSBmb3JtIHh4eFp6 ekVudHJ5OyZuYnNwOyB0aGUgbmFtZSBvZiAKICB0aGU8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBhc3NvY2lhdGVkIFNFUVVFTkNFIHR5cGUgc2hvdWxkIGJlIAogIG9mIHRo ZSBmb3JtIFh4eFp6ekVudHJ5OyZuYnNwOyBhbmQ8QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyB0aGUgCiAgZGVzY3JpcHRvcnMgYXNzb2NpYXRlZCB3aXRoIHRoZSBzdWJvcmRp bmF0ZSBjb2x1bW5hciAKICBvYmplY3RzPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgc2hvdWxkIGJlIG9mIHRoZSBmb3JtIAogIHh4eFp6elNvbWVvdGhlck5hbWUuPEJSPiZn dDs8QlI+Jmd0OyBJIHByZXN1bWUgaXQgaXMgYSB0eXBvIGFuZCB5b3Ugd291bGQgbGlrZSAKICBz ZWUgZXh0cmljdDxCUj4mZ3Q7IGNvbXBsaWFuY2UgdG8gdGhvc2UgcmVjb21tZW5kYXRpb25zPEJS PiZndDsgQW55IAogIGNvbW1lbnRzPzxCUj4mZ3Q7PEJSPk5vdCBzdXJlIEkgdW5kZXJzdGFuZC4g VGhlIGlkZWEgb2YgdGhlIEd1aWRlbGluZXMgaXMgdG8gCiAgc2hvdyB0aGF0IChpZGVhbGx5KTxC Uj5hbGwgY29sdW1ucyB3dGhpbiBvbmUgdGFibGUgaGF2ZSBhIGNvbW1vbiBwcmVmaXggKHRoYXQg CiAgc2V0cyB0aGVtIGFwYXJ0PEJSPmZyb20gb3RoZXIgb2JqZWN0cyBpbiB0aGUgc2FtZSAob3Ig ZXZlbiBvdGVocikgTUlCIAogIG1vZHVsZShzKSApLjxCUj48QlI+U28gYnkgaW5zZXJ0aW5nIHRo ZSAiQ20iIGZvciB0aGUgdHdvIG9iamVjdHMgSSBsaXN0ZWQsIAogIHRoYXQgc2VlbXMgdG8gZG88 QlI+dGhlIHRyaWNrLiBXaGF0IGRpZCB5b3UgdGhpbmsgdGhhdCB0aGUgR3VpZGVsaW5lcyBhcmUg CiAgc3VnZ2VzdGluZz88QlI+PEJSPiZndDs8QlI+Jmd0OyBUaGFua3M8QlI+Jmd0OzxCUj4mZ3Q7 IEVkdWFyZG88QlI+PEJSPi4uIAogIHNuaXA8QlI+PEJSPiZndDsgMy4gSSBzZWU6PEJSPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgMS4zLjYuMS4yLjEueHguMS42Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIGRvY3NTdWJNZ3RDbUZpbHRlclRhYmxlPEJSPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgMS4zLjYuMS4yLjEueHguMS42LjEm bmJzcDsmbmJzcDsmbmJzcDsgCiAgZG9jc1N1Yk1ndENtRmlsdGVyRW50cnk8QlI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAxLjMuNi4xLjIuMS54eC4xLjYuMS4xJm5ic3A7 IAogIGRvY3NTdWJNZ3RTdWJGaWx0ZXJEb3duc3RyZWFtPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgCiAgMS4zLjYuMS4yLjEueHguMS42LjEuMiZuYnNwOyAKICBkb2NzU3Vi TWd0U3ViRmlsdGVyVXBzdHJlYW08QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAKICAxLjMuNi4xLjIuMS54eC4xLjYuMS4zJm5ic3A7IAogIGRvY3NTdWJNZ3RDbUZpbHRlckRv d25zdHJlYW08QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKICAxLjMuNi4x LjIuMS54eC4xLjYuMS40Jm5ic3A7IAogIGRvY3NTdWJNZ3RDbUZpbHRlclVwc3RyZWFtPEJSPiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgSSB0aGluayB0aGF0IGZvciBuYW1pbmcgCiAgY29uc2lzdGVu Y3ksIGl0IG1pZ2h0IGJlIGJldHRlciB0byAKICByZW5hbWU8QlI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxLjMuNi4xLjIuMS54eC4xLjYuMS4xJm5ic3A7IAogIGRvY3NTdWJN Z3RTdWJGaWx0ZXJEb3duc3RyZWFtPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgCiAgMS4zLjYuMS4yLjEueHguMS42LjEuMiZuYnNwOyAKICBkb2NzU3ViTWd0U3ViRmlsdGVy VXBzdHJlYW08QlI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBpbnRvIHNvbWV0aGluZyAKICBsaWtl OjxCUj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuMy42LjEuMi4xLnh4LjEu Ni4xLjEmbmJzcDsgCiAgZG9jc1N1Yk1ndENtU3ViRmlsdGVyRG93bnN0cmVhbTxCUj4mZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IAogIDEuMy42LjEuMi4xLnh4LjEuNi4xLjImbmJz cDsgCiAgZG9jc1N1Yk1ndENNbXViRmlsdGVyVXBzdHJlYW08QlI+Jmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBzbyBhcyB0byBtYWtlIGl0IAogIGNsZWFyZXIgKGZyb20gdGhlIG5hbWUvZGVzY3JpcHRv cikgdGhhdCB0aGVzZSAyPEJSPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgCiAgb2JqZWN0cyBleGlz dHMgaW4gdGhlIGRvY3NTdWJNZ3RDbUZpbHRlclRhYmxlLjxCUj4mZ3Q7PEJSPjxCUj4uLiAKICBz bmlwPEJSPjxCUj5CZXJ0PEJSPjxCUj48L0ZPTlQ+PC9QPjwvQkxPQ0tRVU9URT4KCjwvQk9EWT4K PC9IVE1MPg== ------_=_NextPart_001_01C469DC.8DFA9FFA-- --===============2096819045== 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 --===============2096819045==-- From ipcdn-bounces@ietf.org Thu Jul 15 05:48:57 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07183 for ; Thu, 15 Jul 2004 05:48:57 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl2rJ-0003tP-DS for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 05:48:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl2qV-0003aw-00 for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 05:48:08 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl2q3-0003IC-00 for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 05:47:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl2kD-0004Cn-SS; Thu, 15 Jul 2004 05:41:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl2fp-0002Wo-On for ipcdn@megatron.ietf.org; Thu, 15 Jul 2004 05:37:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06749 for ; Thu, 15 Jul 2004 05:37:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl2fn-00006A-CH for ipcdn@ietf.org; Thu, 15 Jul 2004 05:37:03 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl2eq-0007Zr-00 for ipcdn@ietf.org; Thu, 15 Jul 2004 05:36:04 -0400 Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx with esmtp (Exim 4.12) id 1Bl2eH-0007GU-00 for ipcdn@ietf.org; Thu, 15 Jul 2004 05:35:29 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6F9ZTrO022873 for ; Thu, 15 Jul 2004 04:35:30 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 15 Jul 2004 11:35:28 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504D05EF4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Ipcdn (E-mail)" Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Date: Thu, 15 Jul 2004 11:35:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 OK, so Eduardo and I discussed this a bit more off-line, because I was not sure I was understanding his comments. I think I now got it. Eduardo I think wanted to express that the MIB review Guidelines do suggest that the best solution would be to rename all of these: 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream into: 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmFilterSubDownstream 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCmFilterSubUpstream 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterCmDownstream 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterCmUpstream which is completely inline with the MIB review Guidelines. My original suggestion for change was not as drastic. YES... the above change of names would even be BETTER and more consistent qith the MIB Review Guidelines. It is not a MUST CHANGE though. But I would think everyone would agree that following a good naming convention will be better for all of us (MIB developers) to avoid name conflicts now and in the future. Thanks, Bert -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: woensdag 14 juli 2004 21:56 To: Wijnen, Bert (Bert); wsawyer@ieee.org; sawyerwd@comcast.net; Ipcdn (E-mail) Cc: Harrie Hazewinkel Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Just looking for a clarification of how to interpret the OPS guidelines. "Should be... " is being obscure for me compared with "RECOMMENDED" also that is at some point "quasy-mandatory" by MIB doctors reviews, That's why I ask the question in a generic way for multiple editors/authors - good to have your perspective. My only recollection of theoretical prefix complains is in smilib for the common model tool that uses heuristics for dependencies discovery (?) I got confused if the 'CM' should be added ( recommended) to the SomeOtherName part of xxxZzzSomeotherName Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Wed 7/14/2004 1:18 PM To: Eduardo Cardona; wsawyer@ieee.org; sawyerwd@comcast.net; Ipcdn (E-mail) Cc: Harrie Hazewinkel Subject: RE: [ipcdn] AD review of: draft-ietf-ipcdn-subscriber-mib-14.txt Eduardo writes: > > Bert, > For the benefot of other authors/editors in the same path of > AD evaluation, > I see your comment 3 a little deviation of OPS guidelines Appendix C: > - The descriptor associated with a conceptual table should be of the > form xxxZzzTable; the descriptor associated with the corresponding > conceptual row should be of the form xxxZzzEntry; the name of the > associated SEQUENCE type should be of the form XxxZzzEntry; and > the descriptors associated with the subordinate columnar objects > should be of the form xxxZzzSomeotherName. > > I presume it is a typo and you would like see extrict > compliance to those recommendations > Any comments? > Not sure I understand. The idea of the Guidelines is to show that (ideally) all columns wthin one table have a common prefix (that sets them apart from other objects in the same (or even otehr) MIB module(s) ). So by inserting the "Cm" for the two objects I listed, that seems to do the trick. What did you think that the Guidelines are suggesting? > > Thanks > > Eduardo .. snip > 3. I see: > 1.3.6.1.2.1.xx.1.6 docsSubMgtCmFilterTable > 1.3.6.1.2.1.xx.1.6.1 docsSubMgtCmFilterEntry > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > 1.3.6.1.2.1.xx.1.6.1.3 docsSubMgtCmFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.4 docsSubMgtCmFilterUpstream > I think that for naming consistency, it might be better to rename > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtSubFilterUpstream > into something like: > 1.3.6.1.2.1.xx.1.6.1.1 docsSubMgtCmSubFilterDownstream > 1.3.6.1.2.1.xx.1.6.1.2 docsSubMgtCMmubFilterUpstream > so as to make it clearer (from the name/descriptor) that these 2 > objects exists in the docsSubMgtCmFilterTable. > .. snip Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 15 07:59:09 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13862 for ; Thu, 15 Jul 2004 07:59:09 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl4tK-000725-EQ for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 07:59:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl4rf-00065G-00 for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 07:57:29 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl4pv-0005VE-00 for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 07:55:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl4jv-0006r9-24; Thu, 15 Jul 2004 07:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl4en-00059a-2o for ipcdn@megatron.ietf.org; Thu, 15 Jul 2004 07:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12737 for ; Thu, 15 Jul 2004 07:44:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl4em-0001jA-GR for ipcdn@ietf.org; Thu, 15 Jul 2004 07:44:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl4dk-0001Lp-00 for ipcdn@ietf.org; Thu, 15 Jul 2004 07:43:06 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Bl4cp-0000j1-00 for ipcdn@ietf.org; Thu, 15 Jul 2004 07:42: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 i6FBfYbw012098; Thu, 15 Jul 2004 05:41:34 -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] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 2 Date: Thu, 15 Jul 2004 05:41:34 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E5C4@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 2 Thread-Index: AcRp/Sd7gRKtK3OmThexiBquclIT/gAY27tQ From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar 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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Very much appreciated Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, July 14, 2004 2:06 PM To: Ipcdn (E-mail) Subject: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt - part 2 OK, here is part 2. AT the bottom I also have repreated part 1, so you=20 have it all in one email in case that is handy. more or less serious (I continue with number 12): 12. I see: docsBpi2CmtsProvisionedCmCertStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Standard RowStatus object except: a) if a row has ever been activated, a set to docsBpi2CmtsProvisionedCmCert need not succeed, b) inactive rows need not be timed out." So you are changing the rules of the RowStatus TC? Seems not allowed to me. nits/administrative/questions (continue with muber 2): 2. I see: docsBpi2CmtsCACertSubject OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The subject name exactly as it is encoded in the X509 certificate. The organizationName portion of the certificate's subject name must be present. All other fields are optional. Any optional field present must be prepended with (carriage return) (line feed) ASCII characters. Ordering of fields present must conform to: organizationName countryName A 7-bit ASCII character (which CR and LF are) does get represented exactly the same when UTF-8 encoded. But it is kind of weird to speak about ASCII characters when discussing the content of a UTF-8 based OCTET STRING. I checked with our UTF-8 and Unicode expert (Patrik Faltstrom) and he comes up with this suggestion: Replace sentence: Any optional field present must be prepended with (carriage return) (line feed) ASCII characters. with: Any optional field present must be prepended with (carriage return, U+000D) and (line feed, U+000A). You have this in a number of objects, pls check them all. 3. I see: docsBpi2CmDeviceCmCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-write STATUS current DESCRIPTION "The X509 DER-encoded cable modem certificate. Note: This object can be set only when the value is the null string. Once the object contains the certificate, its access MUST be read-only." Maybe this is just wording.=20 - First, I already discussed the "null string" issue. I think you mean=20 a zero length string or maybe better "zero length certificate" or "zero length OCTET STRING" or "zero length value". - Now, it seems to me that if the requirement is that the object has a zero length value in order for a SET to be accepted, then, when someone tries a SET while there is already a value, that then the system ought to return a error that explains what is wrong. I.e. an error that would otherwise not occur. If you get a notWritable, then the management station does not necassarily know why that is, see bullet 2 page 20 of RFC3416 or point 9 on page 21. Maybe a better error would be a inconsistentValue, point 10 on page 21 of RFC3416?? Does that not seem a better way to indicate this error? 4. I see: docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE SYNTAX INTEGER { none(0), des56CbcMode(1), des40CbcMode(2) } MAX-ACCESS read-only I understand that this is read-only and so can only report what is in the=20 Cm. But I would not be surprised if this will cause questions from the security folk. Is this the only envryption that is supported? 5. I see: docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE SYNTAX INTEGER { trusted (1), untrusted (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines the default trust of self-signed manufacturer certificate entries, contained in docsBpi2CmtsCACertTable, created after setting the object." I cannot say that I understand what "afetr setting the object" means. which object? Thanks, Bert=20 > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: woensdag 14 juli 2004 18:03 > To: Ipcdn (E-mail) > Subject: [ipcdn] AD review of: draft-ietf-ipcdn-bpiplus-mib-12.txt -=20 > part 1 >=20 >=20 > Sorry, it took too long to finally get this done. >=20 > Not sure this document is ready for IETF Last Call. > Actaully I think it is not. >=20 > This is part 1. Mainly serious things. > I may have more nits/admin stuff later. >=20 > Here are my findings. >=20 > More or less serious: > 1. I see various read-write and/or read-create objects and I do > not see any text in the DESCRIPTION clauses (non > STorageType objects) > that tell me what the expected behaviour is w.r.t.=20 > persistency of such > objects. SO what happens after a restart/reboot? >=20 > 2. I see a number of ZeroBasedCOunter32 objects that have text aka: > (for example docsBpi2CmAuthentInfos) > DESCRIPTION > "The value of this object is the count of > times the CM > has transmitted an Authentication Information message, > since reboot." > It is OK to tell us that a ZeroBasedCOunter32 object must=20 > start with zero > at (re-)boot time or at row creation. > But from that point on, a ZeroBasedCounter32 behaves=20 > exactly the same > as a Counter32, and so it is incorrect to say "count of X=20 > since reboot" > because the Counter32 may have wrapped!. Possibly this is not gonna > happen in practice, but literally the claim is incorrect. >=20 > 3. For these ZeroBasedCounter32 objects, I also see no word > about a possible > discontinuity timer. Why not. Can there NEVER be a=20 > discontinuity? Of if > there is one does that mean ALL counters experience a=20 > discontionuity? > The latter is what you basically state (or cause) by not=20 > pointing to a > specific discontinuity timer. Because then by default it=20 > is sysUpTime, and > so that means that when you DO experience a discontinuity,=20 > then you MUST=20 > reset sysUpTime and that means that a discontinuity for=20 > EVERYONE (object) > that assumes the default. If such is intended, then fine,=20 > but it would be > good to then state that sysUpTime is the discontinuity timer. >=20 > 4. I see that for some objects you speak about a "null > string" or "NULL string". > The base data type for such objects is OCTET STRING. In=20 > all those cases > I suspect (but I am not sure) that you mean the=20 > zero-length octet string. > Otherwise I do not understand what "null string" means. > Pls explain and fix. >=20 > 5. For docsBpi2CmtsAuthCmExpiresOld I see: > Note: For CMs running in BPI mode, implementation of this > object is optional and MAY vary." > Mmm... that sounds like a MODULE-COMPLIANCE aspect and I > would rather > see such things in MODULE-COMPLIANCE and not in object=20 > DESCRIPTION clauses. >=20 > 6. I see: > -- Note: the following object has been obsoleted >=20 > docsBpi2CmtsAuthCmReset OBJECT-TYPE > SYNTAX INTEGER { > noResetRequested(1), > invalidateAuth(2), > sendAuthInvalid(3), > invalidateTeks(4) > } > MAX-ACCESS read-write > STATUS current >=20 > So the --Note: is out of sync with the actual status!? > What is it? If it IS obsoleted, then status should sya so, > And DESCRIPTION clause should explain why it was obsoleted. > And the ASN.1 comment line then of course is no longer needed. >=20 > 7. I see: > docsBpi2CmtsAuthCACertIndexPtr OBJECT-TYPE > SYNTAX Integer32 (0..10000) > And find that a strange limit (range). And nowhere, not > even in the=20 > docsBpi2CmtsCACertTable do I see an explanation why that=20 > range makes > sense (assuming that it does). >=20 > 8. When I see: > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastMaskType InetAddressType, > docsBpi2CmtsIpMulticastMask InetAddress, > I wonder if (in the same row) > docsBpi2CmtsIpMulticastMaskType will ever > have a different value then docsBpi2CmtsIpMulticastAddressType !?? > It seems to me that should NOT be allowed, cause otherwise I am not > sure how the ANDing of the Mask is going to work/happen. > So the next question then is why you do not do: > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastMask InetAddress, > And let docsBpi2CmtsIpMulticastAddressType be the=20 > discriminator for both > InetAddresses. One less object, and less change for error/conflict. >=20 > But thinking even further, Possibly the best thing to do is to use > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastPrefixLength =20 > InetAddressPrefixLength, > Are not such masks always setup that they basically > specify a prefix length? > If so, then this is the way to do it with the TCs from=20 > INET-ADDRESS-MIB. >=20 > 9. I see various uses of InetAddress as for example here: > docsBpi2CmtsIpMulticastAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object represents the IP multicast address > to be mapped, in conjunction with > docsBpi2CmtsIpMulticastMask." > The TC for InetAddress (in RFC3291 or its follow on) > clearly state that > you MUST specify which InetAddressType controls the format=20 > of this object > as per DESCRIPTION from InetAddress TC: > An InetAddress value is always interpreted within the context > of an InetAddressType value. Every usage of the InetAddress > textual convention is required to specify the InetAddressType > object which provides the context. ... >=20 > 10. I see: > docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object controls and reflects the IP multicast > address mapping entry. There is no restriction on the > ability to change values in this row while the row is > active. Inactive rows need not be timed out." > Mmm... that "need not be timed out" seems in conflict > with the RowStatus > TC DESCRIPTION clause in RFC2579. Can you explain why this is?=20 >=20 > Also, a RowSTatus object MUST specify in its DESCRIPTION > clause under > which conditions=20 > - the row can be activated > - which columns (if any) can bve changed while in the=20 > active state. > I am missing the first. >=20 > 11. You specify: > -- > -- The BPI+ MIB Conformance Statements (with a placeholder for > -- notifications) > -- >=20 > docsBpi2Notification OBJECT IDENTIFIER > ::=3D { docsBpi2MIB 2 } > docsBpi2Conformance OBJECT IDENTIFIER > ::=3D { docsBpi2MIB 3 } > docsBpi2Compliances OBJECT IDENTIFIER > ::=3D { docsBpi2Conformance 1 } > docsBpi2Groups OBJECT IDENTIFIER > ::=3D { docsBpi2Conformance 2 } >=20 > Why not be (more) consistent with other MIB modules and follow the > suggested OID subtrees as per MIB guidelines,=20 > draft-ietf-ops-mib-review-guidelines-03.txt, appendix D: > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > This is not mandatiory, but consistency is always useful/helpful >=20 >=20 > Nits/administrativia: >=20 > 1. The RFC editor wants all references to have at least one citation > in the document. ALso for the normative references to RFCs from > which you import. See MIB review guidelines, sect 3.5 >=20 > You need to add a citation somehwere for [RFC3411], [RFC2021], > [RFC3291], [RFC2670] >=20 > Thanks, > Bert >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=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 Jul 15 13:24:45 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05834 for ; Thu, 15 Jul 2004 13:24:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9yR-0004UL-Ho for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 13:24:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9xT-00046m-00 for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 13:23:47 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9wZ-0003Up-00 for ipcdn-archive@ietf.org; Thu, 15 Jul 2004 13:22:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9kx-0001FN-4M; Thu, 15 Jul 2004 13:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9XC-0005DV-Qk for ipcdn@megatron.ietf.org; Thu, 15 Jul 2004 12:56:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03761 for ; Thu, 15 Jul 2004 12:56:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9XB-0002aS-Lh for ipcdn@ietf.org; Thu, 15 Jul 2004 12:56:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9WH-0002FP-00 for ipcdn@ietf.org; Thu, 15 Jul 2004 12:55:42 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9VY-0001ru-00; Thu, 15 Jul 2004 12:54:56 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bl9LU-0001Jo-UX; Thu, 15 Jul 2004 12:44:32 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 15 Jul 2004 12:44:32 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] Last Call: 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management' to Proposed Standard X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@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-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-08-06 (note: some extra time (3 weeks) because IETF 60 is coming up). The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-14.txt _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jul 19 19:46:27 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 TAA09491 for ; Mon, 19 Jul 2004 19:46:27 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmhq2-0005V9-6l for ipcdn-archive@ietf.org; Mon, 19 Jul 2004 19:46:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmhMi-00013e-EK; Mon, 19 Jul 2004 19:16:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bmewl-0000Yw-3M for ipcdn@megatron.ietf.org; Mon, 19 Jul 2004 16:41: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 QAA27976 for ; Mon, 19 Jul 2004 16:41:12 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmets-0002Dm-0H for ipcdn@ietf.org; Mon, 19 Jul 2004 16:38:16 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Bme7t-0003cp-AY for ipcdn@ietf.org; Mon, 19 Jul 2004 15:48:41 -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 i6JJmIbw015526; Mon, 19 Jul 2004 13:48:19 -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] response to ETSI liaison Date: Mon, 19 Jul 2004 13:48:18 -0600 Message-ID: Thread-Topic: [ipcdn] response to ETSI liaison Thread-Index: AcRaD5O/L6y01F4HSWuxQlFeRRx4BQLBwkhAAPGivzABOu/acA== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.9 (/) X-Scan-Signature: 21f6736b171db90b7af90d77f0c0e285 Cc: Bill Utlaut , Beacham Gordon-CGB005 , David De Reu , Christie Poland , skang@upctechnology.com, Thomas Anders , "Richard Woundy @ Comcast" , Wim De Ketelaere , 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: , Content-Type: multipart/mixed; boundary="===============1420605099==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 This is a multi-part message in MIME format. --===============1420605099== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46DC9.56DFAC00" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46DC9.56DFAC00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I received no comments on the proposed draft response provided on = July 13 for wg review. I assume the text is ok and will send it to ETSI.=20 =20 Jean-Francois. IPCDN co-chair -----Original Message----- From: Jean-Francois Mule=20 Sent: Tuesday, July 13, 2004 8:57 AM To: ipcdn@ietf.org Cc: Bill Utlaut; Beacham Gordon-CGB005; David De Reu; Christie Poland; = Richard Woundy @ Comcast; Thomas Anders; skang@upctechnology.com; Wim De = Ketelaere; bwijnen@lucent.com Subject: [ipcdn] Draft response to ETSI liaison for wg comments by 7/20 =09 =09 This note provides a draft response to the ETSI liaison statement. = The ETSI liaison was sent to the ipcdn list on June 16. The wg response = is based on previous contributions & email exchanges from many = participants. It is submitted for wg review & comments. We would like to send our = response back to ETSI next week; please send any comments by July 20 = 11am Easter Time. Thanks to all of you who have contributed in the past months on these = topics,=20 Jean-Fran=E7ois=20 --- To: ETSI AT working group Digital Cc: Simon Kang (UPC) Wim De Ketelaere (tComLabs) Gordon Beacham (Motorola BCS) Bill Utlaut (CableLabs) =09 RE: ETSI liaison from ETSI AT-Digital, AT-D AT#9(2004)D_25 =09 We would like to thank ETSI and Simon Kang of UPC, Rapporteur of the ETSI AT-D IPCablecom MIB requirements for your continued support of the work of the IETF IP over Cable Data Network (IPCDN) working group in creating one common set of MIBs standardized in IETF. We have received the ETSI liaison statement dated from June 8 2004 regarding the IPCablecom MIB requirements. This note constitutes the IPCDN working group response. It first provides some information on the ipcdn schedule and timeline to publish the RFCs. It also documents the IPCDN working group consensus on the ETSI technical comments. =09 Best regards, Rich Woundy and Jean-Francois Mule IETF IPCDN co-chairs =09 --- 1. Request for information about the ipcdn schedule for the --- approval of the ietf ipcdn packetcable mibs to published RFC --- status taking account of all ETSI comments as summarised in the --- liaison statement AT-D AT#9(2004)D_25 =09 As of July 2004, the 3 IPCDN wg Internet-Drafts in question are "work in progress" documents: draft-ietf-ipcdn-pktc-mtamib-03, draft-ietf-ipcdn-pktc-signaling-03, draft-ietf-ipcdn-pktc-eventmess-03. The procedures for advancing IETF Internet-Drafts are described in BCP 9, RFC2026 (and some procedures are explained in RFC 3160). =09 It is the intent of the IPCDN wg chairs to advance those Internet-Drafts to publication via a formal "publication request" to the IETF Operations and Management Area Directors and our Area Advisor for ipcdn, Bert Wijnen after the following conditions are met: a) all the ETSI comments received in the liaison have been addressed and integrated in revised drafts; Based on the information we have received from the authors and editors of those drafts, we believe that draft04 revisions will be submitted by July 19 and will appear on the IETF Internet-Draft repository by August 2004. =09 b) Working group last call is passed We will issue a 2-week Working Group Last Call notice once the draft04 revisions are published. =09 c) Expert MIB doctor reviews are complete and revised drafts published The assignment of MIB doctors will occur once the draft04s are released and a timeline for completion of MIB doctor reviews will be defined then. We expect that revised drafts addressing all the MIB doctor comments will be published in September 2004. =09 Following the wg chair formal "publication request" to the Area Directors, the work of the working group is usually considered complete. As stated above, we expect to conclude our work on the IPCDN PacketCable/IPCablecom MIBs in September 2004. The standard IETF process will then follow its course with IESG Review and approval (including IETF Last Call) and, upon successful completion of the last call announcement, the final documents will be sent to the RFC Editors. A rough timeline for the final IETF steps is difficult to predict and we will have a better estimate once the IETF Last Call is complete. =09 =09 --- 2. Response to ETSI technical recommendations We note that all the ETSI recommendations relate to one IPCDN Internet-Draft: ID: draft-ietf-ipcdn-pktc-signaling-03. We assume the other drafts have been reviewed by ETSI and meet your requirements. =09 2.1) NCS service flow mechanism: The IPCDN working group is in agreement with the ETSI recommendation to delete the following 4 MIB objects from draft-ietf-ipcdn-pktc-signaling-03: pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask, and pktcSigNcsServiceFlowState. =09 2.2) Ringing cadences: The IPCDN working group is in agreement with the ETSI recommendation to change the definition of the PktcRingCadence textual-convention and its use for every ring cadence defined in the MIB. Note that this topic had already been discussed on IPCDN in March 2004 and that we had reached agreement to change the SYNTAX of the textual-convention. The ETSI liaison makes some additional editorial suggestions in the DESCRIPTION clause of the textual convention and we accept those comments. See ipcdn email references at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01119.html = =20 http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01122.html = =20 =09 =09 2.3) Value Ranges: We note that ETSI supports the IPCDN discussions to change the value range of the pktcSigDevToneDbLevel object to pktcSigDevToneDbLevel OBJECT-TYPE SYNTAX TenthdBm (-250..-30) The IPCDN wg has reached consensus on the above change and the new value range (-250..-30) will be reflected in the revised draft04. Note that the value range of some other MIB objects were also discussed on the IPCDN list and that some changes will be reflected in the upcoming draft04, for e.g., the range of pktcSigPulseSignalDbLevel is changed from (-250..152) to (-350...0). =09 =09 --- end of response to the ETSI liaison statement=20 ------_=_NextPart_001_01C46DC9.56DFAC00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
   I received no comments on the = proposed=20 draft response provided on July 13 for wg review.
   I assume the text is ok and will = send it to ETSI. =
 
Jean-Francois.
IPCDN co-chair
-----Original Message-----
From: = Jean-Francois=20 Mule
Sent: Tuesday, July 13, 2004 8:57 AM
To:=20 ipcdn@ietf.org
Cc: Bill Utlaut; Beacham Gordon-CGB005; David = De Reu;=20 Christie Poland; Richard Woundy @ Comcast; Thomas Anders;=20 skang@upctechnology.com; Wim De Ketelaere;=20 bwijnen@lucent.com
Subject: [ipcdn] Draft response to ETSI = liaison=20 for wg comments by 7/20


  This = note provides=20 a draft response to the ETSI liaison statement. The ETSI liaison was = sent to=20 the ipcdn list on June 16. The wg response is based on previous = contributions=20 & email exchanges from many participants.

  It is = submitted for=20 wg review & comments. We would like to send our response back to = ETSI next=20 week; please send any comments by July 20 11am Easter = Time.

Thanks to = all of you who=20 have contributed in the past months on these topics, =
Jean-Fran=E7ois =

---
To:  ETSI AT=20 working group Digital
Cc:  Simon Kang=20 (UPC)
     Wim De Ketelaere=20 (tComLabs)
     Gordon Beacham (Motorola=20 BCS)
     Bill Utlaut = (CableLabs)

RE:  ETSI=20 liaison from ETSI AT-Digital, AT-D AT#9(2004)D_25

  We = would like=20 to thank ETSI and Simon Kang of UPC, Rapporteur of the
ETSI AT-D = IPCablecom=20 MIB requirements for your continued support of
the work of the IETF = IP over=20 Cable Data Network (IPCDN) working group
in creating one common set = of MIBs=20 standardized in IETF.
  We have received the ETSI liaison = statement=20 dated from June 8 2004
regarding the IPCablecom MIB = requirements.
 =20 This note constitutes the IPCDN working group response. It = first
provides=20 some information on the ipcdn schedule and timeline to
publish the = RFCs. It=20 also documents the IPCDN working group consensus
on the ETSI = technical=20 comments.

Best regards,
Rich Woundy and Jean-Francois=20 Mule
 IETF IPCDN co-chairs

--- 1. Request for information about the = ipcdn schedule=20 for the
---    approval of the ietf ipcdn packetcable = mibs to=20 published RFC
---    status taking account of all ETSI = comments as=20 summarised in the
---    liaison statement AT-D=20 AT#9(2004)D_25

As of July=20 2004, the 3 IPCDN wg Internet-Drafts in question are
"work in = progress"=20 documents:
   = draft-ietf-ipcdn-pktc-mtamib-03,
  =20 draft-ietf-ipcdn-pktc-signaling-03,
  =20 draft-ietf-ipcdn-pktc-eventmess-03.
The procedures for advancing = IETF=20 Internet-Drafts are described in
BCP 9, RFC2026 (and some = procedures are=20 explained in RFC 3160).

It is the intent of the IPCDN wg chairs = to=20 advance those
Internet-Drafts to publication via a formal = "publication=20 request" to
the IETF Operations and Management Area Directors and = our Area=20 Advisor
for ipcdn, Bert Wijnen after the following conditions are=20 met:
   a) all the ETSI comments received in the liaison = have=20 been
      addressed and integrated in = revised=20 drafts;
Based on the information we have received from the authors=20 and
editors of those drafts, we believe that draft04 revisions will = be
submitted by July 19 and will appear on the IETF=20 Internet-Draft
repository by August 2004.

   b) = Working=20 group last call is passed
We will issue a 2-week Working Group Last = Call=20 notice once the draft04
revisions are = published.

   c)=20 Expert MIB doctor reviews are complete and revised=20 drafts
      published
The assignment = of MIB=20 doctors will occur once the draft04s are released
and a timeline = for=20 completion of MIB doctor reviews will be defined
then. We expect = that=20 revised drafts addressing all the MIB doctor
comments will be = published in=20 September 2004.

Following the wg chair formal "publication = request" to=20 the Area
Directors, the work of the working group is usually=20 considered
complete. As stated above, we expect to conclude our = work on the=20 IPCDN
PacketCable/IPCablecom MIBs in September 2004.
The = standard IETF=20 process will then follow its course with IESG Review
and approval=20 (including IETF Last Call) and, upon successful
completion of the = last call=20 announcement, the final documents will be
sent to the RFC Editors. = A rough=20 timeline for the final IETF steps is
 difficult to predict and = we will=20 have a better estimate once the IETF
Last Call is=20 complete.


--- 2. Response to ETSI technical = recommendations
We note that all the ETSI = recommendations relate to=20 one IPCDN
Internet-Draft: ID: draft-ietf-ipcdn-pktc-signaling-03. = We assume=20 the
other drafts have been reviewed by ETSI and meet your=20 requirements.

2.1) NCS service=20 flow mechanism:
The = IPCDN=20 working group is in agreement with the ETSI recommendation
to = delete the=20 following 4 MIB objects = from
draft-ietf-ipcdn-pktc-signaling-03:
 =20 pktcSigServiceClassNameUS,
  = pktcSigServiceClassNameDS,
 =20 pktcSigServiceClassNameMask, and
 =20 pktcSigNcsServiceFlowState.

2.2)=20 Ringing cadences:
The IPCDN=20 working group is in agreement with the ETSI recommendation
to = change the=20 definition of the PktcRingCadence textual-convention and
its use = for every=20 ring cadence defined in the MIB.
Note that this topic had already = been=20 discussed on IPCDN in March 2004
and that we had reached agreement = to=20 change the SYNTAX of the
textual-convention.
The ETSI liaison = makes some=20 additional editorial
suggestions in the DESCRIPTION clause of the = textual=20 convention and we
accept those comments.
See ipcdn email = references=20 at:
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01119.htm= l
  = http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01122.htm= l


2.3) Value=20 Ranges:
We note that = ETSI=20 supports the IPCDN discussions to change the
value range of the=20 pktcSigDevToneDbLevel object to
  =20 pktcSigDevToneDbLevel   =20 OBJECT-TYPE
      =20 SYNTAX       TenthdBm (-250..-30)
The = IPCDN=20 wg has reached consensus on the above change and the new
value = range=20 (-250..-30) will be reflected in the revised draft04.
Note that the = value=20 range of some other MIB objects were also
discussed on the IPCDN = list and=20 that some changes will be reflected in
the upcoming draft04, for = e.g., the=20 range of pktcSigPulseSignalDbLevel
is changed from (-250..152) to=20 (-350...0).


--- end of response to the ETSI liaison statement=20

=00 ------_=_NextPart_001_01C46DC9.56DFAC00-- --===============1420605099== 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 --===============1420605099==-- From ipcdn-bounces@ietf.org Tue Jul 20 19:51:38 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 TAA04010 for ; Tue, 20 Jul 2004 19:51:38 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn4Op-0001AF-76 for ipcdn-archive@ietf.org; Tue, 20 Jul 2004 19:51:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn1PW-0007yJ-Q4; Tue, 20 Jul 2004 16:40:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0vx-0004tQ-6q; Tue, 20 Jul 2004 16:09:53 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24008; Tue, 20 Jul 2004 16:09:50 -0400 (EDT) Message-Id: <200407202009.QAA24008@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, 20 Jul 2004 16:09:50 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-04.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: 5011df3e2a27abcc044eaa15befcaa87 --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-04.txt Pages : 51 Date : 2004-7-20 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-04.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-04.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-04.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-7-20155941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-mtamib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-mtamib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155941.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 Jul 20 19:57: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 TAA05269 for ; Tue, 20 Jul 2004 19:57:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn4Ua-0001Y3-Jw for ipcdn-archive@ietf.org; Tue, 20 Jul 2004 19:57:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn22m-00043H-T4; Tue, 20 Jul 2004 17:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn0wX-000524-7U; Tue, 20 Jul 2004 16:10:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24158; Tue, 20 Jul 2004 16:10:27 -0400 (EDT) Message-Id: <200407202010.QAA24158@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, 20 Jul 2004 16:10:26 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-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: a8a20a483a84f747e56475e290ee868e --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-05.txt Pages : 55 Date : 2004-7-20 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-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-signaling-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-signaling-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-7-20155948.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-pktc-signaling-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-pktc-signaling-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-20155948.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 Wed Jul 21 09:27: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 JAA16233 for ; Wed, 21 Jul 2004 09:27:30 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnH8T-0002co-R9 for ipcdn-archive@ietf.org; Wed, 21 Jul 2004 09:27:55 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnH0n-0004zE-HS; Wed, 21 Jul 2004 09:19:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnGhQ-0007Jk-K1 for ipcdn@megatron.ietf.org; Wed, 21 Jul 2004 08:59: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 IAA14751 for ; Wed, 21 Jul 2004 08:59:54 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnGhl-0002JJ-A9 for ipcdn@ietf.org; Wed, 21 Jul 2004 09:00:18 -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 i6LCxMbw006509 for ; Wed, 21 Jul 2004 06:59:22 -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] WGLC on draft-ietf-ipcdn-pktc-mtamib-04.txt Date: Wed, 21 Jul 2004 06:59:21 -0600 Message-ID: Thread-Topic: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-mtamib-04.txt Thread-Index: AcRutLXk4SPwCsdITnCgxcnp8FO+zwAbX3ow From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable =20 Rich and I would like to start another WGLC last call on this ID. Please send your comments to the authors and the ipcdn list by August 10 (extended 3 week WGLC due to the IETF meeting). Jean-Francois. IPCDN co-chair. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, July 20, 2004 2:10 PM > To: i-d-announce@ietf.org > Cc: ipcdn@ietf.org > Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-mtamib-04.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) Management=20 > Information Base for PacketCable and=20 > IPCablecom=20 > compliant devices > Author(s) : E. Nechamkin, J. Mule > Filename : draft-ietf-ipcdn-pktc-mtamib-04.txt > Pages : 51 > Date : 2004-7-20 > =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-04.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-04.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-04.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 Wed Jul 21 09:28: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 JAA16368 for ; Wed, 21 Jul 2004 09:28:36 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnH9Y-0002fW-V3 for ipcdn-archive@ietf.org; Wed, 21 Jul 2004 09:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnH1z-0005jY-PE; Wed, 21 Jul 2004 09:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnGi7-0007S6-2D for ipcdn@megatron.ietf.org; Wed, 21 Jul 2004 09:00:39 -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 JAA14823 for ; Wed, 21 Jul 2004 09:00:37 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnGiS-0002Jk-P7 for ipcdn@ietf.org; Wed, 21 Jul 2004 09:01: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 i6LD05bw006773 for ; Wed, 21 Jul 2004 07:00: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: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-05 Date: Wed, 21 Jul 2004 07:00:05 -0600 Message-ID: Thread-Topic: [ipcdn] WGLC on draft-ietf-ipcdn-pktc-signaling-05 Thread-Index: AcRutXxZveoR+mmRSBaTmvHaFIl0BwAbRIFQ From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable =20 Rich and I would like to start another WGLC last call on this ID. Please send your comments to the authors and the ipcdn list by August 10 (extended 3 week WGLC due to the IETF meeting). Rich and Jean-Francois. IPCDN co-chairs. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, July 20, 2004 2:10 PM > To: i-d-announce@ietf.org > Cc: ipcdn@ietf.org > Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-pktc-signaling-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 : Network-Based Call Signaling (NCS)=20 > Signaling MIB for=20 > PacketCable and IPCablecom Multimedia=20 > Terminal=20 > Adapters (MTAs) > Author(s) : G. Beacham, et al. > Filename : draft-ietf-ipcdn-pktc-signaling-05.txt > Pages : 55 > Date : 2004-7-20 > =09 > This memo defines the Signaling Management Information Base (MIB) =20 > for use with network management protocols in the Internet community.=20 > In particular, it provides a common data and format representation =20 > for PacketCable/IPCablecom compliant Multimedia Terminal Adapter =20 > devices. =20 > This memo specifies a MIB module in a manner that is compliant to=20 > the SNMP SMIv2. The set of objects are consistent with the SNMP=20 > framework and existing SNMP standards. >=20 > A URL for this Internet-Draft is:=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-sign aling-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-signaling-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-signaling-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 Wed Jul 21 11:42:23 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 LAA28007 for ; Wed, 21 Jul 2004 11:42:23 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnJF3-0004g8-Dr for ipcdn-archive@ietf.org; Wed, 21 Jul 2004 11:42:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnJ67-0004t1-6A; Wed, 21 Jul 2004 11:33:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnJ1e-0002ZW-Qv for ipcdn@megatron.ietf.org; Wed, 21 Jul 2004 11:29:00 -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 LAA26954 for ; Wed, 21 Jul 2004 11:28:56 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnJ21-0004Ud-EW for ipcdn@ietf.org; Wed, 21 Jul 2004 11:29:22 -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 i6LFS9cJ013981; Wed, 21 Jul 2004 09:28:20 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Jul 2004 09:28:18 -0600 Message-ID: Thread-Topic: IETF IPCDN response to ETSI Liaison from ETSI AT-Digital re. packet Cable MIBs Thread-Index: AcRNX86AlVy8bPsHRRyI4lEF6avKegh1Yx7w From: "Jean-Francois Mule" To: "Simon Kang - UPC" , "Ted Laverack" X-Approved: ondar X-Spam-Score: 0.9 (/) X-Scan-Signature: 7b8e6f6ef974ecda19a6b57d59caeb7d Cc: Jean-Francois Mule , Gordon Beacham , Ian Marshall_Internet , bwijnen@lucent.com, "Richard Woundy @ Comcast" , Wim de Ketelaere , ipcdn@ietf.org, ATsupport Subject: [ipcdn] IETF IPCDN response to ETSI Liaison from ETSI AT-Digital re. packet Cable MIBs 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="===============1716085279==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e This is a multi-part message in MIME format. --===============1716085279== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C46F37.5972E300" This is a multi-part message in MIME format. ------_=_NextPart_001_01C46F37.5972E300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ---=20 From: IETF IPCDN Co-chairs Richard Woundy (Comcast) Jean-Francois Mule (CableLabs) =20 To: Simon Kang (UPC), ETSI Rapporteur ETSI AT working group Digital Ted Laverack (ETSI) =20 Cc: Wim De Ketelaere (tComLabs) Gordon Beacham (Motorola BCS) Bert Wijnen (Lucent), IETF Area Director Bill Utlaut, Ed Miller (CableLabs) Christie Poland (CableLabs) RE: ETSI liaison from ETSI AT-Digital, AT-D AT#9(2004)D_25 We would like to thank ETSI and Simon Kang of UPC, Rapporteur of the ETSI AT-D IPCablecom MIB requirements for your continued support of the work of the IETF IP over Cable Data Network (IPCDN) working group in creating one common set of MIBs standardized in IETF. We have received the ETSI liaison statement dated from June 8 2004 regarding the IPCablecom MIB requirements. This note constitutes the IPCDN working group response. It first provides some information on the ipcdn schedule and timeline to publish the RFCs. It also documents the IPCDN working group consensus on the ETSI technical comments. Best regards, Rich Woundy and Jean-Francois Mule IETF IPCDN co-chairs --- 1. Request for information about the ipcdn schedule for the --- approval of the ietf ipcdn packetcable mibs to published RFC --- status taking account of all ETSI comments as summarised in the --- liaison statement AT-D AT#9(2004)D_25 As of July 2004, the 3 IPCDN wg Internet-Drafts in question are "work in progress" documents: draft-ietf-ipcdn-pktc-mtamib-04, draft-ietf-ipcdn-pktc-signaling-05, draft-ietf-ipcdn-pktc-eventmess-03. The procedures for advancing IETF Internet-Drafts are described in BCP 9, RFC2026 (and some procedures are explained in RFC 3160). It is the intent of the IPCDN wg chairs to advance those Internet-Drafts to publication via a formal "publication request" to the IETF Operations and Management Area Directors and our Area Advisor for ipcdn, Bert Wijnen after the following conditions are met: a) all the ETSI comments received in the liaison have been addressed and integrated in revised drafts; Based on the information we have received from the authors and editors of those drafts, we believe that the MTA MIB draft04 and MTA Signaling MIB draft05 revisions address all the ETSI comments. b) Working group last call is passed We have issued a Working Group Last Call notice on July 21st 2004 for the MTA MIB draft04 and MTA Signaling MIB draft05. c) Expert MIB doctor reviews are complete and revised drafts published The assignment of MIB doctors will occur now that the revised drafts are published. A timeline for completion of MIB doctor reviews will be defined. We expect that revised drafts addressing all the MIB doctor comments will be published in September 2004. Following the wg chair formal "publication request" to the Area Directors, the work of the working group is usually considered complete. As stated above, we expect to conclude our work on the IPCDN PacketCable/IPCablecom MIBs in September 2004. The standard IETF process will then follow its course with IESG Review and approval (including IETF Last Call) and, upon successful completion of the last call announcement, the final documents will be sent to the RFC Editors. A rough timeline for the final IETF steps is difficult to predict and we will have a better estimate once the IETF Last Call is complete. --- 2. Response to ETSI technical recommendations We note that all the ETSI recommendations relate to one IPCDN Internet-Draft: ID: draft-ietf-ipcdn-pktc-signaling-03. We assume the other drafts have been reviewed by ETSI and meet your requirements. 2.1) NCS service flow mechanism: The IPCDN working group is in agreement with the ETSI recommendation to delete the following 4 MIB objects from draft-ietf-ipcdn-pktc-signaling-03: pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask, and pktcSigNcsServiceFlowState. 2.2) Ringing cadences:=20 The IPCDN working group is in agreement with the ETSI recommendation to change the definition of the PktcRingCadence textual-convention and its use for every ring cadence defined in the MIB. Note that this topic had already been discussed on IPCDN in March 2004 and that we had reached agreement to change the SYNTAX of the textual-convention. The ETSI liaison makes some additional editorial suggestions in the DESCRIPTION clause of the textual convention and we accept those comments. See ipcdn email references at: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01119.html http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01122.html 2.3) Value Ranges: We note that ETSI supports the IPCDN discussions to change the value range of the pktcSigDevToneDbLevel object to pktcSigDevToneDbLevel OBJECT-TYPE SYNTAX TenthdBm (-250..-30) The IPCDN wg has reached consensus on the above change and the new value range (-250..-30) will be reflected in the revised draft04. Note that the value range of some other MIB objects were also discussed on the IPCDN list and that some changes will be reflected in the upcoming draft04, for e.g., the range of pktcSigPulseSignalDbLevel is changed from (-250..152) to (-350...0). The above comments 2.1, 2.2, and 2.3 have been addressed in draft-ietf-ipcdn-pktc-signaling-05. --- end of note -----Original Message----- From: Ted Laverack [mailto:Ted.Laverack@etsi.org]=20 Sent: Tuesday, June 08, 2004 7:52 AM To: Richard Woundy @ Comcast Cc: Jean-Francois Mule; deketelaere@tcomlabs.com; gordon.beacham@motorola.com; Ian Marshall_Internet; ATsupport Subject: Liaison from ETSI AT-Digital re. packet Cable MIBs Dear Richard, I enclose an approved liaison from ETSI AT-Digital for distribution to the IETF ipcdn working group for information and response. Kind regards, Ted Laverack=20 Fixed Network Competence Centre (FCC) Technical Officer for ETSI AT, HF, SAGE and OCG Security=20 Secretary for BB Cablecoms Tel: +33 (0)492 944273=20 Fax: +33 (0)493 654716=20 Mobile: 0672285266=20 mailto:ted.laverack@etsi.org << File: 09D25r1 Liaison Statement ETSI WG-D to IETF ipcdn.doc >>=20 ------_=_NextPart_001_01C46F37.5972E300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IETF IPCDN response to ETSI Liaison from ETSI AT-Digital re. = packet Cable MIBs

---
From: IETF IPCDN = Co-chairs
      Richard Woundy (Comcast)
      Jean-Francois Mule (CableLabs)
     

To:   Simon Kang (UPC), ETSI Rapporteur
      ETSI AT working group Digital
      Ted Laverack (ETSI)
     
Cc:   Wim De Ketelaere (tComLabs)
      Gordon Beacham (Motorola = BCS)
      Bert Wijnen (Lucent), IETF Area = Director
      Bill Utlaut, Ed Miller  (CableLabs)
      Christie Poland (CableLabs)

RE:   ETSI liaison from ETSI AT-Digital, AT-D = AT#9(2004)D_25

  We would like to thank ETSI and Simon Kang of UPC, Rapporteur of = the
ETSI AT-D IPCablecom MIB requirements for your continued support of
the work of the IETF IP over Cable Data Network (IPCDN) working = group
in creating one common set of MIBs standardized in IETF.
  We have received the ETSI liaison statement dated from June 8 = 2004
regarding the IPCablecom MIB requirements.
  This note constitutes the IPCDN working group response. It = first
provides some information on the ipcdn schedule and timeline to
publish the RFCs. It also documents the IPCDN working group = consensus
on the ETSI technical comments.

Best regards,
Rich Woundy and Jean-Francois Mule
 IETF IPCDN co-chairs

--- 1. = Request for information about the ipcdn schedule for the
---    approval of the ietf ipcdn packetcable mibs = to published RFC
---    status taking account of all ETSI comments as = summarised in the
---    liaison statement AT-D = AT#9(2004)D_25

As of July 2004, the 3 IPCDN wg = Internet-Drafts in question are
"work in progress" documents:
   draft-ietf-ipcdn-pktc-mtamib-04,
   draft-ietf-ipcdn-pktc-signaling-05,
   draft-ietf-ipcdn-pktc-eventmess-03.
The procedures for advancing IETF Internet-Drafts are described in
BCP 9, RFC2026 (and some procedures are explained in RFC 3160).

It is the intent of the IPCDN wg chairs to advance those
Internet-Drafts to publication via a formal "publication = request" to
the IETF Operations and Management Area Directors and our Area = Advisor
for ipcdn, Bert Wijnen after the following conditions are met:
   a) all the ETSI comments received in the liaison have = been
      addressed and integrated in revised = drafts;
Based on the information we have received from the authors and
editors of those drafts, we believe that the MTA MIB draft04 and MTA
Signaling MIB draft05 revisions address all the ETSI comments.

   b) Working group last call is passed
We have issued a Working Group Last Call notice on July 21st 2004 = for
the MTA MIB draft04 and MTA Signaling MIB draft05.

   c) Expert MIB doctor reviews are complete and revised = drafts
      published
The assignment of MIB doctors will occur now that the revised drafts
are published. A timeline for completion of MIB doctor reviews will = be
defined. We expect that revised drafts addressing all the MIB doctor
comments will be published in September 2004.

Following the wg chair formal "publication request" to the = Area
Directors, the work of the working group is usually considered
complete. As stated above, we expect to conclude our work on the = IPCDN
PacketCable/IPCablecom MIBs in September 2004.
The standard IETF process will then follow its course with IESG = Review
and approval (including IETF Last Call) and, upon successful
completion of the last call announcement, the final documents will = be
sent to the RFC Editors. A rough timeline for the final IETF steps = is
 difficult to predict and we will have a better estimate once the = IETF
Last Call is complete.


--- 2. = Response to ETSI technical recommendations
We note that all the ETSI = recommendations relate to one IPCDN
Internet-Draft: ID: draft-ietf-ipcdn-pktc-signaling-03. We assume = the
other drafts have been reviewed by ETSI and meet your requirements.

2.1) NCS = service flow mechanism:
The IPCDN working group is in = agreement with the ETSI recommendation
to delete the following 4 MIB objects from
draft-ietf-ipcdn-pktc-signaling-03:
  pktcSigServiceClassNameUS,
  pktcSigServiceClassNameDS,
  pktcSigServiceClassNameMask, and
  pktcSigNcsServiceFlowState.

2.2) = Ringing cadences:
The IPCDN working group is in = agreement with the ETSI recommendation
to change the definition of the PktcRingCadence textual-convention = and
its use for every ring cadence defined in the MIB.
Note that this topic had already been discussed on IPCDN in March = 2004
and that we had reached agreement to change the SYNTAX of the
textual-convention.
The ETSI liaison makes some additional editorial
suggestions in the DESCRIPTION clause of the textual convention and = we
accept those comments.
See ipcdn email references at:
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01119.html
  http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01122.html


2.3) Value = Ranges:
We note that ETSI supports the IPCDN = discussions to change the
value range of the pktcSigDevToneDbLevel object to
   pktcSigDevToneDbLevel    OBJECT-TYPE
       = SYNTAX       TenthdBm (-250..-30)
The IPCDN wg has reached consensus on the above change and the new
value range (-250..-30) will be reflected in the revised draft04.
Note that the value range of some other MIB objects were also
discussed on the IPCDN list and that some changes will be reflected = in
the upcoming draft04, for e.g., the range of = pktcSigPulseSignalDbLevel
is changed from (-250..152) to (-350...0).

The above comments 2.1, 2.2, and 2.3 have been addressed in
draft-ietf-ipcdn-pktc-signaling-05.

--- end = of note



-----Original = Message-----
From: Ted = Laverack [mailto:Ted.Laverack@etsi.org]
Sent: Tuesday, = June 08, 2004 7:52 AM
To: Richard = Woundy @ Comcast
Cc: Jean-Francois = Mule; deketelaere@tcomlabs.com; gordon.beacham@motorola.com; Ian = Marshall_Internet; ATsupport
Subject: Liaison = from ETSI AT-Digital re. packet Cable MIBs


Dear = Richard,


I enclose an = approved  liaison from ETSI AT-Digital for distribution to the IETF = ipcdn working group for information and response.

Kind = regards,

Ted Laverack =
Fixed Network = Competence Centre (FCC)
Technical Officer = for  ETSI AT, HF, SAGE and OCG Security
Secretary for BB = Cablecoms
Tel:    +33 (0)492 944273
Fax:   = +33 (0)493 654716
Mobile: = 0672285266
mailto:ted.laverack@etsi.org  << File: = 09D25r1 Liaison Statement ETSI WG-D to IETF ipcdn.doc >> =

------_=_NextPart_001_01C46F37.5972E300-- --===============1716085279== 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 --===============1716085279==-- From ipcdn-bounces@ietf.org Wed Jul 21 20:26: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 UAA09076 for ; Wed, 21 Jul 2004 20:26:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnRQA-0005HE-7h for ipcdn-archive@ietf.org; Wed, 21 Jul 2004 20:26:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnPf5-0000gu-KK; Wed, 21 Jul 2004 18: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 1BnO5Q-0001Pf-J4 for ipcdn@megatron.ietf.org; Wed, 21 Jul 2004 16:53:12 -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 QAA28884 for ; Wed, 21 Jul 2004 16:53:09 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnO5o-0002k0-3r for ipcdn@ietf.org; Wed, 21 Jul 2004 16:53:38 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id i6LKqY1U029677 for ; Wed, 21 Jul 2004 15:52:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 21 Jul 2004 22:52:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15504D06A74@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Randy Presuhn (E-mail)" Date: Wed, 21 Jul 2004 22:52:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] MIB Doctor for: draft-ietf-ipcdn-pktc-signaling-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.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Randy Presuhn will be the MIB Doctor for this document. Thanks Randy. Hope you can review in the next 2 weeks, so we have your comments more or less at the same time as the end of WG Last Call. Pls post your comments to IPCDN mailing list. Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 22 17:25: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 RAA07188 for ; Thu, 22 Jul 2004 17:25:29 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnl4s-0004UL-Vq for ipcdn-archive@ietf.org; Thu, 22 Jul 2004 17: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 1BnjkQ-0007jc-Ov; Thu, 22 Jul 2004 16:00:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnjSY-0007Zs-QC; Thu, 22 Jul 2004 15:42:30 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19844; Thu, 22 Jul 2004 15:42:28 -0400 (EDT) Message-Id: <200407221942.PAA19844@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, 22 Jul 2004 15:42:28 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.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: a8a20a483a84f747e56475e290ee868e --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 DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus Author(s) : S. Green, et al. Filename : draft-ietf-ipcdn-bpiplus-mib-13.txt Pages : 83 Date : 2004-7-22 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 the Baseline Privacy Plus features of DOCSIS1.1 and DOCSIS 2.0 compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be Addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-13.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-bpiplus-mib-13.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-bpiplus-mib-13.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-7-22145508.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145508.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 Jul 22 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 RAA07878 for ; Thu, 22 Jul 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 1Bnl8F-0004gk-QZ for ipcdn-archive@ietf.org; Thu, 22 Jul 2004 17:29:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnjkT-0007lF-Au; Thu, 22 Jul 2004 16:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnjTB-0007hG-Uc; Thu, 22 Jul 2004 15:43:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20010; Thu, 22 Jul 2004 15:43:08 -0400 (EDT) Message-Id: <200407221943.PAA20010@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, 22 Jul 2004 15:43:07 -0400 Cc: ipcdn@ietf.org Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-11.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: 944ecb6e61f753561f559a497458fb4f --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 : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus, E. Cardona Filename : draft-ietf-ipcdn-docs-rfmibv2-11.txt Pages : 130 Date : 2004-7-22 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 the Radio Frequency (RF) interfaces for systems compliant with the Data Over Cable Service Interface Specifications (DOCSIS). This document revises RFC 2670. Please see section 10 for a description of the changes from RFC 2670. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.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-docs-rfmibv2-11.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-docs-rfmibv2-11.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-7-22145515.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-22145515.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 Jul 22 19:28: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 TAA29226 for ; Thu, 22 Jul 2004 19:28:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnn08-0001hd-C8 for ipcdn-archive@ietf.org; Thu, 22 Jul 2004 19:29:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnmeU-0005TB-5q; Thu, 22 Jul 2004 19:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnlhw-0006xw-TZ for ipcdn@megatron.ietf.org; Thu, 22 Jul 2004 18:06:33 -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 SAA14701 for ; Thu, 22 Jul 2004 18:06:29 -0400 (EDT) Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnliV-0006Og-Pi for ipcdn@ietf.org; Thu, 22 Jul 2004 18:07:12 -0400 Received: from h-68-166-38-176.snvacaid.dynamic.covad.net ([68.166.38.176] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bnlhl-00000X-00 for ipcdn@ietf.org; Thu, 22 Jul 2004 15:06:21 -0700 Message-ID: <000501c47038$6b749b20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Date: Thu, 22 Jul 2004 15:08:29 -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: c83ccb5cc10e751496398f1233ca9c3a Subject: [ipcdn] part 1 of comments on draft-ietf-ipcdn-pktc-signaling-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.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Hi - Here's the first installment of my MIB review comments on draft-ietf-ipcdn-pktc-signaling-05.txt. This is the "easy" stuff from 1id-guidlines and ID-Checklist. Checks based on http://www.ietf.org/ietf/1id-guidelines.txt: - document is in ASCII: OK - no control characters other than EOL/FF: OK 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) 2) some pages have more than 58 lines 3) pages not separated by FF character - no overstriking: OK 2) some pages have more than 58 lines 3) pages no separated by FF character - no overstriking: OK 4) the words "INTERNET-DRAFT" should be in upper left corner of first page 5) IPR Boilerplate: OK, but note that alternative wording for "plural" authors has been presented on the wgchairs list: 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. - Copyright Notice: OK 6) Internet-Draft boilerplate: text is OK, but formatting is strange. - Abstract: OK 7) Filename: broken by strange formatting on first page - expiration date: OK - Table of contents: OK Checks based on http://www.ietf.org/ID-Checklist.html: - ragged right: OK - no hyphens for line breaks: OK - no footnotes: OK - status & abstract unnumbered: OK - no numbered references in boilerplate / abstract: OK 8) author list: present, but mal-formatted 9) Introduction: missing. (2.2 #5) - Security Considerations present: OK 10) IANA considerations: contradictory, (2.2 #7b) seems to apply, since an OID needs to be allocated. - split references: OK 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.) - IPR boilerplate: OK 12) Keywords: text references RFC 2119, but it is missing from the list of normative references. 13) formal language use: MIB compilation: smilint objects to pktcSigDevCodecType (an index of pktcSigDevCodecEntry) being read-only. It should be not-accessible. - address examples: OK 14) References: [PKT-SP-MGCP-IO9-040113] is never cited. [PKT-SP-PROV-IO8-040113] is never cited. [PKT-SP-CODEC-IO5-040113] is never cited. [PKT-SP-MIB-MTA-I08-040113] is never cited. [ETSI TS 101 909-9] is never cited. [TR 101 183] is never cited. [RFC3289], while referenced in the MIB module, is not cited in the text of the document. [RFC3291], while referenced in the MIB module, is never cited. [RFC3261] is never cited. [RFC3435] is never cited. MIB module IMPORTS from SNMP-FRAMEWORK-MIB, but it's missing from the normative references and not cited in text. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 22 19:52:35 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 TAA01464 for ; Thu, 22 Jul 2004 19:52:35 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnnNF-0002DQ-Kv for ipcdn-archive@ietf.org; Thu, 22 Jul 2004 19:53:17 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnn4w-0000V6-V8; Thu, 22 Jul 2004 19:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnmmX-00050G-JU for ipcdn@megatron.ietf.org; Thu, 22 Jul 2004 19:15: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 TAA27584 for ; Thu, 22 Jul 2004 19:15:18 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bnmn8-0001Ft-Rn for ipcdn@ietf.org; Thu, 22 Jul 2004 19:16: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 i6MNEibw027633 for ; Thu, 22 Jul 2004 17:14: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] wg meeting - IETF #60: TUESDAY, Aug 3, 2004 Date: Thu, 22 Jul 2004 17:14:44 -0600 Message-ID: Thread-Topic: [ipcdn] wg meeting - IETF #60: TUESDAY, Aug 3, 2004 Thread-Index: AcRwQayDvqfhgUI8T+G86KL1I91p/Q== From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Folks, We have scheduled an ipcdn wg meeting in San Diego. It is on Tuesday, = August 3, 2004 from 5:00pm to 6:00pm. See the complete agenda at: = http://www.ietf.org/meetings/agenda_60.txt =20 This note is also a call for agenda items. If you are planning to = attend the meeting, let us know so that we can get a preliminary count.=20 Thanks, -- Rich & Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jul 23 13:20: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 NAA10202 for ; Fri, 23 Jul 2004 13:20:32 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo3jX-0002Pz-RH for ipcdn-archive@ietf.org; Fri, 23 Jul 2004 13:21:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo3bd-0007wm-FN; Fri, 23 Jul 2004 13:13:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bo3ap-0007ic-Am; Fri, 23 Jul 2004 13:12:23 -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 NAA09812; Fri, 23 Jul 2004 13:12:20 -0400 (EDT) Received: from [200.45.191.180] (helo=smtp-mx-03.ti.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bo3bb-0002Ir-A6; Fri, 23 Jul 2004 13:13:13 -0400 Received: from MSG-BE-02.ti.local ([192.168.220.104]) by smtp-mx-03.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jul 2004 14:11:34 -0300 Received: from mail pickup service by MSG-BE-02.ti.local with Microsoft SMTPSVC; Fri, 23 Jul 2004 14:11:32 -0300 Received: from smtp-mx-02.ti.local ([192.168.220.21]) by MSG-BE-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Jul 2004 14:47:44 -0300 Received: from qsmtp-mx-02.arnet.com.ar ([200.45.191.165]) by smtp-mx-02.ti.local with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Jul 2004 14:22:34 -0300 Received: from unknown (HELO megatron.ietf.org) (132.151.6.71) by host191165.arnet.net.ar with SMTP; 15 Jul 2004 17:20:22 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9kx-0001EL-0a; Thu, 15 Jul 2004 13:10:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bl9XB-0005Ct-OT for ietf-announce@megatron.ietf.org; Thu, 15 Jul 2004 12:56:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03756 for ; Thu, 15 Jul 2004 12:56:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bl9XA-0002aN-Ki for ietf-announce@ietf.org; Thu, 15 Jul 2004 12:56:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bl9WH-0002FI-00 for ietf-announce@ietf.org; Thu, 15 Jul 2004 12:55:41 -0400 Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx with esmtp (Exim 4.12) id 1Bl9VY-0001ru-00; Thu, 15 Jul 2004 12:54:56 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1Bl9LU-0001Jo-UX; Thu, 15 Jul 2004 12:44:32 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 15 Jul 2004 12:44:32 -0400 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-OriginalArrivalTime: 15 Jul 2004 17:22:34.0968 (UTC) FILETIME=[51939D80:01C46A90] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipcdn@ietf.org Subject: [ipcdn] Last Call: 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management' to Proposed Standard X-BeenThere: ipcdn@ietf.org Reply-To: iesg@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.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Management Information Base for Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-08-06 (note: some extra time (3 weeks) because IETF 60 is coming up). The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-mib-14.txt _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jul 26 02:39:02 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 CAA03646 for ; Mon, 26 Jul 2004 02:39:02 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Boz9u-0000da-UD for ipcdn-archive@ietf.org; Mon, 26 Jul 2004 02:40:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Boz7W-00012B-Pa; Mon, 26 Jul 2004 02:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Boz5S-0000jU-UN for ipcdn@megatron.ietf.org; Mon, 26 Jul 2004 02:35:50 -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 CAA03526 for ; Mon, 26 Jul 2004 02:35:47 -0400 (EDT) Received: from apate.telenet-ops.be ([195.130.132.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Boz6i-0000bT-RW for ipcdn@ietf.org; Mon, 26 Jul 2004 02:37:12 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by apate.telenet-ops.be (Postfix) with SMTP id C9616118088 for ; Mon, 26 Jul 2004 08:35:39 +0200 (MEST) Received: from tcomlabs.com (D5E00496.kabel.telenet.be [213.224.4.150]) by apate.telenet-ops.be (Postfix) with ESMTP id 8CA25118026 for ; Mon, 26 Jul 2004 08:35:39 +0200 (MEST) Received: (qmail 4019 invoked from network); 26 Jul 2004 08:28:23 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 26 Jul 2004 08:28:23 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Mon, 26 Jul 2004 08:28:22 +0200 (CEST) From: "David De Reu" To: "IPCDN Mailing List" Subject: RE: [ipcdn] part 1 of comments on draft-ietf-ipcdn-pktc-signaling-05.txt Date: Mon, 26 Jul 2004 08:35:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Importance: Normal In-Reply-To: <000501c47038$6b749b20$7f1afea9@oemcomputer> Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable > [PKT-SP-MGCP-IO9-040113] is never cited. > [PKT-SP-PROV-IO8-040113] is never cited. > [PKT-SP-CODEC-IO5-040113] is never cited. Hi, I believe these have to be "I0" (I zero) instead of "IO" (I oh). Also, th= e NCS and PROV spec have in the meantime been updated... Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 =96 9000 Ghent =96 Belgium Tel: +32 9 269 22 91 =96 Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jul 26 12:02: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 MAA22030 for ; Mon, 26 Jul 2004 12:02:20 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp7x6-0000vb-9b for ipcdn-archive@ietf.org; Mon, 26 Jul 2004 12:03:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp7f4-0004ou-Ct; Mon, 26 Jul 2004 11:45:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp7WU-0001K8-SZ for ipcdn@megatron.ietf.org; Mon, 26 Jul 2004 11:36: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 LAA15910 for ; Mon, 26 Jul 2004 11:36:16 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp7Xu-00073X-Cq for ipcdn@ietf.org; Mon, 26 Jul 2004 11:37:47 -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 i6QFZibw000647; Mon, 26 Jul 2004 09:35: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 Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt Date: Mon, 26 Jul 2004 09:35:44 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E629@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt Thread-Index: AcRwMopt0EyrK6RbSYqxIBIT5rqPeAArfkCw From: "Eduardo Cardona" To: , "Wijnen, Bert (Bert)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a9672ae1970aa20cd94e880017fa9b4 Content-Transfer-Encoding: quoted-printable Cc: DOCSIS OSS Majordomo List 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: d01c7b9466fe967a5df27b46fdb03146 Content-Transfer-Encoding: quoted-printable Bert, IPCDN participants,=20 as you may noticed a new draft (13) was published on time for I-D cutoff for the upcoming meeting Bert,=20 Thanks for all the detailed comments, below are the clarification notes added to the published draft. >From the POV of significant changes I only see item 1. as a possible change of requirements by defining persistence where the Draft was not clear: Recently updates to BPI OSS requirements introduces persistent requirement to configurable structures like docsBpi2CmtsProvisionedCmCertEntry, docsBpi2CmtsCACertEntry In a generalized way MULTICAST SAID assignments and CM authorization for static Multicast are the areas where persistent requirements have been added to maintain consistency around user configured data. Below is the list of items in your review with the appropriate comments as are now in draft-13 Thanks Eduardo More or less serious: 1. I see various read-write and/or read-create objects and I do not see any text in the DESCRIPTION clauses (non STorageType objects) that tell me what the expected behavior is w.r.t. persistency of such objects. SO what happens after a restart/reboot? read-write objects:=20 docsBpi2CmAuthReset: N/A testing purposes see description docsBpi2CmDeviceCmCert: -added persistence, already a requirement that might be implicit in current description but not explicit. docsBpi2CmtsDefaultAuthLifetime=20 docsBpi2CmtsDefaultTEKLifetime Added to both objects: "This object value persist after reinitialization of the managed system." docsBpi2CmtsDefaultSelfSignedManufCertTrust: BPI spec calls for a testing object not recommended as an operational parameter Do not persist Description clarified "this" instead of "the" docsBpi2CmtsCheckCertValidityPeriods: With a period validity of 20 years and re-issued certificated within 2 years of expiration do not indicates any usage of this object rather than testing No need of persistence. added=20 "This object value needs not to persist after reinitialization of the=20 managed system.." docsBpi2CodeCvcUpdate added first sentence: "then the content of this object is discarded." See BPI spec pointed by REFERENCE section D.3.3.2.2. read-write objects in non-dynamic tables: docsBpi2CmtsAuthEntry=20 Entries are deleted after CM de-registers docsBpi2CmtsTEKEntry Entries are deleted when the SAID expires read-create:=20 docsBpi2CmtsMulticastAuthEntry, docsBpi2CmtsIpMulticastMapEntry A Multicast Group ca be mapped by the CMTS to primary. Static or dynamic SA.=20 For the MulticastMapEntry=20 it is not expected to have a multicast group mapped to a primary SA to persist after reboot Typically a static SA mapped to a multicast group is required to persist, It implies entries in MulticastAuthEntry for specific authorized CMs Operator may decide also to create a MulticastMapEntry with SAIDType dynamic to track the multicast group with a specific SAID. If that condition is valid, there is no way to know a CMTS dynamically created MulticastMapEntry vs a provisioned one - It requires the introduction of StorageType in MulticastMapTable with syntax read-only: depending on CMTS created or provisioned entries the row storage type could be=20 defined as : e.g SAIDType =3D primary will be volatile SAIDtype =3D static will be non-volatile SAIDType =3D dynamic:non-volatile for provisioned entries,=20 volatile for CMTS dynamically mapped multicast group. The main advantage is to allow the BPI and OSS spec to concrete define the management requirements for this cases, including the mandate of persistence. MulticastAuthEntry form the point of view of the MIB management perspective and operations should be stated as persistent explicitly. docsBpi2CmtsMulticastAuthEntry Added : SAIDs of type static=20 Row entries persist after reinitialization of=20 the managed system. docsBpi2CmtsIpMulticastMapEntry added: docsBpi2CmtsIpMulticastMapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row." ::=3D { docsBpi2CmtsIpMulticastMapEntry 15 } docsBpi2CmtsIpMulticastSAType added: SNMP created entries set this object by default to 'static' if not set at row creation. docsBpi2CmtsProvisionedCmCertEntry Added:(updates to OSSI specification:=20 Row entries persist after reinitialization of=20 the managed system. REFERENCE=20 "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I05-040407, Section 6.2.14" docsBpi2CmtsCACertEntry Added (updates to OSSI specification:=20 Row entries with trust status 'trusted', 'untrusted', or 'root' persist after reinitialization of the managed system." REFERENCE=20 "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I05-040407, Section 6.2.14" 2. I see a number of ZeroBasedCOunter32 objects that have text aka: (for example docsBpi2CmAuthentInfos) DESCRIPTION "The value of this object is the count of times the CM has transmitted an Authentication Information message, since reboot." It is OK to tell us that a ZeroBasedCOunter32 object must start with zero at (re-)boot time or at row creation. But from that point on, a ZeroBasedCounter32 behaves exactly the same as a Counter32, and so it is incorrect to say "count of X since reboot" because the Counter32 may have wrapped!. Possibly this is not gonna happen in practice, but literally the claim is incorrect. 3. For these ZeroBasedCounter32 objects, I also see no word about a possible discontinuity timer. Why not. Can there NEVER be a discontinuity? Of if there is one does that mean ALL counters experience a discontionuity? The latter is what you basically state (or cause) by not pointing to a specific discontinuity timer. Because then by default it is sysUpTime, and so that means that when you DO experience a discontinuity, then you MUST reset sysUpTime and that means that a discontinuity for EVERYONE (object) that assumes the default. If such is intended, then fine, but it would be good to then state that sysUpTime is the discontinuity timer. docsBpi2CmAuthentInfos docsBpi2CmAuthRequests docsBpi2CmAuthReplies=20 docsBpi2CmAuthRejects=20 docsBpi2CmAuthInvalids discontinuity is sysUpTime removed counts since reboot added: "Reinitialization of this counter occurs at boot time. Discontinuities of this counter are indicated by sysUpTime." docsBpi2CmTEKKeyRequests docsBpi2CmTEKKeyReplies docsBpi2CmTEKKeyRejects docsBpi2CmTEKInvalids docsBpi2CmTEKAuthPends discontinuity is sysUpTime removed since registration added: "Reinitialization of this counter occurs at boot time. Discontinuities of this counter are indicated by sysUpTime." docsBpi2CmIpMulticastSAMapRequests docsBpi2CmIpMulticastSAMapReplies docsBpi2CmIpMulticastSAMapRejects Delete: "Since entry creation" Add: "Discontinuities of this counter are indicated by sysUpTime." docsBpi2CmtsAuthentInfos docsBpi2CmtsAuthRequests docsBpi2CmtsAuthReplies docsBpi2CmtsAuthRejects docsBpi2CmtsAuthInvalids docsBpi2CmtsSAMapRequests docsBpi2CmtsSAMapReplies docsBpi2CmtsSAMapRejects Add: "Discontinuities of this counter are indicated by sysUpTime and ifCounterDiscontinuityTime for the associated ifIndex." Delete: "since entry creation" docsBpi2CmtsAuthCmInfos docsBpi2CmtsAuthCmRequests docsBpi2CmtsAuthCmReplies docsBpi2CmtsAuthCmRejects docsBpi2CmtsAuthCmInvalids updated Entry object to indicate MAC interface dependency for IfIndex "Discontinuities of this counter are indicated by sysUpTime and ifCounterDiscontinuityTime for the associated ifIndex." Delete: "since entry creation" docsBpi2CmtsKeyRequests docsBpi2CmtsKeyReplies docsBpi2CmtsKeyRejects docsBpi2CmtsTEKInvalids "Discontinuities of this counter are indicated by sysUpTime and ifCounterDiscontinuityTime for the associated ifIndex." Delete: "since registration" docsBpi2CmtsIpMulticastSAMapRequests docsBpi2CmtsIpMulticastSAMapReplies docsBpi2CmtsIpMulticastSAMapRejects Added: "Discontinuities of this counter are indicated by sysUpTime and ifCounterDiscontinuityTime for the associated ifIndex." Delete: "since entry creation" 4. I see that for some objects you speak about a "null string" or "NULL string". The base data type for such objects is OCTET STRING. In all those cases I suspect (but I am not sure) that you mean the zero-length octet string. Otherwise I do not understand what "null string" means. Pls explain and fix. Added:=20 docsBpi2CodeCvcUpdate OBJECT-TYPE Reading this object always returns the zero-length string." docsBpi2CmtsCACertThumbprint OBJECT-TYPE Note: The zero-length string must be returned if this object is not supported by the CMTS." docsBpi2CmtsCACert OBJECT-TYPE Note: The zero-length string must be returned, on reads, if the entire certificate is not retained in the CMTS." docsBpi2CmtsProvisionedCmCert OBJECT-TYPE Note: The zero-length string must be returned, on reads, if the entire certificate is not retained in the CMTS." docsBpi2CmtsAuthBpkmCmCert OBJECT-TYPE Note: The zero-length string must be returned if the entire certificate is not retained in the CMTS." docsBpi2CmDeviceCmCert OBJECT-TYPE Note: This object can be set only when the value is the zero-length string. Once the object contains the=20 certificate, its access MUST be read-only." 5. For docsBpi2CmtsAuthCmExpiresOld I see: Note: For CMs running in BPI mode, implementation of this object is optional and MAY vary." Mmm... that sounds like a MODULE-COMPLIANCE aspect and I would rather see such things in MODULE-COMPLIANCE and not in object DESCRIPTION clauses. A CMTS keeps track of the old and new authentication keys for example to do seamless traffic Key updates (using a hand-shacking algorithm based on the authentication key (old or new), CMs running in 1.0 mode follows BPI protocol (RFC 3083) which has no concept of old/ new key expire time, therefore the CMTS only have to track the most recent authentication key expire to validate outstanding BPI security requests. Rather than a Compliance statement ( the object MUST be supported) I believe an indication of=20 "Note: For CMs running in BPI mode, this object value has no meaning, therefore the CMTS may not instantiate this object=20 for those CM entries." 6. I see: -- Note: the following object has been obsoleted docsBpi2CmtsAuthCmReset OBJECT-TYPE SYNTAX INTEGER { noResetRequested(1), invalidateAuth(2), sendAuthInvalid(3), invalidateTeks(4) } MAX-ACCESS read-write STATUS current So the --Note: is out of sync with the actual status!? What is it? If it IS obsoleted, then status should sya so, And DESCRIPTION clause should explain why it was obsoleted. And the ASN.1 comment line then of course is no longer needed. The note applies to docsBpi2CmtsAuthCmGraceTime which was already removed In draft 12 =20 Draft 11 docsBpi2CmtsAuthCmLifetime ::=3D { docsBpi2CmtsAuthEntry 7 } -- Note: the following object has been obsoleted=20 docsBpi2CmtsAuthCmGraceTime ::=3D { docsBpi2CmtsAuthEntry 8 } docsBpi2CmtsAuthCmReset ::=3D { docsBpi2CmtsAuthEntry 9 } docsBpi2CmtsAuthCmLifetime ::=3D { docsBpi2CmtsAuthEntry 7 } -- Note: the following object has been obsoleted -- remove docsBpi2CmtsAuthCmReset ::=3D { docsBpi2CmtsAuthEntry 8 } 7. I see: docsBpi2CmtsAuthCACertIndexPtr OBJECT-TYPE SYNTAX Integer32 (0..10000) And find that a strange limit (range). And nowhere, not even in the docsBpi2CmtsCACertTable do I see an explanation why that range makes sense (assuming that it does). docsBpi2CmtsAuthCACertIndexPtr follows the size of docsBpi2CmtsCACertIndex =20 Changed to=20 SYNTAX Unsigned32 (1..4294967295) docsBpi2CmIpMulticastIndex, docsBpi2CmtsIpMulticastIndex SYNTAX Unsigned32 (1..4294967295) 8. When I see: docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastMaskType InetAddressType, docsBpi2CmtsIpMulticastMask InetAddress, I wonder if (in the same row) docsBpi2CmtsIpMulticastMaskType will ever have a different value then docsBpi2CmtsIpMulticastAddressType !?? It seems to me that should NOT be allowed, cause otherwise I am not sure how the ANDing of the Mask is going to work/happen. So the next question then is why you do not do: docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastMask InetAddress, And let docsBpi2CmtsIpMulticastAddressType be the discriminator for both InetAddresses. One less object, and less change for error/conflict. But thinking even further, Possibly the best thing to do is to use docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastPrefixLength InetAddressPrefixLength, Are not such masks always setup that they basically specify a prefix length? If so, then this is the way to do it with the TCs from INET-ADDRESS-MIB. 9. I see various uses of InetAddress as for example here: docsBpi2CmtsIpMulticastAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the IP multicast address to be mapped, in conjunction with docsBpi2CmtsIpMulticastMask." The TC for InetAddress (in RFC3291 or its follow on) clearly state that you MUST specify which InetAddressType controls the format of this object as per DESCRIPTION from InetAddress TC: An InetAddress value is always interpreted within the context of an InetAddressType value. Every usage of the InetAddress textual convention is required to specify the InetAddressType object which provides the context. ... This issue was brought up before and Rich Woundy exposed a detail explanation of the design requirements in favor of a netmask instead of an InetPrefixLength /RFC2373/3513 See... From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Wednesday, February 19, 2003 8:04 AM To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail) Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail) Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask Perhaps a clarification note for object multicast netmask objects. "This object needs not to represent a contiguous netmask i.e. to assign to same multicast SAID multicast IPv6 addresses based on multicast scopes and/or multicast group Ids." added to docsBpi2CmtsIpMulticastAddress and docsBpi2CmtsIpMulticastMask: "The address type of this object is specified by the value of the object docsBpi2CmtsIpMulticastAddressType. Deleted object docsBpi2CmtsIpMulticastMaskType 10. I see: docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not be timed out." Mmm... that "need not be timed out" seems in conflict with the RowStatus TC DESCRIPTION clause in RFC2579. Can you explain why this is? Also, a RowSTatus object MUST specify in its DESCRIPTION clause under which conditions - the row can be activated - which columns (if any) can bve changed while in the active state. I am missing the first. Removed the prohibition to age out inactive row entries. Added: "A created row can be set to active only after the corresponding instances of=20 docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all been set, otherwise the status of this object is 'notReady'". 11. You specify: -- -- The BPI+ MIB Conformance Statements (with a placeholder for -- notifications) -- docsBpi2Notification OBJECT IDENTIFIER ::=3D { docsBpi2MIB 2 } docsBpi2Conformance OBJECT IDENTIFIER ::=3D { docsBpi2MIB 3 } docsBpi2Compliances OBJECT IDENTIFIER ::=3D { docsBpi2Conformance 1 } docsBpi2Groups OBJECT IDENTIFIER ::=3D { docsBpi2Conformance 2 } Why not be (more) consistent with other MIB modules and follow the suggested OID subtrees as per MIB guidelines, draft-ietf-ops-mib-review-guidelines-03.txt, appendix D: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) This is not mandatiory, but consistency is always useful/helpful Updated to follow the OPS recommendations docsBpi2Notification OBJECT IDENTIFIER ::=3D { docsBpi2MIB 0 } docsBpi2Conformance OBJECT IDENTIFIER ::=3D { docsBpi2MIB 2 } 12. I see: docsBpi2CmtsProvisionedCmCertStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Standard RowStatus object except: a) if a row has ever been activated, a set to docsBpi2CmtsProvisionedCmCert need not succeed, b) inactive rows need not be timed out." So you are changing the rules of the RowStatus TC? Seems not allowed to me. Removed the prohibition to age out inactive row entries. Removed the sentence " if a row has ever been activated, a destroy setting need not succeed." "Standard RowStatus objects except: a) if a row has ever been activated, a set to docsBpi2CmtsCACert need not succeed, changed to: " The status of this conceptual row. An attempt to set writable columnar values while this row is active=20 behaves as follows: - Sets to the object docsBpi2CmtsCACertTrust are allowed. - Sets to the object docsBpi2CmtsCACert will return an error inconsistentValue'." Nits/administrativia: 1. The RFC editor wants all references to have at least one citation in the document. ALso for the normative references to RFCs from which you import. See MIB review guidelines, sect 3.5 You need to add a citation somehwere for [RFC3411], [RFC2021], [RFC3291], [RFC2670] Added references 2. I see: docsBpi2CmtsCACertSubject OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "The subject name exactly as it is encoded in the X509 certificate. The organizationName portion of the certificate's subject name must be present. All other fields are optional. Any optional field present must be prepended with (carriage return) (line feed) ASCII characters. Ordering of fields present must conform to: organizationName countryName A 7-bit ASCII character (which CR and LF are) does get represented exactly the same when UTF-8 encoded. But it is kind of weird to speak about ASCII characters when discussing the content of a UTF-8 based OCTET STRING. I checked with our UTF-8 and Unicode expert (Patrik Faltstrom) and he comes up with this suggestion: Replace sentence: Any optional field present must be prepended with (carriage return) (line feed) ASCII characters. with: Any optional field present must be prepended with (carriage return, U+000D) and (line feed, U+000A). You have this in a number of objects, pls check them all. 3. I see: docsBpi2CmDeviceCmCert OBJECT-TYPE SYNTAX DocsX509ASN1DEREncodedCertificate MAX-ACCESS read-write STATUS current DESCRIPTION "The X509 DER-encoded cable modem certificate. Note: This object can be set only when the value is the null string. Once the object contains the certificate, its access MUST be read-only." Maybe this is just wording.=20 - First, I already discussed the "null string" issue. I think you mean=20 a zero length string or maybe better "zero length certificate" or "zero length OCTET STRING" or "zero length value". - Now, it seems to me that if the requirement is that the object has a zero length value in order for a SET to be accepted, then, when someone tries a SET while there is already a value, that then the system ought to return a error that explains what is wrong. I.e. an error that would otherwise not occur. If you get a notWritable, then the management station does not necassarily know why that is, see bullet 2 page 20 of RFC3416 or point 9 on page 21. Maybe a better error would be a inconsistentValue, point 10 on page 21 of RFC3416?? Does that not seem a better way to indicate this error? Added in description=20 "otherwise an error 'inconsistentValue'=20 is returned" 4. I see: docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE SYNTAX INTEGER { none(0), des56CbcMode(1), des40CbcMode(2) } MAX-ACCESS read-only I understand that this is read-only and so can only report what is in the=20 Cm. But I would not be surprised if this will cause questions from the security folk. Is this the only envryption that is supported? Added a note in the security section BPI+ Encryption Algorithms: BPI+ Traffic Encryption Keys TEK uses DES 56 or 40 bits encryption ciphers, due their cryptographic strength weakness, future revisions of BPI+ specification [1] should introduce advanced encryption=20 algorithms to overcome the progress in cheaper and faster decryption tools. CM BPI+ Authentication algorithms uses triple DES, which guarantees strong BPI+ Authentication Traffic encryption keys updates 5. I see: docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE SYNTAX INTEGER { trusted (1), untrusted (2) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object determines the default trust of self-signed manufacturer certificate entries, contained in docsBpi2CmtsCACertTable, created after setting the object." I cannot say that I understand what "afetr setting the object" means. which object? "after setting the object" Changed to:=20 "after setting this object" _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Jul 26 17:41:51 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 RAA12035 for ; Mon, 26 Jul 2004 17:41:51 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpDFl-0000Jb-Mj for ipcdn-archive@ietf.org; Mon, 26 Jul 2004 17:43:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpD6n-0007II-V8; Mon, 26 Jul 2004 17:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpD3S-0006Ru-7d for ipcdn@megatron.ietf.org; Mon, 26 Jul 2004 17:30: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 RAA11365 for ; Mon, 26 Jul 2004 17:30:39 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpD4v-0008WR-LB for ipcdn@ietf.org; Mon, 26 Jul 2004 17:32:13 -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 i6QLU8Ye012112 for ; Mon, 26 Jul 2004 16:30:09 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Jul 2004 23:30:07 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79A9B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Eduardo Cardona'" , ipcdn@ietf.org Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt Date: Mon, 26 Jul 2004 23:30:00 +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: bdc523f9a54890b8a30dd6fd53d5d024 Cc: DOCSIS OSS Majordomo List 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: 3002fc2e661cd7f114cb6bae92fe88f1 Mmm, in your response I see: "Discontinuities of this counter are indicated by sysUpTime and ifCounterDiscontinuityTime for the associated ifIndex." Not sure I understand this. Checking with other MIB doctors. docsBpi2CmtsCACertThumbprint OBJECT-TYPE Note: The zero-length string must be returned if this object is not supported by the CMTS." That seems weird. If an object is not supported, I would expect to return a noSuchObject exception. !! I also see: Rather than a Compliance statement ( the object MUST be supported) I believe an indication of "Note: For CMs running in BPI mode, this object value has no meaning, therefore the CMTS may not instantiate this object for those CM entries." And so that would mean that the agent returns a noSuchInstance exception! I see that to this: But thinking even further, Possibly the best thing to do is to use docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastPrefixLength InetAddressPrefixLength, Are not such masks always setup that they basically specify a prefixlength? If so, then this is the way to do it with the TCs from INET-ADDRESS-MIB. your answer seems to be: This issue was brought up before and Rich Woundy exposed a detail explanation of the design requirements in favor of a netmask instead of an InetPrefixLength /RFC2373/3513 plus en email from Rich, stating that it might be good to explanation which I cannot find. Can that explanation be added to DESCRIPTION clause(s)? I cannot understand that from current DESCRIPTION clauses, or am I not reading clear at this late hour of the night? 10. I see: docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not be timed out." Mmm... that "need not be timed out" seems in conflict with the RowStatus TC DESCRIPTION clause in RFC2579. Can you explain why this is? Also, a RowSTatus object MUST specify in its DESCRIPTION clause under which conditions - the row can be activated - which columns (if any) can bve changed while in the active state. I am missing the first. Removed the prohibition to age out inactive row entries. Added: "A created row can be set to active only after the corresponding instances of docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all been set, otherwise the status of this object is 'notReady'". Mmm... the status could also be notInService I would think? Why not remove that last piece of the sentence, i.e. remove: , otherwise the status of this object is 'notReady' Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 27 06:31:34 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 GAA03501 for ; Tue, 27 Jul 2004 06:31:34 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPGl-0004qN-5o for ipcdn-archive@ietf.org; Tue, 27 Jul 2004 06:33:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPEZ-00007v-JZ; Tue, 27 Jul 2004 06:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPDk-0008Qq-Kf for ipcdn@megatron.ietf.org; Tue, 27 Jul 2004 06:30:08 -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 GAA03442 for ; Tue, 27 Jul 2004 06:30:06 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPFL-0004o9-3r for ipcdn@ietf.org; Tue, 27 Jul 2004 06:31:47 -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 i6RATZV3008365 for ; Tue, 27 Jul 2004 05:29:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jul 2004 12:29:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79AAF@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Eduardo Cardona'" , ipcdn@ietf.org Subject: RE: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-13.txt Date: Tue, 27 Jul 2004 12:29:27 +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: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: DOCSIS OSS Majordomo List 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: f607d15ccc2bc4eaf3ade8ffa8af02a0 As a follow up to this, there was this comment from me: > > Mmm, in your response I see: > > "Discontinuities of this counter are indicated by sysUpTime and > ifCounterDiscontinuityTime for the associated ifIndex." > > Not sure I understand this. > Checking with other MIB doctors. > The first thing we found is that it is not so clear what the text means, but it probably menas the same things as for other IF-MIB related counters, i.e. (as also used in IF-MIB, RFC2863), it means: Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. And if that is indeed the case, then this new text would be MUCH better. Now, when you added the text about discontinuities, it also makes it more visible that one could really question if the use of ZeroBasedCounter32 makes sense and if a regular Counter32 would not be much much better. Have you read the ZeroBasedCounter32 TC and the text that explains what this type of counter was meant for? One comment from another MIB doctor is: A ZeroBasedCounter32 in a conceptual row which can experience discontinuities as part of its normal operational behaviour just seems a bit odd to me. I fail to see what the advantage of a ZeroBasedCounter32 in such a situation is. Another comment (in relation to ifCounterDiscontinuityTime) is that it would be very good to add some text (somewhere early on in the draft) that points to RFC2863, page 12, which has some good text about that object. As per the comment of another MIB Doctor: I think it would be extremely helpful to have a discussion what this means somewhere in the introductionary text together with a pointer to the relevant text in the IF-MIB RFCs (which has some paragraphs about this subject that are interesting to know for implementors). Looking at the MIB, the question that I have is the interaction of discontinuities with these ZeroBasedCounter32 objects. Does a discontinuity couse these counters to be reset to zero? The TC says that a zero based counter is set to zero(0) on creation and it has additional text that the intended usage is in tables where the index space is constantly changing. Does this apply here? Of course you have clarified (but in some prose early on in the draft may want to re-emphasize) that the ZeroBasedCounter32 only MUST be set to zero at row creation. But some additional discussion seems usefull. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 27 06:35: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 GAA03749 for ; Tue, 27 Jul 2004 06:35:41 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPKk-0004ui-EN for ipcdn-archive@ietf.org; Tue, 27 Jul 2004 06:37:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPI7-0000Zw-Ak; Tue, 27 Jul 2004 06:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpPGA-0000KG-Fx for ipcdn@megatron.ietf.org; Tue, 27 Jul 2004 06:32:38 -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 GAA03552 for ; Tue, 27 Jul 2004 06:32:36 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpPHl-0004ql-1O for ipcdn@ietf.org; Tue, 27 Jul 2004 06:34:17 -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 i6RAW5WY009509 for ; Tue, 27 Jul 2004 05:32:06 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 27 Jul 2004 12:32:04 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79AB0@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Eduardo Cardona'" Date: Tue, 27 Jul 2004 12:31:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="utf-8" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.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.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Some quick notes, Here we go: 1. SMICng tells me: W: f(ipcdnbpi2.mi2), (3142,17) Duplicate item "docsBpi2CmtsIpMulticastAddressType" in compliances list for module "DOCS-IETF-BPI2-MIB" W: f(ipcdnbpi2.mi2), (3152,17) Duplicate item "docsBpi2CmtsIpMulticastAddress" in compliances list for module "DOCS-IETF-BPI2-MIB" Seems you duplicated something. 2. docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not A created row can be timed out." set to active only after the Corresponding instances of docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all been set, otherwise the status of this object is 'notReady'. There is no restriction on the ability to change values in this row while the row is active." ::= { docsBpi2CmtsIpMulticastMapEntry 14 } Last sentence in DESCRIPTION clause is duplicate of 2nd sentence. Are you sure value is 'notReady' in that case? Could be notInService too, no? Why specify it. I.e. I would remove otherwise the status of this object is 'notReady' 3. docsBpi2CmtsIpMulticastMapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row." You must (according to RFC 2579) add txt to stat which (if any) writable objects MUST be writeable even for permanent entries. See 2579 fo details. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Jul 27 11:31: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 LAA21933 for ; Tue, 27 Jul 2004 11:31:16 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpTwp-00020t-Od for ipcdn-archive@ietf.org; Tue, 27 Jul 2004 11:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpTis-0001b4-9P; Tue, 27 Jul 2004 11:18:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpTdL-0000kQ-M3; Tue, 27 Jul 2004 11:12: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 LAA20164; Tue, 27 Jul 2004 11:12:49 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpTey-0001Ua-VM; Tue, 27 Jul 2004 11:14:33 -0400 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1BpTPJ-0006dJ-3J; Tue, 27 Jul 2004 10:58:21 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 27 Jul 2004 10:58:21 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipcdn@ietf.org Subject: [ipcdn] Last Call: 'Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus' to Proposed Standard X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@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.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab The IESG has received a request from the IP over Cable Data Network WG to consider the following document: - 'Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2004-08-10. Some initial comments have already been posted to IPCDN mailing list. Those will be considered as comments raised during IETF Last Call. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-13.txt _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Jul 29 19:11:55 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 TAA16626 for ; Thu, 29 Jul 2004 19:11:55 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqK6B-0005Dl-3y for ipcdn-archive@ietf.org; Thu, 29 Jul 2004 19:14:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqJZG-0007bm-6G; Thu, 29 Jul 2004 18:40:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqJ9y-0001uN-U3 for ipcdn@megatron.ietf.org; Thu, 29 Jul 2004 18:13: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 SAA13099 for ; Thu, 29 Jul 2004 18:13:50 -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 1BqJBz-0004Qb-Jd for ipcdn@ietf.org; Thu, 29 Jul 2004 18:16:04 -0400 Received: from dlep31.itg.ti.com ([157.170.139.161]) by dragon.ti.com (8.12.11/8.12.11) with ESMTP id i6TMDHq2003053; Thu, 29 Jul 2004 17:13:17 -0500 (CDT) Received: from dlep90.itg.ti.com (localhost [127.0.0.1]) by dlep31.itg.ti.com (8.12.11/8.12.11) with ESMTP id i6TMDGKo005391; Thu, 29 Jul 2004 17:13:16 -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 i6TMDGUO020525; Thu, 29 Jul 2004 17:13:16 -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, 29 Jul 2004 17:13:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6556.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, 29 Jul 2004 17:13:15 -0500 Message-ID: Thread-Topic: IETF-Sig-Draft-5 MIB pktcNcsEndPntConfigMaxHookFlash default value Thread-Index: AcR1qHf4Db5UapcQQYOLicTHHIS5dA== From: "Kumar, Satish" To: X-OriginalArrivalTime: 29 Jul 2004 22:13:16.0280 (UTC) FILETIME=[3F311F80:01C475B9] X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: Jean-Francois Mule , Beacham Gordon-CGB005 , Richard_woundy@cable.comcast.com Subject: [ipcdn] IETF-Sig-Draft-5 MIB pktcNcsEndPntConfigMaxHookFlash default value 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Hi, The default value for pktcNcsEndPntConfigMaxHookFlash is very small. In signaling-MIB draft-4 the range was small(20..500), and the default was set to 500. In draft-5 the range is increased(20..1000), but the default value is retained 500. I would recommend to change the default value from 500 to 800. Comments please. Thanks, Satish Kumar(email:satish.kumar@ti.com) Texas Instruments(Visiting Engineer-Packetcable) CableLabs, 858, Coal Creek Circle, Louisville, CO-80027 Ph: 303-661-3784, Fax: 303-661-9199, Cell: 301-385-3980 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jul 30 18:00:40 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 SAA03569 for ; Fri, 30 Jul 2004 18:00:40 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqfT0-0006bF-P6 for ipcdn-archive@ietf.org; Fri, 30 Jul 2004 18:03:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqfOh-0002e1-7U; Fri, 30 Jul 2004 17:58:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqfGi-0008Ao-A8 for ipcdn@megatron.ietf.org; Fri, 30 Jul 2004 17:50:24 -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 RAA02801 for ; Fri, 30 Jul 2004 17:50:21 -0400 (EDT) Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqfJ1-0006Rk-Ii for ipcdn@ietf.org; Fri, 30 Jul 2004 17:52:48 -0400 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Fri, 30 Jul 2004 14:49:10 -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-11.broadcom.com (8.9.1/8.9.1) with ESMTP id OAA26645; Fri, 30 Jul 2004 14:48:35 -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); Fri, 30 Jul 2004 14:49:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Jul 2004 14:49:06 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2DA77@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: MTA MIB draft 04 comments thread-index: AcPHPrcfUV9Pn2wAQ3yRYDZLo8CRSgPzCLpgAPwFsDAm4JVWYA== From: "Eugene Nechamkin" To: ipcdn@ietf.org X-OriginalArrivalTime: 30 Jul 2004 21:49:09.0221 (UTC) FILETIME=[0B173150:01C4767F] X-WSS-ID: 6D141DDC15C2460804-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Cc: Jean-Francois Mule Subject: [ipcdn] MTA MIB draft 04 comments 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: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable For everybody's consideration, here are the following comments on the MTA MIB draft-04 recently published: 1. pktcMtaDevProvKerbRealmName =20 Having in mind the recently introduced secure/non-secure provisioning Flows and the fact that the pktcMtaDevRealmTable is not indexed by the pktcMtaDevProvKerbRealmName (as it is in the PacketCable), and also some missing description of the MTA functionality in respect to the RealmTable content, the existing DESCRIPTION of the object seems to be not exactly adequate: =20 " This object contains the name of the associated=20 provisioning Kerberos realm acquired during the MTA4=20 provisioning step (DHCP Ack) for SNMPv3 provisioning.=20 This object value is used as an index into the=20 pktcMtaDevRealmTable. The upper case ASCII representation=20 of the associated Kerberos realm name MUST be used by both=20 the Manager (SNMP entity) and the MTA.=20 The Kerberos realm name for the Provisioning Server is=20 supplied to the MTA via DHCP option code 122 sub-option 6=20 as defined in RFC 3495. In secure SNMP provisioning mode=20 the value of the Kerberos realm name for the Provisioning=20 Server supplied in the MTA configuration file must match=20 the value supplied in the DHCP option code 122 =20 sub-option 6. Otherwise the value of this object must =20 contain the value supplied in DHCP Option 122 =20 sub-option 6." =20 =20 I propose the following DESCRIPTION clause: =20 " This object contains the value indicating which Provisioning Mode=20 the MTA should use for its provisioning - SNMP secure or SNMP non-secure. The value of this object is delivered to the MTA in the DHCP option code=20 122 sub-option 6 during the DHCP-ACK provisioning step=20 (as defined in RFC 3495).=20 =20 In the secure SNMP Provisioning Mode, the object contains the upper case=20 ASCII representation of the name of the associated provisioning=20 Kerberos realm for the SNMPv3 Provisioning. The MTA MUST create, in=20 the pktcMtaDevRealmTable, the conceptual row corresponding=20 to the upper case ASCII representation of the value of this object.=20 The MTA MUST make sure that the value of the Kerberos realm name=20 for the Provisioning Server supplied in the MTA configuration file matches=20 the value supplied in the DHCP option code 122 sub-option 6.=20 The MTA MUST use the Realm Organization Name of the SNMPv3 Provisioning=20 Kerberos Realm supplied in the configuration file, in the=20 new row created for the SNMPv3 Provisioning Kerberos Realm. =20 In the non-secure SNMP Provisioning Mode, this object contains the upper=20 case ASCII representation of the value delivered to the MTA in the DHCP=20 option code 122 sub-option 6." =20 =20 2. pktcMtaDevCmsFqdn =20 The DESCRIPTION clause of the object is as follows: =20 " This object specifies the CMS FQDN. The MTA must =20 prohibit the instantiation of any two rows with identical =20 FQDNs. The MTA must also verify that any search and/or =20 comparison operation involving a CMS FQDN is case =20 insensitive."=20 This description is not consistent with the the description of the similar object - pktcMtaDevRealmName in the pktcMtaDevRealmTable, and I propose the following DESCRIPTION clause which, I think, would better describe the funtionality corresponding to the pktcMtaDevCmsFqdn object: =20 " This object specifies the CMS FQDN in all capitals.=20 The MTA MUST prohibit the instantiation of any=20 two rows with identical FQDNs. The MTA MUST =20 also verify that any search and/or comparison operations involving=20 a CMS FQDN is done using the upper case ASCII =20 representation of the characters." =20 Eugene Nechamkin, Broadcom Corp. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Jul 30 22:01: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 WAA15772 for ; Fri, 30 Jul 2004 22:01:22 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BqjDx-0000yz-Rf for ipcdn-archive@ietf.org; Fri, 30 Jul 2004 22:03:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BqjAU-0000Rb-Tw; Fri, 30 Jul 2004 22:00:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bqize-0007dv-1S for ipcdn@megatron.ietf.org; Fri, 30 Jul 2004 21:49: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 VAA15431 for ; Fri, 30 Jul 2004 21:48:59 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bqj1z-0000sL-8s for ipcdn@ietf.org; Fri, 30 Jul 2004 21:51:28 -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 i6V1mRbw003595; Fri, 30 Jul 2004 19:48:28 -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: Fri, 30 Jul 2004 19:48:27 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E674@srvxchg.cablelabs.com> Thread-Topic: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft Thread-Index: AcRzxPpjI4oVQMDyRJeBNLbstGf1KgChlFtQABUjfsA= From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft 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: e9eeacd7fe925d5f7faae01ed8f85b97 Content-Transfer-Encoding: quoted-printable FYI, This email was sent early today with an attachment of draft BPI 14,=20 It maybe in quarantine to verify viruses This items will be presented by Jean-Francois Mule, Tuesday in IETF IPCDN meeting=20 Eduardo -----Original Message----- From: Eduardo Cardona=20 Sent: Friday, July 30, 2004 9:46 AM To: 'Wijnen, Bert (Bert)'; 'Ipcdn (E-mail)' Subject: RE: Additional AD review: draft-ietf-ipcdn-bpiplus-mib-13.txt-> ID-14 pre-draft Bert,=20 Find a log with the comments for the issues=20 I organize them in a sort of high to low priority, also attached is a draft of the adds into a document to submit ti IETF before Augost 2 or tomorrow, with all the updates Thanks Eduardo ------------------- I see that to this: But thinking even further, Possibly the best thing to do is to use docsBpi2CmtsIpMulticastAddressType InetAddressType, docsBpi2CmtsIpMulticastAddress InetAddress, docsBpi2CmtsIpMulticastPrefixLength InetAddressPrefixLength, Are not such masks always setup that they basically specify a prefixlength? If so, then this is the way to do it with the TCs from INET-ADDRESS-MIB.=20 your answer seems to be: This issue was brought up before and Rich Woundy exposed a detail explanation of the design requirements in favor of a netmask instead of an InetPrefixLength /RFC2373/3513 plus en email from Rich, stating that it might be good to explanation which I cannot find. Can that explanation be added to DESCRIPTION clause(s)? I cannot understand that from current DESCRIPTION clauses, or am I not reading=20 clear at this late hour of the night? The email lost.... -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 Sent: Wednesday, February 19, 2003 8:04 AM To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail) Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail) Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask Bert, Since I am the person that most likely influenced the BPI+ MIB's use=20 of a netmask rather than a prefix length, I suppose I should directly=20 answer your question. (Of course, that makes your suggestion about putting the explanation in the DESCRIPTION clause all the wiser.) The IPv6 addressing architecture is currently defined in RFC 2373.=20 Section 2.7 describes the format of the IPv6 multicast addresses:=20 8 bits of '11111111' for identification as multicast,=20 4 bits of 'flags', 4 bits of 'scope', and 112 bits of 'group ID'.=20 Five scope values are defined for node-local, link-local, site-local,=20 organization-local, and global scopes.=20 Section 2.7.2 shows how new IPv6 multicast addresses can be assigned,=20 making reference to RFC 2375. The draft draft-ietf-ipngwg-addr-arch-v3-11.txt, which updates RFC 2373, defines six scope values: interface-local, link-local, admin-local, site-local,=20 organization-local, and global scopes. Some of the permanently assigned IPv6 multicast addresses appear in RFC=20 2375. This RFC includes all-scope addresses in section 3.0 -- these multicast=20 address assignments apply for all IPv6 multicast scope contexts. Typically, these=20 assignments are written as "FF0X:...". These assignments are referred to as=20 "Variable Scope Multicast Addresses" by IANA,=20 . As an operator, I would strongly prefer to use one row in the BPI+ MIB table to match each of these variable-scope permanently assigned addresses. I want to avoid creating five to six rows (one per defined multicast scope) or sixteen rows (one per potential multicast scope). Unfortunately, every prefix of an IPv6 multicast address that contains at least one bit of the 'group ID' MUST contain the entire 'flags' and 'scope' components. The only way to perform an address match based solely on 'group ID' while ignoring the 'scope' is to use a non-contiguous netmask. If there is a better way to accomplish this, I would love to learn about it. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, February 18, 2003 7:13 AM To: Ipcdn (E-mail) Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail) Subject: [ipcdn] InetAddress or PrefixLength as a mask During the IPCDN WG interim meeting last week I question why in=20 docsBpi2CmtsIpMulticastMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the IP multicast address mask for this row. An IP multicast address matches this row if the logical AND of the address with docsBpi2CmtsIpMulticastMask is identical to the logical AND of docsBpi2CmtsIpMulticastAddr with docsBpi2CmtsIpMulticastMask." ::=3D { docsBpi2CmtsIpMulticastMapEntry 5 } You specify the mask as an InetAddress and not as an InetAddressPrefixLength. I was given some explanations,=20 but I am not 100% sure I understood and I am not 100% sure they are valid.=20 Could the authors pls respond with an explanation (which I think should also be inclued in the DESCRIPTION clause if it is accepted). There may be other occurences of this in one ore more of your MIB documents. Thanks, Bert=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 End of email.... Added in section 2.1.2. Cable Modem Termination System In particular, docsBpi2CmtsIpMulticastMapTable defines=20 the object docsBpi2CmtsIpMulticastMask (non-contiguous=20 netmask) instead of the INET-ADDRESS-MIB MIB Module=20 [RFC3291] Textual Convention InetAddressPrefixLength.=20 This is to facilitate the assignment of same SAID for=20 a IPv6 multicast group ID prefix matching several/any=20 Ipv6 multicast scope types with a unique entry in this=20 table. e.g. To assign transient multicast group prefix 'Y'=20 to SAID 'z' for ANY multicast scope the non-contiguous=20 netmak will be FF10:Y see [RFC3513] for details on IPv6 addressing Also a similar note as proposed for draft 13 comments (not included ID-13 expecting resolution in this open discussion). docsBpi2CmtsIpMulticastMask OBJECT-TYPE DESCRIPTION ".... Note: For IPv6 this object needs not to represent a=20 contiguous netmask, e.g. to associate a SAID to a =20 multicast group id with a the value of the field=20 multicast scope as a mapping criteria." ----------------- As a follow up to this, there was this comment from me: >=20 > Mmm, in your response I see: >=20 > "Discontinuities of this counter are indicated by sysUpTime and > ifCounterDiscontinuityTime for the associated ifIndex." >=20 > Not sure I understand this. > Checking with other MIB doctors. >=20 The first thing we found is that it is not so clear what the text means, but it probably menas the same things as for other IF-MIB related counters,=20 i.e. (as also used in IF-MIB, RFC2863), it means: Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. And if that is indeed the case, then this new text would be MUCH better. Now, when you added the text about discontinuities, it also makes it more=20 visible that one could really question if the use of ZeroBasedCounter32=20 makes sense and if a regular Counter32 would not be much much better. Have you read the ZeroBasedCounter32 TC and the text that explains what this type=20 of counter was meant for? One comment from another MIB doctor is: A ZeroBasedCounter32 in a conceptual row which can experience discontinuities as part of its normal operational behaviour just seems a bit odd to me. I fail to see what the advantage of a ZeroBasedCounter32 in such a situation is. Another comment (in relation to ifCounterDiscontinuityTime) is that it would be very good to add some text (somewhere early on in the draft)=20 that points to RFC2863, page 12, which has some good text about that object.=20 As per the comment of another MIB Doctor: I think it would be extremely helpful to have a discussion what this means somewhere in the introductionary text together with a pointer to the relevant text in the IF-MIB RFCs (which has some paragraphs about this subject that are interesting to know for implementors). Looking at the MIB, the question that I have is the interaction of discontinuities with these ZeroBasedCounter32 objects. Does a discontinuity couse these counters to be reset to zero? The TC says that a zero based counter is set to zero(0) on creation and it has additional text that the intended usage is in tables where the index space is constantly changing. Does this apply here? Of course you have clarified (but in some prose early on in the draft=20 may want to re-emphasize) that the ZeroBasedCounter32 only MUST be set=20 to zero at row creation. But some additional discussion seems usefull. =20 Added the suggested Discontinuity statement from RFC 2863 Also a new section=20 For the discussions if really ZeroBasedCounter32 are needed the section below may clean up some of the concerns. 2.3 BPI+ MIB module relationship with The Interfaces Group MIB The BPI+ MIB module is the management framework of Baseline Privacy Plus Interface Specification [1], which provides the MAC layer (Media Access Control) security Services of DOCSIS. The BPI+ MIB module objects are organized as extensions of the Radio Frequency (RF) Interface Management [RFC2670].=20 The MIB table structures of this MIB Module are extensions of the=20 DOCSIS CATV (Community Antenna Television) MAC layer interface (DocsCableMaclayer by [IANA]). In particular the provisions of the Interface Group MIB[RFC2863] for counters discontinuities and=20 system re-initialization apply to CM and CMTS to validate the=20 difference between two consecutive counters polls. In the case of the CM, BPI+ mode is not enabled until the CM properly=20 registers and a new BPI+ FSM (Full State Machine) is initialized. When CM reboots, counters defined in docsBpi2CmBaseTable,=20 docsBpi2CmTEKTable and docsBpi2CmIpMulticastMapTable are not retained in memory and start at zero. The syntax ZeroBasedCounter32 per=20 [RFC 2021] is used for this counters In the case of the CMTS There are two types of counters:=20 o Counters defined in docsBpi2CmtsBaseTable which are=20 Interface extensions for the BPI+ management of the=20 Interface are regular Counter32 objects. o Entries in tables docsBpi2CmtsAuthTable, docsBpi2CmtsTEKTable and docsBpi2CmtsIpMulticastMapTable are created and deleted=20 dynamically by the management system or by configuration. Counters defined in these tables are of type=20 ZeroBasedCounter32 and set to value zero at creation time. All counters requirements are in the scope of 32 bits counters needs=20 in terms of minimum time to wrap-up [RFC2863] due the fact that those=20 counters are related to events for the BPI+_FSM (e.g. request, replies, rejects, etc.) and their frequency occurrence (see [1] for configuration options and timeouts). As a clarification note, ZeroBasedCounters32 are not set back to zero when=20 discontinuities of the interface associated to the entries. ------------------ docsBpi2CmtsCACertThumbprint OBJECT-TYPE Note: The zero-length string must be returned if this object is not supported by the CMTS." That seems weird. If an object is not supported, I would expect to return a noSuchObject exception. !! similar to the requirements of docsBpi2CmtsCACert, ThumbPrint Certificate validation=20 is an optional feature on DOCSIS, The CMTS is in the freedom to report the value=20 of either docsBpi2CmtsCACert (constly -whole Certificate-) or the ThumbPrint object . the other option could be to define a optional group (only one object) =20 Note: The zero-length OCTET STRING must be returned, on reads, if the CA certificate thumb print is not retained=20 in the CMTS." -------------------- I also see: Rather than a Compliance statement ( the object MUST be supported) I believe an indication of=20 "Note: For CMs running in BPI mode, this object value has no meaning, therefore the CMTS may not instantiate this object=20 for those CM entries." And so that would mean that the agent returns a noSuchInstance exception! The initial intentions of the authors I believe was to avoid holes in=20 docsBpi2CmtsCACertEntry; Not being a valid semantic reason, Updated to say: "Note: This object has no meaning for CMs running in BPI=20 mode, therefore this object is not instantiated for entries associated to those CMs." =20 -------------------- 10. I see: docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not be timed out." Mmm... that "need not be timed out" seems in conflict with the RowStatus TC DESCRIPTION clause in RFC2579. Can you explain why this is? Also, a RowSTatus object MUST specify in its DESCRIPTION clause under which conditions - the row can be activated - which columns (if any) can bve changed while in the active state. I am missing the first. Removed the prohibition to age out inactive row entries. Added: "A created row can be set to active only after the corresponding instances of=20 docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all been set, otherwise the status of this object is 'notReady'". Mmm... the status could also be notInService I would think? Why not remove that last piece of the sentence, i.e. remove: , otherwise the status of this object is 'notReady' done --------------------- As a follow up to this, there was this comment from me: >=20 > Mmm, in your response I see: >=20 > "Discontinuities of this counter are indicated by sysUpTime and > ifCounterDiscontinuityTime for the associated ifIndex." >=20 > Not sure I understand this. > Checking with other MIB doctors. >=20 The first thing we found is that it is not so clear what the text means, but it probably menas the same things as for other IF-MIB related counters, i.e. (as also used in IF-MIB, RFC2863), it means: Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of ifCounterDiscontinuityTime. And if that is indeed the case, then this new text would be MUCH better. Now, when you added the text about discontinuities, it also makes it more visible that one could really question if the use of ZeroBasedCounter32 makes sense and if a regular Counter32 would not be much much better. Have you read the ZeroBasedCounter32 TC and the text that explains what this type of counter was meant for? One comment from another MIB doctor is: A ZeroBasedCounter32 in a conceptual row which can experience discontinuities as part of its normal operational behaviour just seems a bit odd to me. I fail to see what the advantage of a ZeroBasedCounter32 in such a situation is. Another comment (in relation to ifCounterDiscontinuityTime) is that it=20 would be very good to add some text (somewhere early on in the draft)=20 that points to RFC2863, page 12, which has some good text about that object. As per the comment of another MIB Doctor: I think it would be extremely helpful to have a discussion what this means somewhere in the introductionary text together with a pointer to the relevant text in the IF-MIB RFCs (which has some paragraphs about this subject that are interesting to know for implementors). Looking at the MIB, the question that I have is the interaction of discontinuities with these ZeroBasedCounter32 objects. Does a discontinuity couse these counters to be reset to zero? The TC says that a zero based counter is set to zero(0) on creation and it has additional text that the intended usage is in tables where the index space is constantly changing. Does this apply here? Of course you have clarified (but in some prose early on in the draft may want to re-emphasize) that the ZeroBasedCounter32 only MUST be set to zero at row creation. But some additional discussion seems usefull. - Check in which draft the "since reboot was added." -------------- Some quick notes, Here we go: 1. SMICng tells me: W: f(ipcdnbpi2.mi2), (3142,17) Duplicate item "docsBpi2CmtsIpMulticastAddressType" in compliances list for module "DOCS-IETF-BPI2-MIB" W: f(ipcdnbpi2.mi2), (3152,17) Duplicate item "docsBpi2CmtsIpMulticastAddress" in compliances list for module "DOCS-IETF-BPI2-MIB" Seems you duplicated something. cleaned 2. docsBpi2CmtsIpMulticastMapControl OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object controls and reflects the IP multicast address mapping entry. There is no restriction on the ability to change values in this row while the row is active. Inactive rows need not A created row can be timed out." set to active only after the Corresponding instances of docsBpi2CmtsIpMulticastAddress, docsBpi2CmtsIpMulticastMask, docsBpi2CmtsIpMulticastSAId and docsBpi2CmtsIpMulticastSAType have all been set, otherwise the status of this object is 'notReady'. There is no restriction on the ability to change values in this row while the row is active." ::=3D { docsBpi2CmtsIpMulticastMapEntry 14 } Last sentence in DESCRIPTION clause is duplicate of 2nd sentence. Are you sure value is 'notReady' in that case? Could be notInService too, no? Why specify it. I.e. I would remove otherwise the status of this object is 'notReady' done 3. docsBpi2CmtsIpMulticastMapStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-only STATUS current DESCRIPTION "The storage type for this conceptual row." You must (according to RFC 2579) add txt to stat which (if any) writable objects MUST be writeable even for permanent entries. See 2579 fo details. By compliance this table could be read-only,=20 StorageType is read-only. That offers the flexibility for the implementer to configure the BPI+ multiple options of mapping multicast groups to SAID=20 Types primary, static, or dynamic. Implementer can always choose to assign SNMP created entries as 'nonVolatile' and leave 'permanent' for administrative commands, without update options.=20 Added : A SNMP SET for of any writable object with a rows StorageType of 'permanent' returns an error 'notWritable'." =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn