From exim@www1.ietf.org Thu Apr 1 14:40:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27198 for ; Thu, 1 Apr 2004 14:40:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B982n-0002Lz-Df for ipcdn-archive@odin.ietf.org; Thu, 01 Apr 2004 14:40:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Je56t009048 for ipcdn-archive@odin.ietf.org; Thu, 1 Apr 2004 14:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B982k-0002LZ-H8; Thu, 01 Apr 2004 14:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B982H-0002Ju-9h for ipcdn@optimus.ietf.org; Thu, 01 Apr 2004 14:39:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27147 for ; Thu, 1 Apr 2004 14:39:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9824-0001hq-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:39:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9819-0001cG-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:38:24 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B980M-0001XB-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:37:34 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31Jbho4008405 for ; Thu, 1 Apr 2004 12:37:43 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i31JbUjG012596 for ; Thu, 1 Apr 2004 13:37:32 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 1 Apr 2004 11:37:29 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'Jean-Francois Mule'" , "'Woundy, Richard'" Date: Thu, 1 Apr 2004 11:35:45 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] NCS Signaling MIB SC Objects Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Jean-Francois, Please comment on the CL position regarding the deletion of the following service class objects from the NCS MIB as proposed by ETSI. The last notes I have indicate the CL DQoS team was investigating this issue as originally raised by tComlabs. Thanks. >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState objects from the current MIB definition until a workable form of its associated mechanisms is defined. >The removal of these objects from the MIB does not mean that there is no more mechanism to establish a separate NCS Service Flow, because such a Service Flow can still be defined in the Cable Modem config file (with the use of a Service Class Name if desired). This works, because in this case the Service Flow is set up during the CM Registration process, without the need for DSA messaging. This is also probably the way it is currently done, since the use of the above MIB objects is not possible with an IPCablecom/PacketCable compliant CMTS. >Leaving the MIB objects in place, while awaiting the definition of a workable mechanism is not an option either, because this new definition would most likely have different MIB requirements. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 1 14:43:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27328 for ; Thu, 1 Apr 2004 14:43:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B985d-0002Vd-5w for ipcdn-archive@odin.ietf.org; Thu, 01 Apr 2004 14:43:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i31Jh1la009623 for ipcdn-archive@odin.ietf.org; Thu, 1 Apr 2004 14:43:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B985c-0002V3-Tz; Thu, 01 Apr 2004 14:43:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B985B-0002UT-KR for ipcdn@optimus.ietf.org; Thu, 01 Apr 2004 14:42:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27317 for ; Thu, 1 Apr 2004 14:42:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B984y-000216-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:42:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9844-0001wi-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:41:25 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1B983N-0001pu-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:40:42 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i31JefnQ021718 for ; Thu, 1 Apr 2004 12:40:41 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i31JbTlH006426 for ; Thu, 1 Apr 2004 13:37:30 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 1 Apr 2004 11:37:29 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'David De Reu'" , Eugene Nechamkin , Beacham Gordon-CGB005 , Wim De Ketelaere Cc: Jean-Francois Mule Subject: [ipcdn] pktcSigDevToneDbLevel syntax change Date: Thu, 1 Apr 2004 11:36:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , > I think the issue with "pktcSigDevToneDbLevel" has not been > completeley agreed upon (see attached is the latest feedback from > Broadcom). Agreed. Change has been made to: pktcSigDevToneDbLevel OBJECT-TYPE SYNTAX TenthdBm (-250..-30) Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 2 00:04:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09555 for ; Fri, 2 Apr 2004 00:04:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E2m-0003Io-HS for ipcdn-archive@odin.ietf.org; Thu, 01 Apr 2004 21:04:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3224SMS012694 for ipcdn-archive@odin.ietf.org; Thu, 1 Apr 2004 21:04:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ADW-0007uJ-7g; Thu, 01 Apr 2004 16:59:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B982H-0002Jz-Rd for ipcdn@optimus.ietf.org; Thu, 01 Apr 2004 14:39:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27150 for ; Thu, 1 Apr 2004 14:39:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9825-0001hv-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:39:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B981A-0001cQ-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:38:25 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1B980N-0001XD-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:37:35 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i31Jbfo4008355 for ; Thu, 1 Apr 2004 12:37:41 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id i31JbUjF012596 for ; Thu, 1 Apr 2004 13:37:30 -0600 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 1 Apr 2004 11:37:29 -0800 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" , "'David De Reu'" , azlina@cisco.com, Beacham Gordon-CGB005 Subject: RE: [ipcdn] Editorial Changes - NCS MIB Date: Thu, 1 Apr 2004 11:36:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Agreed. Thanks for your comments. Gordon -----Original Message----- From: David De Reu [mailto:DeReu@tComLabs.com] Sent: Tuesday, March 30, 2004 10:50 PM To: IPCDN Mailing List; azlina@cisco.com; Beacham Gordon-CGB005 Subject: RE: [ipcdn] Editorial Changes - NCS MIB > > 3. Change pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } to: > > pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 2 } > > Recommend keeping the notification as it is per Appendix D > of the draft-ietf-ops-mib-review-guidelines-02.txt. Good point indeed. We currently have pktcSigNotification OBJECT IDENTIFIER ::= { pktcSigMib 0 } pktcSigMibObjects OBJECT IDENTIFIER ::= { pktcSigMib 1 } pktcSigConformance OBJECT IDENTIFIER ::= { pktcSigMib 3 } When we follow the OID layout suggested in appendix D of , which is xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) then I suggest instead redefining pktcSigConformance as pktcSigConformance OBJECT IDENTIFIER ::= { pktcSigMib 2 } Thanks, Regards, David _____________________________________________________ David De Reu tComLabs Stapelplein 70/004 - 9000 Ghent - Belgium Tel: +32 9 269 22 91 - Fax: +32 9 329 31 74 www.tComLabs.com _____________________________________________________ _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 2 00:04:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09579 for ; Fri, 2 Apr 2004 00:04:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9E3Z-0003lk-K7 for ipcdn-archive@odin.ietf.org; Thu, 01 Apr 2004 21:05:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3225Hv6014468 for ipcdn-archive@odin.ietf.org; Thu, 1 Apr 2004 21:05:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ADb-0007vR-Ny; Thu, 01 Apr 2004 16:59:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B98F5-0002nJ-37 for ipcdn@optimus.ietf.org; Thu, 01 Apr 2004 14:52:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27651 for ; Thu, 1 Apr 2004 14:52:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B98Es-00030j-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:52:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B98Dy-0002tO-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:51:38 -0500 Received: from mms1.broadcom.com ([63.70.210.58]) by ietf-mx with esmtp (Exim 4.12) id 1B98DC-0002kM-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 14:50:50 -0500 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 01 Apr 2004 11:50:39 -0800 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from nt-irva-0741.brcm.ad.broadcom.com ( nt-irva-0741.brcm.ad.broadcom.com [10.8.194.54]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id LAA02857; Thu, 1 Apr 2004 11:49:50 -0800 (PST) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0741.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Thu, 1 Apr 2004 11:45:54 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] pktcSigDevToneDbLevel syntax change X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Thu, 1 Apr 2004 11:45:50 -0800 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2D094@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] pktcSigDevToneDbLevel syntax change Thread-Index: AcQYINUjoXJF0lmcRE+8WdsAhEIhyAAAQOHw From: "Eugene Nechamkin" To: "Beacham Gordon-CGB005" , ipcdn@ietf.org, "David De Reu" , "Wim De Ketelaere" cc: "Jean-Francois Mule" X-OriginalArrivalTime: 01 Apr 2004 19:45:54.0992 (UTC) FILETIME=[F2376300:01C41821] X-WSS-ID: 6C72AD051NO11222333-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks. Eugene. -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com] Sent: Thursday, April 01, 2004 11:36 AM To: 'ipcdn@ietf.org'; 'David De Reu'; Eugene Nechamkin; Beacham Gordon-CGB005; Wim De Ketelaere Cc: Jean-Francois Mule Subject: [ipcdn] pktcSigDevToneDbLevel syntax change > I think the issue with "pktcSigDevToneDbLevel" has not been > completeley agreed upon (see attached is the latest feedback from > Broadcom). Agreed. Change has been made to: pktcSigDevToneDbLevel OBJECT-TYPE SYNTAX TenthdBm (-250..-30) Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 2 06:47:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04619 for ; Fri, 2 Apr 2004 06:47:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9JwE-00022i-OH for ipcdn-archive@odin.ietf.org; Fri, 02 Apr 2004 03:22:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i328M6BC007850 for ipcdn-archive@odin.ietf.org; Fri, 2 Apr 2004 03:22:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9ECA-0008Jo-DX; Thu, 01 Apr 2004 21:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9CU0-0008Ol-1f for ipcdn@optimus.ietf.org; Thu, 01 Apr 2004 19:24:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13535 for ; Thu, 1 Apr 2004 19:24:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9CTy-0001Qz-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 19:24:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9CT2-0001Kc-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 19:23:29 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1B9CSD-000189-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 19:22:37 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i320M4ut023819; Thu, 1 Apr 2004 17:22:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Apr 2004 17:22:04 -0700 Message-ID: Thread-Topic: NCS Signaling MIB SC Objects Thread-Index: AcQYIMjdi/657JGyQOKXD60mfJePXAAHI3ng From: "Jean-Francois Mule" To: "Beacham Gordon-CGB005" , "David De Reu" , "Wim De Ketelaere" Cc: , "Richard Woundy @ Comcast" , "Kevin Johns" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: NCS Signaling MIB SC Objects Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Okay, now it is my turn to be reminded to close on some issues, I see... = ;) thx for the reminder. We did discuss this question internally with the packetcable team. We = believe that these 3 MIB objects still make sense and that they must be = kept in the NCS signaling MIB. I will try to provide some justification = below. I also cc: Kevin Johns who is our PacketCable QoS lead so he can = chime in on the responses to this note, and may be Greg White can help = too. --- Context These 3 objects are typically used in the MTA config file to indicate = specific service class name(s) corresponding to a pre-provisioned set of = QoS paramaters on the CMTS. If SET in the MTA config file, the MTA can = instruct the CM to generate a SF with the specific service class name = (SCN) so that the MTA NCS signaling packets can use the special service = flow rather than best effort. Unlike PacketCable DQoS which defines = AuthBlock and TLVs like gateid for the MTA to use in the DSx msging, the = SCN use is not intended to use any of the packetcable gate related = parameters =3D> no AuthBlock. DQoS DSx is used to create/modify SF = dynamically for the media streams: NCS starts as soon as the MTA = provisioning is complete, the MTA registers with the CMS (RSIP, etc.) = and a call can be initiated (NCS CRCX with gate info in LCO,...) and QoS = can be installed for that call. The pb is to guarantee some QoS for the = NCS data and this is what those objects are for. So these objects are valid to use in a DOCSIS dialog initiated by the = embedded CM of the MTA with the CMTS. A DSx message with a classifier = and SCN for US|DS and no AuthBlock (hence no gateID) is a valid DOCSIS = qos message. Upon activation, the SCN-based flow, NCS runs over qos SF.=20 --- Response to questions from both Gordon (4/1) and David (1/19) On Thrusday April 1st, Gordon wrote: > >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS,=20 > >pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState=20 > objects from=20 > >the current MIB definition until a workable form of its associated=20 > >mechanisms is defined.=20 I don't see what's wrong with the mechanism I described above. It seems = a workable form to me & Kevin. Gordon wrote: > The removal of these objects from the=20 > MIB does not mean that there is no more mechanism to=20 > establish a separate NCS Service Flow, because such a Service=20 > Flow can still be defined in the Cable Modem config file=20 > (with the use of a Service Class Name if desired).=20 This breaks the whole concept of decoupling the data provisioning from = the voice provisioning. Why ask the data provider to put special CM = config for some voice NCS signaling flows that the Telephony Service = Provider might use? Why not keep the trigger of a special flow for NCS = in the telephony prov, especially since this is an E-MTA with an = embedded CM =3D> the MTA f() can very effectively pass the SCN params = onto the CM? > This=20 > works, because in this case the Service Flow is set up during=20 > the CM Registration process, without the need for DSA=20 > messaging.=20 An E-MTA has an embedded cable modem and it is valid for an E-MTA to = initiate plain docsis DSx messaging (in addition to the DQoS flavored = ones). > This is also probably the way it is currently=20 > done,=20 See above. > since the use of the above MIB objects is not possible=20 > with an IPCablecom/PacketCable compliant CMTS.=20 Disagree. See context above: a compliant ipcablecom/packetcable CMTS is = also a compliant DOCSIS CMTS. > Leaving the=20 > MIB objects in place, while awaiting the definition of a=20 > workable mechanism is not an option either, because this new=20 > definition would most likely have different MIB requirements. This works today, and is used. On January 19, 2004, David de Reu wrote: > (1) pktcSigServiceClassName(US|DS|Mask) objects >=20 > There is still a problem with the=20 > pktcSigServiceClassName(US|DS|Mask) > objects (and indirectly with the related pktcSigNcsServiceFlowState > object). Although the MIBs currently reflect the PacketCable PROV > spec text, the proposed system for setting up a signaling service > flow will *NOT* work with a PacketCable/IPCablecom compliant CMTS. How so? This is incorrect. Note that Service Class Names are also used in the so called = "PacketCable Multimedia" QoS (a policy server using COPS can invoke a = SCN which will trigger the CMTS to initiate DSx with a CM). > This is because the CMTS must reject all DSx messaging initiated by > the CM if there is no valid authorization block.=20 This assumption is not valid. If no Authblock, treat the DSx like a = plain docsis msg (and if there's a correct classifier and a valid = pre-provisioned SCN that can be matched on the CMTS, proceed with SF). > There is no such > block in this case (there even is no gate on the CMTS). Note that Yes no authblock but there's a SCN which matches some pre-provisioned = QoS data on the CMTS. > this does not mean that PacketCable takes a step backward=20 > compared to > (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that=20 > a CM is not > allowed to initiate DSx messaging, since it is not allowed=20 > to expose > an interface to the outside world to do this.=20 I'm not sure I follow this point. > For an=20 > embedded MTA in > PacketCable, this interface is present and the DSx=20 > messaging *can* be > initiated by the CM, but the CMTS will accept it only if the > appropriate authorization can take place (using the authorization > block). Nope, that is true for an E-MTA initiated DSx message compliant to DQoS = only. I'm told this assertion is not true for a CM initiated DSx msg. > Operationally, the practical solution is quite simple. You can add > the necessary MIB objects in the CM config file (specifying the If this is for the NCS flow, why not the MTA config file -- again keep = the telephony related config param in the MTA portion of the prov. > service flow parameters directly, or alternatively using a Service > Class Name (SCN)).=20 Well, this is exactly what we are doing here and it just happens to be = in the SIG MIB so that the MTA which is the entity generating the NCS = traffic knows what SCN <-> SF to use to pass on the data to the eCM. > In that case, the CM will set up the=20 > service flow > during its registration, without the need for DSx messaging. >=20 > Solution: It is of course not up to the SIG MIB to provide=20 > a solution > to this problem.=20 Why not if it is for the NCS signaling? > However, if the=20 > pktcSigServiceClassName(US|DS|Mask) > objects *are* included in the MIB, then you have a set of=20 > objects of > which you know on forehand that they are useless.=20 We obviously do not agree and this has been in our specs for many years = now. > So the question > seems to me: do we want to include these objects in the=20 > MIB? We could > also leave them out now, and wait for a correctly functioning > mechanism to be defined in the PacketCable/IPCablecom specs. > Alternatively, if the objects remain in the MIB, then we=20 > have to ask > ourselves what will be required from an MTA: we will=20 > require that the > MTA does the DSA nevertheless, knowing that it will not succeed > anyway? I hope I've helped clarified this. Jean-Fran=E7ois =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 2 07:31:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06421 for ; Fri, 2 Apr 2004 07:31:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9KM2-0003zT-Fp for ipcdn-archive@odin.ietf.org; Fri, 02 Apr 2004 03:48:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i328mk1j015340 for ipcdn-archive@odin.ietf.org; Fri, 2 Apr 2004 03:48:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9G8y-0000EF-DW; Thu, 01 Apr 2004 23:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9D6x-00085V-Om for ipcdn@optimus.ietf.org; Thu, 01 Apr 2004 20:04:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16010 for ; Thu, 1 Apr 2004 20:04:39 -0500 (EST) From: perozbabu@mototech.com.tw Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9D6v-0006Qp-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 20:04:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9D5x-0006Ht-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 20:03:42 -0500 Received: from 211-23-55-85.hinet-ip.hinet.net ([211.23.55.85] helo=MX2.mototech.com.tw) by ietf-mx with smtp (Exim 4.12) id 1B9D59-00063Z-00 for ipcdn@ietf.org; Thu, 01 Apr 2004 20:02:53 -0500 Received: (qmail 8598 invoked from network); 2 Apr 2004 01:02:12 -0000 Received: from unknown (HELO mototech.com.tw) ([10.12.1.9]) (envelope-sender ) by mx2.mototech.com.tw (qmail-ldap-1.03) with SMTP for ; 2 Apr 2004 01:02:12 -0000 To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 2 Apr 2004 08:58:11 +0800 X-MIMETrack: Serialize by Router on NS1/Mototech(Release 5.0.9 |November 16, 2001) at 2004/04/02 08:58:11 AM MIME-Version: 1.0 Content-type: text/plain; charset=Big5 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=NO_REAL_NAME autolearn=no version=2.60 Subject: [ipcdn] Re: Please unsubscribe my access to ipcdn Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , sir, Please unsubscribe my access to ipcdn Thanks, Peroz Babu mailman-owner@www To: perozbabu@mototech.com.tw 1.ietf.org cc: Sent by: Subject: ietf.org mailing list memberships reminder mailman-admin@iet f.org 04/02/2004 12:19 AM 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, ipcdn-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for perozbabu@mototech.com.tw: List Password // URL ---- -------- ipcdn@ietf.org babubabu https://www1.ietf.org/mailman/options/ipcdn/perozbabu%40mototech.com.tw _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 2 11:01:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15680 for ; Fri, 2 Apr 2004 11:01:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9OT8-0007WY-7h for ipcdn-archive@odin.ietf.org; Fri, 02 Apr 2004 08:12:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i32DCMWa028922 for ipcdn-archive@odin.ietf.org; Fri, 2 Apr 2004 08:12:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9LAg-000714-VQ; Fri, 02 Apr 2004 04:41:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B9HoD-0005H3-Gz for ipcdn@optimus.ietf.org; Fri, 02 Apr 2004 01:05:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11573 for ; Fri, 2 Apr 2004 01:05:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B9HoA-0001wq-00 for ipcdn@ietf.org; Fri, 02 Apr 2004 01:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B9HnU-0001rM-00 for ipcdn@ietf.org; Fri, 02 Apr 2004 01:04:57 -0500 Received: from adicia.telenet-ops.be ([195.130.132.56]) by ietf-mx with esmtp (Exim 4.12) id 1B9Hmz-0001kf-00 for ipcdn@ietf.org; Fri, 02 Apr 2004 01:04:25 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by adicia.telenet-ops.be (Postfix) with SMTP id 6232F44182 for ; Fri, 2 Apr 2004 08:04:22 +0200 (MEST) Received: from tcomlabs.com (D5E0B8ED.kabel.telenet.be [213.224.184.237]) by adicia.telenet-ops.be (Postfix) with ESMTP id F37B1440B4 for ; Fri, 2 Apr 2004 08:04:21 +0200 (MEST) Received: (qmail 3526 invoked from network); 2 Apr 2004 08:03:46 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 2 Apr 2004 08:03:46 +0200 Received: from ([10.5.5.37]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 2 Apr 2004 08:03:45 +0200 (CEST) From: "Wim De Ketelaere" To: "'Jean-Francois Mule'" , "'Beacham Gordon-CGB005'" , "'David De Reu'" Cc: , "'Richard Woundy @ Comcast'" , "'Kevin Johns'" Date: Fri, 2 Apr 2004 08:04:24 +0200 Message-ID: <000701c41878$59e09890$2505050a@LAPTOPWIM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: NCS Signaling MIB SC Objects Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, I do not discuss the usefullness of the objects, I just believe they don't work due to the way the spec is currently written for the CMTS. section 3.2.5 of DQOS-IO8 clearly specifies: If the PacketCable Authorization Module receives a bandwidth reservation request (i.e. a DSA) without an authorization block, the CMTS must reject the request. Unless the dQoS specification is changed so that a clear distinction is made between what is meant for PacketCable authorization=20 and what is not,=20 I still don't see how it can work. It is clearly not the intention of the PacketCable specification that any DSA for a SCN will always succeed, this would be=20 a very easy theft-of-service scenario,..... The DSA for the SCN will be a valid DSA on the DOCSIS level, but if the CMTS has PacketCable enabled, it will not pass the authorization module and be rejected for that reason, this is, unless we change something on the requirements for a CMTS.=20 But I don't have an easy solution for that, just stating that any SCN can be allowed without authorization opens up a security hole,... Just stating that it is valid on the DOCSIS level and is therefor okay is, I believe, a too easy answer, this would make any PacketCable compliant CMTS, non-DOCSIS compliant. A PacketCable CMTS MUST reject a DSA without the authorization block present ! If needed I can clarify my reasoning, in a conf call if this helps to solve the problem, this problem is already=20 on discussion for too long ! Thanks, Best regards, Wim Wim De Ketelaere CTO tComLabs=20 -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]=20 Sent: 02 April 2004 02:22 To: Beacham Gordon-CGB005; David De Reu; Wim De Ketelaere Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Kevin Johns Subject: RE: NCS Signaling MIB SC Objects Okay, now it is my turn to be reminded to close on some issues, I see... ;) thx for the reminder. We did discuss this question internally with the packetcable team. We believe that these 3 MIB objects still make sense and that they must be kept in the NCS signaling MIB. I will try to provide some justification below. I also cc: Kevin Johns who is our PacketCable QoS lead so he can chime in on the responses to this note, and may be Greg White can help too. --- Context These 3 objects are typically used in the MTA config file to indicate specific service class name(s) corresponding to a pre-provisioned set of QoS paramaters on the CMTS. If SET in the MTA config file, the MTA can instruct the CM to generate a SF with the specific service class name (SCN) so that the MTA NCS signaling packets can use the special service flow rather than best effort. Unlike PacketCable DQoS which defines AuthBlock and TLVs like gateid for the MTA to use in the DSx msging, the SCN use is not intended to use any of the packetcable gate related parameters =3D> no AuthBlock. DQoS DSx is used to create/modify SF dynamically for the media streams: NCS starts as soon as the MTA provisioning is complete, the MTA registers with the CMS (RSIP, etc.) and a call can be initiated (NCS CRCX with gate info in LCO,...) and QoS can be installed for that call. The pb is to guarantee some QoS for the NCS data and this is what those objects are for. So these objects are valid to use in a DOCSIS dialog initiated by the embedded CM of the MTA with the CMTS. A DSx message with a classifier and SCN for US|DS and no AuthBlock (hence no gateID) is a valid DOCSIS qos message. Upon activation, the SCN-based flow, NCS runs over qos SF.=20 --- Response to questions from both Gordon (4/1) and David (1/19) On Thrusday April 1st, Gordon wrote: > >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, > >pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState=20 > objects from > >the current MIB definition until a workable form of its associated > >mechanisms is defined.=20 I don't see what's wrong with the mechanism I described above. It seems a workable form to me & Kevin. Gordon wrote: > The removal of these objects from the=20 > MIB does not mean that there is no more mechanism to=20 > establish a separate NCS Service Flow, because such a Service=20 > Flow can still be defined in the Cable Modem config file=20 > (with the use of a Service Class Name if desired).=20 This breaks the whole concept of decoupling the data provisioning from the voice provisioning. Why ask the data provider to put special CM config for some voice NCS signaling flows that the Telephony Service Provider might use? Why not keep the trigger of a special flow for NCS in the telephony prov, especially since this is an E-MTA with an embedded CM =3D> the MTA f() can very effectively pass the SCN params = onto the CM? > This=20 > works, because in this case the Service Flow is set up during=20 > the CM Registration process, without the need for DSA=20 > messaging.=20 An E-MTA has an embedded cable modem and it is valid for an E-MTA to initiate plain docsis DSx messaging (in addition to the DQoS flavored ones). > This is also probably the way it is currently=20 > done,=20 See above. > since the use of the above MIB objects is not possible=20 > with an IPCablecom/PacketCable compliant CMTS.=20 Disagree. See context above: a compliant ipcablecom/packetcable CMTS is also a compliant DOCSIS CMTS. > Leaving the=20 > MIB objects in place, while awaiting the definition of a=20 > workable mechanism is not an option either, because this new=20 > definition would most likely have different MIB requirements. This works today, and is used. On January 19, 2004, David de Reu wrote: > (1) pktcSigServiceClassName(US|DS|Mask) objects >=20 > There is still a problem with the=20 > pktcSigServiceClassName(US|DS|Mask) > objects (and indirectly with the related pktcSigNcsServiceFlowState > object). Although the MIBs currently reflect the PacketCable PROV > spec text, the proposed system for setting up a signaling service > flow will *NOT* work with a PacketCable/IPCablecom compliant CMTS. How so? This is incorrect. Note that Service Class Names are also used in the so called "PacketCable Multimedia" QoS (a policy server using COPS can invoke a SCN which will trigger the CMTS to initiate DSx with a CM). > This is because the CMTS must reject all DSx messaging initiated by > the CM if there is no valid authorization block.=20 This assumption is not valid. If no Authblock, treat the DSx like a plain docsis msg (and if there's a correct classifier and a valid pre-provisioned SCN that can be matched on the CMTS, proceed with SF). > There is no such > block in this case (there even is no gate on the CMTS). Note that Yes no authblock but there's a SCN which matches some pre-provisioned QoS data on the CMTS. > this does not mean that PacketCable takes a step backward=20 > compared to > (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that=20 > a CM is not > allowed to initiate DSx messaging, since it is not allowed=20 > to expose > an interface to the outside world to do this.=20 I'm not sure I follow this point. > For an=20 > embedded MTA in > PacketCable, this interface is present and the DSx=20 > messaging *can* be > initiated by the CM, but the CMTS will accept it only if the > appropriate authorization can take place (using the authorization > block). Nope, that is true for an E-MTA initiated DSx message compliant to DQoS only. I'm told this assertion is not true for a CM initiated DSx msg. > Operationally, the practical solution is quite simple. You can add > the necessary MIB objects in the CM config file (specifying the If this is for the NCS flow, why not the MTA config file -- again keep the telephony related config param in the MTA portion of the prov. > service flow parameters directly, or alternatively using a Service > Class Name (SCN)).=20 Well, this is exactly what we are doing here and it just happens to be in the SIG MIB so that the MTA which is the entity generating the NCS traffic knows what SCN <-> SF to use to pass on the data to the eCM. > In that case, the CM will set up the=20 > service flow > during its registration, without the need for DSx messaging. >=20 > Solution: It is of course not up to the SIG MIB to provide=20 > a solution > to this problem.=20 Why not if it is for the NCS signaling? > However, if the=20 > pktcSigServiceClassName(US|DS|Mask) > objects *are* included in the MIB, then you have a set of=20 > objects of > which you know on forehand that they are useless.=20 We obviously do not agree and this has been in our specs for many years now. > So the question > seems to me: do we want to include these objects in the=20 > MIB? We could > also leave them out now, and wait for a correctly functioning > mechanism to be defined in the PacketCable/IPCablecom specs. > Alternatively, if the objects remain in the MIB, then we=20 > have to ask > ourselves what will be required from an MTA: we will=20 > require that the > MTA does the DSA nevertheless, knowing that it will not succeed > anyway? I hope I've helped clarified this. Jean-Fran=E7ois =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 6 18:50:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07176 for ; Tue, 6 Apr 2004 18:50:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzOM-00083r-MB for ipcdn-archive@odin.ietf.org; Tue, 06 Apr 2004 18:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36Mo2vO030954 for ipcdn-archive@odin.ietf.org; Tue, 6 Apr 2004 18:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzOK-00081z-Pi; Tue, 06 Apr 2004 18:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzNh-000806-Uu for ipcdn@optimus.ietf.org; Tue, 06 Apr 2004 18:49: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 SAA07163 for ; Tue, 6 Apr 2004 18:49:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzNe-0006IE-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 18:49:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAyPT-0007Cn-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 17:47:09 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BAxez-0000gK-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 16:59:05 -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 i36KwWut020952; Tue, 6 Apr 2004 14:58:33 -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] IPCDN qos mib - publication has been requested Date: Tue, 6 Apr 2004 14:58:32 -0600 Message-ID: Thread-Topic: [ipcdn] IPCDN qos mib - publication has been requested Thread-Index: AcQYs+/sKkV252K3SOCIiuJqqyhPagDZWnTQ From: "Jean-Francois Mule" To: Cc: "Patrick Michael-LZZ007" , "Murwin William-LWM008" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks, We have requested publication of the ipcdn-qos-mib ID as Proposed = Standard. This ID had passed WGLC and we had responded to AD comments in November. Publication requested for: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-09.txt Please note that once a request to publish an ID as an RFC has=20 been submitted, the ID must not be revised without the explicit=20 advance approval of the shepherding Area Director (AD) [Bert Wijnen]. Jean-Fran=E7ois=20 IPCDN co-chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 6 19:06:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08473 for ; Tue, 6 Apr 2004 19:06:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzdq-0002tE-K0 for ipcdn-archive@odin.ietf.org; Tue, 06 Apr 2004 19:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i36N62tZ011043 for ipcdn-archive@odin.ietf.org; Tue, 6 Apr 2004 19:06:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzdo-0002rl-Vd; Tue, 06 Apr 2004 19:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BAzd4-0002op-CI for ipcdn@optimus.ietf.org; Tue, 06 Apr 2004 19:05:15 -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 TAA08415 for ; Tue, 6 Apr 2004 19:05:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BAzd1-00003I-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 19:05:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAya0-000140-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 17:58:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BAxr7-0001xc-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 17:11:37 -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 i36LB4ut023242; Tue, 6 Apr 2004 15:11:05 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Re: Please unsubscribe my access to ipcdn Date: Tue, 6 Apr 2004 15:11:04 -0600 Message-ID: Thread-Topic: [ipcdn] Re: Please unsubscribe my access to ipcdn Thread-Index: AcQYjvJjnSNSIk0cTWuR6Kb8wZybMgDixrzg From: "Jean-Francois Mule" To: Cc: X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable You may do this yourselves at: http://www1.ietf.org/mailman/listinfo/ipcdn Peroz Babu wrote: > sir, > Please unsubscribe my access to ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 6 20:10:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16557 for ; Tue, 6 Apr 2004 20:10:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0dq-0004ZD-BI for ipcdn-archive@odin.ietf.org; Tue, 06 Apr 2004 20:10:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i370A6PY017535 for ipcdn-archive@odin.ietf.org; Tue, 6 Apr 2004 20:10:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0dm-0004Tl-U7; Tue, 06 Apr 2004 20:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BB0dD-0004OM-Li for ipcdn@optimus.ietf.org; Tue, 06 Apr 2004 20:09: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 UAA16252 for ; Tue, 6 Apr 2004 20:09:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BB0dB-0000xC-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 20:09:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BAzzK-0002O9-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 19:28:16 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BAyp1-0002zT-00 for ipcdn@ietf.org; Tue, 06 Apr 2004 18:13:31 -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 i36MCSux003206; Tue, 6 Apr 2004 16:12:58 -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: NCS Signaling MIB SC Objects Date: Tue, 6 Apr 2004 16:12:24 -0600 Message-ID: Thread-Topic: [ipcdn] RE: NCS Signaling MIB SC Objects Thread-Index: AcQYs+/sKkV252K3SOCIiuJqqyhPagDaOClw From: "Jean-Francois Mule" To: "Wim De Ketelaere" , "Beacham Gordon-CGB005" , "David De Reu" Cc: , "Richard Woundy @ Comcast" , "Kevin Johns" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Wim, We had some additional discussions internal between the PacketCable & = DOCSIS guys, and we concur on our spec(s) interpretation (Greg on the = DOCSIS side, Kevin and I on the PacketCable side). More importantly, the = CMTS vendors seem to be in sync with our interpretation based on what we = have seen in our labs ([CMTS vendors, feel free to speak up here]). Here's what we can summarize: 1) The PacketCable specs do not intend to imply (nor require) that = DSx-REQs that lack a PacketCable Auth Block be authorized by the = "PacketCable Authorization Module". While we do define the behavior of = the "PacketCable Authorization Module", we do not preclude CMTS to = employ other modules to authorize DOCSIS-based DSx requests. Perhaps the = text could be clarified in DQOS sec. 3.2.5 to add some informative text = around that. However, our understanding is that vendors are clear on = this already. The PacketCable compliant CMTS will support at least two = independent authorization modules: one for DSx-REQs that contain a = PacketCable Auth Block as defined in DQOS I09, and one for those that do = not. Again, if there is no packetcable TLV in the DSx req, why shouldn't = this request be processed by a docsis authorization module?=20 2) The treatment of DSx-REQs that lack a PacketCable Auth Block is = currently in the realm of vendor differentiation. DOCSIS only requires = that the CMTS authorize the request in some manner. Whether that = authorization defaults to "allow" for all requests, "deny" for all = requests, or some rules in between is left to the CMTS vendor and its = QoS policy configurations. 3) This feature is defined so that the operator can configure = high-priority signaling flows for the MTAs on their system. In order to = use this feature, they will need to take a number of steps, including = configuration of the CMTS to allow (ie "pre-authorize") the creation of = service flows based on the SCN in the MTA config file. And Greg, Kevin = and I strongly agree that these mib objects are more suited in the MTA = config file than in the CM one. 4) Even if the operator misconfigures the CMTS (either by not defining = the SCN, or by not "pre-authorizing" it), or the CMTS doesn't support = this feature, the MTA will only attempt to create the signaling flow, = and then upon failure, default to sending all signaling traffic on the = primary US/DS service flows. Therefore, we maintain that these 3 mib objects are pertinent and should = stay in the MTA mib. Jean-Fran=E7ois=20 > -----Original Message----- > From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] > Sent: Thursday, April 01, 2004 11:04 PM > To: Jean-Francois Mule; 'Beacham Gordon-CGB005'; 'David De Reu' > Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Kevin Johns > Subject: [ipcdn] RE: NCS Signaling MIB SC Objects >=20 >=20 > Hi all, >=20 >=20 > I do not discuss the usefullness of the objects, > I just believe they don't work due to the way the spec is > currently written for the CMTS. >=20 >=20 > section 3.2.5 of DQOS-IO8 clearly specifies: >=20 > If the PacketCable Authorization Module receives a bandwidth > reservation request (i.e. a DSA) without an authorization=20 > block, the CMTS must reject the request. Note the informative statement (lowercase) is on the PacketCable Auth = Module. Note that a PacketCable CMTS is a DOCSIS compliant CMTS as well = and when it sees a DSx request from the eCM embedded in the MTA that = does not contain any packetcable tlvs, the CMTS has no way of saying: = but hey, that's a PacketCable MTA request so one could argue that this = requirement is really for those DSA requests that do contain some = packetcable tlvs but the request is malformed or wrong. > Unless the dQoS specification is changed so that a clear > distinction is made between what is meant >=20 > for PacketCable authorization > and what is not,=20 >=20 > I still don't see how it can work. I hope my earlier email and the explanations above have helped clarified = this. > It is clearly not the intention of the PacketCable > specification that any DSA for a SCN will always succeed,=20 That is a question of MSO policy authorization and is left for vendor = differentiation. Some QoS policy configuration & information models are = available in IETF but this is out of the scope of our QoS specs.=20 > this would be=20 > a very easy theft-of-service scenario,..... An operator would have to allow this. > The DSA for the SCN will be a valid DSA on the DOCSIS level, > but if the CMTS has PacketCable enabled, it will not pass the=20 > authorization module and be rejected for that reason, this=20 ^ PacketCable authorization module and again, it does not even hit the PacketCable auth module but that = it gets handled by the plain docsis auth module. > is, unless we change something on the requirements for a CMTS.=20 >=20 > But I don't have an easy solution for that, just stating that > any SCN can be allowed without authorization opens up a=20 > security hole,... Operator decision. > Just stating that it is valid on the DOCSIS level and is > therefor okay is, I believe, a too easy answer, this would=20 > make any PacketCable compliant CMTS, non-DOCSIS compliant. A=20 > PacketCable CMTS MUST reject a DSA without the authorization=20 > block present ! We disagree. > If needed I can clarify my reasoning, in a conf call if this > helps to solve the problem, this problem is already=20 > on discussion for too long ! >=20 >=20 > Thanks, > Best regards, > Wim >=20 >=20 > Wim De Ketelaere > CTO > tComLabs >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: 02 April 2004 02:22 > To: Beacham Gordon-CGB005; David De Reu; Wim De Ketelaere > Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Kevin Johns > Subject: RE: NCS Signaling MIB SC Objects >=20 >=20 > Okay, now it is my turn to be reminded to close on some > issues, I see... > ;) thx for the reminder. >=20 > We did discuss this question internally with the packetcable > team. We believe that these 3 MIB objects still make sense=20 > and that they must be kept in the NCS signaling MIB. I will=20 > try to provide some justification below. I also cc: Kevin=20 > Johns who is our PacketCable QoS lead so he can chime in on=20 > the responses to this note, and may be Greg White can help too. >=20 > --- Context > These 3 objects are typically used in the MTA config file to > indicate specific service class name(s) corresponding to a=20 > pre-provisioned set of QoS paramaters on the CMTS. If SET in=20 > the MTA config file, the MTA can instruct the CM to generate=20 > a SF with the specific service class name > (SCN) so that the MTA NCS signaling packets can use the=20 > special service flow rather than best effort. Unlike=20 > PacketCable DQoS which defines AuthBlock and TLVs like gateid=20 > for the MTA to use in the DSx msging, the SCN use is not=20 > intended to use any of the packetcable gate related=20 > parameters =3D> no AuthBlock. DQoS DSx is used to create/modify=20 > SF dynamically for the media streams: NCS starts as soon as=20 > the MTA provisioning is complete, the MTA registers with the=20 > CMS (RSIP, etc.) and a call can be initiated (NCS CRCX with=20 > gate info in LCO,...) and QoS can be installed for that call.=20 > The pb is to guarantee some QoS for the NCS data and this is=20 > what those objects are for. So these objects are valid to use=20 > in a DOCSIS dialog initiated by the embedded CM of the MTA=20 > with the CMTS. A DSx message with a classifier and SCN for=20 > US|DS and no AuthBlock (hence no gateID) is a valid DOCSIS > qos message. Upon activation, the SCN-based flow, NCS runs > over qos SF.=20 >=20 > --- Response to questions from both Gordon (4/1) and David > (1/19) On Thrusday April 1st, Gordon wrote: > > >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, > > >pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState > > objects from > > >the current MIB definition until a workable form of its associated > > >mechanisms is defined. > I don't see what's wrong with the mechanism I described > above. It seems a workable form to me & Kevin. >=20 >=20 > Gordon wrote: > > The removal of these objects from the > > MIB does not mean that there is no more mechanism to > > establish a separate NCS Service Flow, because such a Service=20 > > Flow can still be defined in the Cable Modem config file=20 > > (with the use of a Service Class Name if desired).=20 > This breaks the whole concept of decoupling the data > provisioning from the voice provisioning. Why ask the data=20 > provider to put special CM config for some voice NCS=20 > signaling flows that the Telephony Service Provider might=20 > use? Why not keep the trigger of a special flow for NCS in=20 > the telephony prov, especially since this is an E-MTA with an=20 > embedded CM =3D> the MTA f() can very effectively pass the SCN=20 > params onto the CM? >=20 > > This > > works, because in this case the Service Flow is set up during > > the CM Registration process, without the need for DSA=20 > > messaging.=20 > An E-MTA has an embedded cable modem and it is valid for an > E-MTA to initiate plain docsis DSx messaging (in addition to=20 > the DQoS flavored ones). >=20 > > This is also probably the way it is currently > > done, > See above. >=20 > > since the use of the above MIB objects is not possible > > with an IPCablecom/PacketCable compliant CMTS.=20 > Disagree. See context above: a compliant > ipcablecom/packetcable CMTS is > also a compliant DOCSIS CMTS. >=20 > > Leaving the > > MIB objects in place, while awaiting the definition of a=20 > > workable mechanism is not an option either, because this new=20 > > definition would most likely have different MIB requirements. > This works today, and is used. >=20 >=20 > On January 19, 2004, David de Reu wrote: > > (1) pktcSigServiceClassName(US|DS|Mask) objects > >=20 > > There is still a problem with the > > pktcSigServiceClassName(US|DS|Mask) > > objects (and indirectly with the related=20 > pktcSigNcsServiceFlowState > > object). Although the MIBs currently reflect the PacketCable PROV > > spec text, the proposed system for setting up a signaling service > > flow will *NOT* work with a PacketCable/IPCablecom > compliant CMTS. > How so? This is incorrect. > Note that Service Class Names are also used in the so called=20 > "PacketCable Multimedia" QoS (a policy server using COPS can invoke a=20 > SCN which will trigger the CMTS to initiate DSx with a CM). >=20 > > This is because the CMTS must reject all DSx messaging > initiated by > > the CM if there is no valid authorization block. > This assumption is not valid. If no Authblock, treat the DSx like a=20 > plain docsis msg (and if there's a correct classifier and a valid=20 > pre-provisioned SCN that can be matched on the CMTS, proceed with SF). >=20 > > There is no such > > block in this case (there even is no gate on the CMTS). Note that > Yes no authblock but there's a SCN which matches some pre-provisioned=20 > QoS data on the CMTS. >=20 > > this does not mean that PacketCable takes a step backward > > compared to > > (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that=20 > > a CM is not > > allowed to initiate DSx messaging, since it is not allowed=20 > > to expose > > an interface to the outside world to do this.=20 > I'm not sure I follow this point. >=20 > > For an > > embedded MTA in > > PacketCable, this interface is present and the DSx=20 > > messaging *can* be > > initiated by the CM, but the CMTS will accept it only if the > > appropriate authorization can take place (using the authorization > > block). > Nope, that is true for an E-MTA initiated DSx message > compliant to DQoS > only. I'm told this assertion is not true for a CM initiated DSx msg. >=20 > > Operationally, the practical solution is quite simple. > You can add > > the necessary MIB objects in the CM config file (specifying the > If this is for the NCS flow, why not the MTA config file -- again keep = > the telephony related config param in the MTA portion of the prov. >=20 > > service flow parameters directly, or alternatively using > a Service > > Class Name (SCN)). > Well, this is exactly what we are doing here and it just happens to be = > in the SIG MIB so that the MTA which is the entity generating the NCS=20 > traffic knows what SCN <-> SF to use to pass on the data to the eCM. >=20 > > In that case, the CM will set up the > > service flow > > during its registration, without the need for DSx messaging. > >=20 > > Solution: It is of course not up to the SIG MIB to provide > > a solution > > to this problem.=20 > Why not if it is for the NCS signaling? >=20 > > However, if the > > pktcSigServiceClassName(US|DS|Mask) > > objects *are* included in the MIB, then you have a set of=20 > > objects of > > which you know on forehand that they are useless.=20 > We obviously do not agree and this has been in our specs for > many years > now. >=20 > > So the question > > seems to me: do we want to include these objects in the > > MIB? We could > > also leave them out now, and wait for a correctly functioning > > mechanism to be defined in the PacketCable/IPCablecom specs. > > Alternatively, if the objects remain in the MIB, then we=20 > > have to ask > > ourselves what will be required from an MTA: we will=20 > > require that the > > MTA does the DSA nevertheless, knowing that it will not succeed > > anyway? >=20 >=20 > I hope I've helped clarified this. > Jean-Fran=E7ois >=20 >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 7 19:44:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20186 for ; Wed, 7 Apr 2004 19:44:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBMiA-0002qv-7i for ipcdn-archive@odin.ietf.org; Wed, 07 Apr 2004 19:44:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i37Ni2jk010957 for ipcdn-archive@odin.ietf.org; Wed, 7 Apr 2004 19:44:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBMi8-0002q1-Gt; Wed, 07 Apr 2004 19:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBMhJ-0002nj-8z for ipcdn@optimus.ietf.org; Wed, 07 Apr 2004 19:43: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 TAA20138 for ; Wed, 7 Apr 2004 19:43:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBMhH-0006DH-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 19:43:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBKfq-0000M1-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 17:33:31 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BBJDk-0003Ro-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 16:00:24 -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 i37Jxjut025134; Wed, 7 Apr 2004 13:59:46 -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: NCS Signaling MIB SC Objects Date: Wed, 7 Apr 2004 13:59:45 -0600 Message-ID: Thread-Topic: [ipcdn] RE: NCS Signaling MIB SC Objects Thread-Index: AcQctFyxszoJLpJqQQ+K+WncNlVBiAAJhHyg From: "Jean-Francois Mule" To: "Thomas Anders" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Thomas, We can address the security concern in the security consideration = question (and beef up the text there). As far as the spec = interpretation, we could add some text in the description clause to = mention that, if these objects are set, the E-MTA eCM will issue a valid = DSx msg to be processed by the DOCSIS Authorization Module. Any other vendors supporting/rejecting these objects? Jean-Fran=E7ois=20 > -----Original Message----- > From: Thomas Anders [mailto:thomas.anders@blue-cable.de]=20 > Sent: Wednesday, April 07, 2004 7:17 AM > To: ipcdn@ietf.org > Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects >=20 >=20 > Hi all, >=20 > since part of this discussion is related to MSOs, we'd like=20 > to speak up. >=20 > Wim> It is clearly not the intention of the PacketCable > Wim> specification that any DSA for a SCN will always succeed, > JFM> > JFM> That is a question of MSO policy authorization and is left for=20 > JFM> vendor > differentiation. > [...] > Wim> this would be a very easy theft-of-service scenario > JFM> > JFM> An operator would have to allow this. > [...] > Wim> just stating that any SCN can be allowed without authorization > Wim> opens up a security hole > JFM> > JFM> Operator decision. >=20 > We as an MSO clearly see more (security) problems than=20 > benefits with this approach. We can hardly imagine "vendor=20 > differentiation" offering any acceptable solution here. Even=20 > worse, much like Wim, we don't think it fits with the current specs. >=20 >=20 > Best regards, > Thomas >=20 > --=20 > Thomas Anders (thomas.anders at blue-cable.de) > Bosch Breitbandnetze GmbH, Berlin, Germany >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 7 20:57:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25957 for ; Wed, 7 Apr 2004 20:57:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNqy-0004yL-Lx for ipcdn-archive@odin.ietf.org; Wed, 07 Apr 2004 20:57:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i380vCnQ019114 for ipcdn-archive@odin.ietf.org; Wed, 7 Apr 2004 20:57:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNqw-0004xO-Js; Wed, 07 Apr 2004 20:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBNqc-0004pK-9k for ipcdn@optimus.ietf.org; Wed, 07 Apr 2004 20:56: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 UAA25889 for ; Wed, 7 Apr 2004 20:56:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBNqZ-0006r9-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 20:56:47 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBLi6-0000ml-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 18:39:55 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BBKIn-0003p0-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 17:09: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 i37L97ut007888; Wed, 7 Apr 2004 15:09:07 -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: NCS Signaling MIB SC Objects Date: Wed, 7 Apr 2004 15:09:07 -0600 Message-ID: Thread-Topic: [ipcdn] RE: NCS Signaling MIB SC Objects Thread-Index: AcQctFyxszoJLpJqQQ+K+WncNlVBiAALBe0w From: "Jean-Francois Mule" To: "Thomas Anders" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thomas wrote: > We as an MSO clearly see more (security) problems than=20 > benefits with this approach. We can hardly imagine "vendor=20 > differentiation" offering any acceptable solution here. Thank you for your comment. I'm trying to understand your concern in = more details. Could you help us and elaborate on what "security = problems" you are seeing with this approach? Here's my brief analysis: - a CMTS is pre-provisioned by the MSO operator with a specific SCN. = Securing this CMTS provisioning interface is out of scope of this E-MTA = mib discussion. One should assume that MSOs use secure means to = provision key parameters on their CMTSes. Note that this SCN is = associated with particular traffic qos profiles for NCS signaling (such = parameters could be even restricted to the specific NCS UDP port, etc.). - the specific SCN is passed to the E-MTA in the configuration file = during provisioning (using Secure software download). - Access to this MIB object is manageable via std SNMPv3 USM/VACM/etc. = mechanisms. IF the management operations that are in full control of the MSO = operators are done in a secure manner (authentication of mgmt = operations, privacy on CMTS write/MTA read operations of SCN, = restriction of traffic profiles to specific MTA IP adds && NCS protocol = UDP ports), the security threats seem quite minimal and can be mitigated = by setting strict profile parameters: - theft of bandwidth: in an attacker does obtain a valid SCN, if the = traffic profile is restricted to the NCS UDP port (udp 2327/2727), the = attacker may gain access to a special SF as long as its applications use = NCS ports (and use that with the NCS sendto ports). I fail to see what = real theft this may entail. - denial of service: I do not see any. Worst case, if the NCS SF is = not usable, you have best effort. - other threats? > Even=20 > worse, much like Wim, we don't think it fits with the current specs. I went over the informative must statement Wim indicated and explained = that it pertains to the "PacketCable Authorization Module". It is our = understanding that these DSx msg would appear like traditional DOCSIS = DSx coming from the CM and therefore, they are not expected to hit the = packetcable auth module and are not subject to this requirement. Jean-Fran=E7ois=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 7 22:06:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07203 for ; Wed, 7 Apr 2004 22:06:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOvb-0004z3-SK for ipcdn-archive@odin.ietf.org; Wed, 07 Apr 2004 22:06:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38263mh019157 for ipcdn-archive@odin.ietf.org; Wed, 7 Apr 2004 22:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOvY-0004xn-Vm; Wed, 07 Apr 2004 22:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBOuz-0004vm-TV for ipcdn@optimus.ietf.org; Wed, 07 Apr 2004 22:05: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 WAA07136 for ; Wed, 7 Apr 2004 22:05:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBOuw-0001kP-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 22:05:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNbI-0004GF-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 20:41:02 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BBLKs-0006L9-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 18:15:54 -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 i37MF8ut019113; Wed, 7 Apr 2004 16:15:08 -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 review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Wed, 7 Apr 2004 16:15:08 -0600 Message-ID: Thread-Topic: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Thread-Index: AcPql1cYYxHVIUk1R02CjMUjuIRwHgyVT10A From: "Jean-Francois Mule" To: Cc: "Nakanishi Greg-MGI8179" , "Azlina Ahmad" , "Richard Woundy @ Comcast" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Folks, Draft03 of the DOCSIS event notif mgmt mib was published on Feb 3rd = 2004. It's been 2 months already and no comments have been received on = this ID update. This draft was first published in May 2001. The wg chairs would like to ask for volunteers to review this draft = before issuing WGLC soon. Let Rich or myself know if you would like to = review this draft. Thank you in advance, Rich Woundy & Jean-Fran=E7ois Mule IPCDN co-chairs. > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, February 03, 2004 1:49 PM > Cc: ipcdn@ietf.org > Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docsisevent-mib-03.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 : Event Notification Management=20 > Information Base for=20 > DOCSIS Compliant Cable Modems and Cable Modem=20 > Termination Systems > Author(s) : A. Ahmad > Filename : draft-ietf-ipcdn-docsisevent-mib-03.txt > Pages : 30 > Date : 2004-2-3 > =09 > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet=20 > community. > In particular, it defines a basic set of managed objects for SNMP- > based event notification management of DOCSIS compliant=20 > Cable Modems > and Cable Modem Termination Systems. This MIB is defined as an > extension to the DOCSIS Cable Device MIB, RFC 2669 [5]. >=20 > This memo specifies a MIB module in a manner that is=20 > compliant to the > SMIv2. The set of objects is 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-docsiseve nt-mib-03.txt To remove yourself from the IETF Announcement list, send a message to=20 ietf-announce-request with the word unsubscribe in the body of the = message. Internet-Drafts are also available by anonymous FTP. Login with the = username "anonymous" and a password of your e-mail address. After = logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-docsisevent-mib-03.txt". A list of Internet-Drafts directories can be found in = http://www.ietf.org/shadow.html=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-docsisevent-mib-03.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 exim@www1.ietf.org Wed Apr 7 22:15:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07525 for ; Wed, 7 Apr 2004 22:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBP4I-00079z-VB for ipcdn-archive@odin.ietf.org; Wed, 07 Apr 2004 22:15:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i382F2BG027513 for ipcdn-archive@odin.ietf.org; Wed, 7 Apr 2004 22:15:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBP4H-00078y-Gk; Wed, 07 Apr 2004 22:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBP3Y-00076i-6b for ipcdn@optimus.ietf.org; Wed, 07 Apr 2004 22:14:16 -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 WAA07445 for ; Wed, 7 Apr 2004 22:14:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBP3V-0002Xg-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 22:14:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBNek-00051N-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 20:44:35 -0400 Received: from pacdcoavas09.cable.comcast.com ([208.17.33.58]) by ietf-mx with esmtp (Exim 4.12) id 1BBLUZ-0007BX-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 18:25:55 -0400 Message-ID: From: "Woundy, Richard" To: "'Thomas Anders'" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects Date: Wed, 7 Apr 2004 18:18:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Speaking as another MSO (and not wearing my co-chair hat)... I am not personally fond of a "CMTS approving any SCN without authorization"; that sounds like a great way to enable theft of service. :^( But I don't think that is what CableLabs is advocating. One case that seems to make sense is if the service flow is pre-authorized in the CM configuration file (e.g. Provisioned but not Admitted/Active). This might be used on an MTA that is initially disabled for telephone service, to conserve on reserved bandwidth on DOCSIS. When the MTA is enabled much later for telephony service (via SNMP Sets), the eCM would send a DSC for the existing provisioned service flow. (Note that the language that folks point to in the DQOS spec refers to rejecting both DSAs and DSCs without authorization blocks.) Another case that might potentially make sense is if the CMTS enforced that all upstream traffic for a specific SCN be directed only towards the CMS. In other words, if a CM sends a DSA for the NCS signaling SCN, then for the resulting service flow, the CMTS would drop all upstream traffic not directed to the CMS. I'm not sure I'm a big fan of this approach, but I could see how other operators might use it. I think in all cases, it should be much more clearly specified in the DQOS specs that the CMTSs have to implement configuration parameters in order to permit/deny these types of DSAs/DSCs. In other words, it should be an operator decision to enable DSAs and DSCs without a PacketCable authorization block -- not a vendor implementation decision. -- Rich -----Original Message----- From: Thomas Anders [mailto:thomas.anders@blue-cable.de] Sent: Wednesday, April 07, 2004 9:17 AM To: ipcdn@ietf.org Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects Hi all, since part of this discussion is related to MSOs, we'd like to speak up. Wim> It is clearly not the intention of the PacketCable Wim> specification that any DSA for a SCN will always succeed, JFM> JFM> That is a question of MSO policy authorization and is left for vendor differentiation. [...] Wim> this would be a very easy theft-of-service scenario JFM> JFM> An operator would have to allow this. [...] Wim> just stating that any SCN can be allowed without authorization Wim> opens up a security hole JFM> JFM> Operator decision. We as an MSO clearly see more (security) problems than benefits with this approach. We can hardly imagine "vendor differentiation" offering any acceptable solution here. Even worse, much like Wim, we don't think it fits with the current specs. Best regards, Thomas -- Thomas Anders (thomas.anders at blue-cable.de) Bosch Breitbandnetze GmbH, Berlin, Germany _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 8 00:51:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16532 for ; Thu, 8 Apr 2004 00:51:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRVU-0003uR-BW for ipcdn-archive@odin.ietf.org; Thu, 08 Apr 2004 00:51:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i384pGEI015027 for ipcdn-archive@odin.ietf.org; Thu, 8 Apr 2004 00:51:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRVS-0003sg-NZ; Thu, 08 Apr 2004 00:51:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBRV5-0003UI-2E for ipcdn@optimus.ietf.org; Thu, 08 Apr 2004 00:50:51 -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 AAA16287 for ; Thu, 8 Apr 2004 00:50:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBRV2-0001Ws-00 for ipcdn@ietf.org; Thu, 08 Apr 2004 00:50:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBP1O-0002Lw-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 22:12:03 -0400 Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx with esmtp (Exim 4.12) id 1BBNeK-0004uk-00 for ipcdn@ietf.org; Wed, 07 Apr 2004 20:44:08 -0400 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Wed, 07 Apr 2004 17:43:33 -0700 X-Server-Uuid: 011F2A72-58F1-4BCE-832F-B0D661E896E8 Received: from nt-irva-0740.brcm.ad.broadcom.com ( nt-irva-0740.brcm.ad.broadcom.com [10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA21469; Wed, 7 Apr 2004 17:43:00 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Wed, 7 Apr 2004 17:43:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects Date: Wed, 7 Apr 2004 17:43:29 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2D142@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] RE: NCS Signaling MIB SC Objects Thread-Index: AcQctGSxUANsQJQMQQmWNTbo1rZ7kAATZZTw From: "Eugene Nechamkin" To: "Thomas Anders" cc: ipcdn@ietf.org X-OriginalArrivalTime: 08 Apr 2004 00:43:33.0800 (UTC) FILETIME=[855FBA80:01C41D02] X-WSS-ID: 6C6A7FBF1PO428146-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Thomas, > We as an MSO clearly see more (security) problems than benefits with = this > approach.=20 Could you be more specific on particular (security) concerns you see as = the potential problems for SC Objects usage and implementation ? Thanks, Eugene Nechamkin Broadcom Corp, ph: (604) 233-8500 -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Thomas Anders Sent: Wednesday, April 07, 2004 6:17 AM To: ipcdn@ietf.org Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects Hi all, since part of this discussion is related to MSOs, we'd like to speak up. Wim> It is clearly not the intention of the PacketCable Wim> specification that any DSA for a SCN will always succeed, JFM> JFM> That is a question of MSO policy authorization and is left for = vendor=20 differentiation. [...] Wim> this would be a very easy theft-of-service scenario JFM> JFM> An operator would have to allow this. [...] Wim> just stating that any SCN can be allowed without authorization Wim> opens up a security hole JFM> JFM> Operator decision. We as an MSO clearly see more (security) problems than benefits with = this approach. We can hardly imagine "vendor differentiation" offering any acceptable solution here. Even worse, much like Wim, we don't think it fits with the current specs. Best regards, Thomas --=20 Thomas Anders (thomas.anders at blue-cable.de) Bosch Breitbandnetze GmbH, Berlin, Germany _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 8 11:03:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25552 for ; Thu, 8 Apr 2004 11:03:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBb3V-0004LM-8M for ipcdn-archive@odin.ietf.org; Thu, 08 Apr 2004 11:03:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i38F31HT016697 for ipcdn-archive@odin.ietf.org; Thu, 8 Apr 2004 11:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBb3U-0004L6-HR; Thu, 08 Apr 2004 11:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BBb3L-0004Kq-FC for ipcdn@optimus.ietf.org; Thu, 08 Apr 2004 11:02:51 -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 LAA25533 for ; Thu, 8 Apr 2004 11:02:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BBb3I-0003oB-00 for ipcdn@ietf.org; Thu, 08 Apr 2004 11:02:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BBYyw-0004Fz-00 for ipcdn@ietf.org; Thu, 08 Apr 2004 08:50:11 -0400 Received: from poseidon.internet-on.tv ([62.117.0.13] helo=mail.blue-cable.net) by ietf-mx with esmtp (Exim 4.12) id 1BBWhf-0004rw-00 for ipcdn@ietf.org; Thu, 08 Apr 2004 06:24:11 -0400 Received: from ncc-zwickau.internet-on.tv ([172.16.2.1] helo=blue-cable.de) by mail.blue-cable.net with esmtp (Exim 4.22) id 1BBWh1-0001qb-25; Thu, 08 Apr 2004 12:23:31 +0200 Message-ID: <40752822.1020108@blue-cable.de> Date: Thu, 08 Apr 2004 12:23:30 +0200 From: Thomas Anders User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: ipcdn@ietf.org Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Envelope-From: thomas.anders@blue-cable.de X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, Jean-Francois Mule wrote: > Thank you for your comment. I'm trying to understand your concern in more > details. Could you help us and elaborate on what "security problems" you > are seeing with this approach? It's left up to "vendor differentiation" to ensure that if an operator allows DSx for NCS SCNs, the CMTS MUST NOT allow *any* DSx (w/o gate id) to succeed. We'd weight the involved risks too high to rely on "vendor differentiation" here. Rather, if we add SC objects to the SIG MIB, the corresponding DSx authorization should be properly addressed by the specifications (enabling proper certification testing) also. We should either go the whole way or not go it at all. > I went over the informative must statement Wim indicated and explained that > it pertains to the "PacketCable Authorization Module". It is our understanding > that these DSx msg would appear like traditional DOCSIS DSx coming from the CM > and therefore, they are not expected to hit the packetcable auth module and are > not subject to this requirement. If this is the original intention of the specs (which I still doubt), then it's ambiguous at best. Isn't it extremely non-obvious to pass a DSx-REQ for a PacketCable NCS flow to be used by a PacketCable MTA as defined by a PacketCable MTA config file setting based on the PacketCable SIG MIB to the CMTS *DOCSIS* Auth Module instead of the *PacketCable* Auth Module? Best regards, Thomas -- Thomas Anders (thomas.anders at blue-cable.de) _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 12 11:34:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25309 for ; Mon, 12 Apr 2004 11:34:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3Rj-0003Fp-D2 for ipcdn-archive@odin.ietf.org; Mon, 12 Apr 2004 11:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CFY3rc012486 for ipcdn-archive@odin.ietf.org; Mon, 12 Apr 2004 11:34:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3Rh-0003F5-FH; Mon, 12 Apr 2004 11:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD3RL-0003E4-BP for ipcdn@optimus.ietf.org; Mon, 12 Apr 2004 11:33: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 LAA25271 for ; Mon, 12 Apr 2004 11:33:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD3RI-0007kE-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 11:33:36 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD3NV-0007Ku-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 11:29:42 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BD3Jx-0006uz-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 11:26:01 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3CFQAek023371 for ; Mon, 12 Apr 2004 08:26:10 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i3CFOg6w004073 for ; Mon, 12 Apr 2004 10:24:42 -0500 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id ; Mon, 12 Apr 2004 11:25:53 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF2381037FD707@ma19exm01.e6.bcs.mot.com> From: Murwin William-LWM008 To: "IPCDN (E-mail) (E-mail)" Cc: Flanagan David-LDF002 , Patrick Michael-LZZ007 Date: Mon, 12 Apr 2004 11:25:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ipcdn] NCS Signaling MIB SC Objects Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , We (Motorola CMTS) agree with Clabs' interpretation. Setting up a service flow for NCS signaling with SCN names is a DOCSIS authorization concern. How a CMTS authorizes DOCSIS based DSX requests is a policy decision based on configuarion at the CMTS. To echo Rich, it should be much more clearly specified in the DQOS specs that the CMTSs have to implement configuration parameters in order to permit/deny these types of DSAs/DSCs. In other words, it should be an operator decision to enable DSAs and DSCs without a PacketCable authorization block -- not a vendor implementation decision. David Flanagan (David.Flanagan@motorola.com) Will Murwin (W.Murwin@motorola.com) _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 12 17:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16117 for ; Mon, 12 Apr 2004 17:31:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD91K-0005wn-Qh for ipcdn-archive@odin.ietf.org; Mon, 12 Apr 2004 17:31:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CLVAw6022861 for ipcdn-archive@odin.ietf.org; Mon, 12 Apr 2004 17:31:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD91C-0005vd-PB; Mon, 12 Apr 2004 17:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BD90u-0005tl-36 for ipcdn@optimus.ietf.org; Mon, 12 Apr 2004 17:30: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 RAA16042 for ; Mon, 12 Apr 2004 17:30:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BD90r-0004Lj-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 17:30:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BD8de-0002PR-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 17:06:46 -0400 Received: from mms2.broadcom.com ([63.70.210.59]) by ietf-mx with esmtp (Exim 4.12) id 1BD8Bn-0000eI-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 16:37:56 -0400 Received: from 63.70.210.1 by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Mon, 12 Apr 2004 13:37:22 -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 NAA18858; Mon, 12 Apr 2004 13:36:48 -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(5.0.2195.6713) ; Mon, 12 Apr 2004 13:37:20 -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(5.0.2195.6713) ; Mon, 12 Apr 2004 13:37:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects Date: Mon, 12 Apr 2004 13:37:19 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0BE2D184@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] RE: NCS Signaling MIB SC Objects Thread-Index: AcQYs+/sKkV252K3SOCIiuJqqyhPagDaOClwASsiBZA= From: "Eugene Nechamkin" To: "Jean-Francois Mule" , "Wim De Ketelaere" , "Beacham Gordon-CGB005" , "David De Reu" cc: ipcdn@ietf.org, "Richard Woundy @ Comcast" , "Kevin Johns" X-OriginalArrivalTime: 12 Apr 2004 20:37:19.0961 (UTC) FILETIME=[F38B8C90:01C420CD] X-WSS-ID: 6C6421881PO1965956-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Leaving the issue of the justification of the NCS SF feature itself = aside, and assuming that the idea of having the NCS flows with QoS can = look usefull to MSOs, Broadcom would second this view. There seems to be = no obvious restrictions in the DOCSIS and/or PacketCable specs which = would not allow the MSOs to Securely Create NCS SF either by completely = relying on the existing PacketCable security meachinsim (SCN is = delivered to the MTA over the SNMPv3 Secured channel), or by = implementing vendor specific mechanisms to augment or extend the = existing ones for better/wider access control on the CMTS side. This, obviously, does not mean that the NCS SF related objects in SIG = MIB do not need some additional work and clarification. For example, the = fact that different CMSs can be assigned to the different end-points of = the MTA, cannot be accomodated by the exitsing NCS SF related MIB = Objects. Another example - pktcSigServiceClassNameMask which does not = seem to be required as this value is supposed to be provided in the NCS = SF US/DS classifiers pre-provisioned on the CMTS and identified by the = SCN. Instead, there is a real need to have an object (currently lacking) = which would provide unambigous means for NCS SF creation/deletion (for = eachg direction - DS/US). Eugene. -----Original Message----- From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of Jean-Francois Mule Sent: Tuesday, April 06, 2004 3:12 PM To: Wim De Ketelaere; Beacham Gordon-CGB005; David De Reu Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Kevin Johns Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects Hi Wim, We had some additional discussions internal between the PacketCable & = DOCSIS guys, and we concur on our spec(s) interpretation (Greg on the = DOCSIS side, Kevin and I on the PacketCable side). More importantly, the = CMTS vendors seem to be in sync with our interpretation based on what we = have seen in our labs ([CMTS vendors, feel free to speak up here]). Here's what we can summarize: 1) The PacketCable specs do not intend to imply (nor require) that = DSx-REQs that lack a PacketCable Auth Block be authorized by the = "PacketCable Authorization Module". While we do define the behavior of = the "PacketCable Authorization Module", we do not preclude CMTS to = employ other modules to authorize DOCSIS-based DSx requests. Perhaps the = text could be clarified in DQOS sec. 3.2.5 to add some informative text = around that. However, our understanding is that vendors are clear on = this already. The PacketCable compliant CMTS will support at least two = independent authorization modules: one for DSx-REQs that contain a = PacketCable Auth Block as defined in DQOS I09, and one for those that do = not. Again, if there is no packetcable TLV in the DSx req, why shouldn't = this request be processed by a docsis authorization module?=20 2) The treatment of DSx-REQs that lack a PacketCable Auth Block is = currently in the realm of vendor differentiation. DOCSIS only requires = that the CMTS authorize the request in some manner. Whether that = authorization defaults to "allow" for all requests, "deny" for all = requests, or some rules in between is left to the CMTS vendor and its = QoS policy configurations. 3) This feature is defined so that the operator can configure = high-priority signaling flows for the MTAs on their system. In order to = use this feature, they will need to take a number of steps, including = configuration of the CMTS to allow (ie "pre-authorize") the creation of = service flows based on the SCN in the MTA config file. And Greg, Kevin = and I strongly agree that these mib objects are more suited in the MTA = config file than in the CM one. 4) Even if the operator misconfigures the CMTS (either by not defining = the SCN, or by not "pre-authorizing" it), or the CMTS doesn't support = this feature, the MTA will only attempt to create the signaling flow, = and then upon failure, default to sending all signaling traffic on the = primary US/DS service flows. Therefore, we maintain that these 3 mib objects are pertinent and should = stay in the MTA mib. Jean-Fran=E7ois=20 > -----Original Message----- > From: Wim De Ketelaere [mailto:deketelaere@tcomlabs.com] > Sent: Thursday, April 01, 2004 11:04 PM > To: Jean-Francois Mule; 'Beacham Gordon-CGB005'; 'David De Reu' > Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Kevin Johns > Subject: [ipcdn] RE: NCS Signaling MIB SC Objects >=20 >=20 > Hi all, >=20 >=20 > I do not discuss the usefullness of the objects, > I just believe they don't work due to the way the spec is > currently written for the CMTS. >=20 >=20 > section 3.2.5 of DQOS-IO8 clearly specifies: >=20 > If the PacketCable Authorization Module receives a bandwidth > reservation request (i.e. a DSA) without an authorization=20 > block, the CMTS must reject the request. Note the informative statement (lowercase) is on the PacketCable Auth = Module. Note that a PacketCable CMTS is a DOCSIS compliant CMTS as well = and when it sees a DSx request from the eCM embedded in the MTA that = does not contain any packetcable tlvs, the CMTS has no way of saying: = but hey, that's a PacketCable MTA request so one could argue that this = requirement is really for those DSA requests that do contain some = packetcable tlvs but the request is malformed or wrong. > Unless the dQoS specification is changed so that a clear > distinction is made between what is meant >=20 > for PacketCable authorization > and what is not,=20 >=20 > I still don't see how it can work. I hope my earlier email and the explanations above have helped clarified = this. > It is clearly not the intention of the PacketCable > specification that any DSA for a SCN will always succeed,=20 That is a question of MSO policy authorization and is left for vendor = differentiation. Some QoS policy configuration & information models are = available in IETF but this is out of the scope of our QoS specs.=20 > this would be=20 > a very easy theft-of-service scenario,..... An operator would have to allow this. > The DSA for the SCN will be a valid DSA on the DOCSIS level, > but if the CMTS has PacketCable enabled, it will not pass the=20 > authorization module and be rejected for that reason, this=20 ^ PacketCable authorization module and again, it does not even hit the PacketCable auth module but that = it gets handled by the plain docsis auth module. > is, unless we change something on the requirements for a CMTS.=20 >=20 > But I don't have an easy solution for that, just stating that > any SCN can be allowed without authorization opens up a=20 > security hole,... Operator decision. > Just stating that it is valid on the DOCSIS level and is > therefor okay is, I believe, a too easy answer, this would=20 > make any PacketCable compliant CMTS, non-DOCSIS compliant. A=20 > PacketCable CMTS MUST reject a DSA without the authorization=20 > block present ! We disagree. > If needed I can clarify my reasoning, in a conf call if this > helps to solve the problem, this problem is already=20 > on discussion for too long ! >=20 >=20 > Thanks, > Best regards, > Wim >=20 >=20 > Wim De Ketelaere > CTO > tComLabs >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: 02 April 2004 02:22 > To: Beacham Gordon-CGB005; David De Reu; Wim De Ketelaere > Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Kevin Johns > Subject: RE: NCS Signaling MIB SC Objects >=20 >=20 > Okay, now it is my turn to be reminded to close on some > issues, I see... > ;) thx for the reminder. >=20 > We did discuss this question internally with the packetcable > team. We believe that these 3 MIB objects still make sense=20 > and that they must be kept in the NCS signaling MIB. I will=20 > try to provide some justification below. I also cc: Kevin=20 > Johns who is our PacketCable QoS lead so he can chime in on=20 > the responses to this note, and may be Greg White can help too. >=20 > --- Context > These 3 objects are typically used in the MTA config file to > indicate specific service class name(s) corresponding to a=20 > pre-provisioned set of QoS paramaters on the CMTS. If SET in=20 > the MTA config file, the MTA can instruct the CM to generate=20 > a SF with the specific service class name > (SCN) so that the MTA NCS signaling packets can use the=20 > special service flow rather than best effort. Unlike=20 > PacketCable DQoS which defines AuthBlock and TLVs like gateid=20 > for the MTA to use in the DSx msging, the SCN use is not=20 > intended to use any of the packetcable gate related=20 > parameters =3D> no AuthBlock. DQoS DSx is used to create/modify=20 > SF dynamically for the media streams: NCS starts as soon as=20 > the MTA provisioning is complete, the MTA registers with the=20 > CMS (RSIP, etc.) and a call can be initiated (NCS CRCX with=20 > gate info in LCO,...) and QoS can be installed for that call.=20 > The pb is to guarantee some QoS for the NCS data and this is=20 > what those objects are for. So these objects are valid to use=20 > in a DOCSIS dialog initiated by the embedded CM of the MTA=20 > with the CMTS. A DSx message with a classifier and SCN for=20 > US|DS and no AuthBlock (hence no gateID) is a valid DOCSIS > qos message. Upon activation, the SCN-based flow, NCS runs > over qos SF.=20 >=20 > --- Response to questions from both Gordon (4/1) and David > (1/19) On Thrusday April 1st, Gordon wrote: > > >Remove the pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, > > >pktcSigServiceClassNameMask and pktcSigNcsServiceFlowState > > objects from > > >the current MIB definition until a workable form of its associated > > >mechanisms is defined. > I don't see what's wrong with the mechanism I described > above. It seems a workable form to me & Kevin. >=20 >=20 > Gordon wrote: > > The removal of these objects from the > > MIB does not mean that there is no more mechanism to > > establish a separate NCS Service Flow, because such a Service=20 > > Flow can still be defined in the Cable Modem config file=20 > > (with the use of a Service Class Name if desired).=20 > This breaks the whole concept of decoupling the data > provisioning from the voice provisioning. Why ask the data=20 > provider to put special CM config for some voice NCS=20 > signaling flows that the Telephony Service Provider might=20 > use? Why not keep the trigger of a special flow for NCS in=20 > the telephony prov, especially since this is an E-MTA with an=20 > embedded CM =3D> the MTA f() can very effectively pass the SCN=20 > params onto the CM? >=20 > > This > > works, because in this case the Service Flow is set up during > > the CM Registration process, without the need for DSA=20 > > messaging.=20 > An E-MTA has an embedded cable modem and it is valid for an > E-MTA to initiate plain docsis DSx messaging (in addition to=20 > the DQoS flavored ones). >=20 > > This is also probably the way it is currently > > done, > See above. >=20 > > since the use of the above MIB objects is not possible > > with an IPCablecom/PacketCable compliant CMTS.=20 > Disagree. See context above: a compliant > ipcablecom/packetcable CMTS is > also a compliant DOCSIS CMTS. >=20 > > Leaving the > > MIB objects in place, while awaiting the definition of a=20 > > workable mechanism is not an option either, because this new=20 > > definition would most likely have different MIB requirements. > This works today, and is used. >=20 >=20 > On January 19, 2004, David de Reu wrote: > > (1) pktcSigServiceClassName(US|DS|Mask) objects > >=20 > > There is still a problem with the > > pktcSigServiceClassName(US|DS|Mask) > > objects (and indirectly with the related=20 > pktcSigNcsServiceFlowState > > object). Although the MIBs currently reflect the PacketCable PROV > > spec text, the proposed system for setting up a signaling service > > flow will *NOT* work with a PacketCable/IPCablecom > compliant CMTS. > How so? This is incorrect. > Note that Service Class Names are also used in the so called=20 > "PacketCable Multimedia" QoS (a policy server using COPS can invoke a=20 > SCN which will trigger the CMTS to initiate DSx with a CM). >=20 > > This is because the CMTS must reject all DSx messaging > initiated by > > the CM if there is no valid authorization block. > This assumption is not valid. If no Authblock, treat the DSx like a=20 > plain docsis msg (and if there's a correct classifier and a valid=20 > pre-provisioned SCN that can be matched on the CMTS, proceed with SF). >=20 > > There is no such > > block in this case (there even is no gate on the CMTS). Note that > Yes no authblock but there's a SCN which matches some pre-provisioned=20 > QoS data on the CMTS. >=20 > > this does not mean that PacketCable takes a step backward > > compared to > > (Euro-)DOCSIS. In plain (Euro-)DOCSIS it is the case that=20 > > a CM is not > > allowed to initiate DSx messaging, since it is not allowed=20 > > to expose > > an interface to the outside world to do this.=20 > I'm not sure I follow this point. >=20 > > For an > > embedded MTA in > > PacketCable, this interface is present and the DSx=20 > > messaging *can* be > > initiated by the CM, but the CMTS will accept it only if the > > appropriate authorization can take place (using the authorization > > block). > Nope, that is true for an E-MTA initiated DSx message > compliant to DQoS > only. I'm told this assertion is not true for a CM initiated DSx msg. >=20 > > Operationally, the practical solution is quite simple. > You can add > > the necessary MIB objects in the CM config file (specifying the > If this is for the NCS flow, why not the MTA config file -- again keep = > the telephony related config param in the MTA portion of the prov. >=20 > > service flow parameters directly, or alternatively using > a Service > > Class Name (SCN)). > Well, this is exactly what we are doing here and it just happens to be = > in the SIG MIB so that the MTA which is the entity generating the NCS=20 > traffic knows what SCN <-> SF to use to pass on the data to the eCM. >=20 > > In that case, the CM will set up the > > service flow > > during its registration, without the need for DSx messaging. > >=20 > > Solution: It is of course not up to the SIG MIB to provide > > a solution > > to this problem.=20 > Why not if it is for the NCS signaling? >=20 > > However, if the > > pktcSigServiceClassName(US|DS|Mask) > > objects *are* included in the MIB, then you have a set of=20 > > objects of > > which you know on forehand that they are useless.=20 > We obviously do not agree and this has been in our specs for > many years > now. >=20 > > So the question > > seems to me: do we want to include these objects in the > > MIB? We could > > also leave them out now, and wait for a correctly functioning > > mechanism to be defined in the PacketCable/IPCablecom specs. > > Alternatively, if the objects remain in the MIB, then we=20 > > have to ask > > ourselves what will be required from an MTA: we will=20 > > require that the > > MTA does the DSA nevertheless, knowing that it will not succeed > > anyway? >=20 >=20 > I hope I've helped clarified this. > Jean-Fran=E7ois >=20 >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 12 19:37:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25198 for ; Mon, 12 Apr 2004 19:37:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDAz9-0006vR-9i for ipcdn-archive@odin.ietf.org; Mon, 12 Apr 2004 19:37:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3CNb3F0026613 for ipcdn-archive@odin.ietf.org; Mon, 12 Apr 2004 19:37:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDAz8-0006uP-96; Mon, 12 Apr 2004 19:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDAyh-0006nM-VV for ipcdn@optimus.ietf.org; Mon, 12 Apr 2004 19:36: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 TAA25139 for ; Mon, 12 Apr 2004 19:36:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDAyd-0004uk-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 19:36:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDAaj-0003GV-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 19:11:49 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BDAI8-0001Qz-00 for ipcdn@ietf.org; Mon, 12 Apr 2004 18:52:36 -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 i3CMpw9T027652; Mon, 12 Apr 2004 16:51:58 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C420E0.C28F3FAC" Date: Mon, 12 Apr 2004 16:51:58 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Changes for next RFI v2 MIB (draft 10) Thread-Index: AcPql1cYYxHVIUk1R02CjMUjuIRwHgyVT10AAPscgxAAAYHmoA== From: "Eduardo Cardona" To: "Donati Andrew-MGIA0477" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C420E0.C28F3FAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew, all,=20 Please review the attached with the proposed changes for the StorageType issues to see of they cover all concerns. In summary, there are eight proposed changes Changes 1,2,3,4 are related to the issue brough by Andrew Donati by adding StorageType object to the Modulation profile table Changes 5,6,7,8 are clarifications to accommodate the OPS MIB revision guidelines sections 4.6.2 and 4.6.4, quite related to the problem raised for the storageType case. During the WG Last call for technical issues, there were no other items pointing our attention. Let the WG know any question or comments by COB Wednesday before submiting the draft to IETF. Eduardo ------_=_NextPart_001_01C420E0.C28F3FAC Content-Type: application/octet-stream; name="Considerations for adding StorageType objects RFIMibv2.pdf" Content-Description: Considerations for adding StorageType objects RFIMibv2.pdf Content-Disposition: attachment; filename="Considerations for adding StorageType objects RFIMibv2.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjI3IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAyOSANL0ggWyA5 NjIgMTk5IF0gDS9MIDIyNDY5IA0vRSA1OTI2IA0vTiA5IA0vVCAyMTgxMSANPj4gDWVuZG9iag0g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTI3IDI4IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA5MDcgMDAwMDAgbg0KMDAw MDAwMTE2MSAwMDAwMCBuDQowMDAwMDAxMzY4IDAwMDAwIG4NCjAwMDAwMDE1MzUgMDAwMDAgbg0K MDAwMDAwMTY0MiAwMDAwMCBuDQowMDAwMDAxODIyIDAwMDAwIG4NCjAwMDAwMDE5MjQgMDAwMDAg bg0KMDAwMDAwMTk0NSAwMDAwMCBuDQowMDAwMDAyNTM4IDAwMDAwIG4NCjAwMDAwMDI1NTkgMDAw MDAgbg0KMDAwMDAwMjkxNiAwMDAwMCBuDQowMDAwMDAyOTM3IDAwMDAwIG4NCjAwMDAwMDMzMTkg MDAwMDAgbg0KMDAwMDAwMzM0MCAwMDAwMCBuDQowMDAwMDAzNzIyIDAwMDAwIG4NCjAwMDAwMDM3 NDMgMDAwMDAgbg0KMDAwMDAwNDI2NSAwMDAwMCBuDQowMDAwMDA0MzcwIDAwMDAwIG4NCjAwMDAw MDQ0NzYgMDAwMDAgbg0KMDAwMDAwNDQ5NyAwMDAwMCBuDQowMDAwMDA0ODgwIDAwMDAwIG4NCjAw MDAwMDQ5MDEgMDAwMDAgbg0KMDAwMDAwNTI4OCAwMDAwMCBuDQowMDAwMDA1MzA5IDAwMDAwIG4N CjAwMDAwMDU2OTcgMDAwMDAgbg0KMDAwMDAwMDk2MiAwMDAwMCBuDQowMDAwMDAxMTQxIDAwMDAw IG4NCnRyYWlsZXINPDwNL1NpemUgNTUNL0luZm8gMjYgMCBSIA0vUm9vdCAyOCAwIFIgDS9QcmV2 IDIxODAxIA0vSURbPDE2NTdhZjk0ZjgzYmJlOTllMGNhYjhiMzFjOTM2YmI5PjwxNjU3YWY5NGY4 M2JiZTk5ZTBjYWI4YjMxYzkzNmJiOT5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTI4IDAg b2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDI1IDAgUiANPj4gDWVuZG9iag01MyAwIG9i ag08PCAvUyA3MCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDU0IDAgUiA+PiANc3RyZWFt DQpIiWJgYGAGokMMrAwMLFkMPAwIAGIDRRk4VoC5N49s0HiU6uDS4rz5EToPCgSAWAKKGRhEGbj0 OhUj5os4cHxgCGFgXcIQ5cB+JUTUgXUFQ3QD6x5LoBqAAAMATPIYWA1lbmRzdHJlYW0NZW5kb2Jq DTU0IDAgb2JqDTk1IA1lbmRvYmoNMjkgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50IDI1 IDAgUiANL1Jlc291cmNlcyAzMCAwIFIgDS9Db250ZW50cyBbIDM1IDAgUiAzNyAwIFIgMzkgMCBS IDQxIDAgUiA0MyAwIFIgNDcgMCBSIDQ5IDAgUiA1MSAwIFIgXSANL01lZGlhQm94IFsgMCAwIDYx MiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoN MzAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzMgMCBS IC9GMyAzMSAwIFIgL0Y0IDQ0IDAgUiAvRjYgNDUgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEg NTIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMyIDAgUiA+PiANPj4gDWVuZG9iag0zMSAw IG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIC9XaW5BbnNp RW5jb2RpbmcgDS9CYXNlRm9udCAvQ291cmllci1Cb2xkIA0+PiANZW5kb2JqDTMyIDAgb2JqDVsg DS9DYWxSR0IgPDwgL1doaXRlUG9pbnQgWyAwLjk1MDUgMSAxLjA4OSBdIC9HYW1tYSBbIDIuMjIy MjEgMi4yMjIyMSAyLjIyMjIxIF0gDS9NYXRyaXggWyAwLjQxMjQgMC4yMTI2IDAuMDE5MyAwLjM1 NzYgMC43MTUxOSAwLjExOTIgMC4xODA1IDAuMDcyMiAwLjk1MDUgXSA+PiANDV0NZW5kb2JqDTMz IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dpbkFu c2lFbmNvZGluZyANL0Jhc2VGb250IC9Db3VyaWVyIA0+PiANZW5kb2JqDTM0IDAgb2JqDTUxNSAN ZW5kb2JqDTM1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMzQgMCBSID4+ IA1zdHJlYW0NCkiJjJPNctsgEMfvPMVOTmqnYEDo69g4dSaHtDO1XkCWkEPGER7Acdun7wo5rms3 SYcZQCy7+9s/q9ncZ9B6EHH4lsxulwLWnggwQPKCZVkFheSMl6DyEqhIGS5Ok55c12S2SNGt7omQ wHHgMvkIKAQ6cZ5C/UR4NGJ0DnWc9iSZ28GbTrsmGNxBbx00XWeGNSyDdc1a1z+3GuzqUbfBQ7Bw f3cN97bbbTTcfJsv6Yf6kXypyZH8BZbnLJOQFoqpc9xLyrzKmVJnlMndgo7ZzACda/owzdTo0FOz bbuBdrb11PVPZvUsKRYafgQYeWYLMelRsSqP4eLmmK1UTB40SaIDR0QmUplBfUNGwaQaJUqwUNOb 9iDOqvG6AzvA1e0ONduYQU+KjZSfd+HBOg/N0MF3/Wz0Xjt/dco8Jqo/ksRuPUVk6uItuj7GolyO JXwCj2LHjIrlTMaQ407BVrvQoB5/mJXKR+bEDCaYZmN+Rdbogpe98UEPrYbWDp2ZYu62aHd6ZW2I 8E43Hd07E3T0ip8XmiQtnuONsdJDMzC4xIiN9Q9JpyMs/kTb9qEZ1gcB//tl385W8uLvB1Ss4mk+ NXpMB18tVnHo2VywSlSQVZyVCjhT+GPFOTbqO1bJ0uporc7NIpOsLF71FlnK0uxollgh9ufJhTRX LH0l+28BBgBfpBdsDWVuZHN0cmVhbQ1lbmRvYmoNMzYgMCBvYmoNMjc5IA1lbmRvYmoNMzcgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAzNiAwIFIgPj4gDXN0cmVhbQ0KSImc kj1rwzAQhnf9ioMuyZBDXydLa0MplNJJ0KF08KC0hSTQNCV/v4qcysacMgSDP/To3tM9WGyEcRaN CkBBorcg0XpYlfshiY1wCsOFGnehSqEdqCKNvmviaTaD76MIGPJ6vsqL65AoKCB3/pQG4k5IiCfx tlh/9vuPBHcKlisjg0O7eEmnnPP9+3VIu7Q/wusjPPc/R1j32y0s3+OTeIj1/J0vnebTaTSh0jDH dTy+WpFBQxVrJc+PyYY6f6P7eLa8VO1opjvHp+kcb+slj1oOekez+kazOVU3xRbY9srWVq2FXrHK d/4/lsNOt39YHo/RLG4btQ6Nnhs1NxolymFNpQNtO+Wrq9QBX7HK1P8JMAB5r+S2DWVuZHN0cmVh bQ1lbmRvYmoNMzggMCBvYmoNMzA0IA1lbmRvYmoNMzkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgL0xlbmd0aCAzOCAwIFIgPj4gDXN0cmVhbQ0KSImkk01Lw0AURffzKx64aRd9zHdntg0i il9gwEVxEXRSB9KIaYp/35jKJKYz2UggBM68d+8cCCmJZmiZBaUkGgkUpYEVY8gNNI6UhCmOZp3m QksUM/ObnFi0Gmj39B96jUpZBkpIVJoKyPdku8jei3rn4ELCciWo1SgX9+6rW/F59I3bu7qF5yu4 LQ4tZEVVwfIlvyGXeWgvRbfsN71/9+Gao7CB2ikOd4tPMyVQqIA5oz/9RwfC3RPpQzdqBjPyPDyC x7sjOK2Vc9SGyr9a1aA1q4rGl/61aP1HDQ+PT3B3vYHd0b+5ytfucKZWsG5hUu2JptXGp4PaE55R m0gfuvG02Sgdbz6naa9dRUOnXvU/vDKLaa09TFuNzgapPZ1xGk8eagk++Y+/BRgA5a/llQ1lbmRz dHJlYW0NZW5kb2JqDTQwIDAgb2JqDTMwNCANZW5kb2JqDTQxIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggNDAgMCBSID4+IA1zdHJlYW0NCkiJnJI/T8MwEMV3f4qTWJIhJ5// xV5bGEBCIOENMUQlKanaIBX4/qQhcSHYGapIkeVf7t29l2MNIy3Qlg40OZQCOCoLBREKC8eaNUwa hZLSfOWZQ2eA989wMCVq7QiUc8gVl+AP7Dlbv1XdtoarEvJCcmdQZet9dWybdlN9tu8dPDw+wf3t CrZf7Wu9b7v6A/IXf8duPDOE7jQBt73gOMHwHgYwAqUL1M1x8BevJi1R6oAF8ZOHXx8E/4nu02y9 a3NOR82bR/FZO4rT0doSycyjtZdHq/oqMqloR5qMNlE9RTvidLSp7tNsGo39v3gTtgqTvyUBR1sD XHAV7xt4VDuYHuiS57h64FH1ZZrel1Kj4j/7wsFvWAa53/XHgpCUMuCv/1xJocPVtwADAFGC31MN ZW5kc3RyZWFtDWVuZG9iag00MiAwIG9iag00NDQgDWVuZG9iag00MyAwIG9iag08PCAvRmlsdGVy IC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQyIDAgUiA+PiANc3RyZWFtDQpIiZSTUW+bMBDH3/0pTtoL TItnG+OYSH3oKJsyqZWWuk/THhh20k4JloCum/ble5g2ixKoWizZh+58/vn/B1IYwqEfbUXUnKZp BjJlNBHApaZMw4xLyhU0jqzJJ0M+fpZYbNaEC2A4cBm2cZCJppqxBMyOsJDEnowyJgSYinyPrK9i RUXULtd5LDHYxTzFpYv7uY05zpehwscCZ3u/LYfcna9N+XPrQhLiH+YrgvABJKOZCqeFYA8jMBBP MD2D7BmilSvtrGpc2TmIzS9i3iNqn9i//a89t9bZBYTMC9dOMk6ZfL72vteIsInWdK4glTRRx7qO 9J3PqZAjcrIg5+w5fCBRflvWGwfv+BOrGlgZHkI5NrgYwFgoPqUTNMuQLg0C4pG4jdH00PNxqcM+ BE0F3mTM90HHC1/1ju+69tIHS9HNou6av7BYnMF18e2muMoL+DcJhh+i0pCoE7AJHsmo1kc8ERw8 9pBoWVv3B0aeZd25jWsS8WGSLEGLdA/4SjKRUfkWss41v8vtTVtuXO6t25NdmeJLsZrmEuoNcnFN xfFvOw2Ve7TOb0/lWvmH667s7tuA9SjAAPAs9ukNZW5kc3RyZWFtDWVuZG9iag00NCAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2Rp bmcgDS9CYXNlRm9udCAvVGltZXMtQm9sZCANPj4gDWVuZG9iag00NSAwIG9iag08PCANL1R5cGUg L0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNl Rm9udCAvVGltZXMtUm9tYW4gDT4+IA1lbmRvYmoNNDYgMCBvYmoNMzA1IA1lbmRvYmoNNDcgMCBv YmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA0NiAwIFIgPj4gDXN0cmVhbQ0KSImU 019PwyAQAPB3PgWPmuiFAmXwulrNEmeMI77XlnY1WzHXLv759GJ9cWZLgHsh4SC/3B2ktCSjPzHW RHEwxlCRSVhwKqSm1xmDXFF0pCVLSwwYRVmIefObnlHBFBjOBLV7wubj8NYF/bMaX4+rtthP49o3 9vPN0VNr9WDLu/Lpil7aV3LKxQSI4FIszsVNDnm86xFdtX/ZuXs3/HMNk+scCn5Wxg0HJoNMRcq0 BC7DjTjZTd+2Dt0w9dWuHGrf9EM3Z1k8TNvnandw52magZIJRVtw0PG027IoET0WHtHVU++H+KIp A0IlyFQWklJkhW/cu8cmdLSbtgntzDUwnSDLGYQ6xw7apsZ50HDjXJM4aFKBSpEJDVpH12xdfSwP OE6b/uv4ix7LvgUYAOfF98MNZW5kc3RyZWFtDWVuZG9iag00OCAwIG9iag0zMDkgDWVuZG9iag00 OSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ4IDAgUiA+PiANc3RyZWFt DQpIiZzTS0/DMAwA4Ht+RY4ggZVHly7XjWqaxEsscC+txwptM7kZaPx6unIBtEkp8SVRrOiT7bDM MckP0RXMKLDWcqUnkHBtDL+UAiaGE7I1mzlmwRou+hg239mSK5WCESLhrmFiuO6fOuM/VumLbrme N6G78eVil1PpqgZX1Sf+zHpsu+qlxVKrC37uXtkxmRrjkgaUEDrSdZ13Ye5L/PBUrjaeAvaWQ5aj Xdg85fUOT7ukglSNoIkErIqmrQrKm+caif9ZMTQhIRlRNWk1mCS6m7N9wGUbkGrM35GucBs2sd2U VoAYQ5sqUP+mzWpfvA0zF0NLp5AarpNpJC0V/TGadk84NNTtt7++AF/eumyRPZx2mRS0GVGyie2T ogfNFU1G5GnuibAIlW/v2mOD9iXAANqjAZQNZW5kc3RyZWFtDWVuZG9iag01MCAwIG9iag0zMTAg DWVuZG9iag01MSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDUwIDAgUiA+ PiANc3RyZWFtDQpIiZSTy07DMBBF9/4KL0GCwa848ZZSpC5YxWXvNpO2KC/ZKRJI/DtuWqQiWpHM bCzNvZ6ja5nMLeH00GFNtABjDOWJBpZRqTW95wwSTT2SkjxaYsBoymIPh6M8elUGImOS2pqwYRzv uqFnVbTrsChndR9e2iJfF7VbND36Ct07+rzHLt99Il02YbdpsJDijt7aN3IJTSmYQiZTYGwaWd55 dAX6eeNWFR5V1u/77aur9nidTEpQE8hEAnoq2X5VelfjrC0wnFRjMhMCuKCKq5FoXIEUo9FmW9c0 WNmPDumveoqqXVh2oY+B1of5dcTIlYoJ6bF4OEPk/6TXt95t8C/i+eAKmjGgFE1GZmc4aMXU5ei+ hh0PzzousCWJbzKwC6pTSJLoTrP4737c9uA8QX0LMAC/49ocDWVuZHN0cmVhbQ1lbmRvYmoNNTIg MCBvYmoNPDwgDS9UeXBlIC9FeHRHU3RhdGUgDS9TQSBmYWxzZSANL1NNIDAuMDIgDS9UUiAvSWRl bnRpdHkgDT4+IA1lbmRvYmoNMSAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjUgMCBS IA0vUmVzb3VyY2VzIDIgMCBSIA0vQ29udGVudHMgMyAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIg NzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTIg MCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzMgMCBSIC9G NCA0NCAwIFIgL0Y2IDQ1IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANL0Nv bG9yU3BhY2UgPDwgL0NzNSAzMiAwIFIgPj4gDT4+IA1lbmRvYmoNMyAwIG9iag08PCAvTGVuZ3Ro IDE5NTAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV11v2kgUfedXjLoPgVVx PePxV6V9oA5dUTUQFadKtd0Hxx4Sr8BGtmnKrva/75mxIYF4wJHWPHiMP+6Z+3Huue+C0iZxSaj6 lXHv3e9zSu7LHiUp6TmuYds+cZlpcE6YaxoOGVJuUIcUorfofQh77z46eDFc9CgjJn441W9R4po+ njQtEq56prqJ7w9NwzRNvBH3dqvH3h/9aV4JMlqWOYmSRCRkXuVFNBg6Bu3fD/AO7Yv6KhwM8dX+ dkB9w++vm3tkMKRmPwxIldfLyYAx3L/CBe5fz76Ec1KKuErzzCCDP8NPAM5r4CaRz7gkvMRSwpKI +mQQ/tUbh729YxpfOD4zPE5sblgvfPHSBY5HDYsduUDtm0lTw90SBoOHKLsX5BemLO/dWqOzzqLD bn2gc7hhIlKM4TXTsJ/HidYfhNschUQt6vcA1HYMxvHqMVDGpdV+ksflZBGsqvIqTzbLSDpynFXF lsw+fBoH4TD8dj3WorKZ4Toyf45RacBwjssjr/VJc8y/TcPRbb2+1MLSQeFUBo5hp92gWBYe0kG5 Gt0OR0Ewns8JyfJqGMWxKMv0bim09i041SPUeREgjX2kMfO0rghH4c28XsebohBZpTVMPcOBYdp1 43jI0xq+HM+DL5PrcDKbag2arsEJZx1jbvu+4Zg6e/J4cynKuEjvREkistqHm6yLfJHC44u8IFFG Jlklih/RktyUEeopyBNtMGwfjMII8zoGw/a8l9V8gFGByDNBcFrlhSCbdVkVIlqRGOWdiWVpaMF4 3HAZsVyvIxjXMfzTYGQlpHBXmpHqIS1JFcnMjAArBqYKNHu3xR2gXYsiAuPW4BrKYfaedLR8Y+OM UrIcpyNo8OYpmjmAP8nSKkUgE7GINsuKiGY7q2hL7p72EFWk3JaVWBEtStuU/GN5HXPf5uwE/6gj rbGlf9c5WKUr8ZY8PqTxQ+1BswbALIP7HFfwZJ/E+WaZwPY6L6o6XQkSdSP0wC3f4B7hZtecsCiK /Mm99CXwC4R6FWXw5YVM0gs4MZlly+2FAnRA86oH34twuxbGblfKFdyEUcuvt3UmQZgn+Y53pR0b UuM539FTCTIiwRX6uswHsC+Jlsv8UeWzSg0Zl3wh9UQq10ikPTXowFLH8Ijld01m6BvTPMJ6iPCJ g8om4C3EdSfS7F5meZrV6azFZ9qgVOp3zAbuuweU2oJv8jKND0MNleW5vv0i1MPdjWdUoU0C7inN 1Ln+uGuDVVpUU1sSTHMUY5L+SJMNIpvf/QWVV5KH6IeQYhA8Ua5FnC5SuBY8mBeJKLQ4XVrr3I4J wB3LcI5xHqIDhJqnZGsSSpkcsLG2HXDHlNKyczvg0FjWac5SGrt6kHyZr8TeVUmuqkd5bEe1NS29 1WYi555k1M7dnSvKOInublNJKApGHC1jWSWIWYMIPT9LSCbwjwR7EFYdRsuV5Nm9XJgvyfMUxmRT yFItQDM7itEHkEFRv8JD0Gf8pP4h4YNA60bmZDk+Bl2RxjXJZTXpyQFCwgPpqfg9NX4dRIwvr+A7 DkVnnoZYKwz0waXMNJGC8coyj1MVSritVOojAm5E+TGtHhRyLT4T4psRancEaPk2JNRJgOJnLNZN a3j/TO1w7pxvZpZnvorHLNfqzmPUIJNFe4NIVSQ3pZB67bm61AJ1fImOWx2FreVQlPNJx+F4oWXf qujVXIGkOxAPQf2MFA9alLYnKY7RruGFjDtDcTiubuYhmc5CJRFlSYhEW6MWR8P3XhFQ6DHzNEWw /zOMlv0q+Wcx9xyDvTqMOXpWvtRDZBD03SnEgsI6w3JHISxFJZtoIvku337vO98H0m9oApNsDjWX xuJ7n30fGG+0ECnOYGKzazFAZVEti0yml+Nb8s+hlyZZIn6+Pf6vFptKAkoF+K8WoEklzTG7Y5iZ b52guffvfzuG1yRiqMiZkn9PTnnvPkJiknDRo0x9GyfHNWxbGnY8AK3HixaSVE/hIfQ9jhkKtQoT XJb4bj8tn7Tl1NsyECJagDTcLR97/UAVM/nFamDSGqbGRxyT137QxJdM9Q31avjrCfSYVxyvAyft 8GNe8Y4nrmcUrxuoyOzDp3EQDsNv12MtFupiFiLUOZcXOyymnBbb9P782zQc3TYJ8hyFzrLpdDcL gWWw1jHjanQ7HAXBeD7HhRw0h40W1pilPjdgmJ9j451hD+xttk2783AU3syb/cabooDy1hr1LAN9 0j+n03ZGMZvYrM3o5XgefJlch5PZtIUuG2MugyJAxXe15oBeeZs1ebyBIiRlHU5SyXjKGVMpvjjP pNCRIxFkV0sDbPBgynCAxz3HjTs8tpzktCNlcGBVTWFSkD61l4u1KFZRhnBcPIl5HTbuSwo535x3 2Dho1NFii5ZLyPbHIq3EMIpjUZayr0TZFr5ablZZVOwnorQW1NJxLV2lQYfpAsaRgx3RWXKea0N3 Of74dfS5BvkPHJJ9zSVfg6pbOkZjHLOFZCneNY0wXHitzKDvFmM1rDLWoABpPmsSB6JZq5d9Bm4H yo7iwOPo03q1XIP8EJVpHOSr9TKNkGxfGbmaXd58Hg+D2dX158loGuz59L8BABqcR6UKZW5kc3Ry ZWFtDWVuZG9iag00IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyNSAwIFIgDS9SZXNv dXJjZXMgNSAwIFIgDS9Db250ZW50cyA2IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNNSAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzMyAwIFIgL0Y0IDQ0IDAg UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAz MiAwIFIgPj4gDT4+IA1lbmRvYmoNNiAwIG9iag08PCAvTGVuZ3RoIDE0MTUgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImsV01v20YQvfNXLNKLUsTr/SSXAXqwZTtQUVuBSQcN4AtN rWwWEqmIlFMjyH/vLKlvaclVUOpg2qY4b2fem3lz3i8lSktE60+ZeuefIoqeS4+iDHk+w2EYooCG mAlEfYbOKMHSR3Ptjb3L2Du/MV+Lx16IQx8R+NQ3zfcofJFiIQhH8dQj9b8hAsGEwNtiuEPxd6+H llcUX8QPUXOfLuZznVfoffyPdx17a3QrQCQwYSgV+4AsOAjB1N/DsQ58dR317wef48HwzhbQD30T hSvHgL5SOLAGNNe7+EWjtJjOJlmSpxqVVVLpqTnzuJijkX7NUl2i6iWpUAYPNf+yoVMSM4V4oBzR BQEWqg0duu3fRedXw340iNYoK3SfjLIC3cz1t4XO0zc0yCs9HyeAFL+rwREAgKkQPoqvTHnNa22g 4SeUkBFHzFJgRaxU6t0Orx7+ukbo7AyNirQcjG+zpy1InEkHSBxCMsSoKybOMBxA2DABlkWeFvko q7IiTyaTNzRN8lFSFfM39DwvFrPSCoUp7IPkiGtJGcFqX2m924u7q4t4eP/17NP98OFzhH5Y49Gg ljgEcotHwkNlrynUVOAyKbP0kznmF2aNS6R5rXTUlQxVi5B/1lHi3zvKLBU3cqHhQTuzBA3koVx2 y9xaZCuOgAH/HRMufYHZPv97dVmX6e5PO3ItfYJPaJpSskPFndI0pQgxZ0gQ1zwLiiXraJpZuUwq 3Kwbox6hIofEZznqJ08TjW6LkZ6WH1BeVOaPNoBcYVAvC1xrwAmIZE/vu31zKzyK9Xya5YmhBYre Smjvv9AmJZWY+yeQFUaj3FfI/0FWwuuRyx0bkoCJeajUXb5WZQdjRQgzQrlTVigYEtbB5kBZocCw IOE6lETAsW+VyOmM3aGMDWJAEJOuVYCbw66xw9glM9da2RbQDl2dRqgQgdG889wSMHIPNL9L1+Gs 4er2xOzs8YIJMGCIKkdpC+rDr3Yc+8RdgeoiMOW1ep0JDOPwQL0nEZgwDLkX3LFd8BDGSqsV3GNw saqGsakd3e6DDSUPidE1J44644q16Lq+oIvVDE5m4FXTGtcewhWbO7nDfTAZYAO5Y9E4zFW+5DA9 wh2EMUaPveliUmUgfzS8/PO6H2+Z/xI9vq8fasS2eoP7kOACHIpwHxKcB+AuN/mke4iXCLf4DhmM YEgkzzp+m2krDi6agepaV+abgbqLY7MQfr2LL/5G23F/QI3zL8UEaDbRjz0OeftpBcNY3QJctcep 2GkB9FTtcbPtAqtDx57DYaT6yhaw1t6gMprbLGBV0YyNcjGbFfPKZON1mQ3YIOs8rXv2kkaddGew qyrEmCN3GIxIQuxLzwr7x49/QLmWDNpQHXolPWrUz2+AwCgeeyC9OhsM9lQspQkppXGidcgjx6if goc4TBIwkabhnkEt6eYkR14p2PFTgFkFSGer2+9er/+S5M8a/SaWMGkD05IdsIjBeiWMjYrNO6y5 Z83apRwFw2i9dlmTf+isGik3+58VBXhMZZZNVwoQ45ttPriJ2LJrQnpMDEYdD03BSgbWoWiuzbH7 ySx5yiZgb7V9/NCQG3a4A1DGg7f5/g2A6C1PB+Dv5q/JxA4ANKSUSYQjgAD6qnID8JCOuuMHZhNk 1LFRUZ+t9dcV/jb5N4LgWaoHo5YKyBAz9zlBJXTWVhu7ATDIXzOw1/cg2ix/vqjAiMyqFiRgWGFs Orc/KgiYA1copZ5X3dXgvulc7tlgyvQYJwhRlVQLk5NkktU50ff6W0s2mDT9iPmuxKSB6UcnQFnV 5QnGl25jCK33TedNh5Jj+6ZLUvRze0rAUZtuJR0JEgrnZtXguElgenfCCCn4dPfCKA5W5BeycZVU yQ6O/wYA5LmCOwplbmRzdHJlYW0NZW5kb2JqDTcgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFy ZW50IDI1IDAgUiANL1Jlc291cmNlcyA4IDAgUiANL0NvbnRlbnRzIDkgMCBSIA0vTWVkaWFCb3gg WyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4g DWVuZG9iag04IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0Yx IDMzIDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg L0NzNSAzMiAwIFIgPj4gDT4+IA1lbmRvYmoNOSAwIG9iag08PCAvTGVuZ3RoIDEzODUgL0ZpbHRl ciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUl01z2zYQhu/6FTy2My2Mb5LHmFJSzcSxasm9 0yIksaFIFYQsx7++C1ppVDugF9bBtD00nlnsPnhxVfQqWfcJGz79enL1acmSbT9hSZ1MNCd5nicp ywmXCRcy+Z1RonRizWQzuV5Nrj7611abSU5ynVD4DA8v7zF4kREpqUhW+wkd/gwrUEIp/LcVPCWr 0+SX5OKr6tb9fFPsXb90pTv2K7Wq96Y7uv635NfV35PZavIf6Xc4mvoludSv4QJMlBKmXzEFIIr9 C8ZNuf5QVdb0YQyda782z9/U6OcYOstIGokx7U5tsSvb1jTzzbytzFMYJ1OEZwnPOBInTYnM4nDu D1iYVJAMYAAIB6M1oZEwd0+L7mRsmAG+w/YoLIKSJKNxCNCqdbu93Wx648IcihHBIzZGCqJ4HMjs n2PZ1M+lq7t2WroyDCNgLYBhyNnRghPGqYyB+atsjiZMwDOiJX56Nacke22U9/q0NdZ21lQj08vS wXBoDJq/Fds7GEVnrVm7UQyqBpelFIeh8izaZfft+gWkfGhMGEXlkmiYWYXsU5VpmPE4lGW9bcvm S1f34QZRmYgSmUpVtMhu6rXvj00DVYGRGSlKCsOikYZXWhIeqZDZk0N0q9LUuwwNoni0ywAE0a9K 5i8yQ1pVSRYvM18SXMuKjICb8HURFIY+zmZT+E3d35ntTVeNNC3Xg9XQc8yyaKsBwLEZFL/6dhhB YYoIrxSk2RTEKRWplHlr3DkfjbNQMegN6xQJmSpWbxcsQQ6Z88Ft2JrITEa7bTj2Ppe9uz9UpQvX RGYQkRMhsSWBKKUjZ/mPeru7M33XHIduwaQUCZ2LPgwlPGBFtzT2sV6bDxVAvNCFGRQkZJCLRA6R VBTCTBTGn12/sN2mbkb2R6aD4tAUEKmwijtTFNZAh/iLTphC6EFt2AQtIVZxpFDOFPP2FmQ/ctGS XMKN5We3wAAD0/BjJMOiXH8dhWAiSmcSEhVWZ2eIL+b0QyZj1xpJOVxTEpYhW0NApOJIjYDdR1Uq cuoVxnJkQ4iMoxUGaxdd62zXhJdPIf9COyKtJVKGthasvoCB2MNR/9m0YQIN0ZfjG0FAZhLIuQSE ab3ZGGtaV5fNDOJHBc4MsyhNYpKhkBnaVMDycVbMfCQ8BzJweJhEQvqV+GuuECkElRiSAnLPqbMV 7M3W7cIgQg7CwspCQGLCCgtAlms7dIhdGlOFITgfjIW1pmASbSyAuCmfro+2d8v6eWRQGZzvWUQh ICNp/KB+Opa28kfHOASl3lToSxSHgBRhKh9zvvfFctdZZ9qRXYHbAgEWhrQmh4BEKS6lX3ZGeP00 9e7CioPrPMZd198cHGPO2MaUj8ZOzWFkSrjWXmKwPUgWiEQgMWwtXrFcN93662ifcAVBNyJmcAhH FHmDuvD66MnGpRgUht4fobzCsAyr9f6VTG/DOuWCwwUkYn8gIsFBg+/Val9ebNDSmcP4/nA6CA17 r+SMe6FF8SwPsEuVsbO2fBjJxZzmg9ewZx6nzHstDuX4sIFpNt4t4UgIGYhwfBZhkJwkfp6LXdm2 phltWZZpbzQ0AYSnS6Oxd0rhOltux4eGpRBzIxII0ykkFtxu/LgkLYzd130PMzOyG1p6pTGNVAiD 7ITNZcV+4cJeZ4oP8sqxNYCsRJGR49wF965u6ufSW2MY28cyHJGZZJ4BHcWYEDDbkTgXQGEQQb3E OEMKlUFqwkps2p3aYtc2hbPz8InPGJz4Ea5gkJko0hUXBKvOlY0/80a6k6aDtbCbkudoaV2A3Pem GufItVcWNo5BYJLIBHRBMXtyiIpkEHkjrlGQnRjSG/9HeVuTfwcAGBgtIAplbmRzdHJlYW0NZW5k b2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyNSAwIFIgDS9SZXNvdXJjZXMg MTEgMCBSIA0vQ29udGVudHMgMTIgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3Jv cEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0xMSAwIG9iag08PCAN L1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzMyAwIFIgL0Y0IDQ0IDAgUiA+ PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzMiAw IFIgPj4gDT4+IA1lbmRvYmoNMTIgMCBvYmoNPDwgL0xlbmd0aCAxNzg0IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJrFddb9s2FH33r7joXuyhYUWKoqQCe3DdrPOAtEOs7APLHlSJ jtXJkiHSTYNh/32XlL+SlDa9TQFsRTJ1j+4999zDVxMVQaGA2j9VDF69m1G4UwMKFQwEI2maQkxT wjiwgMMFDUgkoJOD+eBNNnj1vVmWzQcpSQUE+GdP+nUUF1LCeRBCthwE9jZGCEgQ4NMyPIPsfjCE g6NsCzWdT5Za3awmi6ae6G5avoRR9mlwmQ12ILe4gthEY1HyFJcDThAQKp7AORU/a3VeX6m61coJ RKTCRA+DwA+ISBISnwvkpsiVftfljZblKTxJRFgCLGGeeOKY8OTfJGbS6OYUmDgkCYKJhScYIUhw LpgbJUsfLPgtzoAScZIEZ0K5/KK9OBNREjIIqSd5BQ9JxM7Hcg5tQozIzqBxyAg1qvBv0uNTLZYQ gbqT+KaIBSR5Kjc+KXpEHicaGhsVjJ6JoANMkD7Xvh2Yv51Rgsg8hQrP1o3S5IimzbJxdjPrz4t1 18lGuwJHKSciAUo93y9KBLa1K/Dby9nkevpTNv3w3hkwCY1I8cCzulEcnRCpF++6dr2Cdg7tx0+y wFJWy1Utl9JwH6oGJvnHWsJVW8olZLJbVk2uq7ZxIowZ0NC3EIITdlQrYPagtFwq8sIZUAQoTzT1 DRmxI/L0+vV38NeG8TYx6mfs7Q3zTIcTfLcIsrdmDpt1LlBhQrDHGfcUzSgMsE+eqMJ+6A+vZZ2b ehSLvLmTCuZtB2/bYm3KBEXbqAqz1BQP5AAox+CPgT56ga9gj0kUIXbsJooZNTqOC7j5Z+9deO9d KLMo8atfRYGnIQqP07f8PsSsjgThQ0ztzYjjyWqEcMRQ6RGSdNjZm9J+5iOGn0t7fWJ/i+/d9Pfq zBDSnsLoj+xHp5/a4koYCcU2tbtcZN8e5vfNA1x/PwEm4gD0olKgLevxpJN5eXHfVVq+hLwpzaW8 AfkF061MG2DjVHMLqS/Kh8lsOttGGCKBND5haQvXyFrZZ+yu1u1dVeT1/u6z6g2zhewxFPipJaiH Rudf4D7HRm1015brAnnx0eCfwtX0zWcGeCuHpdSLtrSY7MoN1uc0wO5atV3ePUDX3itYo67bVe18 flFXjYRV3uX4NNnhY8tPa6UN6dRxpn2FVpyFqO3oJ003nEErtMPp0xH++3Dyw/j9u1EyvIRvIDrO g02LcTSyW346+zZMY8v91FNfwyQ15HKRftgriZmbtsAzneu1gg9vfrycZBfZbz9dOoGgG0XHRWPP yRLGxtY7R9pv77Pxr/35dXu/geEKHWPD4VBLPLUrRO8pnDPmavzrxXgyuZzhRD3ksSu4CNHI+o/y MDKu/X8Y5SFayzMmecg5Vvk/TPKQYxScLamnbwzRN8ZHreyLzAhXP8WNTN3JRnZ5XT8YoZBNiX2t W/go9y2uF+46sBRt6hnwmHHmRyf5oQzlsJednRqi/uxgrdbdqlVueOgrE4497UsT/FFw1OVaVFbe quZuK8iH2mdRrxYPyir2DrQLYCCM2tHIM38sTZ5Pzyf522DCNJFz/QhL7H4SW9UTTmz3k04/8giY GVHztq7be5O6TmJmqsJUGgfGaoX8Q9rpPTdfO0HGzAiPP0hh3PexrRRQApc4JSu0TPeVXhzCACW1 QZYj1M/ydkhvR5B3EpzoBCXM33mzCMddcBScOTYOAJOEs/bPvkVzKOUcJ2+5p5vp4G6eF9I4cidC nqKEceZLOc6MhJ1CaLpxHx4dRu+UEhG+hKbd9XGFr9BLu30HJ0Y0xih7LPDUWYbGOGYnQRZ1+8ip EGd8Zjek3FfnGbU70mPxGYExqH6k6i5HW2hVbt61y0fkwqw0rZ42M9l9rgq8yPCiCyaNjL6xxFPf WGD2G6fShNpamu5sH26HAoNjLyAiWJldncbCubMWcIOBM8/OpKlA93JUzUKCvnlc4nZy40ZsvgzZ pl8lG6hFu65LM78cICluQNC7hdwzZxQt1n5j4MqZHZZGwPI/pXH+N1vh31g645ONTXbmjib0LOlF y/dceh/D4gSy3fismp5kvX1f4gAzOdq24loZTXZBQzN+htlFU0aSk4LRRx435S95pW+H0e3InZoo NZLqK1gULRp3ei57RMROo7ZBNUL/oCqzL9v0ppmfd7Kf48Zq+KWIo68+ByPaOnrcB301R3A7rAiS 6JlC4C1sW7x8jeYZ+zbEC06woTDi6l9QlpzwlOZAlUD+HwqHu6AsOktdKdo4ftz1iEOub0u2p3oj P8vOEP4OW6Cx+qGO7m4oDQ0CGvm2Ixo5elzK8DjQ+UNvxrk47c1S9BWJf87QyfGnGx6XMxvDVd6U uW4xd6uuLWS57qT12Huri5qmVrKo5lWx9xtbrP8MAAUaWe0KZW5kc3RyZWFtDWVuZG9iag0xMyAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjUgMCBSIA0vUmVzb3VyY2VzIDE0IDAgUiAN L0NvbnRlbnRzIDE1IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAw IDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTQgMCBvYmoNPDwgDS9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzMgMCBSIC9GNCA0NCAwIFIgPj4gDS9FeHRH U3RhdGUgPDwgL0dTMSA1MiAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMzIgMCBSID4+IA0+ PiANZW5kb2JqDTE1IDAgb2JqDTw8IC9MZW5ndGggMTkxMiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+ PiANc3RyZWFtDQpIiZxXXXPbthJ916/AtC9yJ0YI8DszfVBkpXWmTtyImdvOdR8gErKQUqQKQFbU O/e/dwGQkiyJMlPrwbIlYs+e3T178HqsQpQrROxL5YPXP00JelQDggQaRBSnaYpikmIaIJIm6Jp4 OIyQ5IP54G02eP3OPJbNBylOI+TBy75xzxF4kOAg8HyULQee/RgieNjz4LQM3qFsMxiiw5/PK6Ul Z0uUL1hV8RIJ9QZdZV8Gk2yww9jC8mITzE+CY1gdaDwPk+gIzfPwBKMxhNccMaT5clVLJrdI1huk F7JePy4Qq9D0w909mk4ytFaieuxCF6WRgRR4tB+6KElwfBkd/OQW3agq/sOEfhiGD1cYSFPc4BLz 26rgX9ETK9cc1WutRMEBOO+EmISYJogmJ3XtgBjHOEheglivuGRa1BUrkWTVI0CZWxRqq4BT3Ikm 9jEgCUjPckZRhL3LaChGU65t8KLO1e3882rs+mpc1hV/J+slmgteFkjX9lsthV0Q4Tc0HIDohzAM cOK9xFdTLsfRarFVIjfMQc9tFjVUdsUkW3LNpYJwf62F7K5nSLBPEYn6tlzg45C+hI8VX9ZKL3ml u0vnw7n0G3rdp5hQL7gQ2MdoZAM7WloOHFuqGT3zUcU3B6PaiZAmOAq+oXTUw8mxcp1QA0WC8ZtU ag1FYWV5WKu8rjQTFSq4gpIVLfAufCQ2Ekujvs3vpafKeoJvxuc1IFvJOue8sIzVCIZwhYLuWnqh VdWoJ1NhmrykqhDs86owqnrS4rMtUlzrtpj17AvPdRe0MA1wBApB+0JLIlCUl0g6UoYWKQiCXPOH IbESmy2E2isbmjNRdtYyTHwjq4HXU1bDOOwhqxuhF4hLWUv0yKuJlCBWljM3n9BhB83HoOpVrTvH IYwpomFffFGA6YsyltfLFZAzK3kDleULVANA6VrNg2CYBEGEspujp0OMbnjJm/74lr3rDvVpeHoo csmTFnCKIz8x2Zlv3kx+mWSTlpwwcaQEAQZN8qG7PChIBysEmtDREpBn6mn5HcK4a1lvH4aR6Zts lwvIpxQw/xUMoi0N9JISqinRNYGWCf2L2TANiEQltGCl+Nv1YbM1lqxij3Cu27COmCZtP8C+H/tN 3vi7zo6gkRFImqS4b1uQ5FQi/7uD/ebNj+h/u+Fyrq4ZsQlwsUUkQf9HV5A5uJBoiK7+yN6DNwzC ODmkwTNGcXiKOsZhCKhBrAjUhMAEGeUMzF97cxo4c0qohQe/3GMEBakP2Z4xprDBMpOFw311DQIy /LVW91fgZOlQ1s2/RMkzZlrdou5ywW2whGI/arfdLp3shwMrPPz07vaJNjKp2s8bGAYAhL5jXzMw VGop9Nu1VKYdViXL4esFX0meMyMCJ098dd89GcEDJM+m6ACT9Uef3o1hLcUeEhrMuB3zUrBKG4Wc ccDAiuu6KrfoYcgU2nDYgqfj7lCNl1o1yIDAey6XQiloY3hsIUAt1KJeGy+24JU5WnEbxPuaeA9X 6My876AVtZksGKq8fgKPcO9GC0audUzGvSi8o/049ZaSfeqjUi+s7tittGqHbcaN8jCXtfPiSNtG WLItElUhclu/JZdCK4P+iJAWesHnomr24Xm0aA1OVKK727fw7ydheEKPa3D0JTwIuWSNrz9H9J5k 16WWFthfpkwm5M3H8fR2CrcdD41LppRJbcrlk8itWYAHIc1XZ2C7OkEbqPUKhM00HDiM/XkEdLoA 2w3n3mVTIMJ8WnB7sPlEuSD7Bp+x/M8Nk8VufUBovT2zMXq060hZD+ZE0BkwUYG11mZohClh44AO 4P76cfoKKIGMXBk3Ak6A3gPjdkquoW6+1sbs7SfOPM6lM1owIqYPTCdugJ2FCbbeOx9TS0PIKa9T DVvikWfbFX/eBHCAgBWiutvEHNim3LLaVMekC7pi4z7Rf0cqzNKCrYBZlJdMirlpcGDyzcXDzig1 bDfYllYTo28QahpQo8rB0ZIZ/zz68NNVMpyg76NeGkx9D8fNjeMMRrcDKbUmnKQ9NyAl1oQHJ1uk 4e54GN3e+/j2/WScXWe/3086gcA+S2AZBz2NLvUScC5d96np7x+y0W/u/c1ZSF0wvMDENrT1gkHS CMedV4G70W/Xo/F4Mp0iMyHXLAchUNYwdsQnsKXNdu97nyXgJPaL9oSGbJR9njZmdS2lmaSuwAmB iwPYir6Jx+Ack67AN5Pp+NPtfXb78UNnwNjDUf8bAzCCk+OpeGYYv7vhKpdiBlJr7wga3OdsrRtF Zsg4aLMYWvVvhPncijwHN4hxSvvfEUngYULP2K1mUJ753Nu5kbzSyhvsFzAVh9sWhNkkNLZqfVcX fNkJ0o+M4gS9i0gTIxGXrjmZsSyVs95Tq7mvkMXV2IPW5FuQu50iOm+KhIZGcKjfFyKJjeBcgmi2 nqzLEpibuWX/xEpYgoCuCwTcPSAGjb2eILwIpvIiiBfsHu6E4lET3097QoGr2KHekFMkOyuYWwoO O2lXLLXvN1fJLngp3AFAFfyeU5r4cIu8iA5cBK8KMNM7Rv4ZAN1C4zgKZW5kc3RyZWFtDWVuZG9i ag0xNiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjUgMCBSIA0vUmVzb3VyY2VzIDE3 IDAgUiANL0NvbnRlbnRzIDE4IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BC b3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgDS9Q cm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzMgMCBSIC9GMyAzMSAwIFIgL0Y0 IDQ0IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwg L0NzNSAzMiAwIFIgPj4gDT4+IA1lbmRvYmoNMTggMCBvYmoNPDwgL0xlbmd0aCAxODI4IC9GaWx0 ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlFddb9pIFH3nV1ztE67C1DMef1Xah5QkFSul TRukrbTdB8eMwa0/WI8dGq32v++dGUMJxmCaCpzB8T2ce++5576fj97eUaAwT0YhCT2w8UdfeIyE YUjBp5Rwbjswz0dvp9KFWOqbbJDx6O2HRwpLObJhHquXzWgM1vz76HY+Ug+l6h4KKYzM08C3ffVs bjOYUJu4HlRilIzez/uC2zahngm+C2oT22ZcRRzD/r9ZAmm+zkQuilosIJL48GgxKYvs5QrwrEqF hKgSEOO5uuMpkvh6iLeF6oWewueE9jCoXhAQ/xDqa4BlAWmRlFUe1am+hi+3HyZfbj/D/fUUciFl tBQKdSzSZ0SWVGXeCy9wCQvA4QOZ9Hyf8OAkvGn0lAm4Lxcil/BtvPcrzEWVp4WB/fgia9GPy3dI EGCGg4G4PI/Yp3Htkqrjf7OuoKza3B0wKn7WVRTX56jDd0ysPxShy0lgn0RYrwTM7+YPUK41jiRF 5l4zePglSC86lxKHAad8IDzuEJedhDcrNMK+hEqd0Ktf3bJrlj6IDiJg4NjeQIgOI5TZ/ARE1ZaV yEtV9mkCRQlZWSxFhYeJqEQRq3Z96QXEAuJxYHQoIGaTgJ/kbFHGcpZM81o+iuo5jcVcsWeyphSB UM49mN8Y6euq3haZ7V4keG4YDBe860Jn6kUpSb1KJdQ6w3kja2SwhqdfnG5WqiTTGtLerLohJx4q SjiQRDfwsNNPkvg6edEe3C29++TuOqYPYOAoyeNsoCK7vntO8nQzfLOUoBxP+Akd7EPpM6BsKIce J+y0thi53QrG/M2ZgnN5qORjeBY57crHhQUnV2WTLbYlF68i7Fz9gam6PqROQFATBk8K17EJ4ydV xNT3+ao71tTnmaUucbwLyg+9jnuBd9kjFC+2HiVq6lJNtzjKlI1BHa92hGut7kNrOxcJD0e70xGe 1xgxtxHItFgiQkMpTl4QUbyCaRZJCWUCLa8EW6vJ6nTdn34eMiU3g+nkAT8nN9uxtUnrlZ54MspF BxusowrPa1EZN6jKtg9jgN4XqDuwlzh6H+90N6O3K3O0AQuxIL/1hvXt4bOM40W/hMw+3tx+hX/b yv9cyoeqTGYY/if81xveRSfLgDkDHQh3bbQDfQjevfv9MD6KghFX2oKwCXe1HTs2Vc20dZirzo90 J3aZi6CZHrQs0K59QjlW8w732ztuVhzKND58M39Glc/arTc78BPdpkwvNe3VZvTX+JM1QbkeP1kT D9++i7hG71SY32oLLcU4+qldlDma6KONpUhk48qi+FtqHlFbkxDfBLS3tsdJ0p6jfLWPxcI1Z/Dl 14PjypoE6j79zAgjsB0EoTTE3JeZpyoj9/f8j6Os4R8iT9TXa9kBa0fIwnXMOyRLMaSOWtrUpSLr 2/jTg4W7ozN+tCYO8cdwP3sPyyZdiCwtEJNE/tQc9QiCxBlsQPZtoy0CJ8DxtpOp10vnK1vWWygO ugLUHeqFmPcLCsXxeI8z+/XdWfvdsdotD785lvyNxfGitBi+bvQ1ZpYiHbK2cJ5gWagbhX7FRPr4 SW6pSTOe6rtxmBbm00z3jL7cceWc5Mp1lO0+ytUxYtA5oL2iXUE+lxO0EB2ftTfo7q+/Tq6n09vH x70Vow+EgwicczNrG1g5go70Gam5KTfFVJOXXePLT+hqSd+4b5GoJKAKuufsyRaMGvcnjNQhC5sq rcUVNsXH4eTYXDmm8/OohcRwprPOmtPh564S/zTol3rjMjWq+fC8MDWqO06tE/fPdIFzui8mjl50 W9QbGhNnL7qtczHRxjdZj39vA/uYtOCCwGr+dnxJJ/CsQMORiej5iCFqA+PY9S6ofoZjFw3RuW/8 UG5EpWPu5MJ0gR3w813AlON1Oi1wRhEYC7qNud8Lx4o+2S1hCr2s8ZO8/Q7GLaT5OlP2Tjk73MLS PMp6YTOuLYx/zlxuAVPviIVRAQWatdoUzCqSaBZhjcYxxZ2sqEE1TlrpW8jFAsNspvcffs5mtRhp yLv7zx6pD1tcaHHz6IeesIUUZkvQCxvuZpE6SOCoGIFs1uuyqkkfYhraxMd68AZKIg3QIXZ68jqr cX1ZrszCg/+jfR6hbJTnMWibqlJHN5+mj7NHkGsRX2m7HsEilXEjJS5IfVj90GxrA7WS+rS7rY2R lXzL3aasfuDyA8uqbNa6Wr/czeA+fYJndqVWz3YrwzUpE0mt70iaSm1svSC9QGnNcEI9+5jWGC6w RAlgEayitbwCWeLq84yLRolrzqJBVygkGsM0S+sXlXNZFhLL5AWr+tm0lqb/BKGuRxCqP7Ra0U2g GTzI/V6xRXEscC97agxTiuEIDSGCicsiSZdNZbpOLXOqJmRdVtGyVYFYfyZ7sXIX9zZvaOod/8ja 1qwxeCWkaPth/qa7lLzymkf2lOOKu1OE/wcAPIMiiwplbmRzdHJlYW0NZW5kb2JqDTE5IDAgb2Jq DTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyNSAwIFIgDS9SZXNvdXJjZXMgMjAgMCBSIA0vQ29u dGVudHMgMjEgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yMCAwIG9iag08PCANL1Byb2NTZXQgWyAv UERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzMyAwIFIgL0YzIDMxIDAgUiAvRjQgNDQgMCBSID4+ IA0vRXh0R1N0YXRlIDw8IC9HUzEgNTIgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDMyIDAg UiA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDE3MzkgL0ZpbHRlciAvRmxhdGVE ZWNvZGUgPj4gDXN0cmVhbQ0KSIm8l11v2zYUhu/9K4juovIQqyJF6qPALlzH7VzMaVCrQ4tmF4pE Jyxs2ZXkpNmw/76XlPwVW56CFk2KRpb58ZJ8zzkPXwwKQZKCUPNbJJ0XbyaU3BQdShTpeL4tREh8 5ticE9+xhUd6lNvUI7nsTDuvos6L1xwdo2mHMuLgF3+qXhTtAztkjkuieccxX2J8h0Tmv/vOZ2vw e//iTTewhuQX4pPuX9FbDOdWw4V26Jk+5mE9pBf6dhBUQ1qkG33pDKPORrvH7DAM0cgoZNyBWKN5 K5YeHd30w+iBZ7uew/cF247DuFZtpYukGE3PF/dZUeYyng9u4yyTs2FW5g/k3au3w0HUiz5dDhuF Bcz2ISwIHgtr0ONzfHy0gRapfyafLqL+x+r5/JSyJjU+tXlAGNbbTo3n2l7QpGbc/9jrDwbDyYSQ bFH24iSRRaGuZ7Jxfg9bGxDqsZbzC2azxvknUT/6MKmek1Wey6xsnJgHNualbdfNKSzQNO/5cDJ4 P7qMRu8uGudz4V5G3KDthCy0/cdxs5lQ/zzrZ0Sas13mizuVyoLEZKaKkiymJC7LXF2vSrycLnJ8 Uajs5sQxMM9G0NKw7THQwHZPqiNbH5KkMqLdODuyCfaFO21nd3zb4Sdn3+yNykh5qwpSxtqF8hv2 p9oSGSe3RE2r6LhX5S2Js0aBjqtzX+uYFaGwvdMC1TR6WEp9VDqhDLS67Y5dWZQFV93GDRMh08mN M6+lnoDv5TR6qCe6lWQwjiYkvlYzVT6QcoFByxj7N7kYX5LJMKr2DfrS3n2uSknu4tkKBmsSGThI 04S7LU9V+C5SwXbTjoiMp6XMSfFQlHKO0VSmShXP1N9xqRYZwSmr+XIm5zj56k0qlzJL46y0tcbN SXBkYJ9SfIjOO9azxgV4oc6NVByUkIYFePREbhxdnA8/kn9w8KMsld/Iv43TisBmhPltz1agLjdm ppcvf8OcDTUrMjFBayl6lTbl3NO7Yiq0tfPeZcLs1qHqCg8EEzpEKCR7/Al8IKh7yAc9XW/RHxo+ W2m3h2iyFl3I8Cy9kG4vwNNg3qUoXlZZjGN8Z76Muj2Ov/F11WfW7aFcWbLL0G7NFser/1qOw7aR +7joD+ZlMXnIklEGG8L8Z2T7/kOSbl8fbOfOAKPsDrGTvo+zG6TkfgkrL8tid6hRVsi8XI/28vAQ dg6H2oHjs72T26rukVGpoyJZICwUwsAE8E46XFx/kQnyIWL9WlaRvchmD+TIuffIlTUeXazL+6bt Vdc07qEse4I2qDzico4gREalLV3OXZzrY5fvLHUSzyWJi9NON6uyufCDNjorX3NgL6riU7GXO+Fh VO7DbnDakPXC3TBAZf4f2HUBu4g6GrTMVC4YN3hcn47afRwnrcnWDVxUGcJYyyrp+gKN2pPtnp4m DeBZTNGaZ11Pn+iP41lUWdSA9jzrgmeDH8GzLg8Bxu2B1uUa/L8DaF030MHRcjbXsVljkdqn2WSR aexActzkJ7BtApzVr3bAFuxkIK5JIJgWqdH1WqYYlx65qe7zx7g/qESegSRLoIVWVIKcVIbMOq8x JFtjZSO/uVQAn9sDr+voy8NPBF7X4SDs9hDCQs9mTwZeBPMsfpC5xl3/BO6yUBfl9rjLAn2f+Mm4 ywKqs19r3GXAXXGayX8u7jLUOOcJuMvwwL4fdxlwFxmzNQkwoa8V231r5t26Xhyj3Faln7k+QJwC bE1Fa1v6GTp4jwVWRCt2iFZURCs2RCtqohUg2knVAgCoNMKiUbfn6xcGcEUNuKICXGEAV7QDXIZ1 AExqdZvlR7/u1v93Ju/ubONEK0lkP52rbAK3rQptv21snCGXpEg9qUpinZp1TqyHtWLdCVkoh0nv JKm7Iw8g/cSJeTcYk9WyAjbydSVXkhTVhGd4D2Pn8nqxKEk8mx1Ba9OhIHEuEQAzCbY2YgbjAlkO PXLZy+UNBMjcJpcyL/Rjlki9AhR1kkmZytQ2KeGQeyE7K5QJr+epKrSX0ucvnsusetKDIC+otEZr SWZqKosl1qZXqFdWTZ6bELVP3rSOeJAKYe6gDkD/KSakHNcq76gJ+Y4JeWVCvjEhr03oWTpytNl4 bTZemY0bs3ntzIZd3IbC1l6Rrk/4F5tDKpYyUVOV1NXePnIIayPWl6ZIzeViVe7i2Z4bq+p2Pnz9 Z/8PghKzKuSRjbeqy9G1nCl5B9OUt3FpTnCZy8IYBCeoP9cDaVPpj+PRq1oqppzK3DRF+TjiHbTW q9PTFKsp1qg0waGt9l2qy81MO2S5NqUe8etK5SanF6fN0ju8yWxc9N8AddTClwplbmRzdHJlYW0N ZW5kb2JqDTIyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAyNSAwIFIgDS9SZXNvdXJj ZXMgMjMgMCBSIA0vQ29udGVudHMgMjQgMCBSIA0vTWVkaWFCb3ggWyAwIDAgNjEyIDc5MiBdIA0v Q3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVuZG9iag0yMyAwIG9iag08 PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAzMyAwIFIgL0Y0IDQ0IDAg UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDUyIDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAz MiAwIFIgPj4gDT4+IA1lbmRvYmoNMjQgMCBvYmoNPDwgL0xlbmd0aCA3NTcgL0ZpbHRlciAvRmxh dGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImclk1T2zAQhu/+FTpKBwtJ1od9Jf0YOtNDJ+bEcDDBgDvG 6cQBhv767mptkzZOSJlMLGm1ip5dvSvnvEzOvmimWXmXFLLwTMEndryRRVFoFrSW1qqMlY/J2aJ3 bNVHJ8X6VXL2danZfZ8oVq7w8ZJwJsqfyecywR/V6KNZwxIfpHMFC6qQ2rPcS8tSbbG/qZO75Bwx LGFoE38dGlqkmS+C9APCtHWqpFLghBsPvZfkipcitdLwSqQamhuROmhakWbQ1D3sVt2SLRVa5nzd /eXxSssYE9flt4OZGbEgjMwrS1iHEzDE7vMMV+tM/1/wwUz5n4LHiFXAPa/47XrVX9yJFGD4srkX WsnAO4wn41X7Q+QwfBqHzfa1rG6EB1tbU5RzqEEhnYajz/y/rDOILt8/H0Q02YQoEA84F8JC51Fo h7hbgU1FzVMPaG0dPQ+jOUw6oHnY8gQ0a2U+Lx0/sKEAPF/jyXtOqYRw+AIY4aT4kubrzXODSQQX kQY0RKV5Xt2QQ0uztYDjOoJvjXSAb9QJ7KAU9ZG0Ujp7EPjHUmxAMihUaMwJmDpIY8cy2MHM7Btm gKRETAcdwIQLADDx2ceELQbbkowVytkPHiN0OJpYwMTqstl+dc0wq2y/qEgWdkcWlmRhJ1nYQRaA 1n/HOyZORiWA70KkBYWHHmDVaCaBWBKIjQLxR+JQOpYeXHkmfz8Qlxfzpaffcu9i5oEKUt4vHqqu q8HWXm6btvkNvWrbrLuLbovWDXyfq/YgnstDLL/cnZJmF9x+9UW6HQW7QcEIiOKdEGEwQUYJAyYp wR2TrwsZlphRpwDCW26+xMJuiYWxxAKVWIglFmKJBf4pTqzhXAN/6cjtAXUDzF28fruablyaWz91 tJysm/gEtShcQNUZjoTnilidcPCn3M3O5vPVafxuhH6M0FOEPkboY4SeX8aJX1QL5PVAg3hSuLwl 8xCb52TdxGeMzY6xjeJ/53+HyzwMx6MB1OnF+keAAQDW/erICmVuZHN0cmVhbQ1lbmRvYmoNMjUg MCBvYmoNPDwgDS9UeXBlIC9QYWdlcyANL0tpZHMgWyAyOSAwIFIgMSAwIFIgNCAwIFIgNyAwIFIg MTAgMCBSIDEzIDAgUiAxNiAwIFIgMTkgMCBSIDIyIDAgUiBdIA0vQ291bnQgOSANPj4gDWVuZG9i ag0yNiAwIG9iag08PCANL0NyZWF0aW9uRGF0ZSAoRDoyMDA0MDQxMjE2MDgxOSkNL1Byb2R1Y2Vy IChBY3JvYmF0IERpc3RpbGxlciA0LjA1IGZvciBXaW5kb3dzKQ0vTW9kRGF0ZSAoRDoyMDA0MDQx MjE2MDgxOS0wNicwMCcpDT4+IA1lbmRvYmoNeHJlZg0wIDI3IA0wMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDU3NzUgMDAwMDAgbg0KMDAwMDAwNTkyNiAwMDAwMCBuDQowMDAwMDA2MDgxIDAwMDAw IG4NCjAwMDAwMDgxMDUgMDAwMDAgbg0KMDAwMDAwODI1NiAwMDAwMCBuDQowMDAwMDA4NDAwIDAw MDAwIG4NCjAwMDAwMDk4ODkgMDAwMDAgbg0KMDAwMDAxMDA0MCAwMDAwMCBuDQowMDAwMDEwMTcz IDAwMDAwIG4NCjAwMDAwMTE2MzIgMDAwMDAgbg0KMDAwMDAxMTc4NiAwMDAwMCBuDQowMDAwMDEx OTMxIDAwMDAwIG4NCjAwMDAwMTM3OTAgMDAwMDAgbg0KMDAwMDAxMzk0NCAwMDAwMCBuDQowMDAw MDE0MDg5IDAwMDAwIG4NCjAwMDAwMTYwNzYgMDAwMDAgbg0KMDAwMDAxNjIzMCAwMDAwMCBuDQow MDAwMDE2Mzg2IDAwMDAwIG4NCjAwMDAwMTgyODkgMDAwMDAgbg0KMDAwMDAxODQ0MyAwMDAwMCBu DQowMDAwMDE4NTk5IDAwMDAwIG4NCjAwMDAwMjA0MTMgMDAwMDAgbg0KMDAwMDAyMDU2NyAwMDAw MCBuDQowMDAwMDIwNzEyIDAwMDAwIG4NCjAwMDAwMjE1NDMgMDAwMDAgbg0KMDAwMDAyMTY2MiAw MDAwMCBuDQp0cmFpbGVyDTw8DS9TaXplIDI3DS9JRFs8MTY1N2FmOTRmODNiYmU5OWUwY2FiOGIz MWM5MzZiYjk+PDE2NTdhZjk0ZjgzYmJlOTllMGNhYjhiMzFjOTM2YmI5Pl0NPj4Nc3RhcnR4cmVm DTE3Mw0lJUVPRg0= ------_=_NextPart_001_01C420E0.C28F3FAC-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 13 11:52:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18330 for ; Tue, 13 Apr 2004 11:52:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQCp-0006Zp-J0 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 11:52:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DFqB1V025281 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 11:52:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDQCf-0006ZM-Cd; Tue, 13 Apr 2004 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDP0T-0001IH-HJ for ipcdn@optimus.ietf.org; Tue, 13 Apr 2004 10:35: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 KAA15155 for ; Tue, 13 Apr 2004 10:35:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDP0Q-0006lf-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 10:35:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDOzG-0006gn-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 10:34:07 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1BDOxp-0006YM-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 10:32:38 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i3DEWdT6005260 for ; Tue, 13 Apr 2004 07:32:39 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i3DEVB6w005509 for ; Tue, 13 Apr 2004 09:31:12 -0500 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id ; Tue, 13 Apr 2004 10:32:23 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF238104817B33@ma19exm01.e6.bcs.mot.com> From: Keske Tom-LTK002 To: "'ipcdn@ietf.org'" Date: Tue, 13 Apr 2004 10:32:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Subject: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , All, Thanks very much, Eduardo. I think that this looks reasonable. There is a very minor spelling error in a number of places, where it has "dependant", and should say "dependent". < Persistence of read-create entries is implementation < dependant. Regards, Tom Keske .------------------------------------------------------------. | Thomas R. Keske IP Network Systems | | | | Motorola, Broadband Communications Sector | | 111 Locke Dr. | | Marlborough, MA, 01752 | | | | Tel: (508) 786-7687 Email: LTK002@email.mot.com | `------------------------------------------------------------' > > > > -----Original Message----- > > From: Donati Andrew-MGIA0477 > > Sent: Tuesday, April 13, 2004 8:48 AM > > To: Murwin William-LWM008; Patrick Michael-LZZ007; Wang > > Daohong-MGIA0610; Keske Tom-LTK002; Scully Brian-LBS002; Ryan > > Dan-LDR001; Mowry Gary-LGM005; Hamblin William-MGIA0504; > > Potvin Donald-MGIA0574; Liberman Alex-MGIA0537; Gulbas > Aysun-MGIA0497 > > Cc: Dua Anirudh-MGIA0481; Jaroug Souhail-LSJ001 > > Subject: FW: Changes for next RFI v2 MIB (draft 10) > > > > > > All, > > > > Here are proposed changes in the docs RFI MIB to review. > > > > This allows us to legally designate one or more default > > modulation profiles > > as "read-only" (Objects in row can neither be changed nor > > deleted - Not Writable) or > > "permanent" (Objects in row can be changed but not deleted). > > > > Note that in this document they allow 'permanent' as "need > > not allow write-access to any columnar objects in the row." > > So it seems > > that "permanent" and "read-only" can have the same functional > > behavior. > > > > Thanks, > > Andy > > > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Monday, April 12, 2004 6:52 PM > > To: Donati Andrew-MGIA0477; ipcdn@ietf.org > > Subject: Changes for next RFI v2 MIB (draft 10) > > > > > > Hi Andrew, all, > > > > Please review the attached with the proposed changes for the > > StorageType issues to see of they cover all concerns. > > > > In summary, there are eight proposed changes > > > > Changes 1,2,3,4 are related to the issue brough by Andrew > > Donati by adding StorageType object to the Modulation profile table > > > > Changes 5,6,7,8 are clarifications to accommodate the OPS MIB > > revision guidelines sections 4.6.2 and 4.6.4, quite related > > to the problem raised for the storageType case. > > > > During the WG Last call for technical issues, there were no > > other items pointing our attention. > > > > Let the WG know any question or comments by COB Wednesday > > before submiting the draft to IETF. > > > > > > Eduardo > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 13 13:12:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22548 for ; Tue, 13 Apr 2004 13:12:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDRL5-0005Td-Q7 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 13:04:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DH4lFY021046 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 13:04:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDRHT-0004jA-5l; Tue, 13 Apr 2004 13:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDRDy-0004Ff-JM for ipcdn@optimus.ietf.org; Tue, 13 Apr 2004 12:57:29 -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 MAA21889 for ; Tue, 13 Apr 2004 12:57:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDRDv-0002dh-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 12:57:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDRBa-0002Mb-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 12:54:59 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BDR8Z-000266-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 12:51:51 -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 i3DGpE9T020954; Tue, 13 Apr 2004 10:51:14 -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: Changes for next RFI v2 MIB (draft 10) Date: Tue, 13 Apr 2004 10:51:13 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQhb2Xoya6SGGxmRsiX83I+VsNKfwAB8fRQ From: "Eduardo Cardona" To: "Keske Tom-LTK002" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks Tom,=20 Will fix them Eduardo -----Original Message----- From: Keske Tom-LTK002 [mailto:Tom.Keske@motorola.com]=20 Sent: Tuesday, April 13, 2004 8:32 AM To: 'ipcdn@ietf.org' Subject: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10) All, Thanks very much, Eduardo. I think that this looks reasonable. There is a very minor spelling=20 error in a number of places, where it has "dependant", and should say "dependent".=20 =20 < Persistence of read-create entries is implementation < dependant. =20 Regards, Tom Keske .------------------------------------------------------------. | Thomas R. Keske IP Network Systems | | | | Motorola, Broadband Communications Sector | | 111 Locke Dr. | | Marlborough, MA, 01752 | | | | Tel: (508) 786-7687 Email: LTK002@email.mot.com | `------------------------------------------------------------' >=20 >=20 > > -----Original Message----- > > From: Donati Andrew-MGIA0477 > > Sent: Tuesday, April 13, 2004 8:48 AM > > To: Murwin William-LWM008; Patrick Michael-LZZ007; Wang=20 > > Daohong-MGIA0610; Keske Tom-LTK002; Scully Brian-LBS002; Ryan=20 > > Dan-LDR001; Mowry Gary-LGM005; Hamblin William-MGIA0504;=20 > > Potvin Donald-MGIA0574; Liberman Alex-MGIA0537; Gulbas=20 > Aysun-MGIA0497 > > Cc: Dua Anirudh-MGIA0481; Jaroug Souhail-LSJ001 > > Subject: FW: Changes for next RFI v2 MIB (draft 10) > >=20 > >=20 > > All, > >=20 > > Here are proposed changes in the docs RFI MIB to review. > >=20 > > This allows us to legally designate one or more default > > modulation profiles=20 > > as "read-only" (Objects in row can neither be changed nor=20 > > deleted - Not Writable) or=20 > > "permanent" (Objects in row can be changed but not deleted). =20 > >=20 > > Note that in this document they allow 'permanent' as "need > > not allow write-access to any columnar objects in the row." =20 > > So it seems=20 > > that "permanent" and "read-only" can have the same functional=20 > > behavior. > >=20 > > Thanks, > > Andy > >=20 > > -----Original Message----- > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: Monday, April 12, 2004 6:52 PM > > To: Donati Andrew-MGIA0477; ipcdn@ietf.org > > Subject: Changes for next RFI v2 MIB (draft 10) > >=20 > >=20 > > Hi Andrew, all, > >=20 > > Please review the attached with the proposed changes for the > > StorageType issues to see of they cover all concerns. > >=20 > > In summary, there are eight proposed changes > >=20 > > Changes 1,2,3,4 are related to the issue brough by Andrew > > Donati by adding StorageType object to the Modulation profile table > >=20 > > Changes 5,6,7,8 are clarifications to accommodate the OPS MIB > > revision guidelines sections 4.6.2 and 4.6.4, quite related=20 > > to the problem raised for the storageType case. > >=20 > > During the WG Last call for technical issues, there were no > > other items pointing our attention. > >=20 > > Let the WG know any question or comments by COB Wednesday > > before submiting the draft to IETF. > >=20 > >=20 > > Eduardo > >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 13 14:32:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26379 for ; Tue, 13 Apr 2004 14:32:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSg9-0000Mm-Nv for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 14:30:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DIUbQ9001386 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 14:30:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSZm-0007xH-4t; Tue, 13 Apr 2004 14:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDSRw-000736-7g for ipcdn@optimus.ietf.org; Tue, 13 Apr 2004 14:15:56 -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 OAA25701 for ; Tue, 13 Apr 2004 14:15:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDSRt-000207-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 14:15:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDSQJ-0001ph-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 14:14:15 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1BDSOz-0001dm-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 14:12:53 -0400 Received: from h-68-164-88-71.snvacaid.dynamic.covad.net ([68.164.88.71] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BDSOZ-0002R8-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 11:12:27 -0700 Message-ID: <001201c42183$59f0c440$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <62173B970AE0A044AED8723C3BCF238104817B33@ma19exm01.e6.bcs.mot.com> Subject: Re: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10) Date: Tue, 13 Apr 2004 11:15:50 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Keske Tom-LTK002" > To: > Sent: Tuesday, April 13, 2004 7:32 AM > Subject: [ipcdn] RE: Changes for next RFI v2 MIB (draft 10) ... Thanks very much, Eduardo. I think that this > looks reasonable. There is a very minor spelling > error in a number of places, where it > has "dependant", and should say "dependent". > > < Persistence of read-create entries is implementation > < dependant. ... It's good to fix spelling errors, but having entry persistence implementation dependent cannot help foster interoperability. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 13 15:17:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00155 for ; Tue, 13 Apr 2004 15:17:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTKS-0006T0-8R for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 15:12:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3DJCGw6024850 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 15:12:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDTDT-0001VN-Bz; Tue, 13 Apr 2004 15:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDT5u-0003yM-O4 for ipcdn@optimus.ietf.org; Tue, 13 Apr 2004 14:57: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 OAA27504 for ; Tue, 13 Apr 2004 14:57:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDT5q-0005TP-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 14:57:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDT46-0005K5-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 14:55:23 -0400 Received: from albatross.mail.pas.earthlink.net ([207.217.120.120]) by ietf-mx with esmtp (Exim 4.12) id 1BDT2d-00059a-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 14:53:51 -0400 Received: from h-68-164-88-71.snvacaid.dynamic.covad.net ([68.164.88.71] helo=oemcomputer) by albatross.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BDT2U-0006yT-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 11:53:42 -0700 Message-ID: <001b01c42189$1d6aef40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Tue, 13 Apr 2004 11:57:05 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - I was able to extract the text from that PDF file, so I have some more detailed comments in-line below. > From: "Eduardo Cardona" > To: "Donati Andrew-MGIA0477" ; > Sent: Monday, April 12, 2004 3:51 PM > Subject: [ipcdn] Changes for next RFI v2 MIB (draft 10) ... > Change #2 > docsIfCmtsModulationEntry OBJECT-TYPE ... > Initial default entries may be created at system I think you mean "MAY" > initialization time, which could report for a value > 'permanent' or 'readOnly' for docsIfCmtsModStorageType. Is "could report" intended to mean that this is the complete set of values that can be returned by a conformant implementation? > A CMTS may not allow the creation of additional Interval > Usage Codes for a modulation profile being defined at > Initialization time. Does "may not" here mean "MUST NOT" or "MAY"? ... > Note that some objects do not have default value , I think you mean "values" ... > upstream channels, the value of docsIfCmtsModChannelType > MUST NOT be changed. This is ambiguous. Three readings possible: a) agent must not change the value it reports over time b) agent must not permit SET requests to modify the value c) both (a) AND (b) ... > MUST NOT be set to destroy(6) or notInService(2)." ditto ... > CHANGE # 5 > docsIfUpChannelStatus OBJECT-TYPE ... > 1. Entries with this object set to active(1) are > logically linked to a defined physical interface in > the interface MIB RFC 2863, no temporarily created to > clone parameters. I think you mean "not" instead of "no". (Even so, as a non-expert, it's still unclear to me what this sentence is supposed to mean.) > 2. A status transition from active(1) to notInService(2) > or destroy(6) is not permitted. ??? So how DOES one get rid of these things??? > 3. ifAdminStatus from the Interface MIB RFC 2863 should be > used to take an Upstream Channel offline. I assume you mean "SHOULD". What other mechanisms can take an Upstream Channel offline? > 4. Temporary inactive rows must be created using > createAndWait(5). I think you mean "MUST". The conformance material should reflect that the value createAndGo is not permitted. > 5. The only possible status change of a row created using > createAndWait(5) (i.e. notInService(2)) or notReady(3) > is to destroy(6). So how does it get to be active? (see number 2 above) > 6. Temporary created rows must never be given the status > active(1). I have trouble reconciling this with 2 above. In general, this is a *very* confusing DESCRIPTION. > A Mandatory procedure for adjusting an specific physical > Upstream channel is: why is "mandatory" capitalized? > 1. Create a temporary row through an SNMP SET using > createAndWait(5). Use an ifIndex value outside the > operational range of the system. How is the "operational range" determined? > 4. Update the physical row by setting the object > docsIfUpChannelUpdate to true(1). This operation fails > with error genErr if the adjusted parameters are not > compatible with each other. My reading of RFC 3416 section 4.2.5 (10) is that inconsistentValue would be more appropriate. > 5. Delete the temporary row through an SNMP SET using > DELETEdestroy(6). Temporary entries need not persist > at reinitialization of the managed system." Optional persistence isn't helpful for interoperability. In this particular case, it sounds like persistence would be inappropriate, particularly given RFC 2579's page 16. ... > CHANGE #6 > docsIfQosProfileEntry OBJECT-TYPE ... > An entry in this table must not be removed while it is MUST NOT? > An entry in this table should not be changeable while SHOULD NOT? > it is referenced by an entry in docsIfCmtsServiceTable. > If this table is created automatically, there should only SHOULD? > be a single entry for each Class of Service. Multiple > entries with the same Class of Service parameters are not > recommended." NOT RECOMMENDED? ... > MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the minimal > implementation has no persistent requirement. > Persistence makes sense only in the case of MAX-ACCESS read-write support. I don't understand how you come to this conclusion. ... > CHANGE # 7 > docsIfDownstreamChannelEntry OBJECT-TYPE ... > The CMTS ability to retain SNMP SETs for read-write values > after system reinitialization is implementation dependant." This is what StorageType is for. ... > CHANGE # 8 > docsIfCmtsMacEntry OBJECT-TYPE ... > The CMTS ability to retain SNMP SETs for read-write values > after system reinitialization is implementation dependant." This is what StorageType is for. > docsIfCmtsServiceTable > Object docsIfCmtsServiceAdminStatus is read-write, and indicates the > administrative Status of an active CM upstream queue service, upon reboot all The ", upon" should be ". Upon" > queues are deleted and CMs will re-register. Persistence is not needed. The One sentence appears to prohibit persistence, and the following sentence says it's optional. I prefer the former over the latter. > docsIfCmMacTable > This is a CMs specific object. > docsIfCmRangingTimeout MAX-ACCESS is read-write with DEFVAL clause. > It is believed that the presence of the DEFVAL and the MIB object reference to > the spec is sufficient to not detail CM persistent requirements. I'm unable to parse this sentence. ... Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Apr 13 21:37:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23536 for ; Tue, 13 Apr 2004 21:37:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDZKO-0002YX-4x for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 21:36:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E1aa4p009825 for ipcdn-archive@odin.ietf.org; Tue, 13 Apr 2004 21:36:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDZFw-00025L-Mn; Tue, 13 Apr 2004 21:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDZC9-0001PI-Hf for ipcdn@optimus.ietf.org; Tue, 13 Apr 2004 21:28: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 VAA23390 for ; Tue, 13 Apr 2004 21:28:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDZC6-0003Ld-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 21:28:02 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDZBB-0003GF-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 21:27:07 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BDZAS-00035e-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 21:26:20 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3E1Pn9T007261; Tue, 13 Apr 2004 19:25: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] Changes for next RFI v2 MIB (draft 10) Date: Tue, 13 Apr 2004 19:25:48 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQhiz7+pdy1wIQzRWemTdxP8GYQ4QACSfZw From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi,=20 That's a very good detailed analysis for the proposed changes,=20 Before going to a detail response, RFI MIBv2 is an update of RFC 2670,=20 V2 introduces in brief : *DOCSIS 2.0 new burst profiles ( in terms of extensions of existing enumerations) *Upstream Channels SCDMA parameters in docsIfUpstreamChannelTable *Utilization and DOCSIS MAC Counters=20 docsIfCmtsChannelUtilizationTable, docsIfCmtsDownChannelCounterTable, docsIfCmtsUpChannelCounterTable *Added some objects in docsIfCmtsCmStatusTable The other set of objects related to not DOCSIS 2.0 enhanced functionality were not updated nor the wording of RFC2670 original objects in terms of OPS guidelines being leaved as they were in RFC 2670. Proposed changes are in two categories,=20 1..4 Modulation Profiles StorageType object 5..8 read-write/read-create objects not upgraded by DOCSIS 2.0 that could be questioned by IESG in terms of OPS MIB guidelines for not indicating persistence requirements. Note that 5..8 all have compliance statements that allows MIN-ACCESS read-only back in RFC 2670 The disjunctive here is be OPS MIB guidelines compliance without introduce new requirements or indeed introduce new technical changes (persistence MUST) not identified before. Options : 5..8 a) as proposed (explicit vendor specific, not interoperable, with the precendent of read-only compliances) b) turn as MUST (new requirement: sent proposal back to IPCDN group and DOCSIS groups for approval) c) leave silent as in RFC 2670 (not introduce changes 5..8) a) or b) will be my options, I started with a) due the b) implications. =20 See inline some specific comments=20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, April 13, 2004 12:57 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) Hi - I was able to extract the text from that PDF file, so I have some more detailed comments in-line below. > From: "Eduardo Cardona" > To: "Donati Andrew-MGIA0477" ; > Sent: Monday, April 12, 2004 3:51 PM > Subject: [ipcdn] Changes for next RFI v2 MIB (draft 10) ... > Change #2 > docsIfCmtsModulationEntry OBJECT-TYPE ... > Initial default entries may be created at system I think you mean "MAY" Will update all document to upper cases MAY, MUST, MUST NOT > initialization time, which could report for a value 'permanent' or=20 > 'readOnly' for docsIfCmtsModStorageType. Is "could report" intended to mean that this is the complete set of values that can be returned by a conformant implementation? > A CMTS may not allow the creation of additional Interval Usage Codes=20 > for a modulation profile being defined at Initialization time. Does "may not" here mean "MUST NOT" or "MAY"? A bit clear saying : "A CMTS MAY allow...." ... > Note that some objects do not have default value , I think you mean "values" Yes, and may leave as he original RFC 2670 version and previous drafts. "Note that some objects do not have DEFVALs," ... > upstream channels, the value of docsIfCmtsModChannelType > MUST NOT be changed. This is ambiguous. Three readings possible: a) agent must not change the value it reports over time b) agent must not permit SET requests to modify the value c) both (a) AND (b) ... > MUST NOT be set to destroy(6) or notInService(2)." ditto ... (a) and (b);=20 Not sure how (a)is put in context, docsIfCmtsModChannelType is a=20 Configuration parameter. An alternative:=20 1. If a modulation profile is being referenced by one or more upstream channels, an attempt to set the value of=20 docsIfCmtsModChannelType returns 'inconsistentValue' error. 2. If a modulation profile is being referenced by one or more upstream channels, an attempt to set docsIfCmtsModControl to destroy(6) or notInService(2) returns 'inconsistentValue' error. > CHANGE # 5 > docsIfUpChannelStatus OBJECT-TYPE ... > 1. Entries with this object set to active(1) are > logically linked to a defined physical interface in > the interface MIB RFC 2863, no temporarily created to > clone parameters. I think you mean "not" instead of "no". (Even so, as a non-expert, it's still unclear to me what this sentence is supposed to mean.) Agree, Although text current text was discussed discussed in the IPCDN list=20 back around October 10 to 15 (eventually closed to experts in the topic) 1. Entries with this object set to active(1) are=20 extensions of defined physical interfaces in=20 the interface MIB RFC 2863, entries created by=20 createAndWait(5) are temporarily created to clone parameters. > 2. A status transition from active(1) to notInService(2) > or destroy(6) is not permitted. ??? So how DOES one get rid of these things??? By definition an entry with status active(1) is the extension if IfTable For interfaces ifType 129 or 205 - regular ifTable extension- Those are not deleted since are hardware dependant nor created by users, Only the non-related to ifTable interface entries ( used for clonning)=20 are created with CreateAndWait and the rules 4 and 5 apply 4. Temporary inactive rows must be created using createAndWait(5). 5. The only possible status change of a row created using createAndWait(5) (i.e. notInService(2)) or notReady(3)=20 is to destroy(6). > 3. ifAdminStatus from the Interface MIB RFC 2863 should be used to=20 > take an Upstream Channel offline. I assume you mean "SHOULD". What other mechanisms can take an Upstream Channel offline? Should replaced by SHOULD No other SNMP mechanism is defined explicitely, If I understood your request from the possibility of docsIfUpChannelStatus =3D notInService(2) Upstream channels docsIfUpChannelStatus only reports active(1) > 4. Temporary inactive rows must be created using createAndWait(5). I think you mean "MUST". The conformance material should reflect that the value createAndGo is not permitted. Changed for MUST The current compliance statement is hard to build since the Flavor (US channel interface vs Cloning entry) Is the one with different connotation IfEntry extension read active(1) No ifEntry extension: CreateAndWait(5), destroy(6) write For docsIfBasicComplianceV2 MODULE-COMPLIANCE Current: OBJECT docsIfUpChannelStatus MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems, read-only in Cable Modems." Proposed: OBJECT docsIfUpChannelStatus SYNTAX RowStatus (active(1), notReady(2)) WRITE-SYNTAX RowStatus (CreateAndGo(5), destroy(6)) MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems, read-only in Cable Modems. Entries associated to upstream channels entries in ifTable only support read-only value active(2) Entries used for cloning purposes supports values notReady(2) createAndGo(5) and destroy(6)." > 5. The only possible status change of a row created using > createAndWait(5) (i.e. notInService(2)) or notReady(3) > is to destroy(6). So how does it get to be active? (see number 2 above) Never goes active, created entries are used d only as a buffer for copying values from an upstream channel, modify them and update=20 The same or other operational interface. In RFC 2670 docsIfUpChannelEntries where read-write with optional=20 read-only ( no row status), just simple extension of IfTable which are Vendor dependant configured this extension entries are by default "always" Active(1) > 6. Temporary created rows must never be given the status active(1). I have trouble reconciling this with 2 above. In general, this is a *very* confusing DESCRIPTION. Item 2 is for the ifTable entries extension (physical upstream channel entries)=20 not for the user created entries=20 Will the proposed text plus the Object compliance makes that a bit clear? > A Mandatory procedure for adjusting an specific physical Upstream=20 > channel is: why is "mandatory" capitalized? Typo, fixed > 1. Create a temporary row through an SNMP SET using createAndWait(5).=20 > Use an ifIndex value outside the operational range of the system. How is the "operational range" determined? Out of scope, as the design was concern, you will point with all reasons that is not=20 Good for interoperability=20 Will be a scalar with a suggested initial value an option? =20 it will goes beyond the closed for additions as we stand rigth now. > 4. Update the physical row by setting the object docsIfUpChannelUpdate > to true(1). This operation fails with error genErr if the adjusted=20 > parameters are not compatible with each other. My reading of RFC 3416 section 4.2.5 (10) is that inconsistentValue would be more appropriate. I read inconsistenValue as values that in other circumstances will be valid,=20 e.g setting to a row while active returns inconsistentValue error but if the row is set to 'notInService' same set will success (RowStatus constrains). Here we had the problem that DOCSIS PHY parameters are broad and some=20 implementation MAC and or PHY may not support the whole range, =20 for that cases the vendor should be able do document the=20 AGENT-CAPABILITIES for the implementation version or model > 5. Delete the temporary row through an SNMP SET using=20 > DELETEdestroy(6). Temporary entries need not persist at=20 > reinitialization of the managed system." Optional persistence isn't helpful for interoperability. In this particular case, it sounds like persistence would be inappropriate, particularly given RFC 2579's page 16. Will be better to mandate non-persistence? In any case temporary entries have no operational or configuration meaning after the cloning process=20 is completed, =20 Perhaps: "Temporary entries SHOULD NOT persist at=20 reinitialization of the managed system." ... > CHANGE #6 > docsIfQosProfileEntry OBJECT-TYPE ... > An entry in this table must not be removed while it is MUST NOT? done > An entry in this table should not be changeable while SHOULD NOT? done > it is referenced by an entry in docsIfCmtsServiceTable. > If this table is created automatically, there should only SHOULD? > be a single entry for each Class of Service. Multiple > entries with the same Class of Service parameters are not=20 > recommended." NOT RECOMMENDED? By the way, old text from RFC2670,=20 can be updated to say "NOT RECOMMENDED" ... > MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the=20 > minimal implementation has no persistent requirement. Persistence=20 > makes sense only in the case of MAX-ACCESS read-write support. I don't understand how you come to this conclusion. docsIfDownstreamChannelTable are configuration parameters, if SNMP is read-only by compliance,=20 persistente IMHO is not a feature, Either the system uses defaults upon reboot or the system=20 gather the parameters from a config file. (which is persistent but outside the scope of SNMP) Requiring persisntece now will be a new requirement, for DOCSIS not in RFC 2670 nor DOCSIS spec.=20 which should be considered for further work or send back the draft to IPCDN group discussions for approval. ... > CHANGE # 7 > docsIfDownstreamChannelEntry OBJECT-TYPE ... > The CMTS ability to retain SNMP SETs for read-write values after=20 > system reinitialization is implementation dependant." This is what StorageType is for. There is no read-create object for this table, it is also a ifTable extension (for downstream interfaces ifType 128) ... > CHANGE # 8 > docsIfCmtsMacEntry OBJECT-TYPE ... > The CMTS ability to retain SNMP SETs for read-write values after=20 > system reinitialization is implementation dependant." This is what StorageType is for. Same as above, setting persistence requirements will require IPCDN group to discuss and aprove that. > docsIfCmtsServiceTable > Object docsIfCmtsServiceAdminStatus is read-write, and indicates the=20 > administrative Status of an active CM upstream queue service, upon=20 > reboot all The ", upon" should be ". Upon" Ok, > queues are deleted and CMs will re-register. Persistence is not=20 > needed. The One sentence appears to prohibit persistence, and the following sentence says it's optional. I prefer the former over the latter. Ok,=20 queues are deleted and CMs will re-register. Therefore, persistence does not apply > docsIfCmMacTable > This is a CMs specific object. > docsIfCmRangingTimeout MAX-ACCESS is read-write with DEFVAL clause. It > is believed that the presence of the DEFVAL and the MIB object=20 > reference to the spec is sufficient to not detail CM persistent=20 > requirements. I'm unable to parse this sentence. Will explore that a little bit more ... 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 exim@www1.ietf.org Wed Apr 14 02:07:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11255 for ; Wed, 14 Apr 2004 02:07:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdP2-0004l7-RV for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 01:57:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3E5vesR018275 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 01:57:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDdHm-0003j5-Up; Wed, 14 Apr 2004 01:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDbjw-0007jN-HW for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 00:11:08 -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 AAA00731 for ; Wed, 14 Apr 2004 00:11:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDbju-0006rM-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 00:11:06 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDbiv-0006la-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 00:10:07 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BDbi1-0006gR-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 00:09:09 -0400 Received: from h-68-165-64-39.snvacaid.dynamic.covad.net ([68.165.64.39] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BDbi1-0001Ai-00 for ipcdn@ietf.org; Tue, 13 Apr 2004 21:09:09 -0700 Message-ID: <001001c421d6$b6805c40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Tue, 13 Apr 2004 21:12:33 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - Thanks Edo for the patient response! More inline below. > From: "Eduardo Cardona" > To: "Randy Presuhn" ; > Sent: Tuesday, April 13, 2004 6:25 PM > Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) ... > Options : > 5..8 a) as proposed (explicit vendor specific, not interoperable, with > the precendent of read-only compliances) > b) turn as MUST (new requirement: sent proposal back to IPCDN group > and DOCSIS groups for approval) > c) leave silent as in RFC 2670 (not introduce changes 5..8) > > a) or b) will be my options, I started with a) due the b) implications. I, too, dislike option (c). I dislike option (a), particularly if the interoperability difficulties are not merely theoretical. I think there are at least three ways of accomplishing (b): - using the DESCRIPTION clause to mandate persistence behaviour - adding a (potentially read-only) StorageType to the row to indicate whether the information there will persist - adding a read-only scalar object to the MIB that reports whether the table persists. ... > > (a) and (b); > Not sure how (a)is put in context, docsIfCmtsModChannelType is a > Configuration parameter. In some environments, SNMP is not the only possible configuration mechanism. For example, a CLI or netconf might be used to modify configuration data. ... > > CHANGE # 5 ... > (Even so, as a non-expert, it's still unclear to me what > this sentence is supposed to mean.) > > Agree, Although text current text was discussed discussed in the IPCDN list > back around October 10 to 15 (eventually closed to experts in the topic) Since you're dealing with installed base, I'm not suggesting you change the way it works (if it has in fact proven to be interoperable). My comment is just that to the non-expert, this "clone-to" mechanism seems really bizarre. I could suggest much simpler ways to accomplish the goal, but that would not help maintain compatibility. > > > 2. A status transition from active(1) to notInService(2) > > or destroy(6) is not permitted. > > ??? So how DOES one get rid of these things??? > > > By definition an entry with status active(1) is the extension if IfTable > For interfaces ifType 129 or 205 - regular ifTable extension- > Those are not deleted since are hardware dependant nor created by users, So, If I understand correctly, these things cannot be provisioned: one must wait for the hardware to be installed before doing any configuration, rather than setting up the parameters in advance. > Only the non-related to ifTable interface entries ( used for clonning) > are created with CreateAndWait and the rules 4 and 5 apply I'd be nice if the distinction between these two entry types was made clearer. ... > > 3. ifAdminStatus from the Interface MIB RFC 2863 should be used to > > take an Upstream Channel offline. > > I assume you mean "SHOULD". What other mechanisms > can take an Upstream Channel offline? > > Should replaced by SHOULD > No other SNMP mechanism is defined explicitely, > If I understood your request from the possibility of > docsIfUpChannelStatus = notInService(2) > Upstream channels docsIfUpChannelStatus only reports active(1) It might be better to avoid the question by replacing "should be" with "is". :-) ... > The current compliance statement is hard to build since the Flavor (US > channel interface vs Cloning entry) > Is the one with different connotation > IfEntry extension read active(1) > No ifEntry extension: CreateAndWait(5), destroy(6) write This explanation was most helpful. I think your proposed explanation would be useful, but that it probably should go into BOTH the OBJECT and OBJECT-TYPE. ... > In RFC 2670 docsIfUpChannelEntries where read-write with optional > read-only ( no row status), just simple extension of IfTable which are > Vendor dependant configured this extension entries are by default > "always" Active(1) > Oh. This "clone-to" stuff is new. I'm sorely tempted to propose a much tidier (I think) way to do it, but I don't wan't to be unduly disruptive at the -10- draft stage of work. ... > Will the proposed text plus the Object compliance makes that a bit > clear? Your patient explanations make the intent much clearer. Thanks. That doesn't mean that I like it. :-) ... > > 1. Create a temporary row through an SNMP SET using createAndWait(5). > > Use an ifIndex value outside the operational range of the system. > > How is the "operational range" determined? > > Out of scope, as the design was concern, you will point with all reasons > that is not > Good for interoperability > Will be a scalar with a suggested initial value an option? > it will goes beyond the closed for additions as we stand rigth now. One of the things one would hope to avoid is that a newly inserted interface gets a number that a management system is about to use for cloning. It's also hard to imagine how one could configure VACM to give different users access to different interfaces with this sort of scheme. This scheme also wouldn't provide any help at all in avoiding collisions (direct or indirect). (Two managers try to use the same row for clone-to, or worse still, two managers use different rows to clone-to the same interface.) The simplest thing that comes to mind, if I understand the requirements correctly, would be to put all the clone-to stuff into an AUGMENTS table, with a simple row "update" button to cause changes to be applied. That way it would be trivial to ensure that the access rights were properly restricted. However, I haven't been in on the discussion and the use cases, so I'm not making a proposal. For example, a "profile" mechanism might be a better fit. ... > > 4. Update the physical row by setting the object docsIfUpChannelUpdate > > to true(1). This operation fails with error genErr if the adjusted > > parameters are not compatible with each other. > > My reading of RFC 3416 section 4.2.5 (10) is that inconsistentValue > would be more appropriate. > > I read inconsistenValue as values that in other circumstances will be > valid, > e.g setting to a row while active returns inconsistentValue error but if > the row is set to 'notInService' same set will success (RowStatus > constrains). > Here we had the problem that DOCSIS PHY parameters are broad and some > implementation MAC and or PHY may not support the whole range, > for that cases the vendor should be able do document the > AGENT-CAPABILITIES for the implementation version or model > Fine, but I still believe that inconsistentValue would be the correct return. Beyond what RFC 3416 says, take the example of RowStatus from RFC 2579. In the state chart and notes on pages 9 and 10, the case most analogous to this is setting the status to "active" in state "b". The intent of "genErr" was as a catch-all for truly pathological cases. As I see it, this isn't one of them. > > 5. Delete the temporary row through an SNMP SET using > > DELETEdestroy(6). Temporary entries need not persist at > > reinitialization of the managed system." > > Optional persistence isn't helpful for interoperability. In this > particular case, it sounds like persistence would be inappropriate, > particularly given RFC 2579's page 16. > > Will be better to mandate non-persistence? That would be fine with me. > In any case temporary entries have no operational or configuration > meaning after the cloning process > is completed, All the more reason for them to not persist. > Perhaps: > > "Temporary entries SHOULD NOT persist at > reinitialization of the managed system." > I'd prefer MUST. Otherwise, RowStatus really isn't the right thing to use here. (One could argue that it isn't anyway.) ... > > MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the > > minimal implementation has no persistent requirement. Persistence > > makes sense only in the case of MAX-ACCESS read-write support. > > I don't understand how you come to this conclusion. > > > docsIfDownstreamChannelTable are configuration parameters, if SNMP is > read-only by compliance, > persistente IMHO is not a feature, Either the system uses defaults upon > reboot or the system > gather the parameters from a config file. (which is persistent but > outside the scope of SNMP) I disagree with this reasoning. It is perfectly reasonable for read-only management information to be persistent. An example would be a log entry. It is also perfectly reasonable for read-only information to be ephemeral. A time-of-day clock would be an example. > Requiring persisntece now will be a new requirement, for DOCSIS not in > RFC 2670 nor DOCSIS spec. > which should be considered for further work or send back the draft to > IPCDN group discussions for approval. > My comment is simply that the document needs to be clear, and that preventing a management system from being able to predict whether a managed device will be able to remember a configuration is probably not good for interoperability. Presumably the members of the WG know whether: - there has been any consistency among implementations here - whether interoperability has been impaired by this degree of freedom ... > > CHANGE # 7 > > docsIfDownstreamChannelEntry OBJECT-TYPE > ... > > The CMTS ability to retain SNMP SETs for read-write values after > > system reinitialization is implementation dependant." > > This is what StorageType is for. > > There is no read-create object for this table, it is also a ifTable > extension (for downstream interfaces ifType 128) > There is no need for there to be any writeable objects in a table with a StorageType object. One could also use a "capabilities" object outside the table to report whether this information can be retained. For an example of total over-engineering, one could have a single read-only BITS object with one bit for each of these tables, reporting whether the implementation maintains the data persistently. ... Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 14 13:30:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09089 for ; Wed, 14 Apr 2004 13:30:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo3W-0002Np-EY for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 13:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHKApb009159 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 13:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnrw-0007P8-VN; Wed, 14 Apr 2004 13:08:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnL8-0007FX-C8 for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 12:34: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 MAA04666 for ; Wed, 14 Apr 2004 12:34:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnL6-0005IG-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 12:34:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnK3-0005Dv-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 12:33:12 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BDnJV-00057u-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 12:32:37 -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 i3EGVp9V004403; Wed, 14 Apr 2004 10:32:05 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Wed, 14 Apr 2004 10:32:01 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQh5W1A9AOp7E8jTRGPGDZExJaMIgAQ7BMg From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable The patient merit is all yours More inline Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, April 13, 2004 10:13 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) Hi - Thanks Edo for the patient response! More inline below. > From: "Eduardo Cardona" > To: "Randy Presuhn" ; > Sent: Tuesday, April 13, 2004 6:25 PM > Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) ... > Options : > 5..8 a) as proposed (explicit vendor specific, not interoperable, with > the precendent of read-only compliances) > b) turn as MUST (new requirement: sent proposal back to IPCDN=20 > group and DOCSIS groups for approval) > c) leave silent as in RFC 2670 (not introduce changes 5..8) > > a) or b) will be my options, I started with a) due the b)=20 > implications. I, too, dislike option (c). I dislike option (a), particularly if the interoperability difficulties are not merely theoretical. I think there are at least three ways of accomplishing (b): - using the DESCRIPTION clause to mandate persistence behaviour - adding a (potentially read-only) StorageType to the row to indicate whether the information there will persist - adding a read-only scalar object to the MIB that reports whether the table persists. Perhaps that will be a good compromise, a read only scalar on relevant tables,=20 will propose the objects for relevant cases 5..8. -- From an SMI implementation POV I would rather prefer defining most of this 'capabilities' in the context of templates via device/model=20 AGENT-CAPABILITIES. What I recall is thatt this toolkit is not being used=20 intensively by vendors and Management applications (maybe I am wrong),=20 to top it off, there is no a VARIATION clause for objects persistence regardless of SWYNTAX,=20 then I gave up....=20 ... > > (a) and (b); > Not sure how (a)is put in context, docsIfCmtsModChannelType is a=20 > Configuration parameter. In some environments, SNMP is not the only possible configuration mechanism. For example, a CLI or netconf might be used to modify configuration data. Totally agree, didn't want to say that explicitely, due the lack of normalization model for configuration tools Coexistence. e.g spinlocks work for SNMP users collitions but are not extended to CLI or future netconf . Visualizing SNMP not as the facto core internal/storage data model implementation, and rather closed to CLI high level, I do not see relevance in dig a lot in updated values due CLI simultaneous operations. I believe from vendors POV CLI can override SNMP but not always the inverse, that's why try to avoid a) in the context of other management tools like CLI. I say stay with option b) as indicate in the alternatives previously=20 "An alternative:=20 1. If a modulation profile is being referenced by one or more upstream channels, an attempt to set the value of=20 docsIfCmtsModChannelType returns 'inconsistentValue' error. 2. If a modulation profile is being referenced by one or more upstream channels, an attempt to set docsIfCmtsModControl to destroy(6) or notInService(2) returns 'inconsistentValue' error. " ... > > CHANGE # 5 ... > (Even so, as a non-expert, it's still unclear to me what > this sentence is supposed to mean.) > > Agree, Although text current text was discussed discussed in the IPCDN > list back around October 10 to 15 (eventually closed to experts in the > topic) Since you're dealing with installed base, I'm not suggesting you change the way it works (if it has in fact proven to be interoperable). My comment is just that to the non-expert, this "clone-to" mechanism seems really bizarre. I could suggest much simpler ways to accomplish the goal, but that would not help maintain compatibility. Yes, it was introduced in draft 02 published almost two years ago. Perhaps having a set of scalars ( or a user profile (following one of your comments below) replicating the docsIfUpstreamChannelTable entries plus the cloneFrom and Update objects will look more sanitized, I guess the decision was taken back in that way. > > > 2. A status transition from active(1) to notInService(2) > > or destroy(6) is not permitted. > > ??? So how DOES one get rid of these things??? > > > By definition an entry with status active(1) is the extension if=20 > IfTable For interfaces ifType 129 or 205 - regular ifTable extension-=20 > Those are not deleted since are hardware dependant nor created by=20 > users, So, If I understand correctly, these things cannot be provisioned: one must wait for the hardware to be installed before doing any configuration, rather than setting up the parameters in advance. Correct...=20 > Only the non-related to ifTable interface entries ( used for clonning) > are created with CreateAndWait and the rules 4 and 5 apply I'd be nice if the distinction between these two entry types was made clearer. Will have another iteration today ... > > 3. ifAdminStatus from the Interface MIB RFC 2863 should be used to=20 > > take an Upstream Channel offline. > > I assume you mean "SHOULD". What other mechanisms > can take an Upstream Channel offline? > > Should replaced by SHOULD > No other SNMP mechanism is defined explicitely, > If I understood your request from the possibility of=20 > docsIfUpChannelStatus =3D notInService(2) Upstream channels=20 > docsIfUpChannelStatus only reports active(1) It might be better to avoid the question by replacing "should be" with "is". :-) sounds better, will do ... > The current compliance statement is hard to build since the Flavor (US > channel interface vs Cloning entry) Is the one with different=20 > connotation IfEntry extension read active(1) > No ifEntry extension: CreateAndWait(5), destroy(6) write This explanation was most helpful. I think your proposed explanation would be useful, but that it probably should go into BOTH the OBJECT and OBJECT-TYPE. Will replicate that ... > In RFC 2670 docsIfUpChannelEntries where read-write with optional=20 > read-only ( no row status), just simple extension of IfTable which are > Vendor dependant configured this extension entries are by default=20 > "always" Active(1) Oh. This "clone-to" stuff is new. I'm sorely tempted to propose a much tidier (I think) way to do it, but I don't wan't to be unduly disruptive at the -10- draft stage of work. See above, same reasons it is since draft 02, with clarified language in draft 09 ... > Will the proposed text plus the Object compliance makes that a bit=20 > clear? Your patient explanations make the intent much clearer. Thanks. That doesn't mean that I like it. :-) Your rights.... ... > > 1. Create a temporary row through an SNMP SET using=20 > > createAndWait(5). Use an ifIndex value outside the operational range > > of the system. > > How is the "operational range" determined? > > Out of scope, as the design was concern, you will point with all=20 > reasons that is not Good for interoperability > Will be a scalar with a suggested initial value an option? > it will goes beyond the closed for additions as we stand rigth now. One of the things one would hope to avoid is that a newly inserted interface gets a number that a management system is about to use for cloning. It's also hard to imagine how one could configure VACM to give different users access to different interfaces with this sort of scheme. This scheme also wouldn't provide any help at all in avoiding collisions (direct or indirect). (Two managers try to use the same row for clone-to, or worse still, two managers use different rows to clone-to the same interface.) I do not imagine an IfIndex VACM schema, being ifIndex an unique sub-oid. Or have to be done on an entry basis=20 The simplest thing that comes to mind, if I understand the requirements correctly, would be to put all the clone-to stuff into an AUGMENTS table, with a simple row "update" button to cause changes to be applied. That way it would be trivial to ensure that the access rights were properly restricted. However, I haven't been in on the discussion and the use cases, so I'm not making a proposal. For example, a "profile" mechanism might be a better fit. Yes a profile mechanism would be cleanest way -see above-=20 Although, I will not consider the collision something will ever happen from an operator policy perspective, rather a centralized policy manager to allow Upstream/downstream changes due the fact that may cause serious service disruption. Therefore, the MIB simplicity allows simple centralized poilicies, sort of Deny-all-/Allow-exclusive-=20 I know this is not the best architecture, but is reasonable as far as the IPDCN group concens. Perhaps a topic for a next MIB version.=20 =20 ... > > 4. Update the physical row by setting the object=20 > > docsIfUpChannelUpdate to true(1). This operation fails with error=20 > > genErr if the adjusted parameters are not compatible with each=20 > > other. > > My reading of RFC 3416 section 4.2.5 (10) is that inconsistentValue=20 > would be more appropriate. > I read inconsistenValue as values that in other circumstances will be > valid, > e.g setting to a row while active returns inconsistentValue error but if > the row is set to 'notInService' same set will success (RowStatus > constrains). > Here we had the problem that DOCSIS PHY parameters are broad and some > implementation MAC and or PHY may not support the whole range, > for that cases the vendor should be able do document the > AGENT-CAPABILITIES for the implementation version or model > Fine, but I still believe that inconsistentValue would be the correct return. Beyond what RFC 3416 says, take the example of RowStatus from RFC 2579. In the state chart and notes on pages 9 and 10, the case most analogous to this is setting the status to "active" in state "b". The intent of "genErr" was as a catch-all for truly pathological cases. As I see it, this isn't one of them. I see your point, lately I am more confused if follow RFC 3416 or other examples that may not concur with that. We took the aproach of catch all to leave the MAC/PHY layers implements freely their verification algorithms which may varies. 'InconsistentValue' can be used if no other outstanding opinion is presented.=20 > > 5. Delete the temporary row through an SNMP SET using=20 > > DELETEdestroy(6). Temporary entries need not persist at=20 > > reinitialization of the managed system." > > Optional persistence isn't helpful for interoperability. In this=20 > particular case, it sounds like persistence would be inappropriate,=20 > particularly given RFC 2579's page 16. > Will be better to mandate non-persistence? That would be fine with me. Will propose the change > In any case temporary entries have no operational or configuration=20 > meaning after the cloning process is completed, All the more reason for them to not persist. > Perhaps: > > "Temporary entries SHOULD NOT persist at > reinitialization of the managed system." > I'd prefer MUST. Otherwise, RowStatus really isn't the right thing to use here. (One could argue that it isn't anyway.) ... > > MIN-ACCESS read-only for docsIfDownstreamChannelTable implies the=20 > > minimal implementation has no persistent requirement. Persistence=20 > > makes sense only in the case of MAX-ACCESS read-write support. > > I don't understand how you come to this conclusion. > > > docsIfDownstreamChannelTable are configuration parameters, if SNMP is=20 > read-only by compliance, persistente IMHO is not a feature, Either the > system uses defaults upon reboot or the system > gather the parameters from a config file. (which is persistent but > outside the scope of SNMP) I disagree with this reasoning. It is perfectly reasonable for read-only management information to be persistent. An example would be a log entry. It is also perfectly reasonable for read-only information to be ephemeral. A time-of-day clock would be an example. Not disagree, as I said configuration parameters, logs, and time-of-day are status objects not configuration parameters. For the benefit of flat SNMP MIB introspection for persistence sa I said I can try to propose other storage Type objects for cases 5..8 as noted above > Requiring persisntece now will be a new requirement, for DOCSIS not in > RFC 2670 nor DOCSIS spec. which should be considered for further work=20 > or send back the draft to IPCDN group discussions for approval. > My comment is simply that the document needs to be clear, and that preventing a management system from being able to predict whether a managed device will be able to remember a configuration is probably not good for interoperability. Presumably the members of the WG know whether: - there has been any consistency among implementations here - whether interoperability has been impaired by this degree of freedom Any operator voice? ... > > CHANGE # 7 > > docsIfDownstreamChannelEntry OBJECT-TYPE > ... > > The CMTS ability to retain SNMP SETs for read-write values after=20 > > system reinitialization is implementation dependant." > > This is what StorageType is for. > > There is no read-create object for this table, it is also a ifTable=20 > extension (for downstream interfaces ifType 128) There is no need for there to be any writeable objects in a table with a StorageType object. One could also use a "capabilities" object outside the table to report whether this information can be retained. For an example of total over-engineering, one could have a single read-only BITS object with one bit for each of these tables, reporting whether the implementation maintains the data persistently. Any example or I assume all new MIB designs consider the StorageType by default. ... 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 exim@www1.ietf.org Wed Apr 14 13:43:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10238 for ; Wed, 14 Apr 2004 13:43:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDoNP-000823-3i for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 13:40:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EHehAn030852 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 13:40:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDo7G-0003ap-Fx; Wed, 14 Apr 2004 13:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDnyZ-0000Ag-K0 for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 13:15: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 NAA07461 for ; Wed, 14 Apr 2004 13:15:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDnyX-0000rM-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 13:15:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDnxi-0000pD-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 13:14:10 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 1BDnx9-0000lp-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 13:13:35 -0400 Received: from h-68-164-157-30.snvacaid.dynamic.covad.net ([68.164.157.30] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BDnx8-0002zF-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 10:13:35 -0700 Message-ID: <003801c42244$4c56e460$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Wed, 14 Apr 2004 10:17:00 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Eduardo Cardona" > To: "Randy Presuhn" ; > Sent: Wednesday, April 14, 2004 9:32 AM > Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) ... (lots of agreement, questions to the WG, and explanations deleted) ... >> There is no need for there to be any writeable objects in a table with a >> StorageType object. One could also use a "capabilities" object outside >> the table to report whether this information can be retained. For an >> example of total over-engineering, one could have a single read-only >> BITS object with one bit for each of these tables, reporting whether the >> implementation maintains the data persistently. > > Any example or I assume all new MIB designs consider the StorageType by > default. > > ... The work with which I am most familiar has been very explicit about persistence, either mandating it in DESCRIPTIONs or using StorageType to report / control it as needed. However, using a scalar to report capabilities, including persistance behaviour, has a long history, especially in the rmonmib working group. For an example chosen at random, see "hcAlarmCapabilities" in RFC 3434. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 14 14:45:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14088 for ; Wed, 14 Apr 2004 14:45:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDpBp-0005dS-Kd for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 14:32:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EIWncr021651 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 14:32:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDozZ-0002b8-Ar; Wed, 14 Apr 2004 14:20:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDorr-00009I-US for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 14:12: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 OAA12194 for ; Wed, 14 Apr 2004 14:12:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDorp-0005KH-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 14:12:09 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDoqw-0005I6-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 14:11:15 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BDoqc-0005FA-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 14:10:54 -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 i3EIAM9T025031; Wed, 14 Apr 2004 12:10: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: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Wed, 14 Apr 2004 12:10:22 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQiR6j34Y9qLN7+TxalyhIBwkKXiQAAZu1A From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Thanks,=20 I though it was a either StorageType support or capabilities. I see how the combination of both StorageType and Capabilities in RFC 3434 defines all options with the advantage of a short COMPLIANCE statement. Although the solution work, I see more (theoretical) advantages in the AGENT-CAPABILITIES variation if broadly adopted and implemented ( I doubt not) to solve the problem at the class (SMI) level rather than at the managed object level. I mean supporting VARIATION clauses that update dynamically the Device profile Object model and operations to execute (expose) rather than having the management application writing code on a MIB table basis to discover them.=20 It is not fat to be a trade-off dilemma I will try to came up with a revision of the proposed changes based on all the feedback. If anyone else has comments, please post the list =20 Eduardo =20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Wednesday, April 14, 2004 11:17 AM To: ipcdn@ietf.org Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) Hi - > From: "Eduardo Cardona" > To: "Randy Presuhn" ; > Sent: Wednesday, April 14, 2004 9:32 AM > Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) ... (lots of agreement, questions to the WG, and explanations deleted) ... >> There is no need for there to be any writeable objects in a table=20 >> with a StorageType object. One could also use a "capabilities"=20 >> object outside the table to report whether this information can be=20 >> retained. For an example of total over-engineering, one could have a=20 >> single read-only BITS object with one bit for each of these tables,=20 >> reporting whether the implementation maintains the data persistently. > > Any example or I assume all new MIB designs consider the StorageType=20 > by default. > > ... The work with which I am most familiar has been very explicit about persistence, either mandating it in DESCRIPTIONs or using StorageType to report / control it as needed. However, using a scalar to report capabilities, including persistance behaviour, has a long history, especially in the rmonmib working group. For an example chosen at random, see "hcAlarmCapabilities" in RFC 3434. 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 exim@www1.ietf.org Wed Apr 14 17:39:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29059 for ; Wed, 14 Apr 2004 17:39:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrsL-00083t-SP for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 17:24:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3ELOrfh030986 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 17:24:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrgq-0002hD-Ps; Wed, 14 Apr 2004 17:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDrNK-0003K0-Pu for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 16:52:51 -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 QAA25132 for ; Wed, 14 Apr 2004 16:52:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDrNI-0002ei-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 16:52:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDrMT-0002ZN-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 16:51:57 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1BDrLf-0002R2-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 16:51:07 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 14 Apr 2004 13:50:47 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i3EKoZiM020138; Wed, 14 Apr 2004 13:50:35 -0700 (PDT) Received: from cisco.com (sjc-vpn3-341.cisco.com [10.21.65.85]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ASZ50650; Wed, 14 Apr 2004 13:50:33 -0700 (PDT) Message-ID: <407DA419.6090605@cisco.com> Date: Wed, 14 Apr 2004 13:50:33 -0700 From: Azlina Ahmad Reply-To: azlina@cisco.com Organization: CIsco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Cardona CC: Donati Andrew-MGIA0477 , ipcdn@ietf.org Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit In general, how would we avoid storing a 'bad' configuration? For example: User might create an notInService entry and set the storageType to nonVolatile (persistent across reload). And while its in Status of notInService, the columnar values are not validated. Change #2: : "Initial default entries ....., which could report for a value 'permanent' or 'readOnly' for docsIfCmtsModStorageType. A CMTS may not allow the creation of additional Interval ....." [AZ] I found the above to be confusing: Can we reword it to: "Initial default entries may be created at system intialization time by defaulting the docsIfCmtsModStorageType value to 'permanent(4)' or 'readOnly(5). Change #3: : : Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects ..." [AZ] Since the definition of 'permanent(4)' mentioned that a row can be changed but not deleted, I don't think we need to repeat the statement above. Thanks, Azlina Eduardo Cardona wrote: > Hi Andrew, all, > > Please review the attached with the proposed changes for the StorageType > issues to see of they cover all concerns. > > In summary, there are eight proposed changes > > Changes 1,2,3,4 are related to the issue brough by Andrew Donati by > adding StorageType object to the Modulation profile table > > Changes 5,6,7,8 are clarifications to accommodate the OPS MIB revision > guidelines sections 4.6.2 and 4.6.4, quite related to the problem raised > for the storageType case. > > During the WG Last call for technical issues, there were no other items > pointing our attention. > > Let the WG know any question or comments by COB Wednesday before > submiting the draft to IETF. > > > Eduardo _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 14 18:45:02 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03733 for ; Wed, 14 Apr 2004 18:45:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDt0R-0002RW-15 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 18:37:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EMbI8t009383 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 18:37:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDswG-0001DO-Vs; Wed, 14 Apr 2004 18:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDsrJ-0008Qf-8I for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 18:27: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 SAA03091 for ; Wed, 14 Apr 2004 18:27:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDsrG-0002PK-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 18:27:50 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDsqV-0002Lo-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 18:27:04 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BDspy-0002GN-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 18:26:30 -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 i3EMPm9T018309; Wed, 14 Apr 2004 16:25:48 -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] Changes for next RFI v2 MIB (draft 10) Date: Wed, 14 Apr 2004 16:25:48 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQiYif/wRLW0bFkRo+946vi62T4VAABmpaQ From: "Eduardo Cardona" To: Cc: "Donati Andrew-MGIA0477" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Azlina, see inline, Eduardo -----Original Message----- From: Azlina Ahmad [mailto:azlina@cisco.com]=20 Sent: Wednesday, April 14, 2004 2:51 PM To: Eduardo Cardona Cc: Donati Andrew-MGIA0477; ipcdn@ietf.org Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) In general, how would we avoid storing a 'bad' configuration? For example: User might create an notInService entry and set the storageType to nonVolatile (persistent across reload). And while its in Status of=20 notInService, the columnar values are not validated. Is that a bad configuration or a temporary held offline configuration? Bad configuration is 'notReady'=20 'notInService' could be : a createAndWait with complete setup but deferred set 'active' an entry previously 'active' set to 'notInService' I believe the StorageType object carries the RowStatus values before the reset, leaving to the operator=20 The responsibility to have the house clean. :) Change #2: : "Initial default entries ....., which could report for a value 'permanent' or 'readOnly' for docsIfCmtsModStorageType. A CMTS may not allow the creation of additional Interval ....." [AZ] I found the above to be confusing: Can we reword it to: "Initial default entries may be created at system intialization time by defaulting the docsIfCmtsModStorageType value to 'permanent(4)' or 'readOnly(5). After Randy's comments the definition says:=20 =20 Initial default entries MAY be created at system=20 initialization time which could report for a value=20 'permanent' or 'readOnly' for docsIfCmtsModStorageType. A CMTS MAY allow the creation of additional Interval Usage Codes for a modulation profile being defined at=20 Initialization time. Will add yours to become: Initial default entries MAY be created at system=20 initialization time by defaulting the=20 docsIfCmtsModStorageType value to permanent(4) or=20 readOnly(5). A CMTS MAY allow the creation of additional Interval Usage Codes for a modulation profile being defined at=20 Initialization time. Change #3: : : Conceptual rows having the value 'permanent' need not allow write-access to any columnar objects ..." [AZ] Since the definition of 'permanent(4)' mentioned that a row can be changed but not deleted, I don't think we need to repeat the statement above. There are two definitions: Effective read-write columnar values in a row which has a StorageType 'permananent'=20 'permanent' Can be written and last value will be back up after reset. The not writable property in the TC description is for the StorageType=20 I guess the only difference within nonVolatile and 'permanent' is that you may not create 'permanent' entries via SNMP but could modified existing 'permanent' entries, while 'nonVolatile' entries can be created via SNMP, deleted and even and turn later to 'volatile'. What the text is trying to say is that behaves as a 'readOnly' but TC refers to=20 readOnly as a ROM (fully) implementation which is not always the case,=20 So many RFCs uses this phrase to indicate that the storage realization may be=20 Partially ROM (what's that? EEPROM? ) instead of fully ROM but behaves as readOnly,=20 (unchangeable), mainly for the difficult to implement a 'permanent' entry that is=20 persistent and writable. Or a code initialized value ("ROM") but conditioned to further updates (code with NVRAM hooks i.e.)=20 Not that I like to go to all these compliances formalism but probably necessary. It leaves also the vendors freedom to handle the 'permanent' cases read-only or read-write Being dual read-only or read-write is probably another point for interoperability problems due the ambiguous definition. I guess is being accepted as a generalization of permanent -> being likely 'readOnly'=20 without state the ROM implications by TC definitions. Not something I am very concern. Thanks, Azlina Eduardo Cardona wrote: > Hi Andrew, all, >=20 > Please review the attached with the proposed changes for the=20 > StorageType issues to see of they cover all concerns. >=20 > In summary, there are eight proposed changes >=20 > Changes 1,2,3,4 are related to the issue brough by Andrew Donati by=20 > adding StorageType object to the Modulation profile table >=20 > Changes 5,6,7,8 are clarifications to accommodate the OPS MIB revision > guidelines sections 4.6.2 and 4.6.4, quite related to the problem=20 > raised for the storageType case. >=20 > During the WG Last call for technical issues, there were no other=20 > items pointing our attention. >=20 > Let the WG know any question or comments by COB Wednesday before=20 > submiting the draft to IETF. >=20 >=20 > Eduardo _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Apr 14 19:18:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05021 for ; Wed, 14 Apr 2004 19:18:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtVS-0002RL-VQ for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 19:09:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3EN9MET009367 for ipcdn-archive@odin.ietf.org; Wed, 14 Apr 2004 19:09:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtSD-0001AR-Mk; Wed, 14 Apr 2004 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BDtOz-0000Ni-Gb for ipcdn@optimus.ietf.org; Wed, 14 Apr 2004 19:02: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 TAA04555 for ; Wed, 14 Apr 2004 19:02:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BDtOw-000489-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 19:02:38 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BDtO2-00044P-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 19:01:42 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BDtN6-0003xN-00 for ipcdn@ietf.org; Wed, 14 Apr 2004 19:00:44 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 Apr 2004 15:09:28 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3EN0C2O017569; Wed, 14 Apr 2004 16:00:12 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-69-114-166.cisco.com [171.69.114.166]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ASZ68168; Wed, 14 Apr 2004 16:00:10 -0700 (PDT) Message-Id: <4.3.2.7.2.20040414155527.02f9eef8@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Apr 2004 16:00:10 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Cc: , milu@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi. Eduardo, Thanks for efforts to make this MIB better. > A CMTS may not allow the creation of additional Interval Usage Codes > for a modulation profile being defined at Initialization time. Does "may not" here mean "MUST NOT" or "MAY"? A bit clear saying : "A CMTS MAY allow...." ... I think it is 'A CMTS MAY NOT allow ...." In the ECN OSSIv2.0-N-04.0121, The CMTS MAY have pre-defined modulation profiles (entries in the DOCS-IF-MIB docsIfCmtsModulationTable) with the purpose of being used by operators as is or as templates to define other modulation profiles. CMTS pre-defined modulation profiles entries MAY be read-only to prevent users from accidental modifications. Adding or creating entries with new docsIfCmtsModIntervalUsageCode values and the same docsIfCmtsModIndex values as the pre-defined modulation profiles MAY result in error. Thanks a lot ! Minnie At 07:25 PM 4/13/2004 -0600, Eduardo Cardona wrote: > > A CMTS may not allow the creation of additional Interval Usage Codes > > for a modulation profile being defined at Initialization time. > >Does "may not" here mean "MUST NOT" or "MAY"? > >A bit clear saying : >"A CMTS MAY allow...." > >... _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 06:56:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16483 for ; Thu, 15 Apr 2004 06:56:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4Vt-0004Yu-HD for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 06:54:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FAsXif017529 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 06:54:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4RV-0003Fm-Tn; Thu, 15 Apr 2004 06:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE4Mf-0001mQ-9f for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 06:45:01 -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 GAA16223 for ; Thu, 15 Apr 2004 06:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE4Mb-0003lh-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 06:44:57 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE4Ld-0003ha-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 06:43:57 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BE4Kh-0003au-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 06:42:59 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3FAgK9T014966; Thu, 15 Apr 2004 04:42:21 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C422D6.5434752A" Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 04:42:20 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQidEWEQnHKsmXZQJOtw9Rg2KXTKwAXPkqM From: "Eduardo Cardona" To: "Minnie Lu" Cc: , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C422D6.5434752A Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlubmllLCANCiANCklmIEkgdW5kZXJzdGFuZCB0aGUgaW50aWFsIFJhbmR5J3MgY29tbWVu dCwgUkZDIDIxMTkgZGVmaW5lcyBNQVkgYW5kIE9QVElPTkFMIGFzICJ0cnVseSBvcHRpb25hbCIu IEluIGEgZ2VuZXJhbCBjb250ZXh0ICJNQVkiIGFuZCAiTUFZIE5PVCIgYmVjb21lcyB0aGUgc2Ft ZS4gTm90IGJlaW5nICJNQVkgTk9UIiBhbiBJRVRGIGtleXdvcmQsIEkgc2VlIHRoZSBNSUIgZG9j dG9ycyByZWx1Y3RhbmNlIHRvIHVzZSBpdC4NCiANCkluIHRoZSBvdGhlciBoYW5kLCB0aGUgcmVh c29uIGZvciB0aGUgZGVmYXVsdCBlbnRyaWVzIGlzIGEgdmVuZG9yIGZlYXR1cmUgb3V0c2lkZSB0 aGUgc3BlYyByZXF1aXJlbWVudHMuIEluIHRoZSB2ZW5kb3Igc2lkZSwgdGhpcyBmZWF0dXJlIHdv dWxkIG1ha2Ugc2Vuc2UgdG8gInJlcXVpcmUiICh2ZW5kb3IgZGVzaWduICAtIG5vdCBzcGVjIHJl cXVpcmVtZW50KQ0KIC0gU0hPVUxEIGJlIHJlYWQtb25seQ0KIC0gU0hPVUxEIE5PVCBjcmVhdGUg bmV3IEludGVydmFsIFVzYWdlIENvZGVzLg0KIA0KQW5vdGhlciB2ZW5kb3IgbWF5IG9wdCB0byBv ZmZlciBkZWZhdWx0IGVudHJpZXMgYXMgImN1c3RvbSIgZW50cmllcyB3aGljaCBtYXkgYmUgbm9u Vm9sYXRpbGUgYW5kIGFkanVzdGFibGUgb3IgcmVtb3ZlZCAgYXMgcGFydCBvZiBhIGZhY3Rvcnkg Y29uZmlndXJhdGlvbiwgdGhhdCdzIHdoeSBJIHRoaW5rIHRoYXQgc2hvbGQgYmUgbGV2ZSBpbiBj b250ZXh0IGFzIGluZm9ybWF0aW9uYWwuIA0KIA0KSW4gc3BlYyB3b3JkcyB0aGUgb3B0aW9uYWwg TUFZIG1ha2UgdGhvc2UgdmVuZG9yIHJlcXVpcmVtZW50cyBpbmZvcm1hdGlvbmFsLCBpbiBmYWN0 IHRoZSBFQ04gc2F5cyB0aGUgY3JlYXRpb24gb2YgSVVDcyAiTUFZIHJlc3VsdCBpbiBlcnJvciIs IHdoaWNoIGlzIG1lcmUgaW5mb3JtYXRpb25hbC4NCiANCnRyeWluZyB0byBhdm9pZCB0aGUgIk1B WSBOT1QiICBpZiBwb3NzaWJsZSwgDQogDQoNCiAgICAgICAgICAgICBJbml0aWFsIGRlZmF1bHQg ZW50cmllcyBNQVkgYmUgY3JlYXRlZCBhdCBzeXN0ZW0gDQoNCiAgICAgICAgICAgICBpbml0aWFs aXphdGlvbiB0aW1lIHdoaWNoIGNvdWxkIHJlcG9ydCBmb3IgYSB2YWx1ZSANCg0KICAgICAgICAg ICAgICdwZXJtYW5lbnQnIG9yICdyZWFkT25seScgZm9yIGRvY3NJZkNtdHNNb2RTdG9yYWdlVHlw ZS4NCg0KICAgICAgICAgICAgIEEgQ01UUyBNQVkgcmVzdHJpY3QgdGhlIGNyZWF0aW9uIG9mIGFk ZGl0aW9uYWwgSW50ZXJ2YWwNCg0KICAgICAgICAgICAgIFVzYWdlIENvZGVzIGZvciBhIG1vZHVs YXRpb24gcHJvZmlsZSBiZWluZyBkZWZpbmVkIGF0IA0KDQogICAgICAgICAgICAgSW5pdGlhbGl6 YXRpb24gdGltZS4NCg0KIA0KVGhhbmtzDQpFZHVhcmRvDQogDQogDQogDQogDQogDQoNCgktLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBNaW5uaWUgTHUgW21haWx0bzptaWx1QGNp c2NvLmNvbV0gDQoJU2VudDogV2VkIDQvMTQvMjAwNCA1OjAwIFBNIA0KCVRvOiBFZHVhcmRvIENh cmRvbmEgDQoJQ2M6IGlwY2RuQGlldGYub3JnOyBtaWx1QGNpc2NvLmNvbSANCglTdWJqZWN0OiBS RTogW2lwY2RuXSBDaGFuZ2VzIGZvciBuZXh0IFJGSSB2MiBNSUIgKGRyYWZ0IDEwKQ0KCQ0KCQ0K DQoJSGkuIEVkdWFyZG8sDQoJDQoJVGhhbmtzIGZvciBlZmZvcnRzIHRvIG1ha2UgdGhpcyBNSUIg YmV0dGVyLg0KCQ0KCSA+IEEgQ01UUyBtYXkgbm90IGFsbG93IHRoZSBjcmVhdGlvbiBvZiBhZGRp dGlvbmFsIEludGVydmFsIFVzYWdlIENvZGVzDQoJID4gZm9yIGEgbW9kdWxhdGlvbiBwcm9maWxl IGJlaW5nIGRlZmluZWQgYXQgSW5pdGlhbGl6YXRpb24gdGltZS4NCgkNCglEb2VzICJtYXkgbm90 IiBoZXJlIG1lYW4gIk1VU1QgTk9UIiBvciAiTUFZIj8NCgk8ZWRvPg0KCUEgYml0IGNsZWFyIHNh eWluZyA6DQoJIkEgQ01UUyBNQVkgYWxsb3cuLi4uIg0KCTwvZWRvPg0KCS4uLg0KCUkgdGhpbmsg aXQgaXMgJ0EgQ01UUyBNQVkgTk9UIGFsbG93IC4uLi4iICBJbiB0aGUgRUNOIE9TU0l2Mi4wLU4t MDQuMDEyMSwNCglUaGUgQ01UUyBNQVkgaGF2ZSBwcmUtZGVmaW5lZCBtb2R1bGF0aW9uIHByb2Zp bGVzIChlbnRyaWVzIGluIHRoZSBET0NTLUlGLU1JQg0KCWRvY3NJZkNtdHNNb2R1bGF0aW9uVGFi bGUpIHdpdGggdGhlIHB1cnBvc2Ugb2YgYmVpbmcgdXNlZCBieQ0KCW9wZXJhdG9ycyBhcyBpcyBv ciBhcyB0ZW1wbGF0ZXMgdG8gZGVmaW5lIG90aGVyIG1vZHVsYXRpb24gcHJvZmlsZXMuIENNVFMN CglwcmUtZGVmaW5lZCBtb2R1bGF0aW9uIHByb2ZpbGVzIGVudHJpZXMgTUFZIGJlIHJlYWQtb25s eSB0byBwcmV2ZW50IHVzZXJzDQoJZnJvbSBhY2NpZGVudGFsIG1vZGlmaWNhdGlvbnMuIEFkZGlu ZyBvciBjcmVhdGluZyBlbnRyaWVzIHdpdGggbmV3DQoJZG9jc0lmQ210c01vZEludGVydmFsVXNh Z2VDb2RlIHZhbHVlcyBhbmQgdGhlIHNhbWUgZG9jc0lmQ210c01vZEluZGV4DQoJdmFsdWVzIGFz IHRoZSBwcmUtZGVmaW5lZCBtb2R1bGF0aW9uIHByb2ZpbGVzIE1BWSByZXN1bHQgaW4gZXJyb3Iu DQoJDQoJVGhhbmtzIGEgbG90ICENCglNaW5uaWUNCgkNCglBdCAwNzoyNSBQTSA0LzEzLzIwMDQg LTA2MDAsIEVkdWFyZG8gQ2FyZG9uYSB3cm90ZToNCgkNCgk+ID4gQSBDTVRTIG1heSBub3QgYWxs b3cgdGhlIGNyZWF0aW9uIG9mIGFkZGl0aW9uYWwgSW50ZXJ2YWwgVXNhZ2UgQ29kZXMNCgk+ID4g Zm9yIGEgbW9kdWxhdGlvbiBwcm9maWxlIGJlaW5nIGRlZmluZWQgYXQgSW5pdGlhbGl6YXRpb24g dGltZS4NCgk+DQoJPkRvZXMgIm1heSBub3QiIGhlcmUgbWVhbiAiTVVTVCBOT1QiIG9yICJNQVki Pw0KCT48ZWRvPg0KCT5BIGJpdCBjbGVhciBzYXlpbmcgOg0KCT4iQSBDTVRTIE1BWSBhbGxvdy4u Li4iDQoJPjwvZWRvPg0KCT4uLi4NCgkNCgkNCg0K ------_=_NextPart_001_01C422D6.5434752A Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5SRTogW2lwY2RuXSBDaGFu Z2VzIGZvciBuZXh0IFJGSSB2MiBNSUIgKGRyYWZ0IDEwKTwvVElUTEU+CjwvSEVBRD4KPEJPRFkg ZGlyPWx0cj4KPERJVj5IaSBNaW5uaWUsIDwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPklm IEkgdW5kZXJzdGFuZCB0aGUgaW50aWFsIFJhbmR5J3MgY29tbWVudCwgUkZDIDIxMTkgZGVmaW5l cyBNQVkgYW5kIApPUFRJT05BTCZuYnNwO2FzICJ0cnVseSBvcHRpb25hbCIuIEluIGEgZ2VuZXJh bCBjb250ZXh0ICJNQVkiIGFuZCAiTUFZIE5PVCIgCmJlY29tZXMgdGhlIHNhbWUuJm5ic3A7Tm90 IGJlaW5nICJNQVkgTk9UIiBhbiBJRVRGIGtleXdvcmQsIEkgc2VlIHRoZSBNSUIgCmRvY3RvcnMg cmVsdWN0YW5jZSB0byB1c2UgaXQuPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+SW4gdGhl IG90aGVyIGhhbmQsJm5ic3A7dGhlIHJlYXNvbiBmb3IgdGhlIGRlZmF1bHQgZW50cmllcyBpcyBh IHZlbmRvciAKZmVhdHVyZSBvdXRzaWRlIHRoZSBzcGVjIHJlcXVpcmVtZW50cy4gSW4gdGhlIHZl bmRvciBzaWRlLCB0aGlzJm5ic3A7ZmVhdHVyZSAKd291bGQgbWFrZSZuYnNwO3NlbnNlIHRvICJy ZXF1aXJlIiAodmVuZG9yIGRlc2lnbiZuYnNwOyAtIG5vdCBzcGVjIApyZXF1aXJlbWVudCk8L0RJ Vj4KPERJVj4mbmJzcDstIFNIT1VMRCBiZSByZWFkLW9ubHk8L0RJVj4KPERJVj4mbmJzcDstIFNI T1VMRCBOT1QgY3JlYXRlIG5ldyBJbnRlcnZhbCBVc2FnZSBDb2Rlcy48L0RJVj4KPERJVj4mbmJz cDs8L0RJVj4KPERJVj5Bbm90aGVyIHZlbmRvciBtYXkgb3B0IHRvIG9mZmVyIGRlZmF1bHQgZW50 cmllcyBhcyAiY3VzdG9tIiBlbnRyaWVzIHdoaWNoIAptYXkgYmUgbm9uVm9sYXRpbGUgYW5kIGFk anVzdGFibGUgb3IgcmVtb3ZlZCZuYnNwOyBhcyBwYXJ0IG9mIGEgZmFjdG9yeSAKY29uZmlndXJh dGlvbiwgdGhhdCdzIHdoeSBJIHRoaW5rIHRoYXQgc2hvbGQgYmUgbGV2ZSBpbiBjb250ZXh0IGFz IAppbmZvcm1hdGlvbmFsLiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkluIHNw ZWMgd29yZHMgdGhlIG9wdGlvbmFsIE1BWSBtYWtlIHRob3NlIHZlbmRvciByZXF1aXJlbWVudHMg CmluZm9ybWF0aW9uYWwsIGluIGZhY3QgdGhlIEVDTiBzYXlzIHRoZSBjcmVhdGlvbiBvZiBJVUNz ICJNQVkgcmVzdWx0IGluIGVycm9yIiwgCndoaWNoIGlzIG1lcmUgaW5mb3JtYXRpb25hbC48L0RJ Vj4KPERJVj4mbmJzcDs8L0RJVj4KPERJVj50cnlpbmcgdG8gYXZvaWQgdGhlICJNQVkgTk9UIiAm bmJzcDtpZiBwb3NzaWJsZSwgPC9ESVY+CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+CjxQIGNsYXNz PU1zb1BsYWluVGV4dCBzdHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAtNC41cHQiPjxTUEFOIApz dHlsZT0iQkFDS0dST1VORDogd2hpdGU7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnTVMgTWlu Y2hvJyI+PEZPTlQgCnNpemU9Mj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gCnN0eWxl PSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7PC9TUEFOPjxTUEFOIApzdHlsZT0ibXNvLXNwYWNl cnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAKPC9TUEFOPjxTUEFOIHN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5ic3A7Jm5i c3A7PC9TUEFOPkluaXRpYWwgZGVmYXVsdCAKZW50cmllcyBNQVkgYmUgY3JlYXRlZCBhdCBzeXN0 ZW0gPD94bWw6bmFtZXNwYWNlIHByZWZpeCA9IG8gbnMgPSAKInVybjpzY2hlbWFzLW1pY3Jvc29m dC1jb206b2ZmaWNlOm9mZmljZSIgLz48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPjwv UD4KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IC00LjVw dCI+PFNQQU4gCnN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsgbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6ICdNUyBNaW5jaG8nIj48Rk9OVCAKc2l6ZT0yPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48 U1BBTiAKc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCjwvU1BBTj5p bml0aWFsaXphdGlvbiB0aW1lIHdoaWNoIGNvdWxkIHJlcG9ydCBmb3IgYSB2YWx1ZSAKPG86cD48 L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHls ZT0iTUFSR0lOOiAwaW4gMGluIDBwdCAtNC41cHQiPjxTUEFOIApzdHlsZT0iQkFDS0dST1VORDog d2hpdGU7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnTVMgTWluY2hvJyI+PEZPTlQgCnNpemU9 Mj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gCnN0eWxlPSJtc28tc3BhY2VydW46IHll cyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IAo8L1NQQU4+J3Blcm1hbmVudCcgb3IgJ3JlYWRPbmx5JyBmb3Ig CmRvY3NJZkNtdHNNb2RTdG9yYWdlVHlwZS48bzpwPjwvbzpwPjwvRk9OVD48L0ZPTlQ+PC9TUEFO PjwvUD4KPFAgY2xhc3M9TXNvUGxhaW5UZXh0IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IC00 LjVwdCI+PFNQQU4gCnN0eWxlPSJCQUNLR1JPVU5EOiB3aGl0ZTsgbXNvLWZhcmVhc3QtZm9udC1m YW1pbHk6ICdNUyBNaW5jaG8nIj48Rk9OVCAKc2l6ZT0yPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3 Ij48U1BBTiAKc3R5bGU9Im1zby1zcGFjZXJ1bjogeWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgCjwvU1BBTj48U1BB TiBzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOzwvU1BBTj5BIENNVFMgTUFZIHJlc3Ry aWN0Jm5ic3A7dGhlIApjcmVhdGlvbiBvZiBhZGRpdGlvbmFsIEludGVydmFsPG86cD48L286cD48 L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+CjxQIGNsYXNzPU1zb1BsYWluVGV4dCBzdHlsZT0iTUFS R0lOOiAwaW4gMGluIDBwdCAtNC41cHQiPjxTUEFOIApzdHlsZT0iQkFDS0dST1VORDogd2hpdGU7 IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiAnTVMgTWluY2hvJyI+PEZPTlQgCnNpemU9Mj48Rk9O VCBmYWNlPSJDb3VyaWVyIE5ldyI+PFNQQU4gCnN0eWxlPSJtc28tc3BhY2VydW46IHllcyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IAo8L1NQQU4+VXNhZ2UgQ29kZXMgZm9yIGEgbW9kdWxhdGlvbiBwcm9maWxl IGJlaW5nIGRlZmluZWQgYXQgCjxvOnA+PC9vOnA+PC9GT05UPjwvRk9OVD48L1NQQU4+PC9QPgo8 UCBjbGFzcz1Nc29QbGFpblRleHQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQgLTQuNXB0Ij48 U1BBTiAKc3R5bGU9IkJBQ0tHUk9VTkQ6IHdoaXRlOyBtc28tZmFyZWFzdC1mb250LWZhbWlseTog J01TIE1pbmNobyciPjxGT05UIApzaXplPTI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPjxTUEFO IApzdHlsZT0ibXNvLXNwYWNlcnVuOiB5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAKPC9TUEFOPkluaXRp YWxpemF0aW9uIHRpbWUuPG86cD48L286cD48L0ZPTlQ+PC9GT05UPjwvU1BBTj48L1A+PC9ESVY+ CjxESVY+Jm5ic3A7PC9ESVY+CjxESVY+VGhhbmtzPC9ESVY+CjxESVY+RWR1YXJkbzwvRElWPgo8 RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElW PiZuYnNwOzwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8QkxPQ0tRVU9URSBkaXI9bHRyIHN0eWxl PSJNQVJHSU4tUklHSFQ6IDBweCI+CiAgPERJVj48Rk9OVCBzaXplPTI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0gPEJSPjxCPkZyb206PC9CPiBNaW5uaWUgTHUgCiAgW21haWx0bzptaWx1QGNp c2NvLmNvbV0gPEJSPjxCPlNlbnQ6PC9CPiBXZWQgNC8xNC8yMDA0IDU6MDAgUE0gPEJSPjxCPlRv OjwvQj4gCiAgRWR1YXJkbyBDYXJkb25hIDxCUj48Qj5DYzo8L0I+IGlwY2RuQGlldGYub3JnOyBt aWx1QGNpc2NvLmNvbSAKICA8QlI+PEI+U3ViamVjdDo8L0I+IFJFOiBbaXBjZG5dIENoYW5nZXMg Zm9yIG5leHQgUkZJIHYyIE1JQiAoZHJhZnQgCiAgMTApPEJSPjxCUj48L0ZPTlQ+PC9ESVY+CiAg PFA+PEZPTlQgc2l6ZT0yPkhpLiBFZHVhcmRvLDxCUj48QlI+VGhhbmtzIGZvciBlZmZvcnRzIHRv IG1ha2UgdGhpcyBNSUIgCiAgYmV0dGVyLjxCUj48QlI+Jm5ic3A7Jmd0OyBBIENNVFMgbWF5IG5v dCBhbGxvdyB0aGUgY3JlYXRpb24gb2YgYWRkaXRpb25hbCAKICBJbnRlcnZhbCBVc2FnZSBDb2Rl czxCUj4mbmJzcDsmZ3Q7IGZvciBhIG1vZHVsYXRpb24gcHJvZmlsZSBiZWluZyBkZWZpbmVkIGF0 IAogIEluaXRpYWxpemF0aW9uIHRpbWUuPEJSPjxCUj5Eb2VzICJtYXkgbm90IiBoZXJlIG1lYW4g Ik1VU1QgTk9UIiBvciAKICAiTUFZIj88QlI+Jmx0O2VkbyZndDs8QlI+QSBiaXQgY2xlYXIgc2F5 aW5nIDo8QlI+IkEgQ01UUyBNQVkgCiAgYWxsb3cuLi4uIjxCUj4mbHQ7L2VkbyZndDs8QlI+Li4u PEJSPkkgdGhpbmsgaXQgaXMgJ0EgQ01UUyBNQVkgTk9UIGFsbG93IAogIC4uLi4iJm5ic3A7IElu IHRoZSBFQ04gT1NTSXYyLjAtTi0wNC4wMTIxLDxCUj5UaGUgQ01UUyBNQVkgaGF2ZSBwcmUtZGVm aW5lZCAKICBtb2R1bGF0aW9uIHByb2ZpbGVzIChlbnRyaWVzIGluIHRoZSBET0NTLUlGLU1JQjxC Uj5kb2NzSWZDbXRzTW9kdWxhdGlvblRhYmxlKSAKICB3aXRoIHRoZSBwdXJwb3NlIG9mIGJlaW5n IHVzZWQgYnk8QlI+b3BlcmF0b3JzIGFzIGlzIG9yIGFzIHRlbXBsYXRlcyB0byBkZWZpbmUgCiAg b3RoZXIgbW9kdWxhdGlvbiBwcm9maWxlcy4gQ01UUzxCUj5wcmUtZGVmaW5lZCBtb2R1bGF0aW9u IHByb2ZpbGVzIGVudHJpZXMgTUFZIAogIGJlIHJlYWQtb25seSB0byBwcmV2ZW50IHVzZXJzPEJS PmZyb20gYWNjaWRlbnRhbCBtb2RpZmljYXRpb25zLiBBZGRpbmcgb3IgCiAgY3JlYXRpbmcgZW50 cmllcyB3aXRoIG5ldzxCUj5kb2NzSWZDbXRzTW9kSW50ZXJ2YWxVc2FnZUNvZGUgdmFsdWVzIGFu ZCB0aGUgCiAgc2FtZSBkb2NzSWZDbXRzTW9kSW5kZXg8QlI+dmFsdWVzIGFzIHRoZSBwcmUtZGVm aW5lZCBtb2R1bGF0aW9uIHByb2ZpbGVzIE1BWSAKICByZXN1bHQgaW4gZXJyb3IuPEJSPjxCUj5U aGFua3MgYSBsb3QgITxCUj5NaW5uaWU8QlI+PEJSPkF0IDA3OjI1IFBNIDQvMTMvMjAwNCAKICAt MDYwMCwgRWR1YXJkbyBDYXJkb25hIHdyb3RlOjxCUj48QlI+Jmd0OyAmZ3Q7IEEgQ01UUyBtYXkg bm90IGFsbG93IHRoZSAKICBjcmVhdGlvbiBvZiBhZGRpdGlvbmFsIEludGVydmFsIFVzYWdlIENv ZGVzPEJSPiZndDsgJmd0OyBmb3IgYSBtb2R1bGF0aW9uIAogIHByb2ZpbGUgYmVpbmcgZGVmaW5l ZCBhdCBJbml0aWFsaXphdGlvbiB0aW1lLjxCUj4mZ3Q7PEJSPiZndDtEb2VzICJtYXkgbm90IiAK ICBoZXJlIG1lYW4gIk1VU1QgTk9UIiBvciAiTUFZIj88QlI+Jmd0OyZsdDtlZG8mZ3Q7PEJSPiZn dDtBIGJpdCBjbGVhciBzYXlpbmcgCiAgOjxCUj4mZ3Q7IkEgQ01UUyBNQVkgCiAgYWxsb3cuLi4u IjxCUj4mZ3Q7Jmx0Oy9lZG8mZ3Q7PEJSPiZndDsuLi48QlI+PEJSPjwvRk9OVD48L1A+PC9CTE9D S1FVT1RFPgoKPC9CT0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C422D6.5434752A-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 11:18:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00128 for ; Thu, 15 Apr 2004 11:18:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8YX-0006b5-4Y for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 11:13:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFDXn4025350 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 11:13:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8Fe-0007Pe-KM; Thu, 15 Apr 2004 10:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE87E-0004BM-Q7 for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 10:45: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 KAA28141 for ; Thu, 15 Apr 2004 10:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE87C-0001LA-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 10:45:18 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE86Q-0001FV-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 10:44:31 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BE85T-00013A-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 10:43:32 -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 i3FEgW9T023759; Thu, 15 Apr 2004 08:42:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C422F7.E21E5362" Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 08:42:31 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQidEWEQnHKsmXZQJOtw9Rg2KXTKwAXPkqMAAmRkeA= From: "Matthew Schmitt" To: "Eduardo Cardona" , "Minnie Lu" Cc: , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C422F7.E21E5362 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minnie, Just to re-emphasize what Eduardo said, part of the problem with MAY NOT is that the English language and spec language interpretations can be different. In spec parlance, MAY means something is optional, therefore MAY NOT is exactly equivalent (from a spec perspective) to MAY. However, in general English language usage, MAY NOT can mean the same thing as "you're not allowed to" aka MUST NOT. As a result, it's generally a very good idea to avoid usage of that term. Thanks. Matt -----Original Message----- From: Eduardo Cardona=20 Sent: Thursday, April 15, 2004 4:42 AM To: Minnie Lu Cc: ipcdn@ietf.org; milu@cisco.com Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) =09 =09 Hi Minnie,=20 =20 If I understand the intial Randy's comment, RFC 2119 defines MAY and OPTIONAL as "truly optional". In a general context "MAY" and "MAY NOT" becomes the same. Not being "MAY NOT" an IETF keyword, I see the MIB doctors reluctance to use it. =20 In the other hand, the reason for the default entries is a vendor feature outside the spec requirements. In the vendor side, this feature would make sense to "require" (vendor design - not spec requirement) - SHOULD be read-only - SHOULD NOT create new Interval Usage Codes. =20 Another vendor may opt to offer default entries as "custom" entries which may be nonVolatile and adjustable or removed as part of a factory configuration, that's why I think that shold be leve in context as informational.=20 =20 In spec words the optional MAY make those vendor requirements informational, in fact the ECN says the creation of IUCs "MAY result in error", which is mere informational. =20 trying to avoid the "MAY NOT" if possible,=20 =20 Initial default entries MAY be created at system=20 initialization time which could report for a value=20 'permanent' or 'readOnly' for docsIfCmtsModStorageType. A CMTS MAY restrict the creation of additional Interval Usage Codes for a modulation profile being defined at=20 Initialization time. =20 Thanks Eduardo =20 =20 =20 =20 =20 -----Original Message-----=20 From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wed 4/14/2004 5:00 PM=20 To: Eduardo Cardona=20 Cc: ipcdn@ietf.org; milu@cisco.com=20 Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) =09 =09 Hi. Eduardo, =09 Thanks for efforts to make this MIB better. =09 > A CMTS may not allow the creation of additional Interval Usage Codes > for a modulation profile being defined at Initialization time. =09 Does "may not" here mean "MUST NOT" or "MAY"? A bit clear saying : "A CMTS MAY allow...." ... I think it is 'A CMTS MAY NOT allow ...." In the ECN OSSIv2.0-N-04.0121, The CMTS MAY have pre-defined modulation profiles (entries in the DOCS-IF-MIB docsIfCmtsModulationTable) with the purpose of being used by operators as is or as templates to define other modulation profiles. CMTS pre-defined modulation profiles entries MAY be read-only to prevent users from accidental modifications. Adding or creating entries with new docsIfCmtsModIntervalUsageCode values and the same docsIfCmtsModIndex values as the pre-defined modulation profiles MAY result in error. =09 Thanks a lot ! Minnie =09 At 07:25 PM 4/13/2004 -0600, Eduardo Cardona wrote: =09 > > A CMTS may not allow the creation of additional Interval Usage Codes > > for a modulation profile being defined at Initialization time. > >Does "may not" here mean "MUST NOT" or "MAY"? > >A bit clear saying : >"A CMTS MAY allow...." > >... =09 =09 ------_=_NextPart_001_01C422F7.E21E5362 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Minnie,
    Just to re-emphasize what Eduardo said, part of = the problem=20 with MAY NOT is that the English language and spec language = interpretations can=20 be different.  In spec parlance, MAY means something is optional, = therefore=20 MAY NOT is exactly equivalent (from a spec perspective) to MAY.  = However,=20 in general English language usage, MAY NOT can mean the same thing as = "you're=20 not allowed to" aka MUST NOT.  As a result, it's generally a very = good idea=20 to avoid usage of that term.
    Thanks.

Matt
-----Original Message-----
From: = Eduardo Cardona=20
Sent: Thursday, April 15, 2004 4:42 AM
To: Minnie = Lu
Cc: ipcdn@ietf.org; milu@cisco.com
Subject: RE: = [ipcdn]=20 Changes for next RFI v2 MIB (draft 10)

Hi Minnie,
 
If I understand the intial Randy's comment, RFC 2119 defines MAY = and=20 OPTIONAL as "truly optional". In a general context "MAY" and "MAY = NOT"=20 becomes the same. Not being "MAY NOT" an IETF keyword, I see the = MIB=20 doctors reluctance to use it.
 
In the other hand, the reason for the default entries is a = vendor=20 feature outside the spec requirements. In the vendor side, = this feature=20 would make sense to "require" (vendor design  - not spec=20 requirement)
 - SHOULD be read-only
 - SHOULD NOT create new Interval Usage Codes.
 
Another vendor may opt to offer default entries as "custom" = entries which=20 may be nonVolatile and adjustable or removed  as part of a = factory=20 configuration, that's why I think that shold be leve in context as=20 informational. 
 
In spec words the optional MAY make those vendor requirements=20 informational, in fact the ECN says the creation of IUCs "MAY result = in=20 error", which is mere informational.
 
trying to avoid the "MAY NOT"  if possible,
 

          =20   Initial = default=20 entries MAY be created at system

           &n= bsp;=20 initialization time which could report for a value=20

           &n= bsp;=20 'permanent' or 'readOnly' for=20 docsIfCmtsModStorageType.

           =20  A CMTS MAY=20 restrict the creation of additional=20 Interval

           &n= bsp;=20 Usage Codes for a modulation profile being defined at=20

           &n= bsp;=20 Initialization time.

 
Thanks
Eduardo
 
 
 
 
 
-----Original Message-----
From: = Minnie Lu=20 [mailto:milu@cisco.com]
Sent: Wed 4/14/2004 5:00 PM=20
To: Eduardo Cardona
Cc: ipcdn@ietf.org; = milu@cisco.com=20
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft=20 10)

Hi. Eduardo,

Thanks for efforts to make = this MIB=20 better.

 > A CMTS may not allow the creation of = additional=20 Interval Usage Codes
 > for a modulation profile being = defined at=20 Initialization time.

Does "may not" here mean "MUST NOT" or=20 "MAY"?
<edo>
A bit clear saying :
"A CMTS MAY=20 allow...."
</edo>
...
I think it is 'A CMTS MAY NOT = allow=20 ...."  In the ECN OSSIv2.0-N-04.0121,
The CMTS MAY have = pre-defined=20 modulation profiles (entries in the=20 DOCS-IF-MIB
docsIfCmtsModulationTable) with the purpose of being = used=20 by
operators as is or as templates to define other modulation = profiles.=20 CMTS
pre-defined modulation profiles entries MAY be read-only to = prevent=20 users
from accidental modifications. Adding or creating entries = with=20 new
docsIfCmtsModIntervalUsageCode values and the same=20 docsIfCmtsModIndex
values as the pre-defined modulation profiles = MAY=20 result in error.

Thanks a lot !
Minnie

At 07:25 PM=20 4/13/2004 -0600, Eduardo Cardona wrote:

> > A CMTS may = not=20 allow the creation of additional Interval Usage Codes
> > = for a=20 modulation profile being defined at Initialization = time.
>
>Does=20 "may not" here mean "MUST NOT" or "MAY"?
><edo>
>A = bit=20 clear saying :
>"A CMTS MAY=20 = allow...."
></edo>
>...

=
=00 ------_=_NextPart_001_01C422F7.E21E5362-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 11:33:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00884 for ; Thu, 15 Apr 2004 11:33:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8lv-0002ba-On for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 11:27:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FFRNTo009997 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 11:27:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8d7-0008Vl-DP; Thu, 15 Apr 2004 11:18:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8UP-00051D-Ds for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 11:09:17 -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 LAA29441 for ; Thu, 15 Apr 2004 11:09:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8UM-0003uw-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 11:09:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8TX-0003ng-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 11:08:24 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BE8Si-0003aD-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 11:07:32 -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 i3FF6w9T000077; Thu, 15 Apr 2004 09:06:59 -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] Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 09:06:58 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQidEWEQnHKsmXZQJOtw9Rg2KXTKwAXPkqMAAlBF9A= From: "Eduardo Cardona" To: , "DOCSIS OSS Majordomo List" , "DOCSIS Macup Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all,=20 I have some questions regarding the MIB object docsIfCmRangingTimeout=20 Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96 show docsIfCmRangingTimeout with syntax read-write ( the only CM read-write object in RFI MIB). The questions are=20 Is this object really need to be read-write?=20 particularly if there is any management case where read-write is used. Currently there is no Compliance statement to allow read-only access, is that needed? Is there any instance (in general) when the T3 timer is being adjusted by the CM and retained in Memory after CM reboots ?, or would be ok to explicitly not require persistence without incurring in spec changes? (just a clarification) I am Not planning to deprecate the object but The new revision of RF MIB is being updated to address IETF OPS MIB revision guidelines related to persistence and would be good to precise CM usage of the object.=20 See ipcdn mailing list for current discussion about draft 10 updates=20 http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h tml I will post OSSI DOCSIS reflector with a second revision of the changes as well as IPCDN list soon Thanks Eduardo=20 PD: In Annex A of OSSI spec the obsolete object above docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being tracked to include in an Omnibus ECR) _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 13:01:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04916 for ; Thu, 15 Apr 2004 13:01:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEA94-00056x-TA for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 12:55:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FGtMAT019640 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 12:55:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEA03-00027S-4J; Thu, 15 Apr 2004 12:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE9lC-00063S-4E for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 12:30:42 -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 MAA03024 for ; Thu, 15 Apr 2004 12:30:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE9lA-0003zw-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 12:30:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE9k1-0003oo-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 12:29:31 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BE9iy-0003Yi-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 12:28:26 -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 i3FGRf9T016459; Thu, 15 Apr 2004 10:27:41 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C42306.92AB2B66" Date: Thu, 15 Apr 2004 10:27:41 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: V2 Changes for next RFI v2 MIB (draft 10) Thread-Index: AcPql1cYYxHVIUk1R02CjMUjuIRwHgyVT10AAPscgxAAAYHmoACJV3jw From: "Eduardo Cardona" To: "Eduardo Cardona" , "Donati Andrew-MGIA0477" , , "Randy Presuhn" , "Keske Tom-LTK002" , "Azlina Ahmad" , "Minnie Lu" , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] V2 Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C42306.92AB2B66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 Please find attached the summary of changes after all your feedback, special thanks to Randy Presuhn for all the detailed comments. Please note that the storageType objects are being set as CMTS only requirement docsIfCmtsGroupV2 since the CM compliances are read-only or any other tables do not apply to CMs. Change #9 for the docsIfCmRangingTimeout please review the other question sent to the list and OSSI reflector Please see if the coments are being captured properly. =20 PDF has the color change, also attached text file for convenience. Thanks Eduardo ------_=_NextPart_001_01C42306.92AB2B66 Content-Type: application/octet-stream; name="Considerations for adding StorageType objects RFIMibv2_revision2.pdf" Content-Description: Considerations for adding StorageType objects RFIMibv2_revision2.pdf Content-Disposition: attachment; filename="Considerations for adding StorageType objects RFIMibv2_revision2.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjINJeLjz9MNCjMwIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyAzMiANL0ggWyA5 NjIgMjAwIF0gDS9MIDI1NTM2IA0vRSA2MDY2IA0vTiAxMCANL1QgMjQ4MTggDT4+IA1lbmRvYmoN ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTMwIDI4IA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDA5MDcgMDAwMDAgbg0KMDAw MDAwMTE2MiAwMDAwMCBuDQowMDAwMDAxMzY5IDAwMDAwIG4NCjAwMDAwMDE1MzYgMDAwMDAgbg0K MDAwMDAwMTY0MyAwMDAwMCBuDQowMDAwMDAxODIzIDAwMDAwIG4NCjAwMDAwMDE5MjUgMDAwMDAg bg0KMDAwMDAwMTk0NiAwMDAwMCBuDQowMDAwMDAyNTMxIDAwMDAwIG4NCjAwMDAwMDI1NTIgMDAw MDAgbg0KMDAwMDAwMjk0OCAwMDAwMCBuDQowMDAwMDAyOTY5IDAwMDAwIG4NCjAwMDAwMDMzNzgg MDAwMDAgbg0KMDAwMDAwMzM5OSAwMDAwMCBuDQowMDAwMDAzODAwIDAwMDAwIG4NCjAwMDAwMDM4 MjEgMDAwMDAgbg0KMDAwMDAwNDMxOCAwMDAwMCBuDQowMDAwMDA0NDIzIDAwMDAwIG4NCjAwMDAw MDQ1MjkgMDAwMDAgbg0KMDAwMDAwNDU1MCAwMDAwMCBuDQowMDAwMDA1MDI5IDAwMDAwIG4NCjAw MDAwMDUwNTAgMDAwMDAgbg0KMDAwMDAwNTQ1NiAwMDAwMCBuDQowMDAwMDA1NDc3IDAwMDAwIG4N CjAwMDAwMDU4MzcgMDAwMDAgbg0KMDAwMDAwMDk2MiAwMDAwMCBuDQowMDAwMDAxMTQyIDAwMDAw IG4NCnRyYWlsZXINPDwNL1NpemUgNTgNL0luZm8gMjkgMCBSIA0vUm9vdCAzMSAwIFIgDS9QcmV2 IDI0ODA4IA0vSURbPDZmZWM3YjAyMjViZmIwZGQ5NGJiMjY4NWE5ZTA5MWI0Pjw2ZmVjN2IwMjI1 YmZiMGRkOTRiYjI2ODVhOWUwOTFiND5dDT4+DXN0YXJ0eHJlZg0wDSUlRU9GDSAgICAgDTMxIDAg b2JqDTw8IA0vVHlwZSAvQ2F0YWxvZyANL1BhZ2VzIDI4IDAgUiANPj4gDWVuZG9iag01NiAwIG9i ag08PCAvUyA3MyAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDU3IDAgUiA+PiANc3RyZWFt DQpIiWJgYGAGokMMrAwM7FwMPAwIAGIDRRk4VkD4Owp/MQloch36KTKRX6gAnQsFAkAsAcUMDKIM XHqdihHzRRw4LjDEHmATYIhnYC8IEXVg12BIcGD1sQSqAQgwAGydE8MNZW5kc3RyZWFtDWVuZG9i ag01NyAwIG9iag05NiANZW5kb2JqDTMyIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAy OCAwIFIgDS9SZXNvdXJjZXMgMzMgMCBSIA0vQ29udGVudHMgWyAzOCAwIFIgNDAgMCBSIDQyIDAg UiA0NCAwIFIgNDYgMCBSIDUwIDAgUiA1MiAwIFIgNTQgMCBSIF0gDS9NZWRpYUJveCBbIDAgMCA2 MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2Jq DTMzIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0YxIDM2IDAg UiAvRjMgMzQgMCBSIC9GNCA0NyAwIFIgL0Y2IDQ4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1Mx IDU1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAzNSAwIFIgPj4gDT4+IA1lbmRvYmoNMzQg MCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9FbmNvZGluZyAvV2luQW5z aUVuY29kaW5nIA0vQmFzZUZvbnQgL0NvdXJpZXItQm9sZCANPj4gDWVuZG9iag0zNSAwIG9iag1b IA0vQ2FsUkdCIDw8IC9XaGl0ZVBvaW50IFsgMC45NTA1IDEgMS4wODkgXSAvR2FtbWEgWyAyLjIy MjIxIDIuMjIyMjEgMi4yMjIyMSBdIA0vTWF0cml4IFsgMC40MTI0IDAuMjEyNiAwLjAxOTMgMC4z NTc2IDAuNzE1MTkgMC4xMTkyIDAuMTgwNSAwLjA3MjIgMC45NTA1IF0gPj4gDQ1dDWVuZG9iag0z NiAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0VuY29kaW5nIC9XaW5B bnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvQ291cmllciANPj4gDWVuZG9iag0zNyAwIG9iag01MDcg DWVuZG9iag0zOCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM3IDAgUiA+ PiANc3RyZWFtDQpIiYxT23LbIBB95yt28qR2CkYIIemxcepMHtLO1PoBWSCFjAMewHHbry9CrtPY aSfDDNfdPWfPLoulL6H3kKfhe7S4XecwepSDBiQqUpYNVIwSWgMXNeC8IHFxCg3oukWLVRHd2gHl DGgccZl9cqjy6ERpAe0ToukxRqfQpumAsqU1XkvluqDjDgbroJNSmxHWwbpuVO3PnQK7eVR98BAs 3N9dw72V+62Cm2/LNf7QPqIvLTox/0OWClIyKCpO+DndS5aiEYTzM5bZ3QpPaNqAdN0Q5hlrFQas d700WNreYzc86c0zwzHR8CPAP/iIhpGaRw3fQaZmpBLnZL6rZ+2jRpgliMUqnyVvSCOSUdqcYlSU iGNCWXKgEZjkBSuhvUFTTRifqpBFLfWg+6P+m84rCdbA1e0+lmWrjZqLMgnxeR8erPPQGQkTHXVQ zl/9LcsLEOdiAsrszuOoD3bJHo+nqJiySa9P4GNlEzYngrAUfNpx2CkXuij+BftMGx10t9W/Euvk Eo299kGZXkFvjdRzzP0uvju1sTakNJzqJD44HVTySscpfvsRZX08xfsp02O/EYCLjFLvviFp9obp i8r9Q2fGo5TvbqPXJTvHrWn1GoSThhZi/lUJDr7amM+xIUVOmryBsqoIq4ESHn9xmlMj/vf1twAD AJb/FfENZW5kc3RyZWFtDWVuZG9iag0zOSAwIG9iag0zMTggDWVuZG9iag00MCAwIG9iag08PCAv RmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDM5IDAgUiA+PiANc3RyZWFtDQpIiZSSyWrDMBBA 7/qKgV7sQwbtiq5NS6GUngQ9JD2YRN1IQps45Pcr2YltGsmhGIThjWZ5I6I5CmtBGYN8CpainMKk OXeevBGmOE5Nxy+xQKE6LJhExYcBUpux+1ewZmhZpBrPkDGUf1tL0T5zit46YtFqoOFrfkK0UpaB UholpQLchlBwRzIvZh/V9t3DDYNyIqgNvHj2x5Dn5/C58xu/reHlAZ6qfQ2zar2G8tU9knvXNa9V qHox2Ul7A/PWk3c76Q0dcZ6ufG5LouV5qWncp07ivFYZm2y19kb5f4zGnAz2S8I1KkvDYODuSLEo Dt+rqvarRVm6ryaKxqgwOmemDQrHkhQQ+WAvwaLi2cW0NL+Z9O1uNS0e2U2met8blb1enqie4sPs KZ7fj+Bo9OnZI6VcRmXzXwEGAIgz30YNZW5kc3RyZWFtDWVuZG9iag00MSAwIG9iag0zMzEgDWVu ZG9iag00MiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQxIDAgUiA+PiAN c3RyZWFtDQpIiZySS0vDQBCA7/srBrwkhw6ZfSTZa6uI4gsMeLAeQrutkTRqmuLfd9vYJLS7OcjC svDNi282mL3n1drAhYBwIiIdowwezA/U5ntX1GZjqgZeruEu3zYwy8sSwrfsll1lLCbUpEFJwiSG CGUKk8NdG7ZiMUehO6pPMSmOaeLNJiVQqA4Lkqj4MEDGyVj+YDae/lEilOfNHXhY24GnGdOobU97 Dg8brpQmUDzCNI0EZBv2Ghy1yn9q5doW82ptqV+rO7vT2uIRrZ7u/Wyy98IdzR14WNuB/VojjcRP tape66zM62JVLPKm+Kzg8ekZ7m+msN4VS1MWldm2avd1CbYLxrV9ZZcsmAe7r2XemOU8DLOPQ0C0 D1AoOSVtkL0WLIA9H+yGUjuRdzct9e/Gnd3tpsUju/F0P86WYCz9X96N+9rn+FeAAQBSe+XoDWVu ZHN0cmVhbQ1lbmRvYmoNNDMgMCBvYmoNMzIzIA1lbmRvYmoNNDQgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCA0MyAwIFIgPj4gDXN0cmVhbQ0KSImsk8tKAzEUQPf5iguz6YC9 5P1w2epCQRTMTroYpzN1pFZo9f9NZjptKUmhIIEQOPeVHEJaMvPEodNAw+oP2qBSjoF0BrmkAvwX oUgpl+Br8jaZf1SbVQOFhnIqqNMoJ/N1te3arq5+uu8NPL+8wtPDDFa/3bJZd5tmB1Au/COJLRjs 6tCQcapgypAJrsDfkX3V5S2U/jMERiSl7lGhq5vQ7j1u9YDjCnUMWsFEOIcwGqeb9On3nmiGjjlQ VIc7AEVpYdrv24a0RHMU7kDdOWaKozXZbKYECnXAgklU/DRAhie8kH+YTaHReypEfPqz7ml+rJ7m eaHh2pbmhZorhGZ9jtISPkfVhYk+TfRprvQpDUOb0znArM107ihzoHmXmc7HsQQfVUikidYpflo8 xfMqub34N+1/qBx8/QkwAFkH6CQNZW5kc3RyZWFtDWVuZG9iag00NSAwIG9iag00MTkgDWVuZG9i ag00NiAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ1IDAgUiA+PiANc3Ry ZWFtDQpIiXxTTU/jMBC9+1eM1EuKyMjfibkBC1KR2EVgDghxCKkLZdWmSlKk/fdru02AkiBLI3ve zLzRezJJzl+L9Yubn8DUvhF7RJJJXhzDJH8OoQxJCuE0JckwF0z4u/3lk7YkSWy6sEQzNMyAFBly CRRlDmmMtSMLojkK06PmEGaKY56NdjMlUKgeFkyi4p8LpM5+6u9305jpPSoEGn3IPox/TB/Gzywx 4RE0ihdfr5RhIIzAnFIBdhUlZEFCipT6HYN2O+FhYjoRGbBdEVP5TjDKUAPXElJGUY0RduWDhIl1 67Zol+8OykjYwKKqYV6VzWxxvrr1qeX6xS5Xrtq20K3SW96JR71Io75GcNzWwd7e1Yj+YOow88da gu9RxlB+Zx6AP48egMcNzT0rP9D3ManaV1c3ME2loQJ1cr+ZF60LCm9XXnv46/410Faw3WxcXRaN g+mTvfIcjFPliZEJrsKXSq5PH+D6/s4exwi///jbNk6bw+3lzK+3cLVbly7Ou7tJuy/rwXeONJ1R lVLpTzZmpPA2GT7m5B79auV/AQYALIbreg1lbmRzdHJlYW0NZW5kb2JqDTQ3IDAgb2JqDTw8IA0v VHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyAN L0Jhc2VGb250IC9UaW1lcy1Cb2xkIA0+PiANZW5kb2JqDTQ4IDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1R5cGUxIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250 IC9UaW1lcy1Sb21hbiANPj4gDWVuZG9iag00OSAwIG9iag00MDEgDWVuZG9iag01MCAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDQ5IDAgUiA+PiANc3RyZWFtDQpIiYRTyU7D MBC9+ysscUmQOtjjJTU3KCCBxAX5hjiEJGVRF6kt4vcZOwuhdYssTUZ+s7z3krA5kwZhWjiunACH XICe8kmMm4YFWIEyA6ykBoPjAm2LU/1WgpMtqnWHKgXO/oWNDcix5iMognID6g6Z/wpLrR7w9PRB eAufFp6aP+Dp+f/A1565MErQiQmVG+MkV7qgIqG4XzLBfcUynvtP5s+7RPCJBKm15f6mu7r1TPJw thVrx3CFGORIPQVBe0mctMPiiztNxZ48wLifHsN2KUGIfns4NFPQFWLg8pzV6yq3gNn2fj7LNSXL XBp67PIQt7mk+Bgr1jlSrL8WZYt9rFe+fF00EeT5i38gIrIlkrYCnYMCOzKBg45+PDVlPak2Tblr emtGRrX+KDTBn1HXVV039SWPNScMQKsAtdB79icsRisCWaNB2X2HE3O1o6+onzsyVkRjJ336zbLZ e7l6a/iZ7LjalmsnLMoKLSIWH7JDcPTXoMJAiKRQmwAzfvtp02MfEcUgKBL9EWAAY+LgiA1lbmRz dHJlYW0NZW5kb2JqDTUxIDAgb2JqDTMyOCANZW5kb2JqDTUyIDAgb2JqDTw8IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggNTEgMCBSID4+IA1zdHJlYW0NCkiJlJJRS8MwEIDf8yvyOEGPJG3T ZuCLXZCBDt0632ubzkqXSJqqwz9vV2EMZiG9I3APR+7ju0MEH7MtEAFCWIizAs0WpmiXVbp37aMp uyZ3tdFSO3vA8/kt3sjnrVylEv/gq+wdyQxRfMz+D85ACIEZIxBzHHCCbyiBiGOrUIXuMiRA8GHg UPy1U8xoX3DSD9+jE88Mn0V5TrTUpfrG/8RSO7VTNmDXo2REQJjgoH9+ZIQCTyaQOWU/82bb5juV mlKdyFaZvJfrUS4qEiCJvzEqCLCEBJ5cqem3Z5pLY2vztXG569pxsoTDBGE0Fv0deQvLDh/qkspH WBxBxCYI4zHEzJvryap8/9qoB6WnnhjlIdAjGfckizgEzHuVi7qqlFXa1XkjdWHKWu+Grsx27u0l bzo1jhYxSMIJ0sIISDig/QowANKC8esNZW5kc3RyZWFtDWVuZG9iag01MyAwIG9iag0yODIgDWVu ZG9iag01NCAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDUzIDAgUiA+PiAN c3RyZWFtDQpIiZTSTU/EIBAG4Du/gqMmOoEWWbhus5pNdk9F77XMtjXbkkxpNP5690OTzUYNnblw eIEnMEzwY481u+EX5UM9rndFH8dt8I+rYkUUqAhEWMcuDN+p9RCxQcqzO37r3tjKMcmPfThNZ2Ct 5VJJUIrnWvB7KeBBc0K2Y0vHLFh9uvq0OMcPe/MctBKKu56lyYrg8T2Q3+DQxJany3IBUs+QZRkc wqmysqaqf90jlYj+MpUgkwaMmSGTEoRJlm2rj+VEYyy7T+QzZWIB6ijTaTJrQafDnqaKvOt6vJY9 D2PXDOj/kVkNWbrLGFAi2bWpxvgzZWUbKOJw/lJHU2xfqv2Ef7qMghnvtViAECKfO2L8qn5xfQkw AD917BINZW5kc3RyZWFtDWVuZG9iag01NSAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0ZSANL1NB IGZhbHNlIA0vU00gMC4wMiANL1RSIC9JZGVudGl0eSANPj4gDWVuZG9iag0xIDAgb2JqDTw8IA0v VHlwZSAvUGFnZSANL1BhcmVudCAyOCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAz IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBd IA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0 IF0gDS9Gb250IDw8IC9GMSAzNiAwIFIgL0YzIDM0IDAgUiAvRjQgNDcgMCBSIC9GNiA0OCAwIFIg Pj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMzUg MCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCAxOTE3IC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+IA1zdHJlYW0NCkiJrFfLbts4FN37K4h2UXsQM+JDlFRgFonjFi4QJ6iVQYvpLBSJ jtWxJUOSk7qD/vtcUrLjF20aqLOQFFHk4X2cc3jZK10Ul4jovzJuXX4cEfRUtghKUUtQHAQB8kiA KUdMCNQlDnYFKmRr3LoOW5cf1GfhuBXgQCAH/vRN/R2BDwnm3GEonLUc/RpWcLDjwGwh3KHwpdVG G78kj8vBuDeryts8uV5WcpBVspjK6FkWN3JeTfSoh6xMnzKZMHqBOuH3Vj9srfGvIDueAnIAsgGp 42AidpBaQ7ue5vG/o/SntIEmAqHwMO7bQRO+jz17aPeFjGaPUxku53JzEBoMw/7H/mczLt/F1LcP mfA8zH1rXGE86xdFXvTyopBxlebZXaZHhcWimvwVTRfSDM1j2D8HmhDYsYc2ipNZtJHOUSXn1tmE 6xl1JlyOfec8ZKM5pDSRRT+LIK/IOmguwYyeAY0z7NIzoS0ex0U0k708kWUzyiZoDFamiBNuCY1R TKjDLaH1JlGWyeleB6AbGJWWD/OyUk2i3pshUh+Lg5xngEgd7G9QHTkRvSovoqf9JkWbL0zQiKfo 2LUNnhPsk/Aa2S+9yuUHUfM4oXoEXISHXRc+dwMXem/1eag+3cOlh8JIhplA1HOwChoHQl1DOzCv T/d7tKvEwSFaHJq7l9bf7WFeSXQ1LXMUJYlM6iB1ugKT9lMHviFtWT+FnW4Al2UHFCtoz5t3qAOB aoc9VOX17aBDITjtW3iA9/d3n8MRKmtSwqjzT/gJAsLrgDhIjfFQeFPvvtEsUwiEC1wNqVGBOB0C GEf5TlnrfVO1VHd1Cwuqkn6S6C3dTleNjp1EVxeOy4QqDErpmTru0mBfHV91vL1V2otppALZz6pi ie6uP/V7YTf8et83oqIuFr4qG7t6dqH8fSO5j74Ow6svr+1+GJYJCmQMJFAxjR0URxyRwNurL92r Xq8/GiGU5VU3imNZlqnicNP6MBURe9k5vDiHxqRGKRmFV+HDqL6PFyC5WWValQcEGpbYkjH32REJ u+mPep8H9+Hgbmhcz3eUMHFqmXDu0RPC9OZGlnGRPoIGRWi2zjWaF/k4hXCP8wJFGdIS/xxN0UMJ FIuUaBkxigBDFVDfNhmCqFY+glGDyDOJ4DLLC4kWjQyhuJarEhvBuJ7WIs/SMXIebGnRATCqDVII V5qhapKWqNLWIgJYMWCqgGMfl/AG0M5lEQHd1uAavqHumnGMZMMZP8uBc+od5Zgt+IMsrVJIZCLH 0WJaIdlsZxYt0ePrHqIKlcuykjNkREmZIh8mbGuRuEfIR//SGlv6s67BKp2By3iZpPGkjmDjDWBh HnB4gki2UZwvpgmsPc+LCmr4WTk7M2hCMUfcsS0Hh2PhHLMm6B1keRZlEMZ3qj7fKcN5l02X73TV mpwLXm1IR4E7sCgL6h2dqA0HzoUQ9UDVBlGNdnwHDJwF3zVXptq4Qr1b0HNVCrVWssbacAyN5DcR L+R3EPx6QKN9UAmEu6uMqOLXdaSSmI+V80jVPVTdmkcM22N+gD3abM8iQcwnYIePJuiVscqazQ7R 3KNMsyfVE2lWF78RoOcrBiaBZQUxsHTucYCD/arfLg9wZL4XuHvl0V292GAWY+EwV/sr5ltqFeMe PFqSyjCH3k3S5zRZQG7zR1UgJZrAiVAZR6CVci7jdJxCbIE28wKOZEacnNdW2LYCwJm5uzi30QGE mtaUkkntYrbI26gejDEw2vbqATkAE3QUi/bj1UTRaz6T61AlufI5dcRWzFwz2YW5FClRBGxtBhhh pwj4cVEpKBpGHE1j1SaQswYRWIQsQZmE/yiwW2k1YQRg/IxucegW3x6AmCwK1apF/rLmGGP+aADm +wy7RMHOsaN2CYUTCUoPlZPlMBnYkDSuaS6raU8dNhQ+oD2dv1efYMLoe2cxHvWCLcY7VO/akYBu TlWpyRQ4ryzzONW5hMCV2q1EABzS/JJWEw3dCNADpw45dG0BCh8s187RbBug/BHLeaMO7zfcEefi tAJSl51FZJS7isj2j4qHiIxgNBgflohUp3JRSuXvNt2oESinSqo5szTCFGyf8I8GDn573vdCZ68m C6i6LcfRq8cox2FEyYjiOEps0wvu6wTHwe/2YRSi4V2oLaXqCZmYu1TJ2Bn5BAvnOEfDRH9nFh3/ HMcIx0rFYL81iTlIVj41IiSBp1jOmkEIeCxguRMQNzNYykqJaKL4Ll9+a4tvHRU3EIFBNgI/l8by W5t+6+A3Row+mH8VRsteIGCzHOM5bDC86X9B/22HaZAl8sfF7v9qu6k9oLKAv4wAPa5YjrqWeSZC HGG59+//3IXXFGKouZmgX0cPhZcfeOO8qZ4bLsLDrqsW5kQZer3wAY7UoxBhIHwCudpKdcG+k9f9 HJgSzo97e1EMCdkCSN3V7Uur3dO9jN4ytOX/DTEiAtZfzQszOXoO/Wn4xxH0cMYRFozUwIcTjr/R cbsnHNMRDN1df+r3wm749b5vQhI4WHn9U0XbAPGB73eBrEti9HUYXn1ZPWzAaJb+fwBIGKG1CmVu ZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjggMCBSIA0v UmVzb3VyY2VzIDUgMCBSIA0vQ29udGVudHMgNiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzky IF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTUgMCBv YmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzYgMCBSIC9GNCA0 NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D czUgMzUgMCBSID4+IA0+PiANZW5kb2JqDTYgMCBvYmoNPDwgL0xlbmd0aCAxNDY2IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJrFdbb9pIFH7nVxx1H0pXZTI3j+1IfaAOqahKqIIb tVJfXOMkrsBmbZMIVf3ve8aYOwOT7oIUGWLmfD7zXc5cBKUDcQmsfpdx6+LDiMFD2WKQQku5xHF8 cJlPuATmc+gwShwFRdK6b70PWxfX+mfhfcsnvgKK7/pi+TuGP2RESiognLb0P+sKlFCKq4V4BeFz qw3Na9D92ukGQW80wg9FEo07Mf6tEngT/mz1wtYa4goVdXUtprx9VAYwlBKm9sCsq4/Cbvhl1HyI 50WRZJWpsvKVLseYtKusPI+4xspXvVFw2/8c9oc3YKzoOYR7ILhtRdcl0jNV1K9X4WMCZZUX0UMC 1WKWwH1eQPWYlhDnWZzMqnk0gSJ/JkZMriAeYsKydpiUIvQkJgh2KpfwGD2l2QOiSuApmswTeD1L immU4d68hixJxpDl5l1SnCiQ1JIeypHEoyfhRZNJ/gzPRVolnSiOk7KEKocoW2DLJvNpFhWQ//iZ xFUJaVaj1v17ZQToMCI4cEYtEUpBHG6m0fVd99Py+hf2JbvLJ1GVThL4bQQgcH0EoGxZJThhnMrj AC4v32HhcR6X/ftgWpWDfDzXCPKsl1XFAjhvkOjHJUxwB8Ir7QF6jc33Uir9ffsQNCe+j6CpozFx eY529e0MHN/bkT3d9aD2EvD7qEzjIJ/OJmmEHLzjMBheffnU6wTDwedP/e5N0DMBcnxJ0IOYOnBH AyBPoW72AB31IaMNNYU9oU3hvA2tCrvOjilQow2ZCrochGdbTUnCqana2oLidc/RjdDtp/qBtRWN k6cUJYYyiipI8ablv0zQFEWxC/ec2FfgHL4j9kNwMAhuRhdXw2DUH61BVnAbjdMcrovkn3mSxQvo Z1VS3EcItNG5idzHMAuPoJhQUZagBcUY3shvn8lLxgJ0Oo0KB+mPQ2GdwcQcIpSFJ60wYQg7J9SF WOYZBso41UaABroA9O9xhMGzgIcin89KIxQq6nw/a+ANFImpfCD09qB7c9UNh7ffOh9uh18+j9Ci DPWkz2sdO5bGIj15QsdbtvJBPyY6iqmuh0MSOJaykpi6ysjcpcGGf5/ZZengQMKPDXSGog7FoDi5 yyf32IhDujoBGbdtOQaWs4+jXW/sOnjOdVuoWnS2pim5p0X356YpucThD+cQ214zhR/P+CZOacvG 4sXaG3EcyjNsPs4eQfQDgx8TOJmWb+shCb80AWSilrxruwkYwAeS35vjNuUhxIktzeo5AEaLEh3+ D6xS+LTWpi1hhccPtfk/EFa4PmqVCUtLEi47ItZdvlblGcYKhQMMt2eswCgUByJ5AWOFo7Q7SNtc EtI7dIf/wNgdypgwSpxlJHDHdieES5RRxsvJa0nOtVy2NbTDWKsgFZxr2Vunl2DyUPa7jB3OlnTd zs2XaIjicqghz1LnHPOQn9DQPo1X8M7QmXseecHQyjEdKd0bel7CZu66KFkpLJ2DK/9Evh4hc77a FT20njG+t0aQSmmN4xZZosQAF9zUlfqFhlYzOZrh6BrXuPYQrlh9dlzgePDUYhO2eyYcLbYaHTvC HCCEwPf2dD6pUnQCGL7/2AvCraNACd/f1DctKd6scB4np7XmbFOCM641t3ue3cLZ4No9044wJaKH JFzMEiMOiinhIfNsd5NiTHh7ODYnwm83YfcrbNf9hTub3eUTJNck+d4W2K3fJjDMxwHGXm8Mk1Zu 8Z+9VG9MH28xsC1dhmGibuubHeqtX2mdbc5gVb5MjXI+m+VFpXvx1PQCz5B1l9Z+bUsdhqdVFCDn ltTBU8JhyG5TvHldXr7D3WoItOE32iM7Oqzjp+XFxTXOGRDetxBV3RcOCo9ajq7NfOI18jryQPVd eJM+mOGxQs92HQwXtnmkI0tSPRUfeRycWhFbZ3X53GoHj1H2kMBfsoHJljCPt8nXs+9qWVyI1kus MP87AIlUH9EKZW5kc3RyZWFtDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVu dCAyOCAwIFIgDS9SZXNvdXJjZXMgOCAwIFIgDS9Db250ZW50cyA5IDAgUiANL01lZGlhQm94IFsg MCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1l bmRvYmoNOCAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAz NiAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1NSAwIFIgPj4gDS9Db2xvclNwYWNlIDw8IC9D czUgMzUgMCBSID4+IA0+PiANZW5kb2JqDTkgMCBvYmoNPDwgL0xlbmd0aCAxNDg1IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnJdNV9s4FIb3+RXaDXPOVOjLsr0sIWUypxRKQvfC VoI7jpXaSoHOn58rhxQ6YHM1sCBAIj2W7n306mQ5Of7ACSfL1SSnuSYMvvsXWtA8zzlJOadKMUmW m8nxtEtI0fVvYqQrJsdnC07W3YRRxoQiy2LCyPJucvTJeUv8rfHE3Xy1he8IKV3RzVen7q6Z3pqm sfXCu9as7fJha4lpysc3fHbdZetWz//5+/IrDPuOUy5FQpank6PCta3ttq4pq2ZNvLmpbUdMa0nV PA5zYrqqOGvdbvtFkHX4SW52HpCqjnRbW1SrqiD+zj0bXCndD34gDuNta1PY8mnY6cZ3h1G7qinC Q7oO3mdas7HetvuPNc6TxtoSPvoSvtxZMj3/rSOtNeU719QPpHCbbV2ZMF5rv+2q1m5s4zv6ko6F NT7q/z5bTsLG8bAPnFRkst8xouGnJjwLn2M00TDkZDU5WQ7sr04Uzdh+f3/u69N+Hr188IuTv2bT 5buzq4vryxckB4iEUykIZwJJoSRNxH8ojsjj137GBflncDoJowkiOPahpaBcMPX6dOHr6bGnZmtu qrryle3+GAQQGdUqAkAwmqmh5/0VYPHQFPMGiuu7qYcBeEphx8Iz4QBY/rOt3wK4Lsq352dJGF5w jZs/yTPKNW7+c3O/gNmrws7L4S1IckV1RkSK3IIk0zTLcATz5nvlbXllmjUY5733drP1IyiZpAJQ BLL6kzShCo3S2da/uR9JKiLm14qKZw7go5tRPJPz8PyagYXwm5GIlxYa6gdv/C5siamrfkvslf02 shkqDyoSGtkZieIjKnoN5VAWN66FIhkhkRmF/hRJhiSRDHoaZ6lfF8Wux5dE6N5WCbY+eIa3VQ/y wVS1fZuDJ1TqiK1hKbzpf1TJqfFmnITJXl8SSaJyjdbXnmSZLKuNdbsRbahc9AZTSIeqTKENNt3s MaB935clpKcRjAwSHxE5dilSSTWydQ8Uz2LgfDVvSns/TAMKERmyUBW8EJEs11ssSZLR3qrI9lUJ g1ASB3N1f+nubDvMoNJeZliFKAhGWJkdGKBOwWYXq1Vn/TCI1L3L0DsDAUkgFXIAmX3bQfP+ML5y TejgYRihaBoRPhTX8GsczBdT74aPO8VlbzJ060JcwprsZ6E2tm1dO3bCKCYoizCIhMwkIg0yDZev YvSgkzmLimIyE9Eiu26KPUh/+xtGSXMacdLJlEfLbFGtG1N/clU3XB9SQ9wV+HaREJ9kZN+eV0Uo j1UNiwIdM7Imie5Fhj12pcqiRTa794h6lQqCr4ogkSkEl2gSTMlKtfcZUqwSIlS0z8Ka4KpWiF5o 6HXhKlpop/CXqoOIdu7KkcLlEAZiWhmClI7NJK7c1b3lR68UkrFebilSbgLiVKzc5o31j/lolAXq hGZ4rQiIVIzhkvwrKMMYaRrshl4RnUfbrT/3PprOX29L40dWROtgOKmwSwJpCgwXtSR/VuvbK9u5 etcXCyaniAQyssKfiAICFsPeuWz7vSrs+xI49oDDGEr2olPINhIyCaKLwfjsusvWreDeNUwhBdxa IiggV8FJFEMxbS1USbjqDFMI1ssNm6MFF0FuMRTz5gJ0P3LVEizvtYa97wnGg9biGC5N8fcYBM8h E+O7l0OqUsjufWT4ZO+edDJ2t+GZBp/xDFkYHFIV1mdg91GV8hSisAiLgZxbp5Be0HNPXeNbVw9P r1WfzATSWxzCEzaZwfSX0A8bOOs/2mYYIRG9o9CFAKmJIbMHIJxWq5VtbeMrU88gf5RgzWEWxQMA OnlwKaGZ0SwfZtNZCIWPiQwsPkwiWS8r7FWXQ2bCympPMoXgc+faEvZm7W+HQTic9RGu4BCZGNIV ALIo2r5C2oW15TAES3thYaWZ52hfAcO5uT/ZtZ1fVD+GGzXXwVbYVYCApPCGONuZtgynxihBBik3 4hIF4YjjRREyzqEiFreu9bZ5th//DgBpafRJCmVuZHN0cmVhbQ1lbmRvYmoNMTAgMCBvYmoNPDwg DS9UeXBlIC9QYWdlIA0vUGFyZW50IDI4IDAgUiANL1Jlc291cmNlcyAxMSAwIFIgDS9Db250ZW50 cyAxMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3 OTIgXSANL1JvdGF0ZSAwIA0+PiANZW5kb2JqDTExIDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYg L1RleHQgXSANL0ZvbnQgPDwgL0YxIDM2IDAgUiAvRjQgNDcgMCBSID4+IA0vRXh0R1N0YXRlIDw8 IC9HUzEgNTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1IDM1IDAgUiA+PiANPj4gDWVuZG9i ag0xMiAwIG9iag08PCAvTGVuZ3RoIDE2MDAgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4gDXN0cmVh bQ0KSImcl8ty2zYUhvd6Ckw2kToNDIDgLTNd1LSdUWacuBGdTdMFTUIWU94KQHKUTt+9B6CsSLIp Q7HGMiwKxMdz+fHjLFE+yhWi9qXy0dm7GUX3akRRiUYBw3Eco5DGmHHEKEFvKMF+gKQYzUfn6ejs ykxL56MYxwEi8LKDfh6FiRRzTjyU1iNiL8MKBBMCd0thhNKH0Rjt/BRtrqbzpNbqui1muczqu0rI X9Ek/Tq6TEdbykcwEprlWBgcgg3wEIJpcMAzDHC+1mLaaCErka2EvBCdXgyyBHFgADzyJEjPswRR hMOfZjmv2vzvWfldDPNEPmYRYvDrxhOGmEfOPDdS2OSk6+4IQ+jhKHLPTxAEmLgzpHl9KWUrk1ZK keuybT42wyzw95T0+BxHxBlllhd1tpOfmRbd8fT4FHsMQuPKwz3ss9N4Zh0kqRDysskgU8MoHqwE KAF3RPEYpozwk1CWd3PoZpG0hVDDJCzCQMEYcyRhBEeH+jJMkiyyphHV8ZKlodU6ZwQS70kcfSEY upXZ/QtdQ3yraq758OPIWdX+aNWNbOdlJW6ErEuloGmG8+HHHAcRooGjhvhRAP3uRpLUN3pY2f3I s+oVu8Yg9J3Va1MGt7qsyu+ZkQ3buKusGsYJoT981ygEHDNH6diy7NAMUwQEJIxRRzX1feYsYRft Q5MsmirRcloMA/DYipZzZXLqLFo7BGmrs8pseEcq04swKJB7TjwCbe2mWTskt0oUL4CwwEpW5KgX Po2cJWsH5PKbdokK9bF3gh/ywT/5jsqxD+MQGOJZFSOOtcLBP7mq2G33cq3ymBntcq4QHnFn7dqu b3NyrapWDweCR2CC3Y0HB88UOHbtluM2z5R+JzPQseIlHHAcztXKYeAqZftBSRrdvETigwNm7tXK fQI+5dTIQKG6sPCwt2OuLOCZXJVty/LYxC+xeIHRNo+6Vi64JuYoKbsspxQN43BYOaGIaQD//mR4 XNJFPSt0kWuIwFK5Ct1eiPaqx9JsTZ4JBaYe81F68dy9esG02/sT19fP5TwYmLuxaTvzHpe25IyC tAUh/NNPH4iSF4I3hU3YLUZeSI8Iz3+DiwTgPhl4REdJ8cDEeIOdM0t/T29n/ThfwrGu0YML+4GR D0pdn49HR+Tj4nKWfJrepNOPHwYX5OAxOdSSY9F5XgjW4FjRvXon22WH2jlq777CCVahsu4qUQvT kqhsUGIObgjODaJGqTHsjXWIg4QeN8oBRelICObluHKg2VppUSv8anBNxow00Nh1TcqPSMPbt7+h fzdNYIOjPjPkbapvr+Og9s28ISpCMOSJcUc9Z+AW2OHuD7cgcBY063wSVWZykkND3wuF5q1EF22+ NKlCOZyhSghTk6+xBUp/2cU7aPYnxODB/BhMtd2BqA82BCZwMENb5rMrSCpK5yNoNKs/DPWzANz3 jcnnA+B/jiGWkwDzMQT0dsJh0E0AJxgrPYFyHkt7Udj3bMLgvbafJ/a7Vr7stSo1pWiHaPJX+h6Y aM90ENBHLs7NBrnhOojFYwp/xPd8jT5dJSYIBOlFqZC2lQ8DKbLizYMsNUhn1hTmo6xB4huE2xxe TfOUcwvXJ+VjMpvOnok7lJKGe9U2haDJyt5t+2nV3pd5Vv24+oR2nC5ET5PDuxZIrRudfUMPGbRt o2VbLHOokDvzJFN0PT1fMQSXMlQLvWgLS2dnbqifIkKjdSD4co1k+6DQEjYfO6udz99UZSNQl8kM 7iYk3Lb4ulTalJ/CR5sDanH83Ma1WXQnB1ewlIZnrCEwGew8a9TJFh5pKSH0U20fVC3vofz15jnh i2t0I4VaLhrALZt7JKQ0zwmK9UwEX5fNtlf056xaitcYJb3MV2u7eC+E6HUvAWYvtvm47QoT8meC tgCqFmbKnaUVKkQnmsIAQbBnH65vVhTBRTtiZysPDwkHBWNnzJfnKBzUo3sHS9rLGYQLChUediWa 0miEbuFGdbsSfXnDQFZZ1xlCKf5ZltKqPjpV5ygYLUD1AldcEhkjtI+7UwN72s8x2sTdZKZbrJVt EShOk30ltDb4O1kbggT3ZcQ4dtyp43BPi+nTXWlrlA4LBMKs5VJ8GdMvE4z2TBPB3A+jvdrfC+3/ AwBeAw7QCmVuZHN0cmVhbQ1lbmRvYmoNMTMgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vUGFyZW50 IDI4IDAgUiANL1Jlc291cmNlcyAxNCAwIFIgDS9Db250ZW50cyAxNSAwIFIgDS9NZWRpYUJveCBb IDAgMCA2MTIgNzkyIF0gDS9Dcm9wQm94IFsgMCAwIDYxMiA3OTIgXSANL1JvdGF0ZSAwIA0+PiAN ZW5kb2JqDTE0IDAgb2JqDTw8IA0vUHJvY1NldCBbIC9QREYgL1RleHQgXSANL0ZvbnQgPDwgL0Yx IDM2IDAgUiAvRjMgMzQgMCBSIC9GNCA0NyAwIFIgPj4gDS9FeHRHU3RhdGUgPDwgL0dTMSA1NSAw IFIgPj4gDS9Db2xvclNwYWNlIDw8IC9DczUgMzUgMCBSID4+IA0+PiANZW5kb2JqDTE1IDAgb2Jq DTw8IC9MZW5ndGggMjE3OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PiANc3RyZWFtDQpIiZRX0XKj uBJ991d07X0Yz0MUJCEB++bxOnuzVclOxaTubm3uA8EiZq4NvoCTzd9vSxhi4ggrTNWEGJw+Ot19 +vS3eHJ5RYFCnE0iEknw8J+5kQERIqIQUEp83+MQbyeX81pAWpuXKNTp5PLXJYWneuIRz2M+xOnE g/hlMr2qyi2syrS+zu5383VSFGpzv1sljYKv8Y/JhUd8EYRwQQnlTED8i/5eOpmap4t4ohGZABRy mEhGoigCGUkiJFDq4xc9fVupSTb5Fr9Hbl6nIMOQBLJF3iN+QzqFw/XLYjm/u/4eX/9+exK/Cx0K wkLgkecYOgiIH74L3QfU109wX6sVNCXsVJWV1RaatYKmSoo6UxWUGSSrH/u6wXd2SZVsVaOqGqz4 Ak7CEHxnaqQk3ig+yHQKDSa13ZVVUr3Cflc3lUq2UJUvGrl+ulu/1nmabN4eWjHiTwk+k44QhU9C bxSihpEXKwyvaXp8NYDeVd18UxbKlGP5+EOlDQGI8S0rSEEJZ+B7zBGlz4lgoyj7nOY1os2b3KBt 1lW5f1pDUsDy9uY7LBexpvRLU+3VF51+K0Ifmwd4qDNNieefA8gZ4RJfGwG4RmQ9Ozrs5RVvJYFK wpAS/B626FQT14PNknyzrxSGb/ZVUeuDqKoqKztwFhHKsIekI3JGz9XokyoWJubDtC62u2f68BXw t7TcbvPmCgEi0YdHLL185vg4z0yV2DDSgARd+l0wehGR4xhP2xiek81eIWPIXlE2Gu4uafLHjYKX vFmDStK1FaAnUY3d0y+ikPjjXVQiHxVp036YBEbyRXhIO8CdSlZ58XRcKZBsXpLX+pB++JIlm1p9 IT8Z4J4BgpF0D0VhK/RCyndC75nPfV+2YU6ObCYQCNQ2BoFpxgvqE/rWk5dX/gEwa2cS68eWkHSQ GQPnr+n837PbX7+G0wX8CwR8/W/8m3X+dQwKr2fwA4xtWoQvSQg0Ct1UQ/AIx9A7cEeT6Z2GLZuk 2dfw+7ffFvP4Iv7z+8KKgwuUI6CB4xwQTNf7OyB9eSz/vI1nf7T3d+XLAYYtNPMJwqeho74LKntf cRr6ZvbHxWw+XyyXKPNYfRcp/t9Y+1ZQRrAlqHSUbeEJ7B3rueNZfL9s79N9VamisQb26Kc8iR/x gScZBnZwIn7k6Q5wdiJ+ONR/79SJxEddjXcoqqpKNptXnFaNKlatS3lUsNeGBa3KmID6QaiNiDu8 YCjyp/DAZD4vC+OJbG6kg7XbV7uytsNDeZDu090X0cCDfICuN2paH9O2X48dmwF9apJs+AQOXKDC lT1/qO4fsXeAhCSRI9Edd90dGq7NDXDp2NI+E6dq8oHhNpc2E1m52ZQvmrlKITF5qvOMg3G3w+oz BrOvzJ+tIBnTuuMOEkeIXXfMRQksCoSDM9oM5OOxV6tGI0sQ6rN6mGrHoee4FZ0egNiu0jWjHsf2 HkUH0M9YEwkdCA/lYVarv7Fla8NimQ1GcUBCTnk30lcqywttSrrK1L1eZUmqBn974P/aYqkHf9Uj Ume3fX6U6bywUsKjSPPAA8cm5BEdkczu0s3fnwFurr/B3dUcWCj54EBYodwzbkHT8JbndrzoJWJw PBwrHiro8fmtx8Jtk31iBeOhN1gRR5tlNOdvo7k9RVKs/pPkzcNUtMU5PFFIvID1ddDJaY4N13GA 5W07YyC1ujv7HC6jc+quJUqvaEeaSazhpdDq7cywCM6pNyMwg7olz+xpuZk0md4Xj1scKUGnfl0s VfWcp/ghww9tKHFxxRWSha71jd5RWD1YP2cq7FnUyPL1YSr1HlOb3WGnKlx1MGt20nz8yT7BGlpI Og6HE1yjZqttXhzqzvClO/D6ww4c1i4PCPejg2ZM8RzaVwxqFI0klZFT03F0+Sj+1JVrxtEnujed nkHJ/5Rebu+70X0w5aiv2QY11E488z41mPAQ5waTTyDu/U9etBWqR3s9pBituBfJjuKb+2U84Bfj eFGnHtrZdZ2/r/Ustp3HCzVc9+ZHa3x+lLWhZ0eSZSWURWjeUGGZ4yxlIbq3cfURxPiQskD5Q99Y 548b1emBdk5PqjVw2mI6kYTlbqaAM0b0yydTwIEkeJjmBGvvRJXwEUoFfnyHWxNqBccPrGAD4Z5O htaZjaspXtjO2DPHSmVPp+SfUXMmhFbzkUUG5HF7dOn6oDs4edOfM81RqGdV6RZ5wk4rjMYdysN2 KsG0+lPh2PXM97X6jx0Lr6NZ9GkXz1ikNdKdaEbdNXIGN2g3kqZExndVmarVvlJmG3vbilA8651K 8yxP3/ymFS0aFP4JlWHmpdGy7JW724Xy2rpNME8avx46kkXRzKLIjaUPt4m5qcXB9qoVpVlX5f5p rQla3t58h+UiHlcXGgmjgK77Kw0DrYBniusjCYb72ky9PLsuVupveE42e9TCfVPnK2XawAYxxPUK ZdAxfRQdpRzvarxKtDmJdmZYOFWnyqYXX2uk1CoxNODudU/RXZ4ROLSLS73/YeRVmdbX2f3u4Abm 2sNeaRuU5WqzapdX1dNnwydxtWG44TiKBRUcvdw5DT7kqmWobzhdcC/rsj522hju//u8sidTeEbM pGu9odd0EDOjDFtVNPbEcVwc/E8UOvpA5o8GRtM6M4FbWjoOWrbqQ9/pR4V6OepTK0IW4Fb6idRR /es5ajBJ2HuLotYqmmw2x7lKy6JJ8kIPV0zZqgNuw0el1lEmXasf3Z04i+9RobSrVunVyjBW4kBU O21NbUg8gUuguw9Gl8fGHRHGut+ttKKeVPjjK9Sqabpclo8/VNrYkEW89ZOOwEJxzk7i9U4XOpwo B9X+MMA1GtrbjYgIGtLOb6AdRQvV6x1kSb6pD/C5kAZ2iJYRKx5bw0PvaAHt41vm5WPQxzbhnwEA OPV3kgplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAy OCAwIFIgDS9SZXNvdXJjZXMgMTcgMCBSIA0vQ29udGVudHMgMTggMCBSIA0vTWVkaWFCb3ggWyAw IDAgNjEyIDc5MiBdIA0vQ3JvcEJveCBbIDAgMCA2MTIgNzkyIF0gDS9Sb3RhdGUgMCANPj4gDWVu ZG9iag0xNyAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMSAz NiAwIFIgL0Y0IDQ3IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDU1IDAgUiA+PiANL0NvbG9y U3BhY2UgPDwgL0NzNSAzNSAwIFIgPj4gDT4+IA1lbmRvYmoNMTggMCBvYmoNPDwgL0xlbmd0aCAx NzU3IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlJdZc9s2EMff9Sl22he5EyE4 eCkzfbBlJXWmPhLSnWSSPsAibDGVSBUgLauZfPcuSEk2JcOh5JlEB4H9YY//Ll6PjA8TA6z+M5Pe 63cxgzvTY5BBL+BkOBxCyIaEe+DRCAaMEj8ArXq3vZOk9/qtXZbc9oZkGADFv/pNs47hQkY8jwpI 5rih/RktUEIp7pbgO0iWvT7svJZZOQWldaHhTuVjrSG7hXKqQKbfKlOqFBZSy7kqlTYgtYK8KOEo +dYbJ4/AwmLUwJR40Za3jemFwfrxR0xqwfqb/bZu2WxMQ7uQ+3uecDiAUsICpwPw7DvglJMgAsZf 5A69/d133Dgp5gtZZjcztfannEyhQC9qsrbYbLKxyL3gRZOC0/Xjjybp9kCPPhtwnwypwM0YYR5u mpy2z/vk5RM4VTOMYx3dUs0XhZZ6BbpY4je6qO6mIHOIL86vIB4nUJksv6ut0Hp7wX27/V4C2Se2 zh6SQET2IPbJ0/Gf42S8ia0f1UcKIgri5dOz4drjQRjiU4/Hr3OjnypT6mL1tR98PSKu1AlCQaII PE67pU4QBITumdo9a7L1mspLnSkD59dxAheXCSywPjJTgizRUpZnZSZn2X+YFEUOTkj8H9NbeB0Z fY9E9GeMRVO+c5nLO6xes8IinpNfnAw+I4IDj4akY5UFniA+30nKL1uON29+h++QFhNzdnu9wFAp OR9NZZ6r2RidtgIWwQ84GjAR+STAPP47eY9J6/lh1EpjhzKExPeRmiOuB4z5KCW4zMMyeSKTXiOT WNi1nzg0y5CdRXja3YLCiqHc2vvSb7iPBgGJ+h8Kc3WEYsX7ulh/lc1UIm2Z19QuPd4YQ/mi+0KX /Pa0Rj++PbvncL1IZYnptF9uDZBFQYhz+ZBomZt5Vp5U2thUW8zkBBemaqHVRFq93lvx0Dy7sf1I Qh268VYXc/j4dgQ8CClkJWSmlrhZJvMSygJuFFqW6aDIZyv42pcGlmo2c9KP5qVZ86ADr5SeZ8Zg YeCyaYZKaaZFNUtt2uZ2a6NqI/Qhol+PYJ+0v0VLCzy6bUiT4l5puGpqEGsT8f6tMq3m+N6QfTBn OI5n5bSWQltDxaIuX6yoG2XFUDannuC/VkbrRJjLFWR5mk3q+M2Vzkpj6XccskFP1W2WNxK8eJ4W qjzFs5yfneDX95n1E9xVWapmuBDPkuDSn6TJNktrtxiow2RNnl6O4rMYGKEwmklj7NFipe+zCeLU C/GYr57BbuKEaWCqBSqgTbNbnBi2+zFsHSlwu+95EqMj7K+pqje2v5jGyHMJfiMn/yylTrdNFCHK FTkgXY9xMEFnN0pnMzUvs7xCJ9tSyWwIbfAwJk9wP1zGr9AleKImjMsMd8Dcy/JnEK3rbquywunn sc7scqUVHlTZErF5YDNxid6ZWmNVXdK1220srUP2/RqX2E7uVLJaqHYS4AYZ9hrjThO74ebI+8jr ONmDo8LUBPf8IKemKRQ339SkbAtKm3ijAS8VWPvEz00UDpEXvo+NBrCT+8EBGi88zwr6bn8a/XF8 8e4o6o/h10B20m8hOAn5ZuBz9E+BnQiNcxZ0656Cs+c70NrvpzuF3PRM21Tj8Yfr8cVojN3VxcJC 2xWF6MqCDz02qDVLa6Bohf4Mhelhd9w4y0t1p7Tgr5xUNLBNujMVH0Yk6E51pbMCRXd1IBUf+jaf ulNFIREB9TpSYd+9Xpyg9C2zFPWgM1VUj63dqcJ6bO1K9a6Seg+rA1XI7bTenSrw8JZziK9Oi2Xe xupAFeBohhN+VyhfEI8eArUZnJ5NKxgMng5dLkbPjtXC4x0ZPW6lqyvjiTT1VIAlcC8n6wpIdFVO /5KzSrk9JyIrrN3jKagVwq5YcSnLyuzoxMdi2XzvpuIh4YfoBBuirhwU0Nbs3Apo05XWdyohmubU XGPdwHj7sHLbObo0snLrue9vzk67fT35coNcn1t4RIhQNMiuu9Mam3qW1e9462TDgISBu2FtyH40 nf3AixxDwaMRhB7h0QE9noUMyV/s8TdHA6/fqc+zgKJ1Z59fg/p4/+vQ5jd7YuE/rWS24zVnpC9P 3o9HySD5fDV2onh468W4/CztNigiJMGTeaiddvHni+T40352OY1jpmEgWEQ7WudBa95pWz8//jQ4 Ho3GcYwf2uPkc7a5HcgwXlFH25hPQ6ftODlOruP1h0mltR2xXZYZszMMbtjRMhV2hnGU+uk4Hn08 u0rOLi/AaZHSej7hHS0OeWs82deWX+zF0TQBhtJG2N4g6isQ3pgmalFWcga6WBIXUhShEGCP6hj5 iOInF5EdaL/D7q21GXYZXYsJMvw/AFwAoLAKZW5kc3RyZWFtDWVuZG9iag0xOSAwIG9iag08PCAN L1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjggMCBSIA0vUmVzb3VyY2VzIDIwIDAgUiANL0NvbnRlbnRz IDIxIDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5 MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjAgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAv VGV4dCBdIA0vRm9udCA8PCAvRjEgMzYgMCBSIC9GMyAzNCAwIFIgL0Y0IDQ3IDAgUiAvRjYgNDgg MCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgNTUgMCBSID4+IA0vQ29sb3JTcGFjZSA8PCAvQ3M1 IDM1IDAgUiA+PiANPj4gDWVuZG9iag0yMSAwIG9iag08PCAvTGVuZ3RoIDE2NzcgL0ZpbHRlciAv RmxhdGVEZWNvZGUgPj4gDXN0cmVhbQ0KSImUV1tzm0YYfdev2GleRMda741dyEwfZFlOnalkJyJp MkkfsEA2HQlcwFU8mf73fruAhCSQEJpBXJb9zp7vdvbK613eUESRt+i52JWIwM9cSIVt26VIUYqF IBx5q97lKLPRPDODCMrmvct3M4oesx5B3lyf1r0+sry/e2OvpyelegxFEeoVsyFFXEwlUgw7Ag2o 0Ddp2Fv0rjQOUeCgzEwPfxUG6SosSwwb2wOCCSHCWC6v1r1v/dHvw+k7C8b3x+iNnCPrL+/9qTVK R2Iu9Qyrg6Vc3shWWLAORgpYBg3doKElmlkYovmTH1sDTWP/MURvBHoO09yP4qPQqJKYcHfHhjGv l64tMLEB+q0fJGCAYdqfZ7eLD0l2nyaLWZ6k/mPovT6HpaGDhXBGMLUPjRh+DREVB8fpkwQ75efF BwSci6kQEnnXDSFRRoMUCgMKBuzb8pxw4DaW+3CNAxirHKCvNDN31kBg1n+wBhL+/g7nOcpe4+Iu twB33/8BNv2geDQwj9bAJoG71KJwFxVT5NbAhb8QlUPLx4tF+TwNq2lRUj5DH7cTz1Nr4OhxZk7f +KuCEKLcLxEui1nDrIiOJtY4x5xBgCjtgz3WGshidOOcrW91wnDN1aC61GR979/dWxCovD+zBhyr PprcXqHHlygIl1EMmDLgL0piJDGA/G6hbtkFXNqsQrCbXUWgcGYfDRTblbpgUOlCKTojUGzHBqoa 1s62a2e8SqG5BVWgDwl0bQm4SCwG57W51vkLdGS5BRNCWOiBoTmDIxW8WVlUvxmZ0ZDvcfF26fkP y+JywxU/xpWtgFinmasmYhTRqUOZ5tFcblk56hNbMqxkEzOmrPQnwy+D4Wg0ns1McgySePnaCsI2 RR28uA+ixbZNa9W2tK3519Qn63hk+FsO4fQDGaPer/Vq1ASBSywRs52OCJijc0J0Xf06jfLwApJh 2p0UZmNIUlPXuiCiCov9LD3k5CYN/3kJ43m7Wcqxy87wBZFQgk/a/TMK8qdWm4RBfkN2drQpXIHV aZuTJHhZ+qbctBgWLsVMnGHY4Rspc8TwbZyH6TL0/w1bDauiR3dlWUB/pfvZdmj4PlmHadlwyypR 1EdGTH08ngPCVlA6kOAHSXCiFggBZdU5Uguawn6RpGi7gCyHN6tyGabmoWj1vIygZeRPIVpFcbTy l63IhY0dBzF1UMVaAHMHk33AfW0wXIVxXsTMk5+hONFaK4uyHB4jnTtRaoZgdNh9TrDLTNcVnWMN +oHd2HoKUocZ8je81JBdwOOacqsxnjwY9RLBh0EQBihPUBQH0dzP2+MUejlUA+52rEKCiIZqoD04 m07ut1zOQdT6z/5DtIxy7eNkcTQWcLcizh1Xp7PomlXcoYfpXKN4mqDr8c3n4R+asyBcgIIJUPAS mpAMosVCS7YczRMdqb5eVAaxY7yQmfgeTYDrOGjFWygwancMWw7N+rAKjCbeLMwujKFaHGRNpDXI 6r1KQUAmHVNSHMSjg9SZgpszVlMlJfJqq+XojRZSfid9w6ku2fWtwg5Ihl0XQBKlG0pDO2+rZOY7 ipjrHnaWWkRcNwfpOM7TV/T27W9oNv7waTwdjdHPNmwMpCjMxvmplKogOU5Dz0G147D/BGj30A3p MUw5u2hF5QgtkLujgtAl56HaSo/uqBTXULqjkrYWpeIMVIUwOY8rqZsxxLToiMoWDXL1KKqadClR Tb3xu/HHdkw20R2wOybBdQc8B1NN1XTExF18jvM4PdTUxyEVeqd2eFD4noKr1ed2UKDc2Rk8MaJl 9Tmgym1HLaIKnor6Swo0XPdVpeBWF9t2tFSa/itOdbQKLnF3+i89DbeuFcxRe1BBNqvmEMVc8QJy WyMuYROtXZDdkWTqKl11W3dTFfb/ztVc1DENShld271bUVDbUuzh2etWD9ZA9KuOdbSnULndrbYj Be2tYAMqOkoBKvTtFiLdo+yom++u3o9H3sD7ej9uxSMkSHrwTEcpRUFRS2cPz8Zxs69Tb/gFHcRX q3VuQ3UC93Vlg6kdebFrfTL8Um0/UE0Ot9lmWuBQeSAdWkxDhhLSZnrmDb1Ps/Jm/pIavdhmmDKd NJSeyprKMmht1Zrr1+PZ6OPtvXd7N0WtFoneGnYohqVFV+9gjhWXX7wnrYGNf1GuHaxVcP4E8nme gD5+zl/0ZiVZ4zZIoOBBhjDVcb/hsB0VsotI67GfbfuKQrI5ZU0BJP8PACA1rMAKZW5kc3RyZWFt DWVuZG9iag0yMiAwIG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjggMCBSIA0vUmVzb3Vy Y2VzIDIzIDAgUiANL0NvbnRlbnRzIDI0IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSAN L0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjMgMCBvYmoN PDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzYgMCBSIC9GNCA0NyAw IFIgL0Y2IDQ4IDAgUiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDU1IDAgUiA+PiANL0NvbG9yU3Bh Y2UgPDwgL0NzNSAzNSAwIFIgPj4gDT4+IA1lbmRvYmoNMjQgMCBvYmoNPDwgL0xlbmd0aCAxNzEy IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnFffc5tGEH7XX7HTvIiMucBx/MpM H2RFSZWp7DQinWSSPiB0skkRKIDsejL937t7gIRkYaPaHgtOd7ff7X737e5lMHj11gQTgtXAZ74D Bv6qB4cz3/dNcE2TCWFYEKwHr8aFDVGhJhlQRINX7+Ym3BQDA4KI/t0PhqAF3weTYECbmjTHhBgG jsts2wfX8JnpgGszT4BuCnrJ5WA1uCQcosJhcrU9flSrTHB8lzk1hp1t3WCGYQhluX66H3wdjn8b Xb3TcP5wAi/AjUD7K3jfecjGgOcwy6Et1mozLvYHmksJ0W2Y3kh4IWAj8zKMU3VKhVId0WLctvAt eDMYLrOomK7eZPfpGFelMpmXWR7eyOBhI5tV6gCmwzzHtatlyoOV83TLYLbrWeggZgrhqF0fubX2 qONy5nhgmgZ66ByXOri5c8qluB6hfB0uNd1GL2YawnCGdCZN9/BpvNaIEsOymIX4nfoy0HSBn+Gi WpNouoUfUuM4r18AhM88r4azC0Dty/G6LOYPaTRNS5nfhckF7Mc/Rcv9MPkoeNleNk3v4lIuP2L4 4vRmVJZyvSmL9gbTtMCQNnu8rgNLrre4fRQZk3mGyw++3GPVYVpCXECUrTdJHKYlrLIcylscKsNF IiFbfJdRiW8ZLCTGKFzqWZo8QMtkE20dvg1n0yt9NB5P5vP93G9axRDOuGObHSgPWKJuMdieT/Tg FlEE2bWnyOlLb3t41OML1zrrPF7HSZjTUfZ0L0rEua5JH6gjq5MxgWzug7VitO14jHvgOgSzP6Ft 22HuMaEbOfCUGHhhw0Wn2qWOc8cFq11n+UzgBfO9Y9c9I5y2hVfDqzXlhA/f7Cg4C6NJWuYP8Pr1 rzCf/PFpcjWewM9ORNxjhgeW4fQMJjfQoUeeGULrZ38bxuEmXMRJXMayaM+4nAbzi05ApGRgWX3x YBJAve6Fp33t2zNo7EbmFu8GZdhM9AclKMX0BNXSHDgPlPCRzvwMVJSXeD9Us/CfOWKKIzldFueh 8jjlY8GNnqgwfxvH6tCBqpLXOEuPPBbEaxnE0d+oxQC6DteLIktkKaETpEt1yBmuc6zHNUMnyFNZ opfrHIP0ybJ7CquwORUaZ7juMdPIdc3oQRliCeZbqFNVHdKNWXiolGAJ3hOzMPB1j9l8koRRq9zZ z6gHSxrsgmW5JLS9Pcl9ktcOT/77v1KPoNrUpezTP+8IQyDsp/MOlkU96yDLx1LSeOTrDrwWpnWs R07kpo7dMa37/Gj30+VWK4jXl+8n40APvnyYdAJxPdQpBPIcpRogLk46BrIL3vzLVTD6fMic4CRz auv4iXnW9J7Tr8a67TMuuqzPRp+bugtaVVqXbdumy2Q6fUMg3Ccu0zwYBZ/m9Uu0zXOJZWSXZSFQ SrDyf+7CNJYtqqi6LL+ZzMcfpx+C6fXVCQmuLVqWKjx4X4vcPig8HgvHL8GthKKKMChx2NXMUZZG clNuUfny7J51YuJUZQE3n0sLDSbs1bxOTFSA/TyUs6oy8xpFabVKT2jLE3rBPQ+7iApA58XmmPdt DphnvUdN3YktKR8bR5Wm6uWMqo+tn+53uoS1TqVMUXdFrI5j0KpumLZL+sPdR85/RuY4tnv+cV3T 7i+kBGokkBUvBGwwDYZxCgfJDuPIbavOdZ0J6DBmuMY1Da/darWCdtD1dZ+ZCwqKqbh9Rp7gaBxL uRNBMm3C8HW41HSb2cNMQxj2kA6k6R4+jdeaSSOoytUMqvI03aJJmu7SQIAJBj/DRTUhqb6VGsf/ vfIONziVdDW6nUuCl+2oXKsGtl2dV/XmaLmO03kZltsC8OYqzbzPsaK6gDBdQpwu4ygssaEob2Wz 7TCkRTH2jGEZ30mol2crXAJhpMbGM9huqq4SfmzlFqWiMniB41mKhhZZVkKYJK341XEdqgUFhLmE paTKcqnAjGcF3Me4Ipd6Lm8QgMzZIbO4y5AkoqYWKlQuUZUk0bCg+ahL6APcO80qcdabFW3+hJtN 8sAOCWh0MO8EzUxhUadgGibK1Rk0M6nrPO5jKpqJFs1ERTOxo5moaeYM8QYpOomaTqKik1B0cvrR ycSWc9e37AkUkLDjX6jCUGxkFK/iCDLFK3biEjZUqytzqnyzbdlO0Qd8w8iWt5jK3v45+h2iJNwW kp2gxrSkZQuZxPIOaVHehqWi5iaXhYouspDe642INvQ6m17WUNHkCllBU8vsBGyaTacjM8V2hWeM KZHjXKLMUqKaJcTuHaNoxx/bOJdrfC5OYD4ky38DAFSqH7YKZW5kc3RyZWFtDWVuZG9iag0yNSAw IG9iag08PCANL1R5cGUgL1BhZ2UgDS9QYXJlbnQgMjggMCBSIA0vUmVzb3VyY2VzIDI2IDAgUiAN L0NvbnRlbnRzIDI3IDAgUiANL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAw IDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRvYmoNMjYgMCBvYmoNPDwgDS9Qcm9jU2V0 IFsgL1BERiAvVGV4dCBdIA0vRm9udCA8PCAvRjEgMzYgMCBSIC9GMyAzNCAwIFIgL0Y0IDQ3IDAg UiA+PiANL0V4dEdTdGF0ZSA8PCAvR1MxIDU1IDAgUiA+PiANL0NvbG9yU3BhY2UgPDwgL0NzNSAz NSAwIFIgPj4gDT4+IA1lbmRvYmoNMjcgMCBvYmoNPDwgL0xlbmd0aCAxNDE3IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJnFffc5tGEH7nr9hJX2AmnO83kJk+OFhKnamd1MJtMpk+ YIxsUhm5gO1xO/3fu3eHJNsSMq08FnC3x3679+23p/eZdzBlwCCbewlJNFD8szc6IkolDCLGiJRU QHbjHaStgqK1RhTawjv4MGNw1XqUUMolZIVHIXvw/PSnw9MPE/ghgSD7jmMhI0xwBdmRMSg8344f TIXzbN7GzPucJafOcv1SPyvrLu+q+xKK67y+KvvlbLOcbpYrrV84mmSeMbUuGFTgaU6SJMEYBYlj 4FTiQkqUhqb05t777GUurDkDrTWhscvFxukG5uWyaI/n6c0ZYqzqq6y6KZd3HXx6/3GSZmH29fNk C84KCV41sISPBKIkiekLID70n9nX0+zwi7s3GI7rrmzu88Wgc8WI4MBiOtK7FETxIe8nh1/CwzSd zGaA78kvw4em6spB3wJfjb712MgFNwSRA5Fnh9n5zN0Xd02DtBl0zGOiJTA2du85JbEcCvpoMkvP jj9nx59OBx2yiCBPhNAjHdJkXXjbDs3nzW951SHPoMNNhvmygRx66sFZ2d4u67aE27z4o+zIICqq jFOhR6JSSUyY3qBiW6ggu65aWF58L4sOTs5nGdTLDm7Lpq3aDvIOHVQ14s4X1V9Y08t6CJpKJNFY nWwstFhjNe+FtpxDd13CTV7nV+UltI9tV94Qp1F9hjnDEpcCH9Ya8mZl4DSKaFPvdn5bXlbYY0F4 DIyOpLWKFJF7lGUVwNlkOjmbnKaDQqIiDpLGI71qSfigjFiKHeVdHn66L5swzS8WJcxQSaqiBKsp 8xzvZrdlUc2rwu5l+w4ZeFktB+FpTB/IsUWnFN+jc/Yzbco/78q6eByCBLPP4dn0+J4TGh5TFVKJ f9HbQYQyMWLI+dgcSrZHDJ0qYSUYIAlhRL+11dpAJsibQQwiJihxjI9lvqAoLUOieDSZ/nr4M/yN fQ7+GXTJtZHD0a1QsXiPHL579yP6W7XDk7yY1F3zCLL3P3QgoESqKLaTUupNgT2zd0PhE9tnE3R7 +bNw7bEGpLJtBxXDxCtR0tbxHkylO1YwbuPCy+osJGVM5Es6hqZM0ShzBWvuHrxvfhaEWFx+HiAc 7l8EocLLIghRF/yytZ3RjYUBI7G/rJ9ZPLplAMHv2cfXjmhSRKYn9rDWh7DB2IUkqBJMsP8WPBfb YmEippHx+a0//QShJsKfVVcB0ijyaxOP8PPFL0GMj3erx6p7zPKLQOMYqoqNchdUbLrmdIBnUNs2 n2HdAdG0zF0QuVhDDAw8Q8tA4s1NwJSB2wXmkrvLXZsZrbOWw9CoSTpCs3XzKjSRKOwbO6mje2yG ANpfmp3XvkslHlH8FDHiTvkzN2/01yQRTYIwMgOWadrPL5zBws2WAcdFg/BFIuyZj9MR2GO2rcJj 0urS2SLB/1eKRZSgtCJRY8PX12Hq2LBxG6aQG5gRJsXCxH5rYKIAIEzz3dqEpf3YzA3mhs66t1iB jvYmVitbXXhGHkMLtaMDO1rIJ7SQjhZyTQvZ0wKhtSdGY+ykZQLapkGYuPCMBY4yM+wIIh1BpCWI 3hMH/igwpZdExLbC1wKRdHfpsU3ulc08osKUtyn+kKtLHFucdxUeBfHOtmvTxfG+wX/7k2UIHpLC lF+sRqXZdLed6J4wWPUMNgANedcQ8WEN0lIYYTomqL305dKeJOgYgGzHQceWWPS0xKJViUWuxCJb YpEtscg/shNL3NfIf6id2bXhDWKurfzWpVNcN7e8q91yN9rYb2QLNQtcdUZ7wjPHBLMDySht5kmy uzq5fhqhXkWoXYTaRqhthNo/txO3rhac1bV7sDtlli/ccB+b9t1oY79tbHIV24r8Q921P+nwOMKC ftJd14313wEA92TO4wplbmRzdHJlYW0NZW5kb2JqDTI4IDAgb2JqDTw8IA0vVHlwZSAvUGFnZXMg DS9LaWRzIFsgMzIgMCBSIDEgMCBSIDQgMCBSIDcgMCBSIDEwIDAgUiAxMyAwIFIgMTYgMCBSIDE5 IDAgUiAyMiAwIFIgMjUgMCBSIA1dIA0vQ291bnQgMTAgDT4+IA1lbmRvYmoNMjkgMCBvYmoNPDwg DS9DcmVhdGlvbkRhdGUgKEQ6MjAwNDA0MTUxMDAwMzgpDS9Qcm9kdWNlciAoQWNyb2JhdCBEaXN0 aWxsZXIgNC4wNSBmb3IgV2luZG93cykNL01vZERhdGUgKEQ6MjAwNDA0MTUxMDAwMzgtMDYnMDAn KQ0+PiANZW5kb2JqDXhyZWYNMCAzMCANMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDA1OTE1IDAw MDAwIG4NCjAwMDAwMDYwNjYgMDAwMDAgbg0KMDAwMDAwNjIzMiAwMDAwMCBuDQowMDAwMDA4MjIz IDAwMDAwIG4NCjAwMDAwMDgzNzQgMDAwMDAgbg0KMDAwMDAwODUxOCAwMDAwMCBuDQowMDAwMDEw MDU4IDAwMDAwIG4NCjAwMDAwMTAyMDkgMDAwMDAgbg0KMDAwMDAxMDM0MiAwMDAwMCBuDQowMDAw MDExOTAxIDAwMDAwIG4NCjAwMDAwMTIwNTUgMDAwMDAgbg0KMDAwMDAxMjIwMCAwMDAwMCBuDQow MDAwMDEzODc1IDAwMDAwIG4NCjAwMDAwMTQwMjkgMDAwMDAgbg0KMDAwMDAxNDE4NSAwMDAwMCBu DQowMDAwMDE2NDM4IDAwMDAwIG4NCjAwMDAwMTY1OTIgMDAwMDAgbg0KMDAwMDAxNjczNyAwMDAw MCBuDQowMDAwMDE4NTY5IDAwMDAwIG4NCjAwMDAwMTg3MjMgMDAwMDAgbg0KMDAwMDAxODg5MCAw MDAwMCBuDQowMDAwMDIwNjQyIDAwMDAwIG4NCjAwMDAwMjA3OTYgMDAwMDAgbg0KMDAwMDAyMDk1 MiAwMDAwMCBuDQowMDAwMDIyNzM5IDAwMDAwIG4NCjAwMDAwMjI4OTMgMDAwMDAgbg0KMDAwMDAy MzA0OSAwMDAwMCBuDQowMDAwMDI0NTQxIDAwMDAwIG4NCjAwMDAwMjQ2NjkgMDAwMDAgbg0KdHJh aWxlcg08PA0vU2l6ZSAzMA0vSURbPDZmZWM3YjAyMjViZmIwZGQ5NGJiMjY4NWE5ZTA5MWI0Pjw2 ZmVjN2IwMjI1YmZiMGRkOTRiYjI2ODVhOWUwOTFiND5dDT4+DXN0YXJ0eHJlZg0xNzMNJSVFT0YN ------_=_NextPart_001_01C42306.92AB2B66 Content-Type: text/plain; name="Considerations for adding StorageType objects RFIMibv2_revision2.txt" Content-Description: Considerations for adding StorageType objects RFIMibv2_revision2.txt Content-Disposition: attachment; filename="Considerations for adding StorageType objects RFIMibv2_revision2.txt" Content-Transfer-Encoding: base64 DQoKCgoKCgogICAgICAgICBDb25zaWRlcmF0aW9ucyBmb3IgYWRkaW5nIFN0b3JhZ2VUeXBlIG9i amVjdHMgdG8gTUlCIE1vZHVsZSBET0NTLQ0KICAgICAgICAgSUYtTUlCIGluIGRyYWZ0IGRyYWZ0 LWlldGYtaXBjZG4tZG9jcy1yZm1pYnYyLTEwLnR4dCANCiAgICAgICAgIFJldmlzaW9uLTIgDQog ICAgICAgICAgDQogICAgICAgICBNb2RpZmljYXRpb25zIGJhc2VkIG9uICJHdWlkZWxpbmVzIGZv ciBNSUIgQXV0aG9ycyBhbmQgUmV2aWV3ZXJzIiBkcmFmdC1pZXRmLQ0KICAgICAgICAgb3BzLW1p Yi1yZXZpZXctZ3VpZGVsaW5lcy0wMi50eHQsIHNlY3Rpb25zIDQuNi4yIGFuZCA0LjYuNCBwZXJ0 YWluIA0KICAgICAgICAgaW5pdGlhbGl6YXRpb24gYW5kIHBlcnNpc3RlbmNlIGNvbmRpdGlvbnMg dXBvbiByZWJvb3QgZm9yIHJlYWQtd3JpdGUgYW5kIHJlYWQtDQogICAgICAgICBjcmVhdGUgTUlC IG9iamVjdHMuICANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgIGNoYW5nZXMgZm9y IGRyYWZ0LWlldGYtaXBjZG4tZG9jcy1yZm1pYnYyLTEwLnR4dCANCiAgICAgICAgICANCiAgICAg ICAgIENoYW5nZSAgICAgICBOb3RlIA0KICAgICAgICAgQ2hhbmdlICMxICAgICBOZXcgcmVxdWly ZW1lbnQgV0cgTGFzdCBDYWxsIA0KICAgICAgICAgQ2hhbmdlICMyICAgICBOZXcgcmVxdWlyZW1l bnQgV0cgTGFzdCBDYWxsICh1cGRhdGVkKSANCiAgICAgICAgIENoYW5nZSAjMyAgICAgTmV3IHJl cXVpcmVtZW50IFdHIExhc3QgQ2FsbCANCiAgICAgICAgIENoYW5nZSAjNCAgICAgTmV3IHJlcXVp cmVtZW50IFdHIExhc3QgQ2FsbCANCiAgICAgICAgIENoYW5nZSAjNSAgICAgQ2xhcmlmaWNhdGlv biBPUFMgTUlCIGd1aWRlbGluZXMgKHVwZGF0ZWQpIA0KICAgICAgICAgQ2hhbmdlICM2ICAgICBD bGFyaWZpY2F0aW9uIE9QUyBNSUIgZ3VpZGVsaW5lcyAgDQogICAgICAgICAgICAgICAgICAgICAg Q2hhbmdlZDogDQogICAgICAgICAgICAgICAgICAgICAgIzZhLCAjNmIsICM2YyANCiAgICAgICAg IENoYW5nZSAjNyAgICAgQ2xhcmlmaWNhdGlvbiBPUFMgTUlCIGd1aWRlbGluZXMgDQogICAgICAg ICAgICAgICAgICAgICAgQ2hhbmdlZDogDQogICAgICAgICAgICAgICAgICAgICAgIzdhLCAjN2Is ICM3YyANCiAgICAgICAgIENoYW5nZSAjOCAgICAgQ2xhcmlmaWNhdGlvbiBPUFMgTUlCIGd1aWRl bGluZXMgDQogICAgICAgICAgICAgICAgICAgICAgQ2hhbmdlZDogDQogICAgICAgICAgICAgICAg ICAgICAgIzhhLCAjOGIsICM4YyANCiAgICAgICAgIENoYW5nZSAjOSAgICAgVGVudGF0aXZlIGNo YW5nZXMgZm9yIGRvY3NJZkNtUmFuZ2luZ1RpbWVvdXQgIA0KICAgICAgICAgb3RoZXJzICAgICAg IFVwZGF0ZSBkb2N1bWVudCBrZXlzIHRvIHVwcGVyY2FzZSANCiAgICAgICAgICAgICAgICAgICAg ICBNQVkgTVVTVCwgTVVTVCBOT1QsIHVwZGF0ZWQgUkZJIHJlZmVyZW5jZXMgdG8gU1AtDQogICAg ICAgICAgICAgICAgICAgICAgUkZJdjIuMC1JMDUtMDQwNDA3IA0KICAgICAgICAgIA0KICAgICAg ICAgIA0KICAgICAgICAgIA0KICAgICAgICAgZG9jc0lmQ210c01vZHVsYXRpb25UYWJsZSANCiAg ICAgICAgIFJlYWQtY3JlYXRlIA0KICAgICAgICAgIA0KICAgICAgICAgQWRkZWQ6ICANCiAgICAg ICAgICANCiAgICAgICAgIENoYW5nZSAjMSANCiAgICAgICAgICANCiAgICAgICAgRG9jc0lmQ210 c01vZHVsYXRpb25FbnRyeSA6Oj0gU0VRVUVOQ0UgeyANCiAgICAgICAgICAgICAgICAgICAgZG9j c0lmQ210c01vZEluZGV4ICAgICAgICAgICAgICAgICAgICBJbnRlZ2VyMzIsIA0KICAgICAgICAg ICAgICAgICAgICBkb2NzSWZDbXRzTW9kSW50ZXJ2YWxVc2FnZUNvZGUgICAgICAgIElOVEVHRVIs IA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kQ29udHJvbCAgICAgICAgICAgICAg ICAgIFJvd1N0YXR1cywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RUeXBlICAg ICAgICAgICAgICAgICAgICAgSU5URUdFUiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNt dHNNb2RQcmVhbWJsZUxlbiAgICAgICAgICAgICAgSW50ZWdlcjMyLCANCiAgICAgICAgICAgICAg ICAgICAgZG9jc0lmQ210c01vZERpZmZlcmVudGlhbEVuY29kaW5nICAgICBUcnV0aFZhbHVlLCAN CiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c01vZEZFQ0Vycm9yQ29ycmVjdGlvbiAgICAg ICBJbnRlZ2VyMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kRkVDQ29kZXdv cmRMZW5ndGggICAgICAgIEludGVnZXIzMiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNt dHNNb2RTY3JhbWJsZXJTZWVkICAgICAgICAgICAgSW50ZWdlcjMyLCANCiAgICAgICAgICAgICAg ICAgICAgZG9jc0lmQ210c01vZE1heEJ1cnN0U2l6ZSAgICAgICAgICAgICBJbnRlZ2VyMzIsIA0K ICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kR3VhcmRUaW1lU2l6ZSAgICAgICAgICAg IFVuc2lnbmVkMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kTGFzdENvZGV3 b3JkU2hvcnRlbmVkICAgIFRydXRoVmFsdWUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZD bXRzTW9kU2NyYW1ibGVyICAgICAgICAgICAgICAgIFRydXRoVmFsdWUsIAwNCgoKCgoKICAgICAg ICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kQnl0ZUludGVybGVhdmVyRGVwdGggICAgIFVuc2ln bmVkMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kQnl0ZUludGVybGVhdmVy QmxvY2tTaXplIFVuc2lnbmVkMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9k UHJlYW1ibGVUeXBlICAgICAgICAgICAgIElOVEVHRVIsIA0KICAgICAgICAgICAgICAgICAgICBk b2NzSWZDbXRzTW9kVGNtRXJyb3JDb3JyZWN0aW9uT24gICAgIFRydXRoVmFsdWUsIA0KICAgICAg ICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2NkbWFJbnRlcmxlYXZlclN0ZXBTaXplIFVuc2ln bmVkMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kU2NkbWFTcHJlYWRlckVu YWJsZSAgICAgIFRydXRoVmFsdWUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9k U2NkbWFTdWJmcmFtZUNvZGVzICAgICAgIFVuc2lnbmVkMzIsIA0KICAgICAgICAgICAgICAgICAg ICBkb2NzSWZDbXRzTW9kQ2hhbm5lbFR5cGUgICAgICAgICAgICAgIERvY3Npc1Vwc3RyZWFtVHlw ZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTdG9yYWdlVHlwZSAgICAgICAg ICAgICAgU3RvcmFnZVR5cGUgDQogICAgICAgICAgICAgICAgfSANCiAgICAgICAgICANCiAgICAg ICAgIE5vdGUgQWxzbyBhZGRlZCBTdG9yYWdlVHlwZSBUQyB0byBJTVBPUlRTIHNlY3Rpb24uIA0K ICAgICAgICAgIA0KICAgICAgICAgQ2hhbmdlICMyIA0KICAgICAgICAgIA0KICAgICAgICBkb2Nz SWZDbXRzTW9kdWxhdGlvbkVudHJ5IE9CSkVDVC1UWVBFIA0KICAgICAgICAgICAgICAgIFNZTlRB WCAgICAgIERvY3NJZkNtdHNNb2R1bGF0aW9uRW50cnkgDQogICAgICAgICAgICAgICAgTUFYLUFD Q0VTUyAgbm90LWFjY2Vzc2libGUgDQogICAgICAgICAgICAgICAgU1RBVFVTICAgICAgY3VycmVu dCANCiAgICAgICAgICAgICAgICBERVNDUklQVElPTiANCiAgICAgICAgICAgICAgICAgICAgIkRl c2NyaWJlcyBhIG1vZHVsYXRpb24gcHJvZmlsZSBmb3IgYW4gSW50ZXJ2YWwgVXNhZ2UgQ29kZSAN CiAgICAgICAgICAgICAgICAgICAgIGZvciBvbmUgb3IgbW9yZSB1cHN0cmVhbSBjaGFubmVscy4g DQogICAgICAgICAgICAgICAgICAgICBFbnRyaWVzIGluIHRoaXMgdGFibGUgYXJlIGNyZWF0ZWQg YnkgdGhlIG9wZXJhdG9yLiANCiAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgSW5pdGlh bCBkZWZhdWx0IGVudHJpZXMgbWF5IGJlIGNyZWF0ZWQgYXQgc3lzdGVtICANCiAgICAgICAgICAg ICAgICAgICAgIGluaXRpYWxpemF0aW9uIHRpbWUsIHdoaWNoIGNvdWxkIHJlcG9ydCBhIHZhbHVl ICANCiAgICAgICAgICAgICAgICAgICAgICdwZXJtYW5lbnQnIG9yICdyZWFkT25seScgZm9yIGRv Y3NJZkNtdHNNb2RTdG9yYWdlVHlwZS4gDQogICAgICAgICAgICAgICAgICAgICBBIENNVFMgbWF5 IHJlamVjdCB0aGUgY3JlYXRpb24gb2YgYWRkaXRpb25hbCBJbnRlcnZhbCANCiAgICAgICAgICAg ICAgICAgICAgIFVzYWdlIENvZGVzIGZvciBhIG1vZHVsYXRpb24gcHJvZmlsZSBiZWluZyBkZWZp bmVkIGF0ICANCiAgICAgICAgICAgICAgICAgICAgIEluaXRpYWxpemF0aW9uIHRpbWUuIA0KICAg ICAgICAgDQogICAgICAgICAgICAgICAgICAgICBObyBpbmRpdmlkdWFsIG9iamVjdHMgaGF2ZSB0 byBiZSBzcGVjaWZpZWQgaW4gb3JkZXIgDQogICAgICAgICAgICAgICAgICAgICB0byBjcmVhdGUg YW4gZW50cnkgaW4gdGhpcyB0YWJsZS4gDQogICAgICAgICAgICAgICAgICAgICBOb3RlIHRoYXQg c29tZSBvYmplY3RzIGRvIG5vdCBoYXZlIGRlZmF1bHQgdmFsdWUgLCAgDQogICAgICAgICAgICAg ICAgICAgICBidXQgZG8gaGF2ZSBjYWxjdWxhdGVkIGRlZmF1bHRzIGFuZCBuZWVkIG5vdCBiZSBz cGVjaWZpZWQgDQogICAgICAgICAgICAgICAgICAgICBkdXJpbmcgcm93IGNyZWF0aW9uLiANCiAg ICAgICAgICAgICAgICAgICAgIFRoZXJlIGlzIG5vIHJlc3RyaWN0aW9uIG9uIHRoZSBjaGFuZ2lu ZyBvZiB2YWx1ZXMgaW4gdGhpcyANCiAgICAgICAgICAgICAgICAgICAgIHRhYmxlIHdoaWxlIHRo ZWlyIGFzc29jaWF0ZWQgcm93cyBhcmUgYWN0aXZlIHdpdGggdGhlICANCiAgICAgICAgICAgICAg ICAgICAgIGV4Y2VwdGlvbiBvZjogDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIDEu IElmIGEgbW9kdWxhdGlvbiBwcm9maWxlIGlzIGluIHVzZSBieSBvbmUgb3IgbW9yZSAgDQogICAg ICAgICAgICAgICAgICAgICAgICB1cHN0cmVhbSBjaGFubmVscywgdGhlIHZhbHVlIG9mIGRvY3NJ ZkNtdHNNb2RDaGFubmVsVHlwZSANCiAgICAgICAgICAgICAgICAgICAgICAgIE1VU1QgTk9UIGJl IGNoYW5nZWQuIA0KICAgICAgICAgICAgICAgICAgICAgMi4gSWYgYSBtb2R1bGF0aW9uIHByb2Zp bGUgaXMgaW4gdXNlIGJ5IG9uZSBvciBtb3JlICANCiAgICAgICAgICAgICAgICAgICAgICAgIHVw c3RyZWFtIGNoYW5uZWxzLCB0aGUgdmFsdWUgb2YgZG9jc0lmQ210c01vZENvbnRyb2wgIA0KICAg ICAgICAgICAgICAgICAgICAgICAgTVVTVCBOT1QgYmUgc2V0IHRvIGRlc3Ryb3koNikgb3Igbm90 SW5TZXJ2aWNlKDIpLiIgDQogICAgICAgICAgICAgICAgSU5ERVggeyBkb2NzSWZDbXRzTW9kSW5k ZXgsIGRvY3NJZkNtdHNNb2RJbnRlcnZhbFVzYWdlQ29kZX0gDQogICAgICAgICAgICAgICAgOjo9 IHsgZG9jc0lmQ210c01vZHVsYXRpb25UYWJsZSAxIH0gDQogICAgICAgICANCiAgICAgICAgICAN CiAgICAgICAgIENoYW5nZSAjMyANCiAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICBkb2Nz SWZDbXRzTW9kU3RvcmFnZVR5cGUgT0JKRUNULVRZUEUgDQogICAgICAgICAgICAgICAgIFNZTlRB WCAgICAgICBTdG9yYWdlVHlwZSAMDQoKCgoKCiAgICAgICAgICAgICAgICAgTUFYLUFDQ0VTUyAg IHJlYWQtY3JlYXRlIA0KICAgICAgICAgICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudCANCiAg ICAgICAgICAgICAgICAgREVTQ1JJUFRJT04gIA0KICAgICAgICAgICAgICAgICAgICAgIlRoZSBz dG9yYWdlIHR5cGUgZm9yIHRoaXMgY29uY2VwdHVhbCByb3cuIA0KICAgICAgICAgICAgICAgICAg ICAgIENvbmNlcHR1YWwgcm93cyBoYXZpbmcgdGhlIHZhbHVlICdwZXJtYW5lbnQnIG5lZWQgbm90 IA0KICAgICAgICAgICAgICAgICAgICAgIGFsbG93IHdyaXRlLWFjY2VzcyB0byBhbnkgY29sdW1u YXIgb2JqZWN0cyBpbiB0aGUgcm93LiIgDQogICAgICAgICAgICAgICAgIERFRlZBTCAgICAgIHsg bm9uVm9sYXRpbGUgfSANCiAgICAgICAgICAgICAgICAgOjo9IHsgZG9jc0lmQ210c01vZHVsYXRp b25FbnRyeSAyMiB9IA0KICAgICAgICAgIA0KICAgICAgICAgIA0KICAgICAgICBkb2NzSWZCYXNp Y0NvbXBsaWFuY2VWMiBNT0RVTEUtQ09NUExJQU5DRSANCiAgICAgICAgICAgICAgICBTVEFUVVMg ICAgICBjdXJyZW50IA0KICAgICAgICAgICAgICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAgICAg ICAgICAgICAiVGhlIGNvbXBsaWFuY2Ugc3RhdGVtZW50IGZvciBkZXZpY2VzIHRoYXQgaW1wbGVt ZW50IA0KICAgICAgICAgICAgICAgICAgICAgTUNOUy9ET0NTSVMgY29tcGxpYW50IFJhZGlvIEZy ZXF1ZW5jeSBJbnRlcmZhY2VzLiIgDQogICAgICAgICANCiAgICAgICAgTU9EVUxFICAtLSBkb2Nz SWZNaWIgDQogICAgICAgICANCiAgICAgICAgLS0gdW5jb25kaXRpb25hbGx5IG1hbmRhdG9yeSBn cm91cHMgDQogICAgICAgIE1BTkRBVE9SWS1HUk9VUFMgeyANCiAgICAgICAgICAgICAgICBkb2Nz SWZCYXNpY0dyb3VwVjIgDQogICAgICAgICAgICAgICAgfSANCiAgICAgICAgIA0KICAgICAgICAt LSBjb25kaXRpb25hbGx5IG1hbmRhdG9yeSBncm91cCANCiAgICAgICAgR1JPVVAgZG9jc0lmQ21H cm91cFYyIA0KICAgICAgICAgICAgICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAgICAgICAgICAg ICAiVGhpcyBncm91cCBpcyBpbXBsZW1lbnRlZCBvbmx5IGluIENhYmxlIE1vZGVtcywgbm90IGlu IA0KICAgICAgICAgICAgICAgICAgICAgQ2FibGUgTW9kZW0gVGVybWluYXRpb24gU3lzdGVtcy4i IA0KICAgICAgICAgDQogICAgICAgIC0tIGNvbmRpdGlvbmFsbHkgbWFuZGF0b3J5IGdyb3VwIA0K ICAgICAgICBHUk9VUCBkb2NzSWZDbXRzR3JvdXBWMiANCiAgICAgICAgICAgICAgICBERVNDUklQ VElPTiANCiAgICAgICAgICAgICAgICAgICAgIlRoaXMgZ3JvdXAgaXMgaW1wbGVtZW50ZWQgb25s eSBpbiBDYWJsZSBNb2RlbSBUZXJtaW5hdGlvbiANCiAgICAgICAgICAgICAgICAgICAgIFN5c3Rl bXMsIG5vdCBpbiBDYWJsZSBNb2RlbXMuIiANCiAgICAgICAgIA0KICAgICAgICAtLSBPcHRpb25h bCBncm91cHMgDQogICAgICAgICANCiAgICAgICAgR1JPVVAgZG9jc0lmQ210c09wdGlvbmFsR3Jv dXBWMiANCiAgICAgICAgICAgICAgICBERVNDUklQVElPTiANCiAgICAgICAgICAgICAgICAgICAg IlRoaXMgZ3JvdXAgaXMgb3B0aW9uYWwgZm9yIENhYmxlIE1vZGVtIFRlcm1pbmF0aW9uIFN5c3Rl bXMsIA0KICAgICAgICAgICAgICAgICAgICAgYW5kIG5vdCBhcHBsaWNhYmxlIGZvciBDYWJsZSBN b2RlbXMuIiANCiAgICAgICAgIA0KICAgICAgICAgLi4uIChtdWx0aXBsZSBPQkpFQ1QgY29tcGxp YW5jZXMgKSAuLi4gDQogICAgICAgICANCiAgICAgICAgT0JKRUNUICBkb2NzSWZDbXRzTW9kU3Rv cmFnZVR5cGUgDQogICAgICAgICAgICAgICAgU1lOVEFYIFN0b3JhZ2VUeXBlIHsgbm9uVm9sYXRp bGUoMykgfSANCiAgICAgICAgICAgICAgICBERVNDUklQVElPTiANCiAgICAgICAgICAgICAgICAg ICAgIkl0IGlzIGNvbXBsaWFudCB0byBvbmx5IHN1cHBvcnQgbm9udm9sYXRpbGUgc3RvcmFnZS4i IA0KICAgICAgICAgDQogICAgICAgICAgICAgICAgOjo9IHsgZG9jc0lmQ29tcGxpYW5jZXNWMiAx IH0gDQogICAgICAgICANCiAgICAgICAgIA0KICAgICAgICAgIA0KICAgICAgICAgQ2hhbmdlICM0 IA0KICAgICAgICAgDA0KCgoKCgogICAgICAgIE5vdGUgdGhhdCBvYmplY3RzICBkb2NzSWZEb3du Q2hhbm5lbFN0b3JhZ2VUeXBlIGFuZCBkb2NzSWZRb3NQcm9mU3RvcmFnZVR5cGUgDQogICAgICAg IGNvcnJlc3BvbmRpbmcgdGFibGVzIGFyZSBpbiBkb2NzSWZCYXNpY0dyb3VwVjIgZ3JvdXAgYnV0 IHRoaXMgc3BlY2lmaWMgdHdvIA0KICAgICAgICBvYmplY3RzIGFyZSBwbGFjZWQgaW4gZG9jc0lm Q210c0dyb3VwVjIgc2luY2UgdGhvc2UgcGFyYW1ldGVycyBhcmUgbm90IG5lZWRlZCANCiAgICAg ICAgZHVlIENNJ3MgcmVhZC1vbmx5IGNvbXBsaWFuY2UgcmVxdWlyZW1lbnRzLiANCiAgICAgICAg IA0KICAgICAgICBkb2NzSWZDbXRzR3JvdXBWMiBPQkpFQ1QtR1JPVVAgDQogICAgICAgICAgICAg ICAgT0JKRUNUUyB7IA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzQ2FwYWJpbGl0aWVz LCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c1N5bmNJbnRlcnZhbCwgDQogICAgICAg ICAgICAgICAgICAgIGRvY3NJZkNtdHNVY2RJbnRlcnZhbCwgDQogICAgICAgICAgICAgICAgICAg IGRvY3NJZkNtdHNNYXhTZXJ2aWNlSWRzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210 c0ludml0ZWRSYW5naW5nQXR0ZW1wdHMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRz SW5zZXJ0SW50ZXJ2YWwsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTWFjU3RvcmFn ZVR5cGUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzSW52YWxpZFJhbmdl UmVxcywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNTdGF0dXNSYW5naW5nQWJvcnRl ZHMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzSW52YWxpZFJlZ1JlcXMs IA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzRmFpbGVkUmVnUmVxcywgDQog ICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNTdGF0dXNJbnZhbGlkRGF0YVJlcXMsIA0KICAg ICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU3RhdHVzVDVUaW1lb3V0cywgDQogICAgICAgICAg ICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01hY0FkZHJlc3MsIA0KICAgICAgICAgICAgICAg ICAgICBkb2NzSWZDbXRzQ21TdGF0dXNEb3duQ2hhbm5lbElmSW5kZXgsIA0KICAgICAgICAgICAg ICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNVcENoYW5uZWxJZkluZGV4LCANCiAgICAgICAgICAg ICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzUnhQb3dlciwgDQogICAgICAgICAgICAgICAgICAg IGRvY3NJZkNtdHNDbVN0YXR1c1RpbWluZ09mZnNldCwgDQogICAgICAgICAgICAgICAgICAgIGRv Y3NJZkNtdHNDbVN0YXR1c0VxdWFsaXphdGlvbkRhdGEsIA0KICAgICAgICAgICAgICAgICAgICBk b2NzSWZDbXRzQ21TdGF0dXNWYWx1ZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHND bVN0YXR1c1VuZXJyb3JlZHMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0 dXNDb3JyZWN0ZWRzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzVW5j b3JyZWN0YWJsZXMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNTaWdu YWxOb2lzZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01pY3JvcmVm bGVjdGlvbnMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNFeHRVbmVy cm9yZWRzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRXh0Q29ycmVj dGVkcywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c0V4dFVuY29ycmVj dGFibGVzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzRG9jc2lzUmVn TW9kZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNDbVN0YXR1c01vZHVsYXRpb25U eXBlLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5ldEFkZHJlc3NU eXBlLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0NtU3RhdHVzSW5ldEFkZHJlc3Ms IA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNWYWx1ZUxhc3RVcGRhdGUs IA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzQ21TdGF0dXNIaWdoUmVzb2x1dGlvblRp bWluZ09mZnNldCwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNTZXJ2aWNlQWRtaW5T dGF0dXMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZVFvc1Byb2ZpbGUs IA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZUNyZWF0ZVRpbWUsIA0KICAg ICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzU2VydmljZUluT2N0ZXRzLCANCiAgICAgICAgICAg ICAgICAgICAgZG9jc0lmQ210c1NlcnZpY2VJblBhY2tldHMsIA0KICAgICAgICAgICAgICAgICAg ICBkb2NzSWZDbXRzU2VydmljZU5ld0NtU3RhdHVzSW5kZXgsIA0KICAgICAgICAgICAgICAgICAg ICBkb2NzSWZDbXRzTW9kVHlwZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RD b250cm9sLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c01vZFByZWFtYmxlTGVuLCAN CiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c01vZERpZmZlcmVudGlhbEVuY29kaW5nLCAN CiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c01vZEZFQ0Vycm9yQ29ycmVjdGlvbiwgDQog ICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RGRUNDb2Rld29yZExlbmd0aCwgDQogICAg ICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RTY3JhbWJsZXJTZWVkLCANCiAgICAgICAgICAg ICAgICAgICAgZG9jc0lmQ210c01vZE1heEJ1cnN0U2l6ZSwgDQogICAgICAgICAgICAgICAgICAg IGRvY3NJZkNtdHNNb2RHdWFyZFRpbWVTaXplLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lm Q210c01vZExhc3RDb2Rld29yZFNob3J0ZW5lZCwgDA0KCgoKCgogICAgICAgICAgICAgICAgICAg IGRvY3NJZkNtdHNNb2RTY3JhbWJsZXIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRz TW9kQnl0ZUludGVybGVhdmVyRGVwdGgsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRz TW9kQnl0ZUludGVybGVhdmVyQmxvY2tTaXplLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lm Q210c01vZFByZWFtYmxlVHlwZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RU Y21FcnJvckNvcnJlY3Rpb25PbiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNb2RT Y2RtYUludGVybGVhdmVyU3RlcFNpemUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRz TW9kU2NkbWFTcHJlYWRlckVuYWJsZSwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNN b2RTY2RtYVN1YmZyYW1lQ29kZXMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9k Q2hhbm5lbFR5cGUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzTW9kU3RvcmFnZVR5 cGUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzUW9zUHJvZmlsZVBlcm1pc3Npb25z LCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0NtUHRyLCANCiAgICAgICAgICAgICAg ICAgICAgZG9jc0lmQ210c0NoYW5uZWxVdGlsaXphdGlvbkludGVydmFsLCANCiAgICAgICAgICAg ICAgICAgICAgZG9jc0lmQ210c0NoYW5uZWxVdFV0aWxpemF0aW9uLCANCiAgICAgICAgICAgICAg ICAgICAgZG9jc0lmQ210c0Rvd25DaG5sQ3RySWQsIA0KICAgICAgICAgICAgICAgICAgICBkb2Nz SWZDbXRzRG93bkNobmxDdHJUb3RhbEJ5dGVzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lm Q210c0Rvd25DaG5sQ3RyVXNlZEJ5dGVzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210 c0Rvd25DaG5sQ3RyRXh0VG90YWxCeXRlcywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNt dHNEb3duQ2hubEN0ckV4dFVzZWRCeXRlcywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNt dHNVcENobmxDdHJJZCwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJU b3RhbE1zbG90cywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNVcENobmxDdHJVY2Fz dEdyYW50ZWRNc2xvdHMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzVXBDaG5sQ3Ry VG90YWxDbnRuTXNsb3RzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 clVzZWRDbnRuTXNsb3RzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 ckV4dFRvdGFsTXNsb3RzLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c1VwQ2hubEN0 ckV4dFVjYXN0R3JhbnRlZE1zbG90cywgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNV cENobmxDdHJFeHRUb3RhbENudG5Nc2xvdHMsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZD bXRzVXBDaG5sQ3RyRXh0VXNlZENudG5Nc2xvdHMgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJ ZkRvd25DaGFubmVsU3RvcmFnZVR5cGUsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZRb3NQ cm9mU3RvcmFnZVR5cGUgIA0KICAgICAgICAgICAgICAgIH0gDQogICAgICAgICAgICAgICAgU1RB VFVTICAgICAgY3VycmVudCANCiAgICAgICAgICAgICAgICBERVNDUklQVElPTiANCiAgICAgICAg ICAgICAgICAgICAgIkdyb3VwIG9mIG9iamVjdHMgaW1wbGVtZW50ZWQgaW4gQ2FibGUgTW9kZW0g VGVybWluYXRpb24gDQogICAgICAgICAgICAgICAgICAgICBTeXN0ZW1zLiIgDQogICAgICAgICAg ICAgICAgOjo9IHsgZG9jc0lmR3JvdXBzVjIgMyB9IA0KICAgICAgICAgDQogICAgICAgIFJlbGF0 ZWQgY2hhbmdlcyBmb3IgRG9jdW1lbnQgY29uc2lzdGVuY3kuIA0KICAgICAgICAgDQogICAgICAg ICANCiAgICAgICAgIGRvY3NJZlVwc3RyZWFtQ2hhbm5lbFRhYmxlIA0KICAgICAgICAgIA0KICAg ICAgICAgQnkgUkZDIDI2NzAgdGhpcyB0YWJsZSBpcyByZWFkLXdyaXRlLCBhbmQgaXMgYW4gZXh0 ZW5zaW9uIG9mIGlmVGFibGUgZm9yIERPQ1NJUyANCiAgICAgICAgIHVwc3RyZWFtIGNoYW5uZWxz IGFuZCB1cHN0cmVhbSBsb2dpY2FsIGNoYW5uZWxzIA0KICAgICAgICAgVGhlIHJlYWQtY3JlYXRl IHN5bnRheCB3YXMgaW50cm9kdWNlZCBieSBSRkkgTUlCdjIgYXMgYSBtZXRob2QgZm9yIGNyZWF0 aW9uIG9mIA0KICAgICAgICAgdGVtcG9yYXJ5IHJvd3MgdXNlZCBmb3Igb2ZmLWxpbmUgcGFyYW1l dGVycyBhZGp1c3RtZW50cy4gDQogICAgICAgICAgDQogICAgICAgICAgDQogICAgICAgICBGb3Ig dGhlIG1hbmRhdG9yeSBwcm9jZWR1cmUsIEl0IHdhcyBzdWdnZXN0ZWQgYnkgUmFuZHkgUHJlc3Vo biB1c2luZyBlcnJvciBjb2RlIA0KICAgICAgICAgJ2luY29uc2lzdGVudFZhbHVlJy4gQ3VycmVu dGx5IHRoZSBvYmplY3QgJ2RvY3NJZlVwQ2hhbm5lbFVwZGF0ZSAgDQogICAgICAgICBoYXMgb3Ro ZXIgZXJyb3IgY29kZXMgZGVwZW5kaW5nIG9uIFNOTVB2MSBvciBTTk1QdjIvdjMuIA0KICAgICAg ICAgSXQgaXMgY29udmVuaWVudCB0byByZW1vdmUgdGhpcyBvdmVybGFwcGluZyByZXF1aXJlbWVu dCAgDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIDQuIFVwZGF0ZSB0aGUgcGh5c2lj YWwgcm93IGJ5IHNldHRpbmcgdGhlIG9iamVjdCANCiAgICAgICAgICAgICAgICAgICAgICAgIGRv Y3NJZlVwQ2hhbm5lbFVwZGF0ZSB0byB0cnVlKDEpLiANCiAgICAgICAgICAMDQoKCgoKCiAgICAg ICAgIEZyb20gZG9jc0lmVXBDaGFubmVsVXBkYXRlIA0KICAgICAgICAgDQogICAgICAgICAgICAg ICAgREVTQ1JJUFRJT04gDQogICAgICAgICAgICAgICAgICAgICIgVXNlZCB0byBwZXJmb3JtIHRo ZSB0cmFuc2ZlciBvZiBhZGp1c3RlZCBwYXJhbWV0ZXJzICANCiAgICAgICAgICAgICAgICAgICAg IGZyb20gdGhlIHRlbXBvcmFyeSB1cHN0cmVhbSByb3cgdG8gdGhlIHBoeXNpY2FsIHVwc3RyZWFt ICANCiAgICAgICAgICAgICAgICAgICAgIHJvdyBpbmRpY2F0ZWQgYnkgdGhlIGRvY3NJZlVwQ2hh bm5lbENsb25lRnJvbSBvYmplY3QuICBUaGUgIA0KICAgICAgICAgICAgICAgICAgICAgdHJhbnNm ZXIgaXMgaW5pdGlhdGVkIHRocm91Z2ggYW4gU05NUCBTRVQgdG8gJ3RydWUnIG9mICANCiAgICAg ICAgICAgICAgICAgICAgIHRoaXMgb2JqZWN0LiAgVGhlIFNOTVAgU0VUIGZhaWx1cmUgcmV0dXJu cyBhbiBlcnJvciAgDQogICAgICAgICAgICAgICAgICAgICBnZW5FcnJvciAoc25tcHYxKSBvciBj b21taXRGYWlsZWQgKHNubXB2MmMvdjMpIGlmIHRoZSANCiAgICAgICAgICAgICAgICAgICAgIGFk anVzdGVkIHBhcmFtZXRlciB2YWx1ZXMgYXJlIG5vdCBjb21wYXRpYmxlIHdpdGggZWFjaCANCiAg ICAgICAgICAgICAgICAgICAgIG90aGVyLiAgUmVhZGluZyB0aGlzIG9iamVjdCBhbHdheXMgcmV0 dXJuICdmYWxzZScuIiANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgIENIQU5HRSAj IDUgDQogICAgICAgICANCiAgICAgICAgZG9jc0lmVXBDaGFubmVsU3RhdHVzIE9CSkVDVC1UWVBF IA0KICAgICAgICAgICAgICAgIFNZTlRBWCAgICAgIFJvd1N0YXR1cyANCiAgICAgICAgICAgICAg ICBNQVgtQUNDRVNTICByZWFkLWNyZWF0ZSANCiAgICAgICAgICAgICAgICBTVEFUVVMgICAgICBj dXJyZW50IA0KICAgICAgICAgICAgICAgIERFU0NSSVBUSU9OIA0KICAgICAgICAgICAgICAgICAg ICAiVGhpcyBvYmplY3QgaXMgZ2VuZXJhbGx5IGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIHRoZSAN CiAgICAgICAgICAgICAgICAgICAgIGNyZWF0aW9uIG9mIGEgdGVtcG9yYXJ5IHVwc3RyZWFtIHJv dyBmb3IgdGhlIHB1cnBvc2UgDQogICAgICAgICAgICAgICAgICAgICBvZiBhZGp1c3RpbmcgY2hh bm5lbCBwYXJhbWV0ZXJzIG9mIGEgcGh5c2ljYWwgdXBzdHJlYW0gDQogICAgICAgICAgICAgICAg ICAgICBjaGFubmVsIHJvdy4gDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgIFRoZSBm b2xsb3dpbmcgcmVzdHJpY3Rpb25zIGFwcGx5IHRvIHRoaXMgb2JqZWN0OiANCiAgICAgICAgICAg ICAgICAgICAgIDEuIEVudHJpZXMgd2l0aCB0aGlzIG9iamVjdCBzZXQgdG8gYWN0aXZlKDEpIGFy ZSAgDQogICAgICAgICAgICAgICAgICAgICAgICBleHRlbnNpb25zIG9mIGRlZmluZWQgcGh5c2lj YWwgaW50ZXJmYWNlcyBpbiAgDQogICAgICAgICAgICAgICAgICAgICAgICB0aGUgaW50ZXJmYWNl IE1JQiBSRkMgMjg2My4gRW50cmllcyBjcmVhdGVkIGJ5IA0KICAgICAgICAgICAgICAgICAgICAg ICAgUm93U3RhdHVzIGNyZWF0ZWFuZFdhaXQoNSkgYXJlIHRlbXBvcmFyaWx5IGNyZWF0ZWQgdG8g DQogICAgICAgICAgICAgICAgICAgICAgICBjbG9uZSBwYXJhbWV0ZXJzLiANCiAgICAgICAgICAg ICAgICAgICAgIDIuIEEgc3RhdHVzIHRyYW5zaXRpb24gZnJvbSBhY3RpdmUoMSkgdG8gbm90SW5T ZXJ2aWNlKDIpIA0KICAgICAgICAgICAgICAgICAgICAgICAgb3IgZGVzdHJveSg2KSBpcyBub3Qg cGVybWl0dGVkLiANCiAgICAgICAgICAgICAgICAgICAgIDMuIGlmQWRtaW5TdGF0dXMgZnJvbSB0 aGUgSW50ZXJmYWNlIE1JQiBSRkMgMjg2MyBpcyB1c2VkIA0KICAgICAgICAgICAgICAgICAgICAg ICAgdG8gdGFrZSBhbiBVcHN0cmVhbSBDaGFubmVsIG9mZmxpbmUuIA0KICAgICAgICAgICAgICAg ICAgICAgNC4gVGVtcG9yYXJ5IGluYWN0aXZlIHJvd3MgTVVTVCBiZSBjcmVhdGVkIHVzaW5nIA0K ICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXRlQW5kV2FpdCg1KS4gDQogICAgICAgICAgICAg ICAgICAgICA1LiBUaGUgb25seSBwb3NzaWJsZSBzdGF0dXMgY2hhbmdlIG9mIGEgcm93IGNyZWF0 ZWQgdXNpbmcgDQogICAgICAgICAgICAgICAgICAgICAgICBjcmVhdGVBbmRXYWl0KDUpIChpLmUu IG5vdEluU2VydmljZSgyKSkgb3Igbm90UmVhZHkoMykgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgaXMgdG8gZGVzdHJveSg2KS4gDQogICAgICAgICAgICAgICAgICAgICA2LiBUZW1wb3Jhcnkg Y3JlYXRlZCByb3dzIE1VU1QgbmV2ZXIgYmUgZ2l2ZW4gdGhlIHN0YXR1cyANCiAgICAgICAgICAg ICAgICAgICAgICAgIGFjdGl2ZSgxKS4gDQogICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg IEEgTWFuZGF0b3J5IHByb2NlZHVyZSBmb3IgYWRqdXN0aW5nIGFuIHNwZWNpZmljIHBoeXNpY2Fs ICANCiAgICAgICAgICAgICAgICAgICAgIFVwc3RyZWFtIGNoYW5uZWwgaXM6IA0KICAgICAgICAg ICAgICAgICAgICAgMS4gQ3JlYXRlIGEgdGVtcG9yYXJ5IHJvdyB0aHJvdWdoIGFuIFNOTVAgU0VU IHVzaW5nIA0KICAgICAgICAgICAgICAgICAgICAgICAgY3JlYXRlQW5kV2FpdCg1KS4gIFVzZSBh biBpZkluZGV4IHZhbHVlIG91dHNpZGUgdGhlIA0KICAgICAgICAgICAgICAgICAgICAgICAgb3Bl cmF0aW9uYWwgcmFuZ2Ugb2YgdGhlIHN5c3RlbS4gDQogICAgICAgICAgICAgICAgICAgICAyLiBT ZXQgdGhlIGRvY3NJZlVwQ2hhbm5lbENsb25lRnJvbSBmaWVsZCB0byB0aGUgaWZJbmRleCANCiAg ICAgICAgICAgICAgICAgICAgICAgIHZhbHVlIG9mIHRoZSBwaHlzaWNhbCByb3cgd2hvc2UgcGFy YW1ldGVycyByZXF1aXJlIA0KICAgICAgICAgICAgICAgICAgICAgICAgYWRqdXN0bWVudC4gDQog ICAgICAgICAgICAgICAgICAgICAzLiBBZGp1c3QgdGhlIHBhcmFtZXRlciB2YWx1ZXMgdXNpbmcg dGhlIG5ldyB0ZW1wb3JhcnkgIA0KICAgICAgICAgICAgICAgICAgICAgICAgcm93LiAgRW5zdXJl IGFsbCBwYXJhbWV0ZXJzIGNvbnRhaW4gZGVzaXJlZCB2YWx1ZXMgDQogICAgICAgICAgICAgICAg ICAgICAgICBiZWZvcmUgcHJvY2VlZGluZyB0byBzdGVwIDQuIA0KICAgICAgICAgICAgICAgICAg ICAgNC4gVXBkYXRlIHRoZSBwaHlzaWNhbCByb3cgYnkgc2V0dGluZyB0aGUgb2JqZWN0IA0KICAg ICAgICAgICAgICAgICAgICAgICAgZG9jc0lmVXBDaGFubmVsVXBkYXRlIHRvIHRydWUoMSkuICBU aGlzIG9wZXJhdGlvbiBmYWlscyAMDQoKCgoKCiAgICAgICAgICAgICAgICAgICAgICAgIHdpdGgg ZXJyb3IgZ2VuRXJyIGlmIHRoZSBhZGp1c3RlZCBwYXJhbWV0ZXJzIGFyZSBub3QgIA0KICAgICAg ICAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSB3aXRoIGVhY2ggb3RoZXIuIA0KICAgICAgICAg ICAgICAgICAgICAgNS4gRGVsZXRlIHRoZSB0ZW1wb3Jhcnkgcm93IHRocm91Z2ggYW4gU05NUCBT RVQgdXNpbmcgDQogICAgICAgICAgICAgICAgICAgICAgICBERUxFVEVkZXN0cm95KDYpLiANCiAg ICAgICAgICAgICAgICAgICAgICAgIFRlbXBvcmFyeSBlbnRyaWVzIE1VU1QgTk9UIHBlcnNpc3Qg YXQgcmVpbml0aWFsaXphdGlvbiAgDQogICAgICAgICAgICAgICAgICAgICAgICBvZiB0aGUgbWFu YWdlZCBzeXN0ZW0uIiANCiAgICAgICAgICAgICAgICA6Oj0geyBkb2NzSWZVcHN0cmVhbUNoYW5u ZWxFbnRyeSAxOCB9ICAgDQogICAgICAgICAgDQogICAgICAgICBkb2NzSWZRb3NQcm9maWxlVGFi bGUgDQogICAgICAgICAgDQogICAgICAgICBSRkl2MiBVcGRhdGVzIA0KICAgICAgICAgZG9jc0lm UW9zUHJvZk1heFRyYW5zbWl0QnVyc3QgcmVwbGFjZXMgZGVwcmVjYXRlZCBkb2NzSWZRb3NQcm9m TWF4VHhCdXJzdCANCiAgICAgICAgICANCiAgICAgICAgIEZyb20gUkZDIDI2NzAgaXQgaXMgY29t cGxpYW50IHRvIGJlIHJlYWQtb25seSAoYXMgd2VsbCANCiAgICAgICAgIGRvY3NJZkNtdHNRb3NQ cm9maWxlUGVybWlzc2lvbnMgd2hpY2ggc2hvdWxkIHRoZW4gYmUgc2V0IHRvIDB4ODApICANCiAg ICAgICAgIFJGQyAyNjcwIGRvZXMgbm90IGNvdmVyIFBlcnNpc3RlbnQgcmVxdWlyZW1lbnRzLiAN CiAgICAgICAgICANCiAgICAgICAgIEFsdGhvdWdoIHRoZSBvcHRpb24gb2YgYmVpbmcgYSByZWFk LWNyZWF0ZSB0YWJsZSBtYXkgaW5kaWNhdGVzIG1lcml0cyB0byB3ZWxsIA0KICAgICAgICAgZGVm aW5lIHRoZSBwZXJzaXN0ZW50IHJlcXVpcmVtZW50cyB1bmRlciBNSUIgcmV2aXNpb24gZ3VpZGVs aW5lcy4gVGhlIA0KICAgICAgICAgZG9jc0lmUW9zUHJvZmlsZVRhYmxlIGNvdmVycyBvbmx5IHRo ZSBET0NTSVMgMS4wIENsYXNzIG9mIFNlcnZpY2UgcHJvZmlsaW5nLCANCiAgICAgICAgIHdoaWNo IGlzIHN1cHBvcnRlZCBmb3IgRE9DU0lTIDEuMSBhbmQgMi4wIENNVFNlcyBmb3IgZGV2aWNlIGFu ZCBzZXJ2aWNlcyANCiAgICAgICAgIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkuIA0KICAgICAgICAg IA0KICAgICAgICAgQXMgYWxsIHN5c3RlbXMgY29udGludWUgdHJhbnNpdGlvbmluZyB0byBET0NT SVMgMS4xIFFPUywgdGhpcyB0YWJsZSB3aWxsIGJlIGluIA0KICAgICAgICAgdGhlIGZ1dHVyZSBk ZXByZWNhdGVkLCB0aGVyZWZvcmUgaXQgbWF5IG5vdCB3b3J0aCB0byB1cGRhdGUgdGhlIE1JQiBm b3IgDQogICAgICAgICBTdG9yYWdlVHlwZSByZXF1aXJlbWVudHMgdG8gaW1wb3NlIHBlcnNpc3Rl bnQgcmVxdWlyZW1lbnRzIGZvciBzeXN0ZW1zIA0KICAgICAgICAgc3VwcG9ydGluZyBSRkkgTUlC IHYyLiANCiAgICAgICAgICANCiAgICAgICAgIEFkZCBvYmplY3QgZG9jc0lmUW9zUHJvZlN0b3Jh Z2VUeXBlIHJlYWQtb25seSANCiAgICAgICAgICANCiAgICAgICAgICANCiAgICAgICAgICANCiAg ICAgICAgIENIQU5HRSAjNmEgDQogICAgICAgICAgDQogICAgICAgIERvY3NJZlFvc1Byb2ZpbGVF bnRyeSA6Oj0gU0VRVUVOQ0UgeyANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmUW9zUHJvZklu ZGV4ICAgICAgICAgICAgICAgIEludGVnZXIzMiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJ ZlFvc1Byb2ZQcmlvcml0eSAgICAgICAgICAgICBJbnRlZ2VyMzIsIA0KICAgICAgICAgICAgICAg ICAgICBkb2NzSWZRb3NQcm9mTWF4VXBCYW5kd2lkdGggICAgICAgSW50ZWdlcjMyLCANCiAgICAg ICAgICAgICAgICAgICAgZG9jc0lmUW9zUHJvZkd1YXJVcEJhbmR3aWR0aCAgICAgIEludGVnZXIz MiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZlFvc1Byb2ZNYXhEb3duQmFuZHdpZHRoICAg ICBJbnRlZ2VyMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZRb3NQcm9mTWF4VHhCdXJz dCAgICAgICAgICAgSW50ZWdlcjMyLCAgLS0gZGVwcmVjYXRlZCANCiAgICAgICAgICAgICAgICAg ICAgZG9jc0lmUW9zUHJvZkJhc2VsaW5lUHJpdmFjeSAgICAgIFRydXRoVmFsdWUsIA0KICAgICAg ICAgICAgICAgICAgICBkb2NzSWZRb3NQcm9mU3RhdHVzICAgICAgICAgICAgICAgUm93U3RhdHVz LCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmUW9zUHJvZk1heFRyYW5zbWl0QnVyc3QgICAg IEludGVnZXIzMiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZlFvc1Byb2ZTdG9yYWdlVHlw ZSAgICAgICAgICBTdG9yYWdlVHlwZSANCiAgICAgICAgICAgICAgICB9IA0KICAgICAgICAgIA0K ICAgICAgICAgQ0hBTkdFICM2YiANCiAgICAgICAgICANCiAgICAgICAgIGRvY3NJZlFvc1Byb2ZT dG9yYWdlVHlwZSBPQkpFQ1QtVFlQRSANCiAgICAgICAgICAgICAgICAgU1lOVEFYICAgICAgIFN0 b3JhZ2VUeXBlIA0KICAgICAgICAgICAgICAgICBNQVgtQUNDRVNTICAgcmVhZC1vbmx5IA0KICAg ICAgICAgICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudCANCiAgICAgICAgICAgICAgICAgREVT Q1JJUFRJT04gIA0KICAgICAgICAgICAgICAgICAgICAgIlRoZSBzdG9yYWdlIHR5cGUgZm9yIHRo aXMgY29uY2VwdHVhbCByb3cuIA0KICAgICAgICAgICAgICAgICA6Oj0geyBkb2NzSWZRb3NQcm9m aWxlRW50cnkgMTAgfSAMDQoKCgoKCiAgICAgICAgICANCiAgICAgICAgIENIQU5HRSAjNmMgDQog ICAgICAgICAgDQogICAgICAgICBTZWUgY2hhbmdlICM0IHBlcnRhaW4gZG9jc0lmUW9zUHJvZlN0 b3JhZ2VUeXBlIA0KICAgICAgICAgIA0KICAgICAgICAgIA0KICAgICAgICAgT2JqZWN0IHN5bnRh eCByZWFkLXdyaXRlIGRpZmZlcmVudCBvZiBSZWFkLWNyZWF0ZSB0YWJsZXMgDQogICAgICAgICAo T1BTIE1JQiBndWlkZWxpbmVzIHNlY3Rpb24gNi40LjIpICANCiAgICAgICAgICANCiAgICAgICAg ICANCiAgICAgICAgIGRvY3NJZkRvd25zdHJlYW1DaGFubmVsVGFibGUgIA0KICAgICAgICAgIA0K ICAgICAgICAgTUFYLUFDQ0VTUyByZWFkLW9ubHkgDQogICAgICAgICBkb2NzSWZEb3duQ2hhbm5l bEFubmV4ICANCiAgICAgICAgICANCiAgICAgICAgIE1BWC1BQ0NFU1MgcmVhZC13cml0ZSwgTUlO LUFDQ0VTUyByZWFkLW9ubHkgDQogICAgICAgICBkb2NzSWZEb3duQ2hhbm5lbEZyZXF1ZW5jeSAN CiAgICAgICAgIGRvY3NJZkRvd25DaGFubmVsV2lkdGggDQogICAgICAgICBkb2NzSWZEb3duQ2hh bm5lbE1vZHVsYXRpb24gDQogICAgICAgICBkb2NzSWZEb3duQ2hhbm5lbEludGVybGVhdmUgDQog ICAgICAgICBkb2NzSWZEb3duQ2hhbm5lbFBvd2VyIA0KICAgICAgICAgIA0KICAgICAgICAgTUlO LUFDQ0VTUyByZWFkLW9ubHkgZm9yIGRvY3NJZkRvd25zdHJlYW1DaGFubmVsVGFibGUgaW1wbGll cyB0aGUgbWluaW1hbCANCiAgICAgICAgIGltcGxlbWVudGF0aW9uIGhhcyBubyBwZXJzaXN0ZW50 IHJlcXVpcmVtZW50LiAgDQogICAgICAgICAgDQogICAgICAgICBBcyBhIG1pbmltYWwgcmVxdWly ZW1lbnQsIGEgU3RvcmFnZVR5cGUgcmVhZC1vbmx5IG9iamVjdCBpcyBhZGRlZCB0byBpbmRpY2F0 ZSANCiAgICAgICAgIHRoZSBTTk1QIHBlcnNpc3RlbmNlIGNhcGFiaWxpdGllcyBvZiBkb2NzSWZE b3duc3RyZWFtQ2hhbm5lbFRhYmxlLiANCiAgICAgICAgICANCiAgICAgICAgIE5vIERFRlZBTCBp cyBkZWZpbmVkIGR1ZSB0aGUgZGlmZmVyZW50IGNvbXBsaWFuY2Ugc3RhdGVtZW50cyBmb3IgQ01z IGFuZCANCiAgICAgICAgIENNVFNlcywgYW5kIHJlcXVpcmVtZW50cy4gDQogICAgICAgICAgDQog ICAgICAgICAgDQogICAgICAgICAgDQogICAgICAgICBDSEFOR0UgIyA3YSANCiAgICAgICAgICAN CiAgICAgICAgRG9jc0lmRG93bnN0cmVhbUNoYW5uZWxFbnRyeSA6Oj0gU0VRVUVOQ0UgeyANCiAg ICAgICAgICAgICAgICAgICAgZG9jc0lmRG93bkNoYW5uZWxJZCAgICAgICAgICAgICAgIEludGVn ZXIzMiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkRvd25DaGFubmVsRnJlcXVlbmN5ICAg ICAgICBJbnRlZ2VyMzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZEb3duQ2hhbm5lbFdp ZHRoICAgICAgICAgICAgSW50ZWdlcjMyLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmRG93 bkNoYW5uZWxNb2R1bGF0aW9uICAgICAgIElOVEVHRVIsIA0KICAgICAgICAgICAgICAgICAgICBk b2NzSWZEb3duQ2hhbm5lbEludGVybGVhdmUgICAgICAgSU5URUdFUiwgDQogICAgICAgICAgICAg ICAgICAgIGRvY3NJZkRvd25DaGFubmVsUG93ZXIgICAgICAgICAgICBUZW50aGRCbVYsIA0KICAg ICAgICAgICAgICAgICAgICBkb2NzSWZEb3duQ2hhbm5lbEFubmV4ICAgICAgICAgICAgSU5URUdF UiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkRvd25DaGFubmVsU3RvcmFnZVR5cGUgICAg ICBTdG9yYWdlVHlwZSANCiAgICAgICAgICAgICAgICB9IA0KICAgICAgICAgDQogICAgICAgICBD SEFOR0UgIyA3YiANCiAgICAgICAgIA0KICAgICAgICAgZG9jc0lmRG93bkNoYW5uZWxTdG9yYWdl VHlwZSBPQkpFQ1QtVFlQRSANCiAgICAgICAgICAgICAgICAgU1lOVEFYICAgICAgIFN0b3JhZ2VU eXBlIA0KICAgICAgICAgICAgICAgICBNQVgtQUNDRVNTICAgcmVhZC1vbmx5IA0KICAgICAgICAg ICAgICAgICBTVEFUVVMgICAgICAgY3VycmVudCANCiAgICAgICAgICAgICAgICAgREVTQ1JJUFRJ T04gIA0KICAgICAgICAgICAgICAgICAgICAgIlRoZSBzdG9yYWdlIHR5cGUgZm9yIHRoaXMgY29u Y2VwdHVhbCByb3cuIA0KICAgICAgICAgICAgICAgICA6Oj0geyBkb2NzSWZEb3duc3RyZWFtQ2hh bm5lbEVudHJ5IDggfSAMDQoKCgoKCiAgICAgICAgIA0KICAgICAgICAgQ0hBTkdFICMgN2MgDQog ICAgICAgICBTZWUgY2hhbmdlICM0IHBlcnRhaW4gZG9jc0lmRG93bkNoYW5uZWxTdG9yYWdlVHlw ZSANCiAgICAgICAgIA0KICAgICAgICAgZG9jc0lmQ210c01hY1RhYmxlIA0KICAgICAgICAgZG9j c0lmQ210c1N5bmNJbnRlcnZhbCwgZG9jc0lmQ210c1VjZEludGVydmFsLCANCiAgICAgICAgIGRv Y3NJZkNtdHNJbnZpdGVkUmFuZ2luZ0F0dGVtcHRzLCBkb2NzSWZDbXRzSW5zZXJ0SW50ZXJ2YWw6 IA0KICAgICAgICAgIA0KICAgICAgICAgICAtIEl0IGlzIGNvbXBsaWFudCBmb3IgdGhpcyB0YWJs ZSBvYmplY3RzIHRvIGJlIHJlYWQtb25seSAgDQogICAgICAgICAgIC0gKE1JTi1BQ0NFU1MgcmVh ZC1vbmx5KSANCiAgICAgICAgIA0KICAgICAgICBTaW1pbGFyIHRvIGRvY3NJZkRvd25zdHJlYW1D aGFubmVsVGFibGUgDQogICAgICAgICAgDQogICAgICAgICBDSEFOR0UgIyA4YSANCiAgICAgICAg ICANCiAgICAgICAgRG9jc0lmQ210c01hY0VudHJ5IDo6PSBTRVFVRU5DRSB7IA0KICAgICAgICAg ICAgICAgICAgICBkb2NzSWZDbXRzQ2FwYWJpbGl0aWVzICAgICAgICAgICAgQklUUywgDQogICAg ICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNTeW5jSW50ZXJ2YWwgICAgICAgICAgICBJbnRlZ2Vy MzIsIA0KICAgICAgICAgICAgICAgICAgICBkb2NzSWZDbXRzVWNkSW50ZXJ2YWwgICAgICAgICAg ICAgSW50ZWdlcjMyLCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c01heFNlcnZpY2VJ ZHMgICAgICAgICAgIEludGVnZXIzMiwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNJ bnNlcnRpb25JbnRlcnZhbCAgICAgICBUaW1lVGlja3MsICAgLS0gT2Jzb2xldGUgIA0KICAgICAg ICAgICAgICAgICAgICBkb2NzSWZDbXRzSW52aXRlZFJhbmdpbmdBdHRlbXB0cyAgSW50ZWdlcjMy LCANCiAgICAgICAgICAgICAgICAgICAgZG9jc0lmQ210c0luc2VydEludGVydmFsICAgICAgICAg IFRpbWVJbnRlcnZhbCwgDQogICAgICAgICAgICAgICAgICAgIGRvY3NJZkNtdHNNYWNTdG9yYWdl VHlwZSAgICAgICAgICBTdG9yYWdldHlwZSANCiAgICAgICAgICAgICAgICB9IA0KICAgICAgICAg IA0KICAgICAgICAgQ0hBTkdFICMgOGIgDQogICAgICAgICAgDQogICAgICAgICBkb2NzSWZDbXRz U3RvcmFnZVR5cGUgT0JKRUNULVRZUEUgDQogICAgICAgICAgICAgICAgIFNZTlRBWCAgICAgICBT dG9yYWdlVHlwZSANCiAgICAgICAgICAgICAgICAgTUFYLUFDQ0VTUyAgIHJlYWQtb25seSANCiAg ICAgICAgICAgICAgICAgU1RBVFVTICAgICAgIGN1cnJlbnQgDQogICAgICAgICAgICAgICAgIERF U0NSSVBUSU9OICANCiAgICAgICAgICAgICAgICAgICAgICJUaGUgc3RvcmFnZSB0eXBlIGZvciB0 aGlzIGNvbmNlcHR1YWwgcm93LiANCiAgICAgICAgICAgICAgICAgOjo9IHsgZG9jc0lmQ210c01h Y0VudHJ5IDggfSANCiAgICAgICAgIA0KICAgICAgICAgIA0KICAgICAgICAgQ0hBTkdFICMgOGMg DQogICAgICAgICAgDQogICAgICAgICBTZWUgQ2hhbmdlICM0IHBlcnRhaW4gZG9jc0lmQ210c01h Y1N0b3JhZ2VUeXBlIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgIGRvY3NJZkNtdHNT ZXJ2aWNlVGFibGUgDQogICAgICAgICAgDQogICAgICAgICBPYmplY3QgZG9jc0lmQ210c1NlcnZp Y2VBZG1pblN0YXR1cyBpcyByZWFkLXdyaXRlLCBhbmQgaW5kaWNhdGVzIHRoZSANCiAgICAgICAg IGFkbWluaXN0cmF0aXZlIFN0YXR1cyBvZiBhbiBhY3RpdmUgQ00gdXBzdHJlYW0gcXVldWUgc2Vy dmljZSwgdXBvbiByZWJvb3QgYWxsIA0KICAgICAgICAgcXVldWVzIGFyZSBkZWxldGVkIGFuZCBD TXMgd2lsbCByZS1yZWdpc3Rlci4gVGhlcmVmb3JlIHBlcnNpc3RlbmNlIGRvZXMgbm90IA0KICAg ICAgICAgYXBwbHkuIA0KICAgICAgICAgIA0KICAgICAgICAgZG9jc0lmQ21NYWNUYWJsZSANCiAg ICAgICAgIFRoaXMgaXMgYSBDTXMgc3BlY2lmaWMgb2JqZWN0LiANCiAgICAgICAgIGRvY3NJZkNt UmFuZ2luZ1RpbWVvdXQgTUFYLUFDQ0VTUyBpcyByZWFkLXdyaXRlIHdpdGggREVGVkFMIGNsYXVz ZS4gDQogICAgICAgICBJdCBpcyBiZWxpZXZlZCB0aGF0IHRoZSBwcmVzZW5jZSBvZiB0aGUgREVG VkFMIGFuZCB0aGUgTUlCIG9iamVjdCByZWZlcmVuY2UgdG8gDQogICAgICAgICB0aGUgc3BlYyBp cyBzdWZmaWNpZW50IHRvIG5vdCBkZXRhaWwgQ00gcGVyc2lzdGVudCByZXF1aXJlbWVudHMuIA0K ICAgICAgICAgIAwNCgoKCgoKICAgICAgICAgQ0hBTkdFICM5IA0KICAgICAgICAgIA0KICAgICAg ICAgVGVudGF0aXZlIGNoYW5nZSANCiAgICAgICAgICANCiAgICAgICAgZG9jc0lmQ21SYW5naW5n VGltZW91dCBPQkpFQ1QtVFlQRSANCiAgICAgICAgICAgICAgICBTWU5UQVggICAgICBUaW1lSW50 ZXJ2YWwgDQogICAgICAgICAgICAgICAgTUFYLUFDQ0VTUyAgcmVhZC13cml0ZSANCiAgICAgICAg ICAgICAgICBTVEFUVVMgICAgICBjdXJyZW50IA0KICAgICAgICAgICAgICAgIERFU0NSSVBUSU9O IA0KICAgICAgICAgICAgICAgICAgICAiV2FpdGluZyB0aW1lIGZvciBhIFJhbmdpbmcgUmVzcG9u c2UgcGFja2V0LiANCiAgICAgICAgICAgICAgICAgICAgIFRoaXMgb2JqZWN0IE1VU1Qgbm90IHBl cnNpc3QgYXQgcmVpbml0aWFsaXphdGlvbiANCiAgICAgICAgICAgICAgICAgICAgIG9mIHRoZSBt YW5hZ2VkIHN5c3RlbS4iIA0KICAgICAgICAgICAgICAgIFJFRkVSRU5DRSANCiAgICAgICAgICAg ICAgICAgICAgIkRhdGEtT3Zlci1DYWJsZSBTZXJ2aWNlIEludGVyZmFjZSBTcGVjaWZpY2F0aW9u czogUmFkaW8gDQogICAgICAgICAgICAgICAgICAgICBGcmVxdWVuY3kgSW50ZXJmYWNlIFNwZWNp ZmljYXRpb24gU1AtUkZJdjIuMC1JMDUtMDQwNDA3LCANCiAgICAgICAgICAgICAgICAgICAgIFNl Y3Rpb24gOS4xLjYsIHRpbWVyIFQzLiIgDQogICAgICAgICAgICAgICAgREVGVkFMIHsgMjAgfSAN CiAgICAgICAgICAgICAgICA6Oj0geyBkb2NzSWZDbU1hY0VudHJ5IDQgfSANCiAgICAgICAgIA0K ICAgICAgICAgIA0KICAgICAgICAgIA0KICAgICAgICAgDQogICAgICAgICANCiAgICAgICAgIFRh YmxlcyByZWFkLW9ubHkgIA0KICAgICAgICAgIA0KICAgICAgICAgZG9jc0lmU2lnbmFsUXVhbGl0 eVRhYmxlIA0KICAgICAgICAgZG9jc0lmQ21TdGF0dXNUYWJsZSANCiAgICAgICAgIGRvY3NJZkNt U2VydmljZVRhYmxlIA0KICAgICAgICAgZG9jc0lmQ210c1N0YXR1c1RhYmxlIA0KICAgICAgICAg ZG9jc0lmQ210c0NtU3RhdHVzVGFibGUgDQogICAgICAgICBkb2NzSWZDbXRzTWFjVG9DbVRhYmxl IA0KICAgICAgICAgZG9jc0lmQ210c0NoYW5uZWxVdGlsaXphdGlvbkludGVydmFsIA0KICAgICAg ICAgZG9jc0lmQ210c0NoYW5uZWxVdGlsaXphdGlvblRhYmxlIA0KICAgICAgICAgZG9jc0lmQ210 c0Rvd25DaGFubmVsQ291bnRlclRhYmxlIA0KICAgICAgICAgZG9jc0lmQ210c1VwQ2hhbm5lbENv dW50ZXJUYWJsZSANCiAgICAgICAgIAw= ------_=_NextPart_001_01C42306.92AB2B66-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 15:48:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21769 for ; Thu, 15 Apr 2004 15:48:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECoe-0005w3-NN for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 15:46:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FJkSlI022811 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 15:46:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BECjP-0004qE-2j; Thu, 15 Apr 2004 15:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEChh-0004Ny-35 for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 15:39:17 -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 PAA19876 for ; Thu, 15 Apr 2004 15:39:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BEChf-0005Eg-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 15:39:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BECgh-0005BU-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 15:38:15 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BECfi-00056x-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 15:37:14 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2004 11:46:07 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FJaf7t021104; Thu, 15 Apr 2004 12:36:41 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATA61320; Thu, 15 Apr 2004 12:36:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20040415121843.02655e10@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Apr 2004 12:36:40 -0700 To: "Eduardo Cardona" From: Minnie Lu Cc: "Eduardo Cardona" , "Donati Andrew-MGIA0477" , , "Randy Presuhn" , "Keske Tom-LTK002" , "Azlina Ahmad" , "Minnie Lu" , "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, Thanks a lot for listening to me. I am happy with the new text. But I still have concern about saving notInService or notReady rows for modulation profiles into NVRAM and have them persistent across CMTS reboot, especially for the rows with inconsistent attributes which is allowed for rowStatus in 'notInService' and 'notReady'. Though this is extreme case, but since the MIB or spec does not prevent to do so or does not make it optional, that means CMTS MUST implement such capability to save rows with inconsistent attributes into NVRAM which is a waste of CMTS resource and complicated the implementation for no or little gain. Possible to make it an optional that saving rows with inconsistent attributes into NVRAM and persistent across reboot ? Thanks a lot for your advice ! Minnie At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: >Hi all, > >Please find attached the summary of changes after all your feedback, >special thanks to Randy Presuhn for all the detailed comments. > >Please note that the storageType objects are being set as CMTS only >requirement docsIfCmtsGroupV2 since the CM compliances are read-only or >any other tables do not apply to CMs. > >Change #9 for the docsIfCmRangingTimeout please review the other >question sent to the list and OSSI reflector > >Please see if the coments are being captured properly. > > >PDF has the color change, also attached text file for convenience. > > >Thanks > >Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 16:28:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24968 for ; Thu, 15 Apr 2004 16:28:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDN8-0004F1-TZ for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 16:22:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FKM6Rh016297 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 16:22:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDL8-0003b4-BR; Thu, 15 Apr 2004 16:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BED8P-0000y6-8z for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 16:06: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 QAA23537 for ; Thu, 15 Apr 2004 16:06:50 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BED8N-0006ty-K4 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:06:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BED7h-0006sO-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:06:10 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BED6v-0006n1-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:05:21 -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 i3FK4e9T002034; Thu, 15 Apr 2004 14:04:40 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Apr 2004 14:04:40 -0600 Message-ID: Thread-Topic: V2 Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQjIQDDgoV7ia7gSl+Yy1YXLuIGywAAQUKg From: "Eduardo Cardona" To: "Minnie Lu" Cc: "Donati Andrew-MGIA0477" , , "Randy Presuhn" , "Keske Tom-LTK002" , "Azlina Ahmad" , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minnie,=20 Could be the case that for the same reason you have vendor default entries, a user may create their own set of entries and turn them disable to avoid being used to configure interfaces. Specially I am not comfortable with the case of : active -> notInService -> reboot -> "where is my old entry"?=20 For the case of notReady, I may think that you are trying to align the CLI approach ( a command does not success if is not well formed then you execute the write to memory command to save the changes and only correct table entries are saved, (the bad ones do not exist). I have no strong opinion against that and I would like to hear from IPCDN participants about conventional practices or similar situations in other MIB modules. Will that help? sorry not having a more definitive answer. It does not preclude to come up with the approapiate wording as a proposal which may help to discover other type of reactions :) Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, April 15, 2004 1:37 PM To: Eduardo Cardona Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo List Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) Hi, Eduardo, Thanks a lot for listening to me. I am happy with the new text. But I still have concern about saving notInService or notReady rows for=20 modulation profiles into NVRAM and have them persistent across CMTS=20 reboot, especially for the rows with inconsistent attributes which is=20 allowed for rowStatus in 'notInService' and 'notReady'. Though this is extreme case, but since the MIB or spec does not prevent=20 to do so or does not make it optional, that means CMTS MUST implement such=20 capability to save rows with inconsistent attributes into NVRAM which is a=20 waste of CMTS resource and complicated the implementation for no or little=20 gain. Possible to make it an optional that saving rows with inconsistent=20 attributes into NVRAM and persistent across reboot ? Thanks a lot for your advice ! Minnie At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: >Hi all, > >Please find attached the summary of changes after all your feedback,=20 >special thanks to Randy Presuhn for all the detailed comments. > >Please note that the storageType objects are being set as CMTS only=20 >requirement docsIfCmtsGroupV2 since the CM compliances are read-only=20 >or any other tables do not apply to CMs. > >Change #9 for the docsIfCmRangingTimeout please review the other=20 >question sent to the list and OSSI reflector > >Please see if the coments are being captured properly. > > >PDF has the color change, also attached text file for convenience. > > >Thanks > >Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 16:34:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25267 for ; Thu, 15 Apr 2004 16:34:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDSS-0005D0-I6 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 16:27:36 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FKRaKh020018 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 16:27:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDM7-0003ui-9i; Thu, 15 Apr 2004 16:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDK2-0003IN-1d for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 16:18: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 QAA24373 for ; Thu, 15 Apr 2004 16:18:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEDK0-0007TG-9C for ipcdn@ietf.org; Thu, 15 Apr 2004 16:18:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDJ6-0007SL-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:17:57 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEDIp-0007R1-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:17:39 -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 i3FKH79T004787; Thu, 15 Apr 2004 14:17:07 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42326.A0055F14" Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 14:17:07 -0600 Message-ID: Thread-Topic: [ipcdn] Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQi/znartjH3nEFSCuzdrPhnBM9+AAJrzmA From: "Eduardo Cardona" To: "Lejeune, Andre" , , "DOCSIS OSS Majordomo List" , "DOCSIS Macup Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C42326.A0055F14 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andre,=20 =20 I share your appreciations. =20 are there any other sort of considerations from other parties? =20 Thanks =20 Eduardo -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@Terayon.com]=20 Sent: Thursday, April 15, 2004 9:32 AM To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) I believe this object should have been defined as read-only as there is no advantage in having it read-write. Moreover, the RFI specification, in Annex B, defines a min and max value for it. I do not see how such a timeout can take multiple values. There should have been a unique value for it. Andre=20 -----Original Message-----=20 From: Eduardo Cardona [mailto:e.cardona@cablelabs.com]=20 Sent: Thursday, April 15, 2004 11:07 AM=20 To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo=20 List=20 Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)=20 Hi all,=20 I have some questions regarding the MIB object docsIfCmRangingTimeout=20 Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96=20 show docsIfCmRangingTimeout with syntax read-write ( the only CM=20 read-write object in RFI MIB).=20 The questions are=20 Is this object really need to be read-write?=20 particularly if there is any management case where read-write is used.=20 Currently there is no Compliance statement to allow read-only access, is that needed?=20 Is there any instance (in general) when the T3 timer is being adjusted=20 by the CM and retained in Memory after CM reboots ?, or would be ok to=20 explicitly not require persistence without incurring in spec changes?=20 (just a clarification)=20 I am Not planning to deprecate the object but The new revision of RF MIB is being updated to address IETF OPS MIB revision guidelines related to=20 persistence and would be good to precise CM usage of the object.=20 See ipcdn mailing list for current discussion about draft 10 updates=20 http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h tml=20 I will post OSSI DOCSIS reflector with a second revision of the changes=20 as well as IPCDN list soon=20 Thanks=20 Eduardo=20 PD: In Annex A of OSSI spec the obsolete object above=20 docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being=20 tracked to include in an Omnibus ECR)=20 ------_=_NextPart_001_01C42326.A0055F14 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Andre,
 
I=20 share your appreciations.
 
are there any other sort of considerations from=20 other parties?
 
Thanks
 
Eduardo
-----Original Message-----
From: = Lejeune, Andre=20 [mailto:andre.lejeune@Terayon.com]
Sent: Thursday, April = 15, 2004=20 9:32 AM
To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS = Majordomo=20 List; DOCSIS Macup Majordomo List
Subject: RE: [ipcdn] = Changes for=20 next RFI v2 MIB (draft 10)

I believe this object should have been defined as = read-only as=20 there is no advantage in having it read-write. Moreover, the RFI=20 specification, in Annex B, defines a min and max value for it. I do = not see=20 how such a timeout can take multiple values. There should have been a = unique=20 value for it.

Andre

-----Original Message-----
From:=20 Eduardo Cardona [mailto:e.cardona@cablelabs.com]=20
Sent: Thursday, April 15, 2004 11:07 AM =
To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup=20 Majordomo
List
Subject: RE:=20 [ipcdn] Changes for next RFI v2 MIB (draft 10)


Hi all,

I have some questions regarding the MIB object=20 docsIfCmRangingTimeout

Both the RFI MIB and OSSI spec = SP-OSSIv2.0-I05-040407 Annex A=20 page 96
show docsIfCmRangingTimeout  = with syntax=20 read-write ( the only CM
read-write object = in RFI=20 MIB).


The questions are
Is this = object=20 really need to be read-write?
particularly = if there is=20 any management case where read-write is used.
Currently there is no Compliance statement to allow read-only = access,=20 is
that needed?

Is there any instance (in general) when the T3 timer = is being=20 adjusted
by the CM and retained in Memory = after CM=20 reboots ?, or would be ok to
explicitly not = require=20 persistence without incurring in spec changes?
(just a=20 clarification)

I am Not planning to deprecate the object but The = new revision=20 of RF MIB
is being updated to address IETF = OPS MIB=20 revision guidelines related to
persistence = and would=20 be good to precise CM usage of the object.

See ipcdn mailing list for current discussion about = draft 10=20 updates
http://www1.ietf.org/mail-archive/working-groups/ipcdn/cu= rrent/threads.h=20
tml

I will post OSSI DOCSIS reflector with a second = revision of=20 the changes
as well as IPCDN list = soon

Thanks

Eduardo


PD: In Annex A of OSSI spec the obsolete object = above=20
docsIfCmRangingTimeout should be = docsIfCmRangingRespTimeout.=20 ( being
tracked to include in an Omnibus = ECR)=20

------_=_NextPart_001_01C42326.A0055F14-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 18:09:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00983 for ; Thu, 15 Apr 2004 18:09:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEEn2-0006p1-Oc for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 17:52:56 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FLqu4L026217 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 17:52:56 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEEcY-0002rc-2Y; Thu, 15 Apr 2004 17:42:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEDq7-00029Y-Pd for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 16:52: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 QAA26159 for ; Thu, 15 Apr 2004 16:52: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 1BEDq5-0001ND-Kh for ipcdn@ietf.org; Thu, 15 Apr 2004 16:52:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEDp9-0001KE-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:51:04 -0400 Received: from grebe.mail.pas.earthlink.net ([207.217.120.46]) by ietf-mx with esmtp (Exim 4.12) id 1BEDoM-0001Hf-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 16:50:14 -0400 Received: from h-68-164-86-2.snvacaid.dynamic.covad.net ([68.164.86.2] helo=oemcomputer) by grebe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BEDoI-0002w3-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 13:50:10 -0700 Message-ID: <004501c4232b$ba904740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Date: Thu, 15 Apr 2004 13:53:38 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Eduardo Cardona" > To: "Minnie Lu" ... > Sent: Thursday, April 15, 2004 1:04 PM > Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) ... > Specially I am not comfortable with the case of : active -> notInService > -> reboot -> "where is my old entry"? ... If you do NOT want it to work this way, then you'll need to put language to that effect into the DESCRIPTIONs for the RowStatus object. RFC 2579 page 16 makes it clear why: If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Consequently, if the WG wants the peculiar behaviour of having non-active rows survive re-boots, you'll need to spell it out in the DESCRIPTIONs. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 19:24:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09604 for ; Thu, 15 Apr 2004 19:24:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEG4T-0001tp-40 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 19:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FNF1RD007295 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 19:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFwi-0007g2-OH; Thu, 15 Apr 2004 19:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEFpZ-0005xW-0D for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 18:59: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 SAA07655 for ; Thu, 15 Apr 2004 18:59: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 1BEFpV-0004Gl-Id for ipcdn@ietf.org; Thu, 15 Apr 2004 18:59:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEFoX-0004Dd-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 18:58:34 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEFnb-00049A-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 18:57: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 i3FMut9T006755; Thu, 15 Apr 2004 16:56:55 -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: V2 Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 16:56:55 -0600 Message-ID: Thread-Topic: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQjM/2birE8bintQsaIifKNvw61dgAByrWw From: "Eduardo Cardona" To: "Randy Presuhn" , , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable That's a good pointer,=20 Thanks Randy I personally was not aware of this language in the lengthy RowStatus description, my apologize=20 Minnie, Going back to your question, I now think the aging of 'superfluous' entries is the behavior by default for SNMP and I should put myself in a non-deviating position of that. In the other hand if the 5 minutes by default of RFC 2579 is not convenient, would you have any text proposal for this matter? Thanks Eduardo =20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Thursday, April 15, 2004 2:54 PM To: ipcdn@ietf.org Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Hi - > From: "Eduardo Cardona" > To: "Minnie Lu" ... > Sent: Thursday, April 15, 2004 1:04 PM > Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) ... > Specially I am not comfortable with the case of : active ->=20 > notInService > -> reboot -> "where is my old entry"? ... If you do NOT want it to work this way, then you'll need to put language to that effect into the DESCRIPTIONs for the RowStatus object. RFC 2579 page 16 makes it clear why: If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row. Consequently, if the WG wants the peculiar behaviour of having non-active rows survive re-boots, you'll need to spell it out in the DESCRIPTIONs. 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 exim@www1.ietf.org Thu Apr 15 19:41:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10439 for ; Thu, 15 Apr 2004 19:41:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGRh-000801-Db for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 19:39:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3FNd1ND030744 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 19:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGJ8-0005qx-KX; Thu, 15 Apr 2004 19:30:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEGEn-0004HT-Vo for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 19:25:42 -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 TAA09683 for ; Thu, 15 Apr 2004 19:25: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 1BEGEm-0006Gk-66 for ipcdn@ietf.org; Thu, 15 Apr 2004 19:25:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEGDu-0006E8-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 19:24:46 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEGCz-00068h-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 19:23:49 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 15 Apr 2004 15:33:56 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3FNNG7t020187; Thu, 15 Apr 2004 16:23:16 -0700 (PDT) Received: from cisco.com (dhcp-171-71-186-204.cisco.com [171.71.186.204]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATA91814; Thu, 15 Apr 2004 16:23:16 -0700 (PDT) Message-ID: <407F1964.2060806@cisco.com> Date: Thu, 15 Apr 2004 16:23:16 -0700 From: Azlina Ahmad Reply-To: azlina@cisco.com Organization: CIsco Systems User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eduardo Cardona CC: Donati Andrew-MGIA0477 , ipcdn@ietf.org Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Comment inline ... [AZ] Eduardo Cardona wrote: > Hi Azlina, see inline, > > Eduardo > > -----Original Message----- > From: Azlina Ahmad [mailto:azlina@cisco.com] > Sent: Wednesday, April 14, 2004 2:51 PM > To: Eduardo Cardona > Cc: Donati Andrew-MGIA0477; ipcdn@ietf.org > Subject: Re: [ipcdn] Changes for next RFI v2 MIB (draft 10) > > > > In general, how would we avoid storing a 'bad' configuration? > > For example: > User might create an notInService entry and set the storageType to > nonVolatile (persistent across reload). And while its in Status of > notInService, the columnar values are not validated. > > > Is that a bad configuration or a temporary held offline configuration? > Bad configuration is 'notReady' > 'notInService' could be : > a createAndWait with complete setup but deferred set 'active' [AZ] It would be the above. But after reading some of the comment from Randy, I think we should be ok for status 'notInService'. > an entry previously 'active' set to 'notInService' > > I believe the StorageType object carries the RowStatus values before the > reset, leaving to the operator > The responsibility to have the house clean. :) > > > > Change #2: > : > "Initial default entries ....., which could report > for a value 'permanent' or 'readOnly' for docsIfCmtsModStorageType. > A CMTS may not allow the creation of additional Interval ....." > > [AZ] I found the above to be confusing: > Can we reword it to: > > "Initial default entries may be created at system intialization > time by defaulting the docsIfCmtsModStorageType value to > 'permanent(4)' or 'readOnly(5). > > > After Randy's comments the definition says: > > Initial default entries MAY be created at system > initialization time which could report for a value > 'permanent' or 'readOnly' for docsIfCmtsModStorageType. > A CMTS MAY allow the creation of additional Interval > Usage Codes for a modulation profile being defined at > Initialization time. > > Will add yours to become: > > Initial default entries MAY be created at system > initialization time by defaulting the > docsIfCmtsModStorageType value to permanent(4) or > readOnly(5). > A CMTS MAY allow the creation of additional Interval > Usage Codes for a modulation profile being defined at > Initialization time. [AZ] Thanks! > > > Change #3: > : > : > Conceptual rows having the value 'permanent' need > not allow write-access to any columnar objects ..." > > [AZ] Since the definition of 'permanent(4)' mentioned that > a row can be changed but not deleted, I don't think we need > to repeat the statement above. > > > > There are two definitions: > Effective read-write columnar values in a row which has a StorageType > 'permananent' > 'permanent' Can be written and last value will be back up after reset. > > The not writable property in the TC description is for the StorageType > > I guess the only difference within nonVolatile and 'permanent' is that > you may not create 'permanent' entries > via SNMP but could modified existing 'permanent' entries, while > 'nonVolatile' entries can be created via SNMP, deleted and even and turn > later to 'volatile'. > > What the text is trying to say is that behaves as a 'readOnly' but TC > refers to > readOnly as a ROM (fully) implementation which is not always the case, > > So many RFCs uses this phrase to indicate that the storage realization > may be > Partially ROM (what's that? EEPROM? ) instead of fully ROM but behaves > as readOnly, > (unchangeable), mainly for the difficult to implement a 'permanent' > entry that is > persistent and writable. Or a code initialized value ("ROM") but > conditioned to further updates (code with NVRAM hooks i.e.) > > Not that I like to go to all these compliances formalism but probably > necessary. > > It leaves also the vendors freedom to handle the 'permanent' cases > read-only or read-write [AZ] Since the only requirement to comply is the support for 'nonVolatile' so I don't see the need to re-state how the 'permanent' status should behave since its already clearly defined. This would also avoid further misinterpretation. Thanks, Azlina > Being dual read-only or read-write is probably another point for > interoperability problems due the ambiguous definition. I guess is being > accepted as a generalization of permanent -> being likely 'readOnly' > without state the ROM implications by TC definitions. > Not something I am very concern. > > > Thanks, > Azlina > > > Eduardo Cardona wrote: > >>Hi Andrew, all, >> >>Please review the attached with the proposed changes for the >>StorageType issues to see of they cover all concerns. >> >>In summary, there are eight proposed changes >> >>Changes 1,2,3,4 are related to the issue brough by Andrew Donati by >>adding StorageType object to the Modulation profile table >> >>Changes 5,6,7,8 are clarifications to accommodate the OPS MIB revision > > >>guidelines sections 4.6.2 and 4.6.4, quite related to the problem >>raised for the storageType case. >> >>During the WG Last call for technical issues, there were no other >>items pointing our attention. >> >>Let the WG know any question or comments by COB Wednesday before >>submiting the draft to IETF. >> >> >>Eduardo > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 15 21:18:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15408 for ; Thu, 15 Apr 2004 21:18:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHue-00035l-0M for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 21:13:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G1Cx4H011880 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 21:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHl0-00016w-44; Thu, 15 Apr 2004 21:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEHhs-00007R-VT for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 20:59: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 UAA14160 for ; Thu, 15 Apr 2004 20:59: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 1BEHhq-0003RX-JX for ipcdn@ietf.org; Thu, 15 Apr 2004 20:59:46 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEHgv-0003Nv-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 20:58:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEHgP-0003K8-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 20:58:17 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 15 Apr 2004 17:07:14 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i3G0vjnH005858; Thu, 15 Apr 2004 17:57:45 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB00896; Thu, 15 Apr 2004 17:57:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20040415170703.020c7530@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Apr 2004 17:55:42 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Cc: "Randy Presuhn" , , , "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, How about adding the following in the description ? "Non-active row (rowStatus in 'notInService' or 'notReady') MAY be destroyed by the agent at reinitialization of the managed system to save the resources". This serves a hint to the user that if they wants to persist any rows across CMTS reload, besides setting the StorageType to nonVolatile(3), user also needs to set the rowStatus to active. As aging non-active rows during the run time, I think it could be vendor dependant implementation. Thanks a lot ! Minnie At 04:56 PM 4/15/2004 -0600, Eduardo Cardona wrote: >That's a good pointer, >Thanks Randy >I personally was not aware of this language in the lengthy RowStatus >description, my apologize > >Minnie, Going back to your question, I now think the aging of >'superfluous' entries is the behavior by default for SNMP and I should >put myself in a non-deviating position of that. In the other hand if the >5 minutes by default of RFC 2579 is not convenient, would you have any >text proposal for this matter? > >Thanks > >Eduardo > > > > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Thursday, April 15, 2004 2:54 PM >To: ipcdn@ietf.org >Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) > > >Hi - > > > From: "Eduardo Cardona" > > To: "Minnie Lu" >... > > Sent: Thursday, April 15, 2004 1:04 PM > > Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) >... > > Specially I am not comfortable with the case of : active -> > > notInService > > -> reboot -> "where is my old entry"? >... > >If you do NOT want it to work this way, then you'll need to put language >to that effect into the DESCRIPTIONs for the RowStatus object. RFC 2579 >page 16 makes it clear why: > > If the management station is prevented from setting the > status column to `active' (e.g., due to management station > or network failure) the conceptual row will be left in the > `notInService' or `notReady' state, consuming resources > indefinitely. The agent must detect conceptual rows that > have been in either state for an abnormally long period of > time and remove them. It is the responsibility of the > DESCRIPTION clause of the status column to indicate what an > abnormally long period of time would be. This period of > time should be long enough to allow for human response time > (including `think time') between the creation of the > conceptual row and the setting of the status to `active'. > In the absence of such information in the DESCRIPTION > clause, it is suggested that this period be approximately 5 > minutes in length. This removal action applies not only to > newly-created rows, but also to previously active rows which > are set to, and left in, the notInService state for a > prolonged period exceeding that which is considered normal > for such a conceptual row. > >Consequently, if the WG wants the peculiar behaviour of having >non-active rows survive re-boots, you'll need to spell it out in the >DESCRIPTIONs. > >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 exim@www1.ietf.org Thu Apr 15 23:28:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23392 for ; Thu, 15 Apr 2004 23:28:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJvs-0006oE-6n for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 23:22:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G3MOEx026169 for ipcdn-archive@odin.ietf.org; Thu, 15 Apr 2004 23:22:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJsc-00067L-NC; Thu, 15 Apr 2004 23:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEJpF-0005SU-Ub for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 23:15: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 XAA22464 for ; Thu, 15 Apr 2004 23:15: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 1BEJpD-0005XX-FB for ipcdn@ietf.org; Thu, 15 Apr 2004 23:15:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEJmj-0005E4-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 23:12:59 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1BEJiT-0004pF-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 23:08:33 -0400 Received: from h-68-164-154-108.snvacaid.dynamic.covad.net ([68.164.154.108] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BEJiO-0001wg-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 20:08:28 -0700 Message-ID: <003201c42360$942805e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <4.3.2.7.2.20040415170703.020c7530@mira-sjc5-1.cisco.com> Subject: Re: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 20:11:57 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Minnie Lu" > To: "Eduardo Cardona" ... > Sent: Thursday, April 15, 2004 5:55 PM > Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) ... > How about adding the following in the description ? > "Non-active row (rowStatus in 'notInService' or 'notReady') MAY be > destroyed by the agent at reinitialization of the managed system to save > the resources". I don't see how this would help interoperability. RFC 2119 says: MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) As a practical matter, the proposed language still means that management applications MUST be prepared to work with managed devices where the non-active rows disappear on reboot, as one would expect from the RowStatus definition. (Neglecting the corner case of reboots completing in less than five minutes from the creation of the row.) > This serves a hint to the user that if they wants to persist any rows > across CMTS reload, besides setting the StorageType to > nonVolatile(3), user also needs to set the rowStatus to active. They would need to do this anyway, based on the definition of StorageType and of RowStatus. > As aging non-active rows during the run time, I think it could be vendor > dependant implementation. ... This doesn't seem consistent with the definition of RowStatus, unless you add language to the object's description saying that these things may be retained indefinitely. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 02:02:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03306 for ; Fri, 16 Apr 2004 02:02:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMLZ-00017H-Cv for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 01:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3G5v5Gk004279 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 01:57:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMJZ-0000U2-59; Fri, 16 Apr 2004 01:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEMHW-0008MF-A2 for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 01:52: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 BAA29971 for ; Fri, 16 Apr 2004 01:52: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 1BEMHT-0002Gp-0r for ipcdn@ietf.org; Fri, 16 Apr 2004 01:52:51 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEMGY-0002BX-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 01:51:54 -0400 Received: from gw2.cox.com ([24.248.72.254] helo=hatl0ms21.CORP.COX.COM) by ietf-mx with esmtp (Exim 4.12) id 1BEMFg-00024E-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 01:51:00 -0400 Received: from mail pickup service by hatl0ms21.CORP.COX.COM with Microsoft SMTPSVC; Fri, 16 Apr 2004 01:50:26 -0400 Received: from cox.com ([10.230.2.122]) by hatl0ms23.corp.cox.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 15 Apr 2004 20:59:35 -0400 Received: from ([192.160.73.61]) by post1.cox.com with ESMTP ; Thu, 15 Apr 2004 20:58:58 -0400 Received: from ondar.cablelabs.com (localhost [127.0.0.1]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3G0w49T026434 for ; Thu, 15 Apr 2004 18:58:04 -0600 (MDT) Received: (from majordom@localhost) by ondar.cablelabs.com (8.12.10/8.12.10/Submit) id i3G0w4u0026425 for docsis-oss-outgoing; Thu, 15 Apr 2004 18:58:04 -0600 (MDT) X-Authentication-Warning: ondar.cablelabs.com: majordom set sender to owner-docsis-oss@cablelabs.com using -f Message-Id: <4.3.2.7.2.20040415170703.020c7530@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 Apr 2004 17:55:42 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Cc: "Randy Presuhn" , , , "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Approved: ondar Precedence: bulk X-OriginalArrivalTime: 16 Apr 2004 00:59:35.0829 (UTC) FILETIME=[1617B450:01C4234E] X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, How about adding the following in the description ? "Non-active row (rowStatus in 'notInService' or 'notReady') MAY be destroyed by the agent at reinitialization of the managed system to save the resources". This serves a hint to the user that if they wants to persist any rows across CMTS reload, besides setting the StorageType to nonVolatile(3), user also needs to set the rowStatus to active. As aging non-active rows during the run time, I think it could be vendor dependant implementation. Thanks a lot ! Minnie At 04:56 PM 4/15/2004 -0600, Eduardo Cardona wrote: >That's a good pointer, >Thanks Randy >I personally was not aware of this language in the lengthy RowStatus >description, my apologize > >Minnie, Going back to your question, I now think the aging of >'superfluous' entries is the behavior by default for SNMP and I should >put myself in a non-deviating position of that. In the other hand if the >5 minutes by default of RFC 2579 is not convenient, would you have any >text proposal for this matter? > >Thanks > >Eduardo > > > > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Thursday, April 15, 2004 2:54 PM >To: ipcdn@ietf.org >Subject: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) > > >Hi - > > > From: "Eduardo Cardona" > > To: "Minnie Lu" >... > > Sent: Thursday, April 15, 2004 1:04 PM > > Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) >... > > Specially I am not comfortable with the case of : active -> > > notInService > > -> reboot -> "where is my old entry"? >... > >If you do NOT want it to work this way, then you'll need to put language >to that effect into the DESCRIPTIONs for the RowStatus object. RFC 2579 >page 16 makes it clear why: > > If the management station is prevented from setting the > status column to `active' (e.g., due to management station > or network failure) the conceptual row will be left in the > `notInService' or `notReady' state, consuming resources > indefinitely. The agent must detect conceptual rows that > have been in either state for an abnormally long period of > time and remove them. It is the responsibility of the > DESCRIPTION clause of the status column to indicate what an > abnormally long period of time would be. This period of > time should be long enough to allow for human response time > (including `think time') between the creation of the > conceptual row and the setting of the status to `active'. > In the absence of such information in the DESCRIPTION > clause, it is suggested that this period be approximately 5 > minutes in length. This removal action applies not only to > newly-created rows, but also to previously active rows which > are set to, and left in, the notInService state for a > prolonged period exceeding that which is considered normal > for such a conceptual row. > >Consequently, if the WG wants the peculiar behaviour of having >non-active rows survive re-boots, you'll need to spell it out in the >DESCRIPTIONs. > >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 exim@www1.ietf.org Fri Apr 16 08:16:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03525 for ; Fri, 16 Apr 2004 08:16:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BESCO-0003bN-Nu for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 08:12:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GCC0bl013838 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 08:12:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BES5c-0002JU-Pr; Fri, 16 Apr 2004 08:05:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BES3m-00027a-JK for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 08:03:06 -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 IAA03041 for ; Fri, 16 Apr 2004 08:03:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BES3l-0003NS-MZ for ipcdn@ietf.org; Fri, 16 Apr 2004 08:03:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BES2s-0003GN-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 08:02:11 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx with esmtp (Exim 4.12) id 1BES1y-00037g-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 08:01:14 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id i3GC1ClR003485 for ; Fri, 16 Apr 2004 05:01:12 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id i3GBufqg007639 for ; Fri, 16 Apr 2004 06:56:41 -0500 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 16 Apr 2004 08:01:10 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF2381028EB5D8@ma19exm01.e6.bcs.mot.com> From: Donati Andrew-MGIA0477 To: "'Minnie Lu'" , Eduardo Cardona Cc: Eduardo Cardona , ipcdn@ietf.org, Randy Presuhn , Keske Tom-LTK002 , Azlina Ahmad , DOCSIS OSS Majordomo List Date: Fri, 16 Apr 2004 08:01:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , All, To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. This is defined under "Interaction 4: Making the Conceptual Row Available" in RFC 2579. Taken from RFC2579 Section 2, Row Status, Interaction 4: "If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row." Thanks, Andy -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Thursday, April 15, 2004 3:37 PM To: Eduardo Cardona Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo List Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) Hi, Eduardo, Thanks a lot for listening to me. I am happy with the new text. But I still have concern about saving notInService or notReady rows for modulation profiles into NVRAM and have them persistent across CMTS reboot, especially for the rows with inconsistent attributes which is allowed for rowStatus in 'notInService' and 'notReady'. Though this is extreme case, but since the MIB or spec does not prevent to do so or does not make it optional, that means CMTS MUST implement such capability to save rows with inconsistent attributes into NVRAM which is a waste of CMTS resource and complicated the implementation for no or little gain. Possible to make it an optional that saving rows with inconsistent attributes into NVRAM and persistent across reboot ? Thanks a lot for your advice ! Minnie At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: >Hi all, > >Please find attached the summary of changes after all your feedback, >special thanks to Randy Presuhn for all the detailed comments. > >Please note that the storageType objects are being set as CMTS only >requirement docsIfCmtsGroupV2 since the CM compliances are read-only >or any other tables do not apply to CMs. > >Change #9 for the docsIfCmRangingTimeout please review the other >question sent to the list and OSSI reflector > >Please see if the coments are being captured properly. > > >PDF has the color change, also attached text file for convenience. > > >Thanks > >Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 11:25:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15857 for ; Fri, 16 Apr 2004 11:25:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEV7h-0006Bz-Fz for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 11:19:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GFJLuj023794 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 11:19:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUxl-0003Nv-PZ; Fri, 16 Apr 2004 11:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEUrM-0007YG-Ov for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 11:02: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 LAA14545 for ; Fri, 16 Apr 2004 11:02: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 1BEUrK-0003QA-2u for ipcdn@ietf.org; Fri, 16 Apr 2004 11:02:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEUqc-0003MZ-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 11:01:43 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEUpt-0003GI-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 11:00:57 -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 i3GF0O9T002655; Fri, 16 Apr 2004 09:00:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Date: Fri, 16 Apr 2004 09:00:24 -0600 Message-ID: Thread-Topic: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQjYhFFkmjJ2lsZTveverv1AC+GXAAUmLTA From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minnie, Andrew,=20 In the last few days Randy is being promoting the avoidance of MAY clauses in specific protocol requirements, and I tend to agree with him as far as do not create new requirements but indicates how the box behaves.=20 Having timers on a table basis means to me confusion and unnecessary requirements for both developers and Managers. I also believe the "thinking time" is a valuable feature but current SNMP UIs and applications allow users to do the thinking off-line and set the configuration at once when the management strategy is completed. ( A manager may need to think first time, but if it becomes a very common and repeated task, the manager better script or introduce the task in the OSS workflow to save "$thinking" time). While I think the RowStatus requirements is well intended, I do believe it would be OK in SNMP only managed devices. The storage architecture of systems with CLI I believe is very different of an SNMP only system. Moreover the combinations of both systems makes a cat-catching-its-tail dilemma between CLI and SNMP modules, which I think should be avoided with simplistic approaches. Then I do believe that today there is already a "wide" interoperability issue that is not going to be solved specializing one SNMP table.=20 Therefore, As Randy pointed, the managers should keep the RowStatus in active as a general policy across all management systems to persist entries regardless of accurate implemented RowStatus timeouts, or at reinitialization time deletion.=20 I Also believe a manager will be very uncomfortable to rely in the SNMP agent to age out administratively created entries when it can do them directly (you always will go back to check to see if that happen just for reasons beyond the normal operation of the device).=20 - Which does not solve a totally out of context problem: auditing the management data base quality information, and probably make that more difficult-. =20 In summary, With the RowStatus requirement (which I do not completely understand from a perspective of SNMP state-less protocol but RowStatus) on place I do not see any reasons to deviate from that and I would prefer just leave by default as is with no extra requirements in the DESCRIPTION.=20 But at the same time not saying that the RowStatus aging timeout is something will be ever achieved to be fully interoperable as RFC 2579 says, leaving the issue to be mere operator policy for creation/deletion. Thanks Eduardo =20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Thursday, April 15, 2004 9:12 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Hi - > From: "Minnie Lu" > To: "Eduardo Cardona" ... > Sent: Thursday, April 15, 2004 5:55 PM > Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) ... > How about adding the following in the description ? "Non-active row=20 > (rowStatus in 'notInService' or 'notReady') MAY be destroyed by the=20 > agent at reinitialization of the managed system to save the=20 > resources". I don't see how this would help interoperability. RFC 2119 says: MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) As a practical matter, the proposed language still means that management applications MUST be prepared to work with managed devices where the non-active rows disappear on reboot, as one would expect from the RowStatus definition. (Neglecting the corner case of reboots completing in less than five minutes from the creation of the row.) > This serves a hint to the user that if they wants to persist any rows=20 > across CMTS reload, besides setting the StorageType to nonVolatile(3), > user also needs to set the rowStatus to active. They would need to do this anyway, based on the definition of StorageType and of RowStatus. > As aging non-active rows during the run time, I think it could be=20 > vendor dependant implementation. ... This doesn't seem consistent with the definition of RowStatus, unless you add language to the object's description saying that these things may be retained indefinitely. 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 exim@www1.ietf.org Fri Apr 16 13:00:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21734 for ; Fri, 16 Apr 2004 13:00:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWab-000500-0L for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 12:53:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GGrGbb019209 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 12:53:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWQj-0002iQ-M7; Fri, 16 Apr 2004 12:43:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEW9y-0006fC-7Y for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 12:25:46 -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 MAA19372 for ; Fri, 16 Apr 2004 12:25: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 1BEW9w-0001ND-Jq for ipcdn@ietf.org; Fri, 16 Apr 2004 12:25:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEW8y-0001G6-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 12:24:45 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1BEW8H-00018i-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 12:24:01 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id i3GGO0Ev002404 for ; Fri, 16 Apr 2004 09:24:00 -0700 (MST) Received: from ma19exm01.e6.bcs.mot.com (ma19exm01.e6.bcs.mot.com [10.14.33.5]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id i3GGNt9G028474 for ; Fri, 16 Apr 2004 11:23:55 -0500 Received: by ma19exm01.e6.bcs.mot.com with Internet Mail Service (5.5.2657.2) id ; Fri, 16 Apr 2004 12:23:54 -0400 Message-ID: <62173B970AE0A044AED8723C3BCF2381028EB5DB@ma19exm01.e6.bcs.mot.com> From: Donati Andrew-MGIA0477 To: Donati Andrew-MGIA0477 , "'Minnie Lu'" , "'Eduardo Cardona'" Cc: "'Eduardo Cardona'" , "'ipcdn@ietf.org'" , "'Randy Presuhn'" , Keske Tom-LTK002 , "'Azlina Ahmad'" , "'DOCSIS OSS Majordomo List'" Date: Fri, 16 Apr 2004 12:23:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Subject: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , I would like to correct/clarify the earlier sentence. The suggestion should have stated to add to the "docsIfCmtsModControl" DESCRIPTION, not to the "Row Status" DESCRIPTION already defined in RFC2579. Instead of: To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. This is what was intended: To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of docsIfCmtsModControl to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. Thanks, Andy -----Original Message----- From: Donati Andrew-MGIA0477 Sent: Friday, April 16, 2004 8:01 AM To: 'Minnie Lu'; Eduardo Cardona Cc: Eduardo Cardona; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) All, To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. This is defined under "Interaction 4: Making the Conceptual Row Available" in RFC 2579. Taken from RFC2579 Section 2, Row Status, Interaction 4: "If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row." Thanks, Andy -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Thursday, April 15, 2004 3:37 PM To: Eduardo Cardona Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo List Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) Hi, Eduardo, Thanks a lot for listening to me. I am happy with the new text. But I still have concern about saving notInService or notReady rows for modulation profiles into NVRAM and have them persistent across CMTS reboot, especially for the rows with inconsistent attributes which is allowed for rowStatus in 'notInService' and 'notReady'. Though this is extreme case, but since the MIB or spec does not prevent to do so or does not make it optional, that means CMTS MUST implement such capability to save rows with inconsistent attributes into NVRAM which is a waste of CMTS resource and complicated the implementation for no or little gain. Possible to make it an optional that saving rows with inconsistent attributes into NVRAM and persistent across reboot ? Thanks a lot for your advice ! Minnie At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: >Hi all, > >Please find attached the summary of changes after all your feedback, >special thanks to Randy Presuhn for all the detailed comments. > >Please note that the storageType objects are being set as CMTS only >requirement docsIfCmtsGroupV2 since the CM compliances are read-only >or any other tables do not apply to CMs. > >Change #9 for the docsIfCmRangingTimeout please review the other >question sent to the list and OSSI reflector > >Please see if the coments are being captured properly. > > >PDF has the color change, also attached text file for convenience. > > >Thanks > >Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 13:01:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21872 for ; Fri, 16 Apr 2004 13:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWew-00089k-4q for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 12:57:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GGvkJm031333 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 12:57:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWSe-0003FF-Gz; Fri, 16 Apr 2004 12:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEWL1-0000pr-Vh for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 12:37: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 MAA19950 for ; Fri, 16 Apr 2004 12:37: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 1BEWL0-0002Cj-51 for ipcdn@ietf.org; Fri, 16 Apr 2004 12:37:10 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEWK1-000298-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 12:36:10 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEWJA-00024E-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 12:35:16 -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 i3GGYZ9T023583; Fri, 16 Apr 2004 10:34:35 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Apr 2004 10:34:34 -0600 Message-ID: Thread-Topic: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQjzzuUVK/IFs76TS65/SZRxdHV+wAAQMLw From: "Eduardo Cardona" To: "Donati Andrew-MGIA0477" , "Minnie Lu" Cc: , "Randy Presuhn" , "Keske Tom-LTK002" , "Azlina Ahmad" , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Andrew,=20 very welcome the clarification, even though, I think It was well understood since docsIfCmtsModControl SYNTAX is RowStatus,=20 Thanks Eduardo -----Original Message----- From: Donati Andrew-MGIA0477 [mailto:adonati@motorola.com]=20 Sent: Friday, April 16, 2004 10:24 AM To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona Cc: Eduardo Cardona; 'ipcdn@ietf.org'; 'Randy Presuhn'; Keske Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification I would like to correct/clarify the earlier sentence. The suggestion should have stated to add to the "docsIfCmtsModControl" DESCRIPTION, not to the "Row Status" DESCRIPTION already defined in RFC2579. Instead of: To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. This is what was intended: To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of docsIfCmtsModControl to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. Thanks, Andy -----Original Message----- From: Donati Andrew-MGIA0477=20 Sent: Friday, April 16, 2004 8:01 AM To: 'Minnie Lu'; Eduardo Cardona Cc: Eduardo Cardona; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) All, To address the concern raised by Minnie, may I suggest that we add to the DESCRIPTION clause of the row status column to define a time interval that the agent must remove rows that remain in the 'notInService' or 'notReady' state. This is defined under "Interaction 4: Making the Conceptual Row Available" in RFC 2579.=20 Taken from RFC2579 Section 2, Row Status, Interaction 4: =20 "If the management station is prevented from setting the status column to `active' (e.g., due to management station or network failure) the conceptual row will be left in the `notInService' or `notReady' state, consuming resources indefinitely. The agent must detect conceptual rows that have been in either state for an abnormally long period of time and remove them. It is the responsibility of the DESCRIPTION clause of the status column to indicate what an abnormally long period of time would be. This period of time should be long enough to allow for human response time (including `think time') between the creation of the conceptual row and the setting of the status to `active'. In the absence of such information in the DESCRIPTION clause, it is suggested that this period be approximately 5 minutes in length. This removal action applies not only to newly-created rows, but also to previously active rows which are set to, and left in, the notInService state for a prolonged period exceeding that which is considered normal for such a conceptual row." Thanks, Andy -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Thursday, April 15, 2004 3:37 PM To: Eduardo Cardona Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo List Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) Hi, Eduardo, Thanks a lot for listening to me. I am happy with the new text. But I still have concern about saving notInService or notReady rows for=20 modulation profiles into NVRAM and have them persistent across CMTS=20 reboot, especially for the rows with inconsistent attributes which is=20 allowed for rowStatus in 'notInService' and 'notReady'. Though this is extreme case, but since the MIB or spec does not prevent=20 to do so or does not make it optional, that means CMTS MUST implement such=20 capability to save rows with inconsistent attributes into NVRAM which is a=20 waste of CMTS resource and complicated the implementation for no or little=20 gain. Possible to make it an optional that saving rows with inconsistent=20 attributes into NVRAM and persistent across reboot ? Thanks a lot for your advice ! Minnie At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: >Hi all, > >Please find attached the summary of changes after all your feedback,=20 >special thanks to Randy Presuhn for all the detailed comments. > >Please note that the storageType objects are being set as CMTS only=20 >requirement docsIfCmtsGroupV2 since the CM compliances are read-only=20 >or any other tables do not apply to CMs. > >Change #9 for the docsIfCmRangingTimeout please review the other=20 >question sent to the list and OSSI reflector > >Please see if the coments are being captured properly. > > >PDF has the color change, also attached text file for convenience. > > >Thanks > >Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 14:55:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27448 for ; Fri, 16 Apr 2004 14:55:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYN4-0007nZ-3T for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 14:47:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GIlQTR029972 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 14:47:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYA7-0001vA-1D; Fri, 16 Apr 2004 14:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEY6d-0000b5-P1 for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 14:30: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 OAA25979 for ; Fri, 16 Apr 2004 14:30: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 1BEY6a-0002yI-Tf for ipcdn@ietf.org; Fri, 16 Apr 2004 14:30:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEY5m-0002tw-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 14:29:35 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEY5E-0002nw-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 14:29:00 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2004 10:38:05 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3GISR7t028357; Fri, 16 Apr 2004 11:28:28 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB61771; Fri, 16 Apr 2004 11:28:27 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416110022.01ea8560@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 11:28:27 -0700 To: "Eduardo Cardona" , "Randy Presuhn" From: Minnie Lu Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Cc: "Donati Andrew-MGIA0477" , "Minnie Lu" , , "Keske Tom-LTK002" , "Azlina Ahmad" , "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Randy and Eduardo, Thanks a lot for the advice ! I wonder whether it is really needed to add the new object StorageType in this modulation profiles. Sorry to go back to the step 1. 1. active row most likely are persistent across reboot already in current CMTS implementation. I don't think it will be any extra work for CMTS to have active MUST be persistent across reboot. Also, it will be clear to user that all active rows will be persistent cross reboot. 2. non-active looks like no use to be persistent across reboot. Also non-active rows can be aged out even in the run time. Since the rule is (please allow me to quoted from Randy's previous email) "explicit about persistence, either mandating it in DESCRIPTIONs or using StorageType to report / control it as needed." Here is my suggestions. Suggestion 1: Explicit about persistence mandating it in DESCRIPTION. "rowStatus is in 'Active' MUST be persistent across managed system reload" For non-active rows, just follow the RFC, so no need to mention in the MIB. Suggestion 2: New object StorageType RO (read-only) For user created active row, the value is always 'nonVolatile(3)' For non-active row, the value is always 'volatile(2)' For system created default rows, the value can be ether a. for vendors choose to have read-create access for the system default rows 'volatile(2)' when row is changed to notInService or 'nonVolatile(3)' b. for vendors choose to have read-only access for the system default rows 'permanent(4)' or 'readOnly(5)' Will it work ? Thanks a lot for your advice again ! Minnie At 10:34 AM 4/16/2004 -0600, Eduardo Cardona wrote: >Hi Andrew, >very welcome the clarification, even though, I think It was well >understood since docsIfCmtsModControl SYNTAX is RowStatus, > >Thanks > >Eduardo > >-----Original Message----- >From: Donati Andrew-MGIA0477 [mailto:adonati@motorola.com] >Sent: Friday, April 16, 2004 10:24 AM >To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona >Cc: Eduardo Cardona; 'ipcdn@ietf.org'; 'Randy Presuhn'; Keske >Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification > > >I would like to correct/clarify the earlier sentence. The suggestion >should have stated to add to the "docsIfCmtsModControl" DESCRIPTION, >not to the "Row Status" DESCRIPTION already defined in RFC2579. > >Instead of: > >To address the concern raised by Minnie, may I suggest that we add to >the DESCRIPTION clause of the row status column to define a time >interval that the agent must remove rows that remain in the >'notInService' or 'notReady' state. > >This is what was intended: > >To address the concern raised by Minnie, may I suggest that we add to >the DESCRIPTION clause of docsIfCmtsModControl to define a time >interval that the agent must remove rows that remain in the >'notInService' or 'notReady' state. > >Thanks, >Andy > >-----Original Message----- >From: Donati Andrew-MGIA0477 >Sent: Friday, April 16, 2004 8:01 AM >To: 'Minnie Lu'; Eduardo Cardona >Cc: Eduardo Cardona; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; >Azlina Ahmad; DOCSIS OSS Majordomo List >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) > > >All, > >To address the concern raised by Minnie, may I suggest that we add to >the DESCRIPTION clause of the row status column to define a time >interval that the agent must remove rows that remain in the >'notInService' or 'notReady' state. > >This is defined under "Interaction 4: Making the Conceptual Row >Available" in RFC 2579. > >Taken from RFC2579 Section 2, Row Status, Interaction 4: > > "If the management station is prevented from setting the > status column to `active' (e.g., due to management station > or network failure) the conceptual row will be left in the > `notInService' or `notReady' state, consuming resources > indefinitely. The agent must detect conceptual rows that > have been in either state for an abnormally long period of > time and remove them. It is the responsibility of the > DESCRIPTION clause of the status column to indicate what an > abnormally long period of time would be. This period of > time should be long enough to allow for human response time > (including `think time') between the creation of the > conceptual row and the setting of the status to `active'. > In the absence of such information in the DESCRIPTION > clause, it is suggested that this period be approximately 5 > minutes in length. This removal action applies not only to > newly-created rows, but also to previously active rows which > are set to, and left in, the notInService state for a > prolonged period exceeding that which is considered normal > for such a conceptual row." > >Thanks, >Andy > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Thursday, April 15, 2004 3:37 PM >To: Eduardo Cardona >Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy >Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS Majordomo >List >Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) > > >Hi, Eduardo, > > Thanks a lot for listening to me. I am happy with the new text. > > But I still have concern about saving notInService or notReady rows >for >modulation profiles into NVRAM and have them persistent across CMTS >reboot, especially for the rows with inconsistent attributes which is >allowed for rowStatus in 'notInService' and 'notReady'. > > Though this is extreme case, but since the MIB or spec does not >prevent >to do so or does not make it optional, that means CMTS MUST implement >such >capability to save rows with inconsistent attributes into NVRAM which is >a >waste of CMTS resource and complicated the implementation for no or >little >gain. > > Possible to make it an optional that saving rows with inconsistent >attributes into NVRAM and persistent across reboot ? > > Thanks a lot for your advice ! > Minnie > > > > >At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: > > >Hi all, > > > >Please find attached the summary of changes after all your feedback, > >special thanks to Randy Presuhn for all the detailed comments. > > > >Please note that the storageType objects are being set as CMTS only > >requirement docsIfCmtsGroupV2 since the CM compliances are read-only > >or any other tables do not apply to CMs. > > > >Change #9 for the docsIfCmRangingTimeout please review the other > >question sent to the list and OSSI reflector > > > >Please see if the coments are being captured properly. > > > > > >PDF has the color change, also attached text file for convenience. > > > > > >Thanks > > > >Eduardo > > > > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 15:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00326 for ; Fri, 16 Apr 2004 15:28:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYmu-0005vY-30 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:14:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJE8S6022775 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:14:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYiw-0003y0-LU; Fri, 16 Apr 2004 15:10:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYQu-0000eS-G2 for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 14:51: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 OAA27303 for ; Fri, 16 Apr 2004 14:51:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYQr-0004w6-LS for ipcdn@ietf.org; Fri, 16 Apr 2004 14:51:21 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYPw-0004rT-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 14:50:25 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEYPM-0004n2-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 14:49:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Apr 2004 10:58:53 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3GInG7t001209; Fri, 16 Apr 2004 11:49:16 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB64140; Fri, 16 Apr 2004 11:49:15 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416114725.0208ed80@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 11:49:14 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Cc: "Randy Presuhn" , , milu@cisco.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, For aging, I would also prefer just leave by default as is with no extra requirements in the DESCRIPTION. We can just focus on the persistence. Thanks a lot ! Minnie At 09:00 AM 4/16/2004 -0600, Eduardo Cardona wrote: >Hi Minnie, Andrew, > >In the last few days Randy is being promoting the avoidance of MAY >clauses in specific protocol requirements, and I tend to agree with him >as far as do not create new requirements but indicates how the box >behaves. > >Having timers on a table basis means to me confusion and unnecessary >requirements for both developers and Managers. >I also believe the "thinking time" is a valuable feature but current >SNMP UIs and applications allow users to do the thinking off-line and >set the configuration at once when the management strategy is completed. >( A manager may need to think first time, but if it becomes a very >common and repeated task, the manager better script or introduce the >task in the OSS workflow to save "$thinking" time). > >While I think the RowStatus requirements is well intended, I do believe >it would be OK in SNMP only managed devices. The storage architecture of >systems with CLI I believe is very different of an SNMP only system. >Moreover the combinations of both systems makes a cat-catching-its-tail >dilemma between CLI and SNMP modules, which I think should be avoided >with simplistic approaches. Then I do believe that today there is >already a "wide" interoperability issue that is not going to be solved >specializing one SNMP table. > >Therefore, As Randy pointed, the managers should keep the RowStatus in >active as a general policy across all management systems to persist >entries regardless of accurate implemented RowStatus timeouts, or at >reinitialization time deletion. > >I Also believe a manager will be very uncomfortable to rely in the SNMP >agent to age out administratively created entries when it can do them >directly (you always will go back to check to see if that happen just >for reasons beyond the normal operation of the device). > >- Which does not solve a totally out of context problem: auditing the >management data base quality information, and probably make that more >difficult-. > > >In summary, With the RowStatus requirement (which I do not completely >understand from a perspective of SNMP state-less protocol but RowStatus) >on place I do not see any reasons to deviate from that and I would >prefer just leave by default as is with no extra requirements in the >DESCRIPTION. > >But at the same time not saying that the RowStatus aging timeout is >something will be ever achieved to be fully interoperable as RFC 2579 >says, leaving the issue to be mere operator policy for >creation/deletion. > >Thanks > >Eduardo > > > > > > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Thursday, April 15, 2004 9:12 PM >To: ipcdn@ietf.org >Subject: Re: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) > > >Hi - > > > From: "Minnie Lu" > > To: "Eduardo Cardona" >... > > Sent: Thursday, April 15, 2004 5:55 PM > > Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) >... > > How about adding the following in the description ? "Non-active row > > (rowStatus in 'notInService' or 'notReady') MAY be destroyed by the > > agent at reinitialization of the managed system to save the > > resources". > >I don't see how this would help interoperability. > >RFC 2119 says: > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > >As a practical matter, the proposed language still means that management >applications MUST be prepared to work with managed devices where the >non-active rows disappear on reboot, as one would expect from the >RowStatus definition. (Neglecting the corner case of reboots completing >in less than five minutes from the creation of the row.) > > > This serves a hint to the user that if they wants to persist any rows > > across CMTS reload, besides setting the StorageType to nonVolatile(3), > > > user also needs to set the rowStatus to active. > >They would need to do this anyway, based on the definition of >StorageType and of RowStatus. > > > As aging non-active rows during the run time, I think it could be > > vendor dependant implementation. >... > >This doesn't seem consistent with the definition of RowStatus, unless >you add language to the object's description saying that these things >may be retained indefinitely. > >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 exim@www1.ietf.org Fri Apr 16 15:29:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00433 for ; Fri, 16 Apr 2004 15:29:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYsb-0000Qq-2W for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:20:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJK04T001635 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:20:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYko-0004tm-L4; Fri, 16 Apr 2004 15:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYaV-0004Xg-E2 for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 15:01:19 -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 PAA27772 for ; Fri, 16 Apr 2004 15:01:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEYaS-0005en-Gg for ipcdn@ietf.org; Fri, 16 Apr 2004 15:01:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYZd-0005bP-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:00:26 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEYYv-0005TP-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 14:59: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 i3GIwx9T022101; Fri, 16 Apr 2004 12:58:59 -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: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Fri, 16 Apr 2004 12:58:59 -0600 Message-ID: Thread-Topic: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQj4KM0ylJV3ZaDQ8G4bMtxb0fJPQAATWbQ From: "Eduardo Cardona" To: "Minnie Lu" , "Randy Presuhn" Cc: "Donati Andrew-MGIA0477" , , "Keske Tom-LTK002" , "Azlina Ahmad" , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minnie,=20 In my side, a two months ago the consensus was to introduce the StorageType although other alternatives were suggested, finally all arguments always pointed "it is white, heins make them, scrambled eaten" so the clearest way was the StorageType Going to your proposal 2), there is a compliance statement that says that only nonVolatile(3) is required wich covers "For user created active row, the value is always 'nonVolatile(3)' Having vendor "writeable" (instead of read-create) default entries is not different that operator created entries, so maybe the text below this is not needed For system created default rows, the value can be ether a. for vendors choose to have read-create access for the system default rows 'volatile(2)' when row is changed to notInService or 'nonVolatile(3)' =20 The sentence below is already covered in the Entry Description b. for vendors choose to have read-only access for the system=20 default rows 'permanent(4)' or 'readOnly(5)' time, which could report a value 'permanent' or 'readOnly' for docsIfCmtsModStorageType. The only pending part.=20 "For non-active row, the value is always 'volatile(2)'" I am not sure if the active to non-active Rowstatus transitions for StorageType are needed or what are the current practices, I won't think it hurts, will like to hear Randy's and other's opinions=20 Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Friday, April 16, 2004 12:28 PM To: Eduardo Cardona; Randy Presuhn Cc: Donati Andrew-MGIA0477; Minnie Lu; ipcdn@ietf.org; Keske Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Hi, Randy and Eduardo, Thanks a lot for the advice ! I wonder whether it is really needed to add the new object StorageType in=20 this modulation profiles. Sorry to go back to the step 1. 1. active row most likely are persistent across reboot already in current=20 CMTS implementation. I don't think it will be any extra work for CMTS to=20 have active MUST be persistent across reboot. Also, it will be clear to=20 user that all active rows will be persistent cross reboot. 2. non-active looks like no use to be persistent across reboot. Also=20 non-active rows can be aged out even in the run time. Since the rule is (please allow me to quoted from Randy's previous email)=20 "explicit about persistence, either mandating it in DESCRIPTIONs or using=20 StorageType to report / control it as needed." Here is my suggestions. Suggestion 1: Explicit about persistence mandating it in DESCRIPTION. "rowStatus is in 'Active' MUST be persistent across managed system reload" For non-active rows, just follow the RFC, so no need to mention in the=20 MIB. Suggestion 2: New object StorageType RO (read-only) For user created active row, the value is always 'nonVolatile(3)' For non-active row, the value is always 'volatile(2)' For system created default rows, the value can be ether a. for vendors choose to have read-create access for the system default rows 'volatile(2)' when row is changed to notInService or 'nonVolatile(3)' b. for vendors choose to have read-only access for the system=20 default rows 'permanent(4)' or 'readOnly(5)' Will it work ? Thanks a lot for your advice again ! Minnie At 10:34 AM 4/16/2004 -0600, Eduardo Cardona wrote: >Hi Andrew, >very welcome the clarification, even though, I think It was well=20 >understood since docsIfCmtsModControl SYNTAX is RowStatus, > >Thanks > >Eduardo > >-----Original Message----- >From: Donati Andrew-MGIA0477 [mailto:adonati@motorola.com] >Sent: Friday, April 16, 2004 10:24 AM >To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona >Cc: Eduardo Cardona; 'ipcdn@ietf.org'; 'Randy Presuhn'; Keske=20 >Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification > > >I would like to correct/clarify the earlier sentence. The suggestion=20 >should have stated to add to the "docsIfCmtsModControl" DESCRIPTION,=20 >not to the "Row Status" DESCRIPTION already defined in RFC2579. > >Instead of: > >To address the concern raised by Minnie, may I suggest that we add to=20 >the DESCRIPTION clause of the row status column to define a time=20 >interval that the agent must remove rows that remain in the=20 >'notInService' or 'notReady' state. > >This is what was intended: > >To address the concern raised by Minnie, may I suggest that we add to=20 >the DESCRIPTION clause of docsIfCmtsModControl to define a time=20 >interval that the agent must remove rows that remain in the=20 >'notInService' or 'notReady' state. > >Thanks, >Andy > >-----Original Message----- >From: Donati Andrew-MGIA0477 >Sent: Friday, April 16, 2004 8:01 AM >To: 'Minnie Lu'; Eduardo Cardona >Cc: Eduardo Cardona; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002;=20 >Azlina Ahmad; DOCSIS OSS Majordomo List >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) > > >All, > >To address the concern raised by Minnie, may I suggest that we add to=20 >the DESCRIPTION clause of the row status column to define a time=20 >interval that the agent must remove rows that remain in the=20 >'notInService' or 'notReady' state. > >This is defined under "Interaction 4: Making the Conceptual Row=20 >Available" in RFC 2579. > >Taken from RFC2579 Section 2, Row Status, Interaction 4: > > "If the management station is prevented from setting the > status column to `active' (e.g., due to management station > or network failure) the conceptual row will be left in the > `notInService' or `notReady' state, consuming resources > indefinitely. The agent must detect conceptual rows that > have been in either state for an abnormally long period of > time and remove them. It is the responsibility of the > DESCRIPTION clause of the status column to indicate what an > abnormally long period of time would be. This period of > time should be long enough to allow for human response time > (including `think time') between the creation of the > conceptual row and the setting of the status to `active'. > In the absence of such information in the DESCRIPTION > clause, it is suggested that this period be approximately 5 > minutes in length. This removal action applies not only to > newly-created rows, but also to previously active rows which > are set to, and left in, the notInService state for a > prolonged period exceeding that which is considered normal > for such a conceptual row." > >Thanks, >Andy > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Thursday, April 15, 2004 3:37 PM >To: Eduardo Cardona >Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy=20 >Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS=20 >Majordomo List >Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) > > >Hi, Eduardo, > > Thanks a lot for listening to me. I am happy with the new text. > > But I still have concern about saving notInService or notReady=20 >rows for modulation profiles into NVRAM and have them persistent across >CMTS reboot, especially for the rows with inconsistent attributes=20 >which is allowed for rowStatus in 'notInService' and 'notReady'. > > Though this is extreme case, but since the MIB or spec does not=20 >prevent to do so or does not make it optional, that means CMTS MUST=20 >implement such >capability to save rows with inconsistent attributes into NVRAM which is >a >waste of CMTS resource and complicated the implementation for no or >little >gain. > > Possible to make it an optional that saving rows with inconsistent=20 >attributes into NVRAM and persistent across reboot ? > > Thanks a lot for your advice ! > Minnie > > > > >At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: > > >Hi all, > > > >Please find attached the summary of changes after all your feedback,=20 > >special thanks to Randy Presuhn for all the detailed comments. > > > >Please note that the storageType objects are being set as CMTS only=20 > >requirement docsIfCmtsGroupV2 since the CM compliances are read-only > >or any other tables do not apply to CMs. > > > >Change #9 for the docsIfCmRangingTimeout please review the other=20 > >question sent to the list and OSSI reflector > > > >Please see if the coments are being captured properly. > > > > > >PDF has the color change, also attached text file for convenience. > > > > > >Thanks > > > >Eduardo > > > > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 15:29:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00453 for ; Fri, 16 Apr 2004 15:29:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYt0-0000hu-Vg for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:20:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJKQW7002714 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:20:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYkp-0004uY-AE; Fri, 16 Apr 2004 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYbX-00066a-HC for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 15:02:23 -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 PAA27797 for ; Fri, 16 Apr 2004 15:02: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 1BEYbU-0005ky-A2 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:02:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYaV-0005fV-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:01:20 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEYZx-0005aP-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:00:45 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3GJ059T022375; Fri, 16 Apr 2004 13:00:05 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Date: Fri, 16 Apr 2004 13:00:05 -0600 Message-ID: Thread-Topic: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Thread-Index: AcQj44tS9dMSqJ37SxadT06K+3i7BAAAV9kg From: "Eduardo Cardona" To: "Minnie Lu" Cc: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sounds good, any diverging opinion? Thanks Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Friday, April 16, 2004 12:49 PM To: Eduardo Cardona Cc: Randy Presuhn; ipcdn@ietf.org; milu@cisco.com Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) Hi, Eduardo, For aging, I would also prefer just leave by default as is with no extra requirements in the DESCRIPTION. We can just focus on the persistence. Thanks a lot ! Minnie At 09:00 AM 4/16/2004 -0600, Eduardo Cardona wrote: >Hi Minnie, Andrew, > >In the last few days Randy is being promoting the avoidance of MAY=20 >clauses in specific protocol requirements, and I tend to agree with him >as far as do not create new requirements but indicates how the box=20 >behaves. > >Having timers on a table basis means to me confusion and unnecessary=20 >requirements for both developers and Managers. I also believe the=20 >"thinking time" is a valuable feature but current SNMP UIs and=20 >applications allow users to do the thinking off-line and set the=20 >configuration at once when the management strategy is completed. ( A=20 >manager may need to think first time, but if it becomes a very common=20 >and repeated task, the manager better script or introduce the task in=20 >the OSS workflow to save "$thinking" time). > >While I think the RowStatus requirements is well intended, I do believe >it would be OK in SNMP only managed devices. The storage architecture=20 >of systems with CLI I believe is very different of an SNMP only system. >Moreover the combinations of both systems makes a cat-catching-its-tail >dilemma between CLI and SNMP modules, which I think should be avoided=20 >with simplistic approaches. Then I do believe that today there is=20 >already a "wide" interoperability issue that is not going to be solved=20 >specializing one SNMP table. > >Therefore, As Randy pointed, the managers should keep the RowStatus in=20 >active as a general policy across all management systems to persist=20 >entries regardless of accurate implemented RowStatus timeouts, or at=20 >reinitialization time deletion. > >I Also believe a manager will be very uncomfortable to rely in the SNMP >agent to age out administratively created entries when it can do them=20 >directly (you always will go back to check to see if that happen just=20 >for reasons beyond the normal operation of the device). > >- Which does not solve a totally out of context problem: auditing the=20 >management data base quality information, and probably make that more=20 >difficult-. > > >In summary, With the RowStatus requirement (which I do not completely=20 >understand from a perspective of SNMP state-less protocol but=20 >RowStatus) on place I do not see any reasons to deviate from that and I >would prefer just leave by default as is with no extra requirements in=20 >the DESCRIPTION. > >But at the same time not saying that the RowStatus aging timeout is=20 >something will be ever achieved to be fully interoperable as RFC 2579=20 >says, leaving the issue to be mere operator policy for=20 >creation/deletion. > >Thanks > >Eduardo > > > > > > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Thursday, April 15, 2004 9:12 PM >To: ipcdn@ietf.org >Subject: Re: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) > > >Hi - > > > From: "Minnie Lu" > > To: "Eduardo Cardona" >... > > Sent: Thursday, April 15, 2004 5:55 PM > > Subject: RE: [ipcdn] Re: V2 Changes for next RFI v2 MIB (draft 10) >... > > How about adding the following in the description ? "Non-active row=20 > > (rowStatus in 'notInService' or 'notReady') MAY be destroyed by the=20 > > agent at reinitialization of the managed system to save the=20 > > resources". > >I don't see how this would help interoperability. > >RFC 2119 says: > MAY This word, or the adjective "OPTIONAL", mean that an item is > truly optional. One vendor may choose to include the item because a > particular marketplace requires it or because the vendor feels that > it enhances the product while another vendor may omit the same item. > An implementation which does not include a particular option MUST be > prepared to interoperate with another implementation which does > include the option, though perhaps with reduced functionality. In the > same vein an implementation which does include a particular option > MUST be prepared to interoperate with another implementation which > does not include the option (except, of course, for the feature the > option provides.) > >As a practical matter, the proposed language still means that=20 >management applications MUST be prepared to work with managed devices=20 >where the non-active rows disappear on reboot, as one would expect from >the RowStatus definition. (Neglecting the corner case of reboots=20 >completing in less than five minutes from the creation of the row.) > > > This serves a hint to the user that if they wants to persist any=20 > > rows across CMTS reload, besides setting the StorageType to=20 > > nonVolatile(3), > > > user also needs to set the rowStatus to active. > >They would need to do this anyway, based on the definition of=20 >StorageType and of RowStatus. > > > As aging non-active rows during the run time, I think it could be=20 > > vendor dependant implementation. >... > >This doesn't seem consistent with the definition of RowStatus, unless=20 >you add language to the object's description saying that these things=20 >may be retained indefinitely. > >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 exim@www1.ietf.org Fri Apr 16 15:36:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00893 for ; Fri, 16 Apr 2004 15:36:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ4Y-0003uE-AO for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:32:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GJWMv3015014 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 15:32:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZ1L-0002x7-VG; Fri, 16 Apr 2004 15:29:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEYqv-00084O-9A for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 15:18:17 -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 PAA29735 for ; Fri, 16 Apr 2004 15:18: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 1BEYqt-00070o-WE for ipcdn@ietf.org; Fri, 16 Apr 2004 15:18:16 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEYpy-0006wl-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:17:19 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEYpC-0006pe-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:16:30 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2004 11:26:47 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3GJFw7t010339; Fri, 16 Apr 2004 12:15:58 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB67150; Fri, 16 Apr 2004 12:15:57 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416121242.01f59cb0@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 12:15:57 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Cc: "Minnie Lu" , "Randy Presuhn" , "Donati Andrew-MGIA0477" , , "Keske Tom-LTK002" , "Azlina Ahmad" , "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, Will you agree that the access is read-only for new object StorageType ? For this modulation profile table, I see there is a need to "report' but I don't see there is a need to let user to 'control' which will create so many complicated cases. Thanks a lot for your advice ! Minnie At 12:58 PM 4/16/2004 -0600, Eduardo Cardona wrote: >Hi Minnie, > >In my side, a two months ago the consensus was to introduce the >StorageType although other alternatives were suggested, finally all >arguments always pointed "it is white, heins make them, scrambled eaten" >so the clearest way was the StorageType > >Going to your proposal 2), there is a compliance statement that says >that only nonVolatile(3) is required wich covers "For user created >active row, the value is always 'nonVolatile(3)' > > >Having vendor "writeable" (instead of read-create) default entries is >not different that operator created entries, so maybe the text below >this is not needed > > For system created default rows, the value can be ether > a. for vendors choose to have read-create access for the system > > default rows 'volatile(2)' when row is changed to >notInService or > 'nonVolatile(3)' > >The sentence below is already covered in the Entry Description > > b. for vendors choose to have read-only access for the system > default rows 'permanent(4)' or 'readOnly(5)' time, which >could report a value > 'permanent' or 'readOnly' for docsIfCmtsModStorageType. > > >The only pending part. > "For non-active row, the value is always 'volatile(2)'" > >I am not sure if the active to non-active Rowstatus transitions for >StorageType are needed or what are the current practices, I won't think >it hurts, will like to hear Randy's and other's opinions > >Eduardo > > > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Friday, April 16, 2004 12:28 PM >To: Eduardo Cardona; Randy Presuhn >Cc: Donati Andrew-MGIA0477; Minnie Lu; ipcdn@ietf.org; Keske Tom-LTK002; >Azlina Ahmad; DOCSIS OSS Majordomo List >Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - >Clarification > > >Hi, Randy and Eduardo, > >Thanks a lot for the advice ! > >I wonder whether it is really needed to add the new object StorageType >in >this modulation profiles. Sorry to go back to the step 1. > >1. active row most likely are persistent across reboot already in >current >CMTS implementation. I don't think it will be any extra work for CMTS >to >have active MUST be persistent across reboot. Also, it will be clear to >user that all active rows will be persistent cross reboot. >2. non-active looks like no use to be persistent across reboot. Also >non-active rows can be aged out even in the run time. > >Since the rule is (please allow me to quoted from Randy's previous >email) >"explicit about persistence, either mandating it in DESCRIPTIONs or >using >StorageType to report / control it as needed." > >Here is my suggestions. > > Suggestion 1: Explicit about persistence mandating it in DESCRIPTION. > "rowStatus is in 'Active' MUST be persistent across managed system >reload" > > For non-active rows, just follow the RFC, so no need to mention in >the >MIB. > > Suggestion 2: New object StorageType RO (read-only) > For user created active row, the value is always 'nonVolatile(3)' > For non-active row, the value is always 'volatile(2)' > For system created default rows, the value can be ether > a. for vendors choose to have read-create access for the system > >default rows > 'volatile(2)' when row is changed to notInService or > 'nonVolatile(3)' > b. for vendors choose to have read-only access for the system >default rows > 'permanent(4)' or 'readOnly(5)' > > Will it work ? > > Thanks a lot for your advice again ! > Minnie > >At 10:34 AM 4/16/2004 -0600, Eduardo Cardona wrote: > >Hi Andrew, > >very welcome the clarification, even though, I think It was well > >understood since docsIfCmtsModControl SYNTAX is RowStatus, > > > >Thanks > > > >Eduardo > > > >-----Original Message----- > >From: Donati Andrew-MGIA0477 [mailto:adonati@motorola.com] > >Sent: Friday, April 16, 2004 10:24 AM > >To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona > >Cc: Eduardo Cardona; 'ipcdn@ietf.org'; 'Randy Presuhn'; Keske > >Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List > >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification > > > > > >I would like to correct/clarify the earlier sentence. The suggestion > >should have stated to add to the "docsIfCmtsModControl" DESCRIPTION, > >not to the "Row Status" DESCRIPTION already defined in RFC2579. > > > >Instead of: > > > >To address the concern raised by Minnie, may I suggest that we add to > >the DESCRIPTION clause of the row status column to define a time > >interval that the agent must remove rows that remain in the > >'notInService' or 'notReady' state. > > > >This is what was intended: > > > >To address the concern raised by Minnie, may I suggest that we add to > >the DESCRIPTION clause of docsIfCmtsModControl to define a time > >interval that the agent must remove rows that remain in the > >'notInService' or 'notReady' state. > > > >Thanks, > >Andy > > > >-----Original Message----- > >From: Donati Andrew-MGIA0477 > >Sent: Friday, April 16, 2004 8:01 AM > >To: 'Minnie Lu'; Eduardo Cardona > >Cc: Eduardo Cardona; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; > >Azlina Ahmad; DOCSIS OSS Majordomo List > >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) > > > > > >All, > > > >To address the concern raised by Minnie, may I suggest that we add to > >the DESCRIPTION clause of the row status column to define a time > >interval that the agent must remove rows that remain in the > >'notInService' or 'notReady' state. > > > >This is defined under "Interaction 4: Making the Conceptual Row > >Available" in RFC 2579. > > > >Taken from RFC2579 Section 2, Row Status, Interaction 4: > > > > "If the management station is prevented from setting the > > status column to `active' (e.g., due to management station > > or network failure) the conceptual row will be left in the > > `notInService' or `notReady' state, consuming resources > > indefinitely. The agent must detect conceptual rows that > > have been in either state for an abnormally long period of > > time and remove them. It is the responsibility of the > > DESCRIPTION clause of the status column to indicate what >an > > abnormally long period of time would be. This period of > > time should be long enough to allow for human response >time > > (including `think time') between the creation of the > > conceptual row and the setting of the status to `active'. > > In the absence of such information in the DESCRIPTION > > clause, it is suggested that this period be approximately >5 > > minutes in length. This removal action applies not only >to > > newly-created rows, but also to previously active rows >which > > are set to, and left in, the notInService state for a > > prolonged period exceeding that which is considered normal > > for such a conceptual row." > > > >Thanks, > >Andy > > > >-----Original Message----- > >From: Minnie Lu [mailto:milu@cisco.com] > >Sent: Thursday, April 15, 2004 3:37 PM > >To: Eduardo Cardona > >Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy > >Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS > >Majordomo List > >Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) > > > > > >Hi, Eduardo, > > > > Thanks a lot for listening to me. I am happy with the new text. > > > > But I still have concern about saving notInService or notReady > >rows for modulation profiles into NVRAM and have them persistent across > > >CMTS reboot, especially for the rows with inconsistent attributes > >which is allowed for rowStatus in 'notInService' and 'notReady'. > > > > Though this is extreme case, but since the MIB or spec does not > >prevent to do so or does not make it optional, that means CMTS MUST > >implement such > >capability to save rows with inconsistent attributes into NVRAM which >is > >a > >waste of CMTS resource and complicated the implementation for no or > >little > >gain. > > > > Possible to make it an optional that saving rows with inconsistent > >attributes into NVRAM and persistent across reboot ? > > > > Thanks a lot for your advice ! > > Minnie > > > > > > > > > >At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: > > > > >Hi all, > > > > > >Please find attached the summary of changes after all your feedback, > > >special thanks to Randy Presuhn for all the detailed comments. > > > > > >Please note that the storageType objects are being set as CMTS only > > >requirement docsIfCmtsGroupV2 since the CM compliances are read-only > > > >or any other tables do not apply to CMs. > > > > > >Change #9 for the docsIfCmRangingTimeout please review the other > > >question sent to the list and OSSI reflector > > > > > >Please see if the coments are being captured properly. > > > > > > > > >PDF has the color change, also attached text file for convenience. > > > > > > > > >Thanks > > > > > >Eduardo > > > > > > > > >_______________________________________________ > >IPCDN mailing list > >IPCDN@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 17:00:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09423 for ; Fri, 16 Apr 2004 17:00:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaHT-0002Qj-27 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 16:49:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GKnl25009331 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 16:49:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEa3N-0004Bd-GD; Fri, 16 Apr 2004 16:35:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZPv-0001lY-VC for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 15:54: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 PAA02010 for ; Fri, 16 Apr 2004 15:54: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 1BEZPu-000120-Cy for ipcdn@ietf.org; Fri, 16 Apr 2004 15:54:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZOy-0000yq-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:53:29 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEZON-0000vH-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:52:52 -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 i3GJqA9T003347; Fri, 16 Apr 2004 13:52: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Fri, 16 Apr 2004 13:52:10 -0600 Message-ID: Thread-Topic: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQj50YAGTm1q6wTSRuDxa5zq8U1ZQAAmsBg From: "Eduardo Cardona" To: "Minnie Lu" Cc: "Randy Presuhn" , "Donati Andrew-MGIA0477" , , "Keske Tom-LTK002" , "Azlina Ahmad" , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minnie,=20 I will buy this, the current compliance statement allow only nonVolatile which makes that nearly a compliance read-only. With version 2 of the proposals the other new StorageType objects are read-only, so for the Modulation Table, even there are some benetifs in being read-crate a read-only will be ok with me,=20 any other opinion? Thanks Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Friday, April 16, 2004 1:16 PM To: Eduardo Cardona Cc: Minnie Lu; Randy Presuhn; Donati Andrew-MGIA0477; ipcdn@ietf.org; Keske Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Hi, Eduardo, Will you agree that the access is read-only for new object StorageType ?=20 For this modulation profile table, I see there is a need to "report' but I=20 don't see there is a need to let user to 'control' which will create so=20 many complicated cases. Thanks a lot for your advice ! Minnie At 12:58 PM 4/16/2004 -0600, Eduardo Cardona wrote: >Hi Minnie, > >In my side, a two months ago the consensus was to introduce the=20 >StorageType although other alternatives were suggested, finally all=20 >arguments always pointed "it is white, heins make them, scrambled=20 >eaten" so the clearest way was the StorageType > >Going to your proposal 2), there is a compliance statement that says=20 >that only nonVolatile(3) is required wich covers "For user created=20 >active row, the value is always 'nonVolatile(3)' > > >Having vendor "writeable" (instead of read-create) default entries is=20 >not different that operator created entries, so maybe the text below=20 >this is not needed > > For system created default rows, the value can be ether > a. for vendors choose to have read-create access for the=20 > system > > default rows 'volatile(2)' when row is changed to=20 >notInService or > 'nonVolatile(3)' > >The sentence below is already covered in the Entry Description > > b. for vendors choose to have read-only access for the system > default rows 'permanent(4)' or 'readOnly(5)' time, which=20 >could report a value > 'permanent' or 'readOnly' for docsIfCmtsModStorageType. > > >The only pending part. > "For non-active row, the value is always 'volatile(2)'" > >I am not sure if the active to non-active Rowstatus transitions for=20 >StorageType are needed or what are the current practices, I won't think >it hurts, will like to hear Randy's and other's opinions > >Eduardo > > > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Friday, April 16, 2004 12:28 PM >To: Eduardo Cardona; Randy Presuhn >Cc: Donati Andrew-MGIA0477; Minnie Lu; ipcdn@ietf.org; Keske=20 >Tom-LTK002; Azlina Ahmad; DOCSIS OSS Majordomo List >Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -=20 >Clarification > > >Hi, Randy and Eduardo, > >Thanks a lot for the advice ! > >I wonder whether it is really needed to add the new object StorageType=20 >in this modulation profiles. Sorry to go back to the step 1. > >1. active row most likely are persistent across reboot already in=20 >current CMTS implementation. I don't think it will be any extra work=20 >for CMTS to >have active MUST be persistent across reboot. Also, it will be clear to >user that all active rows will be persistent cross reboot. >2. non-active looks like no use to be persistent across reboot. Also >non-active rows can be aged out even in the run time. > >Since the rule is (please allow me to quoted from Randy's previous >email) >"explicit about persistence, either mandating it in DESCRIPTIONs or=20 >using StorageType to report / control it as needed." > >Here is my suggestions. > > Suggestion 1: Explicit about persistence mandating it in DESCRIPTION. > "rowStatus is in 'Active' MUST be persistent across managed system >reload" > > For non-active rows, just follow the RFC, so no need to mention=20 >in the MIB. > > Suggestion 2: New object StorageType RO (read-only) > For user created active row, the value is always 'nonVolatile(3)' > For non-active row, the value is always 'volatile(2)' > For system created default rows, the value can be ether > a. for vendors choose to have read-create access for the=20 > system > >default rows > 'volatile(2)' when row is changed to notInService or > 'nonVolatile(3)' > b. for vendors choose to have read-only access for the system >default rows > 'permanent(4)' or 'readOnly(5)' > > Will it work ? > > Thanks a lot for your advice again ! > Minnie > >At 10:34 AM 4/16/2004 -0600, Eduardo Cardona wrote: > >Hi Andrew, > >very welcome the clarification, even though, I think It was well=20 > >understood since docsIfCmtsModControl SYNTAX is RowStatus, > > > >Thanks > > > >Eduardo > > > >-----Original Message----- > >From: Donati Andrew-MGIA0477 [mailto:adonati@motorola.com] > >Sent: Friday, April 16, 2004 10:24 AM > >To: Donati Andrew-MGIA0477; 'Minnie Lu'; Eduardo Cardona > >Cc: Eduardo Cardona; 'ipcdn@ietf.org'; 'Randy Presuhn'; Keske=20 > >Tom-LTK002; 'Azlina Ahmad'; DOCSIS OSS Majordomo List > >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) -=20 > >Clarification > > > > > >I would like to correct/clarify the earlier sentence. The suggestion > >should have stated to add to the "docsIfCmtsModControl" DESCRIPTION,=20 > >not to the "Row Status" DESCRIPTION already defined in RFC2579. > > > >Instead of: > > > >To address the concern raised by Minnie, may I suggest that we add to > >the DESCRIPTION clause of the row status column to define a time=20 > >interval that the agent must remove rows that remain in the=20 > >'notInService' or 'notReady' state. > > > >This is what was intended: > > > >To address the concern raised by Minnie, may I suggest that we add to > >the DESCRIPTION clause of docsIfCmtsModControl to define a time=20 > >interval that the agent must remove rows that remain in the=20 > >'notInService' or 'notReady' state. > > > >Thanks, > >Andy > > > >-----Original Message----- > >From: Donati Andrew-MGIA0477 > >Sent: Friday, April 16, 2004 8:01 AM > >To: 'Minnie Lu'; Eduardo Cardona > >Cc: Eduardo Cardona; ipcdn@ietf.org; Randy Presuhn; Keske Tom-LTK002; > >Azlina Ahmad; DOCSIS OSS Majordomo List > >Subject: RE: V2 Changes for next RFI v2 MIB (draft 10) > > > > > >All, > > > >To address the concern raised by Minnie, may I suggest that we add to > >the DESCRIPTION clause of the row status column to define a time=20 > >interval that the agent must remove rows that remain in the=20 > >'notInService' or 'notReady' state. > > > >This is defined under "Interaction 4: Making the Conceptual Row=20 > >Available" in RFC 2579. > > > >Taken from RFC2579 Section 2, Row Status, Interaction 4: > > > > "If the management station is prevented from setting the > > status column to `active' (e.g., due to management station > > or network failure) the conceptual row will be left in the > > `notInService' or `notReady' state, consuming resources > > indefinitely. The agent must detect conceptual rows that > > have been in either state for an abnormally long period of > > time and remove them. It is the responsibility of the > > DESCRIPTION clause of the status column to indicate what >an > > abnormally long period of time would be. This period of > > time should be long enough to allow for human response >time > > (including `think time') between the creation of the > > conceptual row and the setting of the status to `active'. > > In the absence of such information in the DESCRIPTION > > clause, it is suggested that this period be=20 > > approximately >5 > > minutes in length. This removal action applies not only >to > > newly-created rows, but also to previously active rows >which > > are set to, and left in, the notInService state for a > > prolonged period exceeding that which is considered normal > > for such a conceptual row." > > > >Thanks, > >Andy > > > >-----Original Message----- > >From: Minnie Lu [mailto:milu@cisco.com] > >Sent: Thursday, April 15, 2004 3:37 PM > >To: Eduardo Cardona > >Cc: Eduardo Cardona; Donati Andrew-MGIA0477; ipcdn@ietf.org; Randy=20 > >Presuhn; Keske Tom-LTK002; Azlina Ahmad; Minnie Lu; DOCSIS OSS=20 > >Majordomo List > >Subject: Re: V2 Changes for next RFI v2 MIB (draft 10) > > > > > >Hi, Eduardo, > > > > Thanks a lot for listening to me. I am happy with the new text. > > > > But I still have concern about saving notInService or notReady=20 > >rows for modulation profiles into NVRAM and have them persistent=20 > >across > > >CMTS reboot, especially for the rows with inconsistent attributes=20 > >which is allowed for rowStatus in 'notInService' and 'notReady'. > > > > Though this is extreme case, but since the MIB or spec does not=20 > >prevent to do so or does not make it optional, that means CMTS MUST=20 > >implement such capability to save rows with inconsistent attributes=20 > >into NVRAM which >is > >a > >waste of CMTS resource and complicated the implementation for no or=20 > >little gain. > > > > Possible to make it an optional that saving rows with=20 > >inconsistent attributes into NVRAM and persistent across reboot ? > > > > Thanks a lot for your advice ! > > Minnie > > > > > > > > > >At 10:27 AM 4/15/2004 -0600, Eduardo Cardona wrote: > > > > >Hi all, > > > > > >Please find attached the summary of changes after all your=20 > > >feedback, special thanks to Randy Presuhn for all the detailed=20 > > >comments. > > > > > >Please note that the storageType objects are being set as CMTS only > > >requirement docsIfCmtsGroupV2 since the CM compliances are=20 > > >read-only > > > >or any other tables do not apply to CMs. > > > > > >Change #9 for the docsIfCmRangingTimeout please review the other=20 > > >question sent to the list and OSSI reflector > > > > > >Please see if the coments are being captured properly. > > > > > > > > >PDF has the color change, also attached text file for convenience. > > > > > > > > >Thanks > > > > > >Eduardo > > > > > > > > >_______________________________________________ > >IPCDN mailing list > >IPCDN@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 17:00:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09440 for ; Fri, 16 Apr 2004 17:00:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEaI9-0002jT-Tj for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 16:50:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GKoTmW010500 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 16:50:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEa3O-0004C7-Rl; Fri, 16 Apr 2004 16:35:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEZQl-0002H3-3p for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 15:55:19 -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 PAA02037 for ; Fri, 16 Apr 2004 15:55:16 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEZQj-00015M-IF for ipcdn@ietf.org; Fri, 16 Apr 2004 15:55:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEZPj-00010Q-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:54:16 -0400 Received: from bittern.mail.pas.earthlink.net ([207.217.120.119]) by ietf-mx with esmtp (Exim 4.12) id 1BEZOl-0000wm-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:53:15 -0400 Received: from h-68-165-64-62.snvacaid.dynamic.covad.net ([68.165.64.62] helo=oemcomputer) by bittern.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BEZOk-0006yF-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 12:53:14 -0700 Message-ID: <000c01c423ec$f1e83ec0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Fri, 16 Apr 2004 12:56:44 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Eduardo Cardona" > To: "Minnie Lu" ; "Randy Presuhn" ... > Sent: Friday, April 16, 2004 11:58 AM > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification ... > The only pending part. > "For non-active row, the value is always 'volatile(2)'" This seems like an unusual constraint. My understanding is that the point of having a writable StorageType in a table with RowStatus is to permit the management application to specify the desired persistence behaviour of the row. Regardless of the specified storage type of a row that is under creation, if it stays in a non-active state too long, the agent needs to delete it. (Think of it as preventing a memory leak in object identifier space. :-) > I am not sure if the active to non-active Rowstatus transitions for > StorageType are needed or what are the current practices, I won't think > it hurts, will like to hear Randy's and other's opinions ... The most important active to non-active transition is probably "destroy", which is necessary for obvious reasons. Explicitly placing a row "not in service" is useful if there is a need to modify it, and changes to the active row would not be permitted for some reason. The important thing is to be clear on how you want it to work. I think part of the difficulty here is that it's beginning to sound like the lifecycle of these rows created for cloning may be quite different from other rows. For example, "destroy" doesn't make sense for "normal" rows here. Since provisioning isn't supported, "create-and-go" and "create-and-wait" also don't make sense for "normal" rows. As I indicated before, the table is being used for two very different purposes, and, if it weren't so late in the discussion, I'd advocate a different approach. As to Minnie's point, it'd be perfectly reasonable from a MIB design perspective to not use the StorageType TC, and in the table description to require active rows to persist. The question is whether you actually want it to work that way. (Forgive me if I've misunderstood Minnie's concerns.) What StorageType brings is: - a way to control whether entries created by management persist - a way to learn whether an entry will persist - a distinction between nonVolatile, permanent, and readOnly entries. If these features aren't needed, then there's a legitimate question whether it's the right tool for the job. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 18:16:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15326 for ; Fri, 16 Apr 2004 18:16:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbV5-0004Hq-0T for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 18:07:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GM7sXc016473 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 18:07:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbNQ-0006zt-F4; Fri, 16 Apr 2004 18:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbG5-0005GL-5f for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 17:52: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 RAA12503 for ; Fri, 16 Apr 2004 17:52:21 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BEbG2-0004RN-ET for ipcdn@ietf.org; Fri, 16 Apr 2004 17:52:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbF4-0004Nx-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 17:51:23 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEbED-0004La-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 17:50:30 -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 i3GLnw9T026610; Fri, 16 Apr 2004 15:49:58 -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: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Fri, 16 Apr 2004 15:49:57 -0600 Message-ID: Thread-Topic: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQj9H6RzwYMj9AxQd6x0Yg9oxhrVgAAQLMg From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Randy,=20 I guess you confused the docsIfUpChannelTable (the clone) which now says says temporarly entries (used for clonning)=20 Do not persist The Minnie's situation if for the Modulation table (vendor default entries) It has has no constrains in modifying objects while active, so StorageType is just to identify vendor templates (normally readOnly permanent) of user created entries, ( in your list of ussage of StorageType)=20 Minnie's question if if need to be specify that rowstatus !=3D active, StorageType =3D nonVolatile the entry is deleted or if the RowStatus = aging covers that. Eduardo =20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Friday, April 16, 2004 1:57 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Hi - > From: "Eduardo Cardona" > To: "Minnie Lu" ; "Randy Presuhn"=20 > ... > Sent: Friday, April 16, 2004 11:58 AM > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -=20 > Clarification ... > The only pending part. > "For non-active row, the value is always 'volatile(2)'" This seems like an unusual constraint. My understanding is that the point of having a writable StorageType in a table with RowStatus is to permit the management application to specify the desired persistence behaviour of the row. Regardless of the specified storage type of a row that is under creation, if it stays in a non-active state too long, the agent needs to delete it. (Think of it as preventing a memory leak in object identifier space. :-) > I am not sure if the active to non-active Rowstatus transitions for=20 > StorageType are needed or what are the current practices, I won't=20 > think it hurts, will like to hear Randy's and other's opinions ... The most important active to non-active transition is probably "destroy", which is necessary for obvious reasons. Explicitly placing a row "not in service" is useful if there is a need to modify it, and changes to the active row would not be permitted for some reason. The important thing is to be clear on how you want it to work. I think part of the difficulty here is that it's beginning to sound like the lifecycle of these rows created for cloning may be quite different from other rows. For example, "destroy" doesn't make sense for "normal" rows here. Since provisioning isn't supported, "create-and-go" and "create-and-wait" also don't make sense for "normal" rows. As I indicated before, the table is being used for two very different purposes, and, if it weren't so late in the discussion, I'd advocate a different approach. As to Minnie's point, it'd be perfectly reasonable from a MIB design perspective to not use the StorageType TC, and in the table description to require active rows to persist. The question is whether you actually want it to work that way. (Forgive me if I've misunderstood Minnie's concerns.) What StorageType brings is: - a way to control whether entries created by management persist - a way to learn whether an entry will persist - a distinction between nonVolatile, permanent, and readOnly entries. If these features aren't needed, then there's a legitimate question whether it's the right tool for the job. 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 exim@www1.ietf.org Fri Apr 16 18:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16452 for ; Fri, 16 Apr 2004 18:31:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbl4-0003Yb-2S for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 18:24:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GMOQoT013650 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 18:24:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbgn-0001sL-NE; Fri, 16 Apr 2004 18:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEbVi-0004ug-Ru for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 18:08: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 SAA13688 for ; Fri, 16 Apr 2004 18:08: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 1BEbVf-00054Y-VU for ipcdn@ietf.org; Fri, 16 Apr 2004 18:08:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEbUi-00051w-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 18:07:33 -0400 Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by ietf-mx with esmtp (Exim 4.12) id 1BEbUH-0004zg-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 18:07:05 -0400 Received: from h-68-165-64-62.snvacaid.dynamic.covad.net ([68.165.64.62] helo=oemcomputer) by hawk.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BEbUD-0007F5-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 15:07:02 -0700 Message-ID: <000401c423ff$a3134c00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Fri, 16 Apr 2004 15:10:32 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - > From: "Eduardo Cardona" > To: "Randy Presuhn" ; > Sent: Friday, April 16, 2004 2:49 PM > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification ... > Minnie's question if if need to be specify that rowstatus != active, > StorageType = nonVolatile the entry is deleted or if the RowStatus aging > covers that. ... Ah. Sorry about the confusion. When an agent ages out a row that hasn't gone active within the prescribed time, I believe it doesn't matter what the StorageType was set to. Of course, it doesn't hurt to be explicit. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 16 19:15:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18818 for ; Fri, 16 Apr 2004 19:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcRL-0002Ox-FR for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 19:08:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3GN87BK009209 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 19:08:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEcJX-0007HQ-44; Fri, 16 Apr 2004 19:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEc6P-0003Eu-S0 for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 18:46:29 -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 SAA17317 for ; Fri, 16 Apr 2004 18:46: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 1BEc6M-0000IS-LP for ipcdn@ietf.org; Fri, 16 Apr 2004 18:46:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEc5V-0000Fq-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 18:45:34 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BEc4q-0000B7-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 18:44:52 -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 i3GMiL9T006663; Fri, 16 Apr 2004 16:44:21 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Fri, 16 Apr 2004 16:44:21 -0600 Message-ID: Thread-Topic: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQkAYhtzA/lFG7HRR6zp0Fm59Ko3wAAsOdA From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Exactly that's the last Minnies, concern, if explicitely or not even needed. Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Friday, April 16, 2004 4:11 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Hi - > From: "Eduardo Cardona" > To: "Randy Presuhn" ; > Sent: Friday, April 16, 2004 2:49 PM > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) -=20 > Clarification ... > Minnie's question if if need to be specify that rowstatus !=3D active, = > StorageType =3D nonVolatile the entry is deleted or if the RowStatus=20 > aging covers that. ... Ah. Sorry about the confusion. When an agent ages out a row that hasn't gone active within the prescribed time, I believe it doesn't matter what the StorageType was set to. Of course, it doesn't hurt to be explicit. 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 exim@www1.ietf.org Fri Apr 16 20:42:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23373 for ; Fri, 16 Apr 2004 20:42:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdri-00055r-Og for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 20:39:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3H0dQZp019570 for ipcdn-archive@odin.ietf.org; Fri, 16 Apr 2004 20:39:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdmS-0002xS-Ij; Fri, 16 Apr 2004 20:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BEdi5-0001t9-Gs for ipcdn@optimus.ietf.org; Fri, 16 Apr 2004 20:29:29 -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 UAA22659 for ; Fri, 16 Apr 2004 20:29: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 1BEdi3-0006Fn-9t for ipcdn@ietf.org; Fri, 16 Apr 2004 20:29:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BEdhB-0006Dx-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 20:28:33 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BEdgQ-00068e-00 for ipcdn@ietf.org; Fri, 16 Apr 2004 20:27:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2004 16:38:06 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3H0RE7t003724; Fri, 16 Apr 2004 17:27:14 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATB98181; Fri, 16 Apr 2004 17:27:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20040416170739.0218ae70@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 16 Apr 2004 17:27:13 -0700 To: "Eduardo Cardona" , "Randy Presuhn" From: Minnie Lu Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Cc: , milu@cisco.com, "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo and Randy, "When an agent ages out a row that hasn't gone active within the prescribed time, I believe it doesn't matter what the StorageType was set to." Great ! It is very useful info. Thanks a lot ! So please allow me to summary the requirement as I understand so far. For docsIfCmtsModulationTable, 1. active rows MUST be persistent across CMTS reload. 2. non-active row will not be persistent (implied by rowStatus and no matter what value is in the storageType). 3. System default rows MAY be read-only by setting the storageType value to permanent(4), or readOnly(5) when system create the default rows. I think it is ok to have docsIfCmtsModStorageType as read-only object.:-) In this way, it can be sure that the active row's storageType will not be changed to volatile(2) and lost after reboot. This is important especially for those in-used rows. If I miss anything, please correct me. Thanks a lot ! Minnie At 04:44 PM 4/16/2004 -0600, Eduardo Cardona wrote: >Exactly that's the last Minnies, concern, if explicitely or not even >needed. >Thanks >Eduardo > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Friday, April 16, 2004 4:11 PM >To: ipcdn@ietf.org >Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - >Clarification > > >Hi - > > > From: "Eduardo Cardona" > > To: "Randy Presuhn" ; > > Sent: Friday, April 16, 2004 2:49 PM > > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - > > Clarification >... > > Minnie's question if if need to be specify that rowstatus != active, > > StorageType = nonVolatile the entry is deleted or if the RowStatus > > aging covers that. >... > >Ah. Sorry about the confusion. >When an agent ages out a row that hasn't gone active >within the prescribed time, I believe it doesn't matter what the >StorageType was set to. Of course, it doesn't hurt to be explicit. > >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 exim@www1.ietf.org Sun Apr 18 10:26:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23850 for ; Sun, 18 Apr 2004 10:26:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFDF4-000087-UL for ipcdn-archive@odin.ietf.org; Sun, 18 Apr 2004 10:25:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3IEPsfk000495 for ipcdn-archive@odin.ietf.org; Sun, 18 Apr 2004 10:25:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFDCJ-0007GT-Jp; Sun, 18 Apr 2004 10:23:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFDAV-0006Yp-8X for ipcdn@optimus.ietf.org; Sun, 18 Apr 2004 10:21:11 -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 KAA23596 for ; Sun, 18 Apr 2004 10:21: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 1BFDAS-0005AD-Mc for ipcdn@ietf.org; Sun, 18 Apr 2004 10:21:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFD9Y-0004y2-00 for ipcdn@ietf.org; Sun, 18 Apr 2004 10:20:12 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BFD8u-0004kd-00 for ipcdn@ietf.org; Sun, 18 Apr 2004 10:19:32 -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 i3IEIo9T003967; Sun, 18 Apr 2004 08:18: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: multipart/alternative; boundary="----_=_NextPart_001_01C42550.11FB8366" Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Sun, 18 Apr 2004 08:18:50 -0600 Message-ID: Thread-Topic: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQkEsEmMMF+TE74Tdy5bY1dLrHwCwBPHZOn From: "Eduardo Cardona" To: "Minnie Lu" , "Randy Presuhn" Cc: , , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C42550.11FB8366 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlubmllLCANCiANCnRoYXQncyBhIGdvb2Qgc3VtbWFyeSwgDQogDQpJIHdpbGwgbWFrZSBk b2NzSWZDbXRzTW9kU3RvcmFnZVR5cGUgcmVhZC1vbmx5LCBiYXNlZCBpbiBhbGwgeW91ciBhcmd1 bWVudHMNCiANClRoYW5rcw0KIA0KRWR1YXJkbw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0gDQoJRnJvbTogTWlubmllIEx1IFttYWlsdG86bWlsdUBjaXNjby5jb21dIA0KCVNlbnQ6IEZy aSA0LzE2LzIwMDQgNjoyNyBQTSANCglUbzogRWR1YXJkbyBDYXJkb25hOyBSYW5keSBQcmVzdWhu IA0KCUNjOiBpcGNkbkBpZXRmLm9yZzsgbWlsdUBjaXNjby5jb207IERPQ1NJUyBPU1MgTWFqb3Jk b21vIExpc3QgDQoJU3ViamVjdDogUkU6IFtpcGNkbl0gUkU6IFYyIENoYW5nZXMgZm9yIG5leHQg UkZJIHYyIE1JQiAoZHJhZnQgMTApIC0gQ2xhcmlmaWNhdGlvbg0KCQ0KCQ0KDQoJSGksIEVkdWFy ZG8gYW5kICBSYW5keSwNCgkNCgkiV2hlbiBhbiBhZ2VudCBhZ2VzIG91dCBhIHJvdyB0aGF0IGhh c24ndCBnb25lIGFjdGl2ZQ0KCXdpdGhpbiB0aGUgcHJlc2NyaWJlZCB0aW1lLCBJIGJlbGlldmUg aXQgZG9lc24ndCBtYXR0ZXIgd2hhdCB0aGUNCglTdG9yYWdlVHlwZSB3YXMgc2V0IHRvLiINCgkN CgkgIEdyZWF0ICEgIEl0IGlzIHZlcnkgdXNlZnVsIGluZm8uIFRoYW5rcyBhIGxvdCAhDQoJDQoJ ICBTbyBwbGVhc2UgYWxsb3cgbWUgdG8gc3VtbWFyeSB0aGUgcmVxdWlyZW1lbnQgYXMgSSB1bmRl cnN0YW5kIHNvIGZhci4NCgkNCgkgICBGb3IgZG9jc0lmQ210c01vZHVsYXRpb25UYWJsZSwNCgkg ICAxLiBhY3RpdmUgcm93cyBNVVNUIGJlIHBlcnNpc3RlbnQgYWNyb3NzIENNVFMgcmVsb2FkLg0K CSAgIDIuIG5vbi1hY3RpdmUgcm93IHdpbGwgbm90IGJlIHBlcnNpc3RlbnQgKGltcGxpZWQgYnkg cm93U3RhdHVzIGFuZCBubw0KCW1hdHRlciB3aGF0IHZhbHVlIGlzIGluIHRoZSBzdG9yYWdlVHlw ZSkuDQoJICAgMy4gU3lzdGVtIGRlZmF1bHQgcm93cyBNQVkgYmUgcmVhZC1vbmx5IGJ5IHNldHRp bmcgdGhlIHN0b3JhZ2VUeXBlIHZhbHVlDQoJdG8gIHBlcm1hbmVudCg0KSwgb3IgcmVhZE9ubHko NSkgd2hlbiBzeXN0ZW0gY3JlYXRlIHRoZSBkZWZhdWx0IHJvd3MuDQoJDQoJICAgIEkgdGhpbmsg aXQgaXMgb2sgdG8gaGF2ZSBkb2NzSWZDbXRzTW9kU3RvcmFnZVR5cGUgYXMgcmVhZC1vbmx5DQoJ b2JqZWN0LjotKSAgIEluIHRoaXMgd2F5LCBpdCBjYW4gYmUgc3VyZSB0aGF0IHRoZSBhY3RpdmUg cm93J3Mgc3RvcmFnZVR5cGUNCgl3aWxsIG5vdCBiZSBjaGFuZ2VkIHRvIHZvbGF0aWxlKDIpIGFu ZCBsb3N0IGFmdGVyIHJlYm9vdC4gVGhpcyBpcyBpbXBvcnRhbnQNCgllc3BlY2lhbGx5IGZvciB0 aG9zZSBpbi11c2VkIHJvd3MuDQoJDQoJICAgSWYgSSBtaXNzIGFueXRoaW5nLCBwbGVhc2UgY29y cmVjdCBtZS4NCgkNCgkgICBUaGFua3MgIGEgbG90ICENCgkgICBNaW5uaWUNCgkNCgkNCgkNCglB dCAwNDo0NCBQTSA0LzE2LzIwMDQgLTA2MDAsIEVkdWFyZG8gQ2FyZG9uYSB3cm90ZToNCgk+RXhh Y3RseSB0aGF0J3MgdGhlIGxhc3QgTWlubmllcywgY29uY2VybiwgaWYgZXhwbGljaXRlbHkgb3Ig bm90IGV2ZW4NCgk+bmVlZGVkLg0KCT5UaGFua3MNCgk+RWR1YXJkbw0KCT4NCgk+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCgk+RnJvbTogUmFuZHkgUHJlc3VobiBbbWFpbHRvOnJhbmR5X3By ZXN1aG5AbWluZHNwcmluZy5jb21dDQoJPlNlbnQ6IEZyaWRheSwgQXByaWwgMTYsIDIwMDQgNDox MSBQTQ0KCT5UbzogaXBjZG5AaWV0Zi5vcmcNCgk+U3ViamVjdDogUmU6IFtpcGNkbl0gUkU6IFYy IENoYW5nZXMgZm9yIG5leHQgUkZJIHYyIE1JQiAoZHJhZnQgMTApIC0NCgk+Q2xhcmlmaWNhdGlv bg0KCT4NCgk+DQoJPkhpIC0NCgk+DQoJPiA+IEZyb206ICJFZHVhcmRvIENhcmRvbmEiIDxlLmNh cmRvbmFAQ2FibGVMYWJzLmNvbT4NCgk+ID4gVG86ICJSYW5keSBQcmVzdWhuIiA8cmFuZHlfcHJl c3VobkBtaW5kc3ByaW5nLmNvbT47IDxpcGNkbkBpZXRmLm9yZz4NCgk+ID4gU2VudDogRnJpZGF5 LCBBcHJpbCAxNiwgMjAwNCAyOjQ5IFBNDQoJPiA+IFN1YmplY3Q6IFJFOiBbaXBjZG5dIFJFOiBW MiBDaGFuZ2VzIGZvciBuZXh0IFJGSSB2MiBNSUIgKGRyYWZ0IDEwKSAtDQoJPiA+IENsYXJpZmlj YXRpb24NCgk+Li4uDQoJPiA+IE1pbm5pZSdzIHF1ZXN0aW9uIGlmIGlmIG5lZWQgdG8gYmUgc3Bl Y2lmeSB0aGF0IHJvd3N0YXR1cyAhPSBhY3RpdmUsDQoJPiA+IFN0b3JhZ2VUeXBlID0gbm9uVm9s YXRpbGUgdGhlIGVudHJ5IGlzIGRlbGV0ZWQgb3IgaWYgdGhlIFJvd1N0YXR1cw0KCT4gPiBhZ2lu ZyBjb3ZlcnMgdGhhdC4NCgk+Li4uDQoJPg0KCT5BaC4gIFNvcnJ5IGFib3V0IHRoZSBjb25mdXNp b24uDQoJPldoZW4gYW4gYWdlbnQgYWdlcyBvdXQgYSByb3cgdGhhdCBoYXNuJ3QgZ29uZSBhY3Rp dmUNCgk+d2l0aGluIHRoZSBwcmVzY3JpYmVkIHRpbWUsIEkgYmVsaWV2ZSBpdCBkb2Vzbid0IG1h dHRlciB3aGF0IHRoZQ0KCT5TdG9yYWdlVHlwZSB3YXMgc2V0IHRvLiAgT2YgY291cnNlLCBpdCBk b2Vzbid0IGh1cnQgdG8gYmUgZXhwbGljaXQuDQoJPg0KCT5SYW5keQ0KCT4NCgk+DQoJPg0KCT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT5JUENETiBt YWlsaW5nIGxpc3QNCgk+SVBDRE5AaWV0Zi5vcmcNCgk+aHR0cHM6Ly93d3cxLmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXBjZG4NCgk+DQoJPg0KCT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KCT5JUENETiBtYWlsaW5nIGxpc3QNCgk+SVBDRE5AaWV0 Zi5vcmcNCgk+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBjZG4NCgkN CgkNCg0K ------_=_NextPart_001_01C42550.11FB8366 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPgo8IURPQ1RZUEUgSFRNTCBQVUJMSUMgIi0vL1czQy8vRFREIEhUTUwgMy4yLy9F TiI+CjxIVE1MPgo8SEVBRD4KCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMgRXhj aGFuZ2UgU2VydmVyIHZlcnNpb24gNi4wLjYyNDkuMSI+CjxUSVRMRT5SRTogW2lwY2RuXSBSRTog VjIgQ2hhbmdlcyBmb3IgbmV4dCBSRkkgdjIgTUlCIChkcmFmdCAxMCkgLSAgIENsYXJpZmljYXRp b248L1RJVExFPgo8L0hFQUQ+CjxCT0RZIGRpcj1sdHI+CjxESVY+SGkgTWlubmllLCA8L0RJVj4K PERJVj4mbmJzcDs8L0RJVj4KPERJVj50aGF0J3MgYSBnb29kIHN1bW1hcnksIDwvRElWPgo8RElW PiZuYnNwOzwvRElWPgo8RElWPkkgd2lsbCBtYWtlIGRvY3NJZkNtdHNNb2RTdG9yYWdlVHlwZSBy ZWFkLW9ubHksJm5ic3A7YmFzZWQgaW4gYWxsIHlvdXIgCmFyZ3VtZW50czwvRElWPgo8RElWPiZu YnNwOzwvRElWPgo8RElWPlRoYW5rczwvRElWPgo8RElWPiZuYnNwOzwvRElWPgo8RElWPkVkdWFy ZG88L0RJVj4KPEJMT0NLUVVPVEUgZGlyPWx0ciBzdHlsZT0iTUFSR0lOLVJJR0hUOiAwcHgiPgog IDxESVY+PEZPTlQgc2l6ZT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxCUj48Qj5Gcm9t OjwvQj4gTWlubmllIEx1IAogIFttYWlsdG86bWlsdUBjaXNjby5jb21dIDxCUj48Qj5TZW50Ojwv Qj4gRnJpIDQvMTYvMjAwNCA2OjI3IFBNIDxCUj48Qj5Ubzo8L0I+IAogIEVkdWFyZG8gQ2FyZG9u YTsgUmFuZHkgUHJlc3VobiA8QlI+PEI+Q2M6PC9CPiBpcGNkbkBpZXRmLm9yZzsgbWlsdUBjaXNj by5jb207IAogIERPQ1NJUyBPU1MgTWFqb3Jkb21vIExpc3QgPEJSPjxCPlN1YmplY3Q6PC9CPiBS RTogW2lwY2RuXSBSRTogVjIgQ2hhbmdlcyBmb3IgCiAgbmV4dCBSRkkgdjIgTUlCIChkcmFmdCAx MCkgLSBDbGFyaWZpY2F0aW9uPEJSPjxCUj48L0ZPTlQ+PC9ESVY+CiAgPFA+PEZPTlQgc2l6ZT0y PkhpLCBFZHVhcmRvIGFuZCZuYnNwOyBSYW5keSw8QlI+PEJSPiJXaGVuIGFuIGFnZW50IGFnZXMg b3V0IGEgCiAgcm93IHRoYXQgaGFzbid0IGdvbmUgYWN0aXZlPEJSPndpdGhpbiB0aGUgcHJlc2Ny aWJlZCB0aW1lLCBJIGJlbGlldmUgaXQgCiAgZG9lc24ndCBtYXR0ZXIgd2hhdCB0aGU8QlI+U3Rv cmFnZVR5cGUgd2FzIHNldCB0by4iPEJSPjxCUj4mbmJzcDsgR3JlYXQgCiAgISZuYnNwOyBJdCBp cyB2ZXJ5IHVzZWZ1bCBpbmZvLiBUaGFua3MgYSBsb3QgITxCUj48QlI+Jm5ic3A7IFNvIHBsZWFz ZSBhbGxvdyAKICBtZSB0byBzdW1tYXJ5IHRoZSByZXF1aXJlbWVudCBhcyBJIHVuZGVyc3RhbmQg c28gZmFyLjxCUj48QlI+Jm5ic3A7Jm5ic3A7IEZvciAKICBkb2NzSWZDbXRzTW9kdWxhdGlvblRh YmxlLDxCUj4mbmJzcDsmbmJzcDsgMS4gYWN0aXZlIHJvd3MgTVVTVCBiZSBwZXJzaXN0ZW50IAog IGFjcm9zcyBDTVRTIHJlbG9hZC48QlI+Jm5ic3A7Jm5ic3A7IDIuIG5vbi1hY3RpdmUgcm93IHdp bGwgbm90IGJlIHBlcnNpc3RlbnQgCiAgKGltcGxpZWQgYnkgcm93U3RhdHVzIGFuZCBubzxCUj5t YXR0ZXIgd2hhdCB2YWx1ZSBpcyBpbiB0aGUgCiAgc3RvcmFnZVR5cGUpLjxCUj4mbmJzcDsmbmJz cDsgMy4gU3lzdGVtIGRlZmF1bHQgcm93cyBNQVkgYmUgcmVhZC1vbmx5IGJ5IAogIHNldHRpbmcg dGhlIHN0b3JhZ2VUeXBlIHZhbHVlPEJSPnRvJm5ic3A7IHBlcm1hbmVudCg0KSwgb3IgcmVhZE9u bHkoNSkgd2hlbiAKICBzeXN0ZW0gY3JlYXRlIHRoZSBkZWZhdWx0IHJvd3MuPEJSPjxCUj4mbmJz cDsmbmJzcDsmbmJzcDsgSSB0aGluayBpdCBpcyBvayB0byAKICBoYXZlIGRvY3NJZkNtdHNNb2RT dG9yYWdlVHlwZSBhcyByZWFkLW9ubHk8QlI+b2JqZWN0LjotKSZuYnNwOyZuYnNwOyBJbiB0aGlz IAogIHdheSwgaXQgY2FuIGJlIHN1cmUgdGhhdCB0aGUgYWN0aXZlIHJvdydzIHN0b3JhZ2VUeXBl PEJSPndpbGwgbm90IGJlIGNoYW5nZWQgCiAgdG8gdm9sYXRpbGUoMikgYW5kIGxvc3QgYWZ0ZXIg cmVib290LiBUaGlzIGlzIGltcG9ydGFudDxCUj5lc3BlY2lhbGx5IGZvciAKICB0aG9zZSBpbi11 c2VkIHJvd3MuPEJSPjxCUj4mbmJzcDsmbmJzcDsgSWYgSSBtaXNzIGFueXRoaW5nLCBwbGVhc2Ug Y29ycmVjdCAKICBtZS48QlI+PEJSPiZuYnNwOyZuYnNwOyBUaGFua3MmbmJzcDsgYSBsb3QgITxC Uj4mbmJzcDsmbmJzcDsgCiAgTWlubmllPEJSPjxCUj48QlI+PEJSPkF0IDA0OjQ0IFBNIDQvMTYv MjAwNCAtMDYwMCwgRWR1YXJkbyBDYXJkb25hIAogIHdyb3RlOjxCUj4mZ3Q7RXhhY3RseSB0aGF0 J3MgdGhlIGxhc3QgTWlubmllcywgY29uY2VybiwgaWYgZXhwbGljaXRlbHkgb3Igbm90IAogIGV2 ZW48QlI+Jmd0O25lZWRlZC48QlI+Jmd0O1RoYW5rczxCUj4mZ3Q7RWR1YXJkbzxCUj4mZ3Q7PEJS PiZndDstLS0tLU9yaWdpbmFsIAogIE1lc3NhZ2UtLS0tLTxCUj4mZ3Q7RnJvbTogUmFuZHkgUHJl c3VobiBbPEEgCiAgaHJlZj0ibWFpbHRvOnJhbmR5X3ByZXN1aG5AbWluZHNwcmluZy5jb20iPm1h aWx0bzpyYW5keV9wcmVzdWhuQG1pbmRzcHJpbmcuY29tPC9BPl08QlI+Jmd0O1NlbnQ6IAogIEZy aWRheSwgQXByaWwgMTYsIDIwMDQgNDoxMSBQTTxCUj4mZ3Q7VG86IGlwY2RuQGlldGYub3JnPEJS PiZndDtTdWJqZWN0OiBSZTogCiAgW2lwY2RuXSBSRTogVjIgQ2hhbmdlcyBmb3IgbmV4dCBSRkkg djIgTUlCIChkcmFmdCAxMCkgCiAgLTxCUj4mZ3Q7Q2xhcmlmaWNhdGlvbjxCUj4mZ3Q7PEJSPiZn dDs8QlI+Jmd0O0hpIC08QlI+Jmd0OzxCUj4mZ3Q7ICZndDsgRnJvbTogCiAgIkVkdWFyZG8gQ2Fy ZG9uYSIgJmx0O2UuY2FyZG9uYUBDYWJsZUxhYnMuY29tJmd0OzxCUj4mZ3Q7ICZndDsgVG86ICJS YW5keSAKICBQcmVzdWhuIiAmbHQ7cmFuZHlfcHJlc3VobkBtaW5kc3ByaW5nLmNvbSZndDs7ICZs dDtpcGNkbkBpZXRmLm9yZyZndDs8QlI+Jmd0OyAKICAmZ3Q7IFNlbnQ6IEZyaWRheSwgQXByaWwg MTYsIDIwMDQgMjo0OSBQTTxCUj4mZ3Q7ICZndDsgU3ViamVjdDogUkU6IFtpcGNkbl0gCiAgUkU6 IFYyIENoYW5nZXMgZm9yIG5leHQgUkZJIHYyIE1JQiAoZHJhZnQgMTApIC08QlI+Jmd0OyAmZ3Q7 IAogIENsYXJpZmljYXRpb248QlI+Jmd0Oy4uLjxCUj4mZ3Q7ICZndDsgTWlubmllJ3MgcXVlc3Rp b24gaWYgaWYgbmVlZCB0byBiZSAKICBzcGVjaWZ5IHRoYXQgcm93c3RhdHVzICE9IGFjdGl2ZSw8 QlI+Jmd0OyAmZ3Q7IFN0b3JhZ2VUeXBlID0gbm9uVm9sYXRpbGUgdGhlIAogIGVudHJ5IGlzIGRl bGV0ZWQgb3IgaWYgdGhlIFJvd1N0YXR1czxCUj4mZ3Q7ICZndDsgYWdpbmcgY292ZXJzIAogIHRo YXQuPEJSPiZndDsuLi48QlI+Jmd0OzxCUj4mZ3Q7QWguJm5ic3A7IFNvcnJ5IGFib3V0IHRoZSAK ICBjb25mdXNpb24uPEJSPiZndDtXaGVuIGFuIGFnZW50IGFnZXMgb3V0IGEgcm93IHRoYXQgaGFz bid0IGdvbmUgCiAgYWN0aXZlPEJSPiZndDt3aXRoaW4gdGhlIHByZXNjcmliZWQgdGltZSwgSSBi ZWxpZXZlIGl0IGRvZXNuJ3QgbWF0dGVyIHdoYXQgCiAgdGhlPEJSPiZndDtTdG9yYWdlVHlwZSB3 YXMgc2V0IHRvLiZuYnNwOyBPZiBjb3Vyc2UsIGl0IGRvZXNuJ3QgaHVydCB0byBiZSAKICBleHBs aWNpdC48QlI+Jmd0OzxCUj4mZ3Q7UmFuZHk8QlI+Jmd0OzxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0 O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPiZndDtJ UENETiAKICBtYWlsaW5nIGxpc3Q8QlI+Jmd0O0lQQ0ROQGlldGYub3JnPEJSPiZndDs8QSAKICBo cmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbiI+aHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBjZG48L0E+PEJSPiZndDs8QlI+Jmd0 OzxCUj4mZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+Jmd0O0lQQ0ROIAogIG1haWxpbmcgbGlzdDxCUj4mZ3Q7SVBDRE5AaWV0Zi5vcmc8QlI+Jmd0 OzxBIAogIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwY2Ru Ij5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcGNkbjwvQT48QlI+PEJS PjwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPgoKPC9CT0RZPgo8L0hUTUw+ ------_=_NextPart_001_01C42550.11FB8366-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 19 13:49:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27109 for ; Mon, 19 Apr 2004 13:49:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcpR-0000AV-AN for ipcdn-archive@odin.ietf.org; Mon, 19 Apr 2004 13:45:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JHj9Bu000647 for ipcdn-archive@odin.ietf.org; Mon, 19 Apr 2004 13:45:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFchY-0006r2-V3; Mon, 19 Apr 2004 13:37:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFcbr-00060Y-Uw for ipcdn@optimus.ietf.org; Mon, 19 Apr 2004 13:31:08 -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 NAA25846 for ; Mon, 19 Apr 2004 13:31: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 1BFcbp-00022i-Lt for ipcdn@ietf.org; Mon, 19 Apr 2004 13:31:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFcaq-0001nz-00 for ipcdn@ietf.org; Mon, 19 Apr 2004 13:30:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1BFcZt-0001KG-00 for ipcdn@ietf.org; Mon, 19 Apr 2004 13:29:05 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 19 Apr 2004 09:38:44 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3JHSW7t015585; Mon, 19 Apr 2004 10:28:32 -0700 (PDT) Received: from milu-w2k01.cisco.com (dhcp-171-71-51-38.cisco.com [171.71.51.38]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATD11121; Mon, 19 Apr 2004 10:28:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20040419102753.01f320f8@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 19 Apr 2004 10:28:42 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Cc: "Minnie Lu" , "Randy Presuhn" , , "DOCSIS OSS Majordomo List" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, Thanks a lot ! Minnie At 08:18 AM 4/18/2004 -0600, Eduardo Cardona wrote: >Hi Minnie, > >that's a good summary, > >I will make docsIfCmtsModStorageType read-only, based in all your arguments > >Thanks > >Eduardo >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Fri 4/16/2004 6:27 PM >To: Eduardo Cardona; Randy Presuhn >Cc: ipcdn@ietf.org; milu@cisco.com; DOCSIS OSS Majordomo List >Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - >Clarification > >Hi, Eduardo and Randy, > >"When an agent ages out a row that hasn't gone active >within the prescribed time, I believe it doesn't matter what the >StorageType was set to." > > Great ! It is very useful info. Thanks a lot ! > > So please allow me to summary the requirement as I understand so far. > > For docsIfCmtsModulationTable, > 1. active rows MUST be persistent across CMTS reload. > 2. non-active row will not be persistent (implied by rowStatus and no >matter what value is in the storageType). > 3. System default rows MAY be read-only by setting the storageType value >to permanent(4), or readOnly(5) when system create the default rows. > > I think it is ok to have docsIfCmtsModStorageType as read-only >object.:-) In this way, it can be sure that the active row's storageType >will not be changed to volatile(2) and lost after reboot. This is important >especially for those in-used rows. > > If I miss anything, please correct me. > > Thanks a lot ! > Minnie > > > > > >At 04:44 PM 4/16/2004 -0600, Eduardo Cardona wrote: > >Exactly that's the last Minnies, concern, if explicitely or not even > >needed. > >Thanks > >Eduardo > > > >-----Original Message----- > >From: Randy Presuhn > [mailto:randy_presuhn@mindspring.com] > >Sent: Friday, April 16, 2004 4:11 PM > >To: ipcdn@ietf.org > >Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - > >Clarification > > > > > >Hi - > > > > > From: "Eduardo Cardona" > > > To: "Randy Presuhn" ; > > > Sent: Friday, April 16, 2004 2:49 PM > > > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - > > > Clarification > >... > > > Minnie's question if if need to be specify that rowstatus != active, > > > StorageType = nonVolatile the entry is deleted or if the RowStatus > > > aging covers that. > >... > > > >Ah. Sorry about the confusion. > >When an agent ages out a row that hasn't gone active > >within the prescribed time, I believe it doesn't matter what the > >StorageType was set to. Of course, it doesn't hurt to be explicit. > > > >Randy > > > > > > > >_______________________________________________ > >IPCDN mailing list > >IPCDN@ietf.org > >https://www1.ietf.org/mailm > an/listinfo/ipcdn > > > > > >_______________________________________________ > >IPCDN mailing list > >IPCDN@ietf.org > >https://www1.ietf.org/mailm > an/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 19 19:30:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21055 for ; Mon, 19 Apr 2004 19:30:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFi96-0006xX-9b for ipcdn-archive@odin.ietf.org; Mon, 19 Apr 2004 19:25:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3JNPmx7026745 for ipcdn-archive@odin.ietf.org; Mon, 19 Apr 2004 19:25:48 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFi2e-0005aR-0E; Mon, 19 Apr 2004 19:19:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BFhy9-000364-Fe for ipcdn@optimus.ietf.org; Mon, 19 Apr 2004 19:14:29 -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 TAA19960 for ; Mon, 19 Apr 2004 19:14: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 1BFhy7-0002Gv-On for ipcdn@ietf.org; Mon, 19 Apr 2004 19:14:27 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BFhxD-00023A-00 for ipcdn@ietf.org; Mon, 19 Apr 2004 19:13:32 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BFhwU-0001h4-00 for ipcdn@ietf.org; Mon, 19 Apr 2004 19:12:46 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i3JNC59T016471; Mon, 19 Apr 2004 17:12:06 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Date: Mon, 19 Apr 2004 17:12:05 -0600 Message-ID: Thread-Topic: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Thread-Index: AcQkEsEmMMF+TE74Tdy5bY1dLrHwCwBPHZOnAERGCiA= From: "Eduardo Cardona" To: "Eduardo Cardona" , "Minnie Lu" , "Randy Presuhn" Cc: , , "DOCSIS OSS Majordomo List" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable One last comment, as a clarification,=20 At least I received one comment from a software vender, (not a CMTS vender), being unclear about the reported value of docsIfCmtsCmStatusUpChannelIfIndex for 2.0 CMTs, ifType 129 or 205 ? I guess it merits a clarification for non-DOCSIS experts. Speaking for vendors and Cablelabs perspective is clear that 2.0 CMTS reports ifIndex with ifType 205 and for DOCSIS 1.x it reports ifIndex with ifType 129, Something ovbious for a reduced group of the population.=20 See the current text and the clarification below I am including in the draft 10=20 docsIfCmtsCmStatusUpChannelIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "IfIndex of the upstream channel this CM is connected to. If the upstream channel is unknown, this object returns a value of zero." ::=3D { docsIfCmtsCmStatusEntry 5 } docsIfCmtsCmStatusUpChannelIfIndex OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-only STATUS current DESCRIPTION "For DOCSIS 2.0, indicates the ifIndex of the logical=20 upstream channel (ifType 205) this CM is connected to For DOCSIS 1.x, indicates the ifIndex of the upstream=20 channel (ifType 129) this CM is connected to. If the upstream channel is unknown, this object returns a value of zero." ::=3D { docsIfCmtsCmStatusEntry 5 } Eduardo -----Original Message----- From: Eduardo Cardona=20 Sent: Sunday, April 18, 2004 8:19 AM To: Minnie Lu; Randy Presuhn Cc: ipcdn@ietf.org; milu@cisco.com; DOCSIS OSS Majordomo List Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Hi Minnie,=20 that's a good summary,=20 I will make docsIfCmtsModStorageType read-only, based in all your arguments Thanks Eduardo -----Original Message-----=20 From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Fri 4/16/2004 6:27 PM=20 To: Eduardo Cardona; Randy Presuhn=20 Cc: ipcdn@ietf.org; milu@cisco.com; DOCSIS OSS Majordomo List=20 Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - Clarification Hi, Eduardo and Randy, "When an agent ages out a row that hasn't gone active within the prescribed time, I believe it doesn't matter what the StorageType was set to." Great ! It is very useful info. Thanks a lot ! So please allow me to summary the requirement as I understand so far. For docsIfCmtsModulationTable, 1. active rows MUST be persistent across CMTS reload. 2. non-active row will not be persistent (implied by rowStatus and no matter what value is in the storageType). 3. System default rows MAY be read-only by setting the storageType value to permanent(4), or readOnly(5) when system create the default rows. I think it is ok to have docsIfCmtsModStorageType as read-only object.:-) In this way, it can be sure that the active row's storageType will not be changed to volatile(2) and lost after reboot. This is important especially for those in-used rows. If I miss anything, please correct me. Thanks a lot ! Minnie At 04:44 PM 4/16/2004 -0600, Eduardo Cardona wrote: >Exactly that's the last Minnies, concern, if explicitely or not even >needed. >Thanks >Eduardo > >-----Original Message----- >From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >Sent: Friday, April 16, 2004 4:11 PM >To: ipcdn@ietf.org >Subject: Re: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - >Clarification > > >Hi - > > > From: "Eduardo Cardona" > > To: "Randy Presuhn" ; > > Sent: Friday, April 16, 2004 2:49 PM > > Subject: RE: [ipcdn] RE: V2 Changes for next RFI v2 MIB (draft 10) - > > Clarification >... > > Minnie's question if if need to be specify that rowstatus !=3D = active, > > StorageType =3D nonVolatile the entry is deleted or if the RowStatus > > aging covers that. >... > >Ah. Sorry about the confusion. >When an agent ages out a row that hasn't gone active >within the prescribed time, I believe it doesn't matter what the >StorageType was set to. Of course, it doesn't hurt to be explicit. > >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 exim@www1.ietf.org Thu Apr 22 09:19:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25129 for ; Thu, 22 Apr 2004 09:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGe3R-00027M-B3 for ipcdn-archive@odin.ietf.org; Thu, 22 Apr 2004 09:15:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MDFn9g008121 for ipcdn-archive@odin.ietf.org; Thu, 22 Apr 2004 09:15:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdqC-00069S-Jc; Thu, 22 Apr 2004 09:02:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGdic-0003j2-Sm for ipcdn@optimus.ietf.org; Thu, 22 Apr 2004 08:54: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 IAA23760 for ; Thu, 22 Apr 2004 08:54: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 1BGdiV-0004QU-NM for ipcdn@ietf.org; Thu, 22 Apr 2004 08:54:11 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BGdha-00048O-00 for ipcdn@ietf.org; Thu, 22 Apr 2004 08:53:14 -0400 Received: from poseidon.internet-on.tv ([62.117.0.13] helo=mail.blue-cable.net) by ietf-mx with esmtp (Exim 4.12) id 1BGdgt-0003qE-00 for ipcdn@ietf.org; Thu, 22 Apr 2004 08:52:31 -0400 Received: from ncc-zwickau.internet-on.tv ([172.16.2.1] helo=blue-cable.de) by mail.blue-cable.net with esmtp (Exim 4.22) id 1BGdgI-0007Yf-IZ; Thu, 22 Apr 2004 14:51:54 +0200 Message-ID: <4087BFE9.2080904@blue-cable.de> Date: Thu, 22 Apr 2004 14:51:53 +0200 From: Thomas Anders User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: ipcdn@ietf.org Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects References: <24CDBA67F085904999751B3C4F9E8C0BE2D184@NT-RMNA-0740.brcm.ad.broadcom.com> In-Reply-To: <24CDBA67F085904999751B3C4F9E8C0BE2D184@NT-RMNA-0740.brcm.ad.broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Envelope-From: thomas.anders@blue-cable.de X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi all, AFAICS most people seem to agree here that the dQoS specs should be changed if one wants these SC objects in the SIG-MIB. How to proceed? Anyone willing to write up an ECR (and, preferrably, Cc: to this list)? Best regards, Thomas -- Thomas Anders (thomas.anders at blue-cable.de) _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 22 17:39:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02804 for ; Thu, 22 Apr 2004 17:39:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkxT-0007pp-Ai for ipcdn-archive@odin.ietf.org; Thu, 22 Apr 2004 16:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3MKc7EH030113 for ipcdn-archive@odin.ietf.org; Thu, 22 Apr 2004 16:38:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGkKE-0006xR-11; Thu, 22 Apr 2004 15:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BGk4c-0001AF-3O for ipcdn@optimus.ietf.org; Thu, 22 Apr 2004 15:41:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22532; Thu, 22 Apr 2004 15:41:23 -0400 (EDT) Message-Id: <200404221941.PAA22532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 22 Apr 2004 15:41:23 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-10.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus Filename : draft-ietf-ipcdn-docs-rfmibv2-10.txt Pages : 130 Date : 2004-4-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-10.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-10.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-10.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-4-22154026.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-4-22154026.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 26 10:39:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24690 for ; Mon, 26 Apr 2004 10:39:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI79s-00019v-Kn for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 10:32:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QEWWxf004456 for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 10:32:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI74W-0000Cs-Rx; Mon, 26 Apr 2004 10:27:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI6wp-0005r0-Gx for ipcdn@optimus.ietf.org; Mon, 26 Apr 2004 10:19: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 KAA23209 for ; Mon, 26 Apr 2004 10:18:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BI6wm-0002GE-Tw for ipcdn@ietf.org; Mon, 26 Apr 2004 10:19:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI6w5-0002DB-00 for ipcdn@ietf.org; Mon, 26 Apr 2004 10:18:18 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BI6v8-00024E-00; Mon, 26 Apr 2004 10:17: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 i3QEGdGe018712; Mon, 26 Apr 2004 08:16:39 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Apr 2004 08:16:39 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E264@srvxchg.cablelabs.com> Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQrZpSh6AQwB7tLRNuaiutocT3fSQAIi1DA From: "Eduardo Cardona" To: "Juergen Quittek" , "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jurgen,=20 Thanks for your reply, See comments below and inline -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 Sent: Monday, April 26, 2004 2:11 AM To: Eduardo Cardona; Randy Presuhn; disman@ietf.org Cc: Ipcdn List (E-mail) Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt 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. I understand the desire of having normalized process and applications that may tune themselves by just reading static values (read-write with read-only compliances) as a subset of the full module compliance It is also understood that some vendors later may complain of 'static' requirements as a waist of resources in terms of memory and code. Just my note in the disjunctive of the implementer vs the manager approaches. I always though the AGENT-CAPABILLITIES is the best tool for minimize devices implementations plus adding a robust layer in the manager side to create the vendor, compliance/specific "what if cases", but not very used I guess by current tools. We Will be ok with the disman group decision in this matter, =20 =20 Please find further comments inline. Juergen --=20 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=20 > to extend the capabilities in the private branch, could leave with=20 > 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? I see more an augmentation or RowPointer to an enterprise MIB subtree (from the POV of OPS MIB guidelines, and flexible enough for vendor extensions); which may imply deprecation and a new object for the RowPointer case. I just noted that "opaque" objects are not very common in new MIBs, Can go either with read-only or deprecation. > Regardless of the additions to the MIB I apologize for the late=20 > notice, > > Before sending a complete proposal and get your concept of the best=20 > approach, below is the proposal to add a simplified Compliance=20 > 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=20 > draft-ietf-disman-remops-mib-v2-01.txt > With IPCDN draft=20 > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-0 > 0. > 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=20 > 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. The question was really if=20 The PING-MIB is changed to just define a 'minimalCompliance' for IPCDN cable Gateway Or draft-ietf-disman-remops-mib-v2-01.txt will include the 'minimalCompliance' Not to continue the MIB module overlapping. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null=20 > named log" default entry for devices not supporting the named log=20 > Named log is analog to disman remops draft for "OwnerIndex" and=20 > "TestName" where default entries are created (null owner, null=20 > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 > NSLOOKUP, mostly for small foot-print devices with no network=20 > monitoring role at the connectivity level as pretended with this=20 > updated RFC. I 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? I agree it does not prohibit the nul entry, Just for the minumal compliance no need to 'create' the null entry any time - Just a default entry - , then the read-only complience will be ok The only question remaining in our side is: 1) If RowStatus NotReady will be an indication that not all needed parameters ( Dest Addr) are propoerly setup(?) Or=20 2) The pingCtlAdminStatus Description may need an error code for both Full compliance and minimal compliance to address the SNMP SET when the entry is 'notReady'. Something around:=20 "... returns error 'inconsistentVelue'/'wrongValue' -Advice?- when trying to set to 'enabled' if not previously specified a valid pingCtlTargetAddress" =20 The last onr (2) I think will be enough for removing RowStatus in the minimal Compliance ( not include object in the minimal group) or define it as read-only SYNTAX > In summary A new Compliance Statement for small devices with no=20 > 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=20 > are not relevant to the simplified > system. > - Create an additional set of Compliance statements to require=20 > 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 basicPingGroup OBJECT-GROUP clause=20 > qnd/or hints for OBJECT Compliances: > pingMaxConcurrentRequests -- remove Could also be read-only returning 1. Agree... > pingCtlDataFill -- remove or MIN-ACCESS read-only default > value is OK > pingCtlFrequency -- remove Only one test Could also be read-only returning 0. Agree... > 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) Agree... See more for pingCtlAdminStatus above =20 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=20 > 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=20 > 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=20 > draft-ietf-disman-remops-mib-v2-01.txt > > > > Hi - > >> From: Eduardo Cardona >> Sent: Mar 2, 2004 9:25 AM >> To: Randy Presuhn , disman@ietf.org >> Subject: RE: [Disman] WG last call on=20 >> draft-ietf-disman-remops-mib-v2-01.txt > ... >> One simple note, I tough last call was March 5th > > No, it was supposed to end March 2. However, I'm not > going to hand it to our AD until I can be reasonably sure that it has=20 > received adequate review. > >> We at Cablelabs are interested in adding a simplified compliance=20 >> statement for ad-hoc procedure call instead of a user entry schecule=20 >> entry, so an user can do a one time execution e.g PING > > It would have been nice to have learned of this earlier, rather than=20 > 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=20 > make your specific proposal as quickly as you can. My opinion as a=20 > 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=20 > working group chair, I want to ensure that whatever course we take=20 > reflects WG consensus. So, balancing the need for bringing this to a=20 > conclusion with > the need to ensure that the technical issues are properly considered, > I'll entertain discussion of this issue ("ad hoc procedure call") until > Friday noon (Korean Time). Shortly thereafter I'll make a call on > whether there is consensus to modify the draft regarding this specific > proposal. > > Randy > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 26 12:34:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01060 for ; Mon, 26 Apr 2004 12:34:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8tt-0002oe-BB for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 12:24:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGO96O010817 for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 12:24:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8dJ-00055I-4n; Mon, 26 Apr 2004 12:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BE8uU-00052o-IU for ipcdn@optimus.ietf.org; Thu, 15 Apr 2004 11:36: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 LAA01032 for ; Thu, 15 Apr 2004 11:36:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1BE8uT-0006xx-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 11:36:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BE8tb-0006uT-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 11:35:20 -0400 Received: from mails1.terayon.com ([63.201.251.54]) by ietf-mx with esmtp (Exim 4.12) id 1BE8tK-0006qH-00 for ipcdn@ietf.org; Thu, 15 Apr 2004 11:35:02 -0400 Received: from scbh01.terayon.com (SCBH01.terayon.com [192.168.0.23] (may be forged)) by mails1.terayon.com (8.12.10/8.12.10) with ESMTP id i3FFYrFX003069; Thu, 15 Apr 2004 08:34:54 -0700 (PDT) (envelope-from andre.lejeune@Terayon.com) Received: by SCBH01.terayon.com with Internet Mail Service (5.5.2657.72) id <280G7R4F>; Thu, 15 Apr 2004 08:34:54 -0700 Message-ID: From: "Lejeune, Andre" To: Eduardo Cardona , ipcdn@ietf.org, DOCSIS OSS Majordomo List , DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Thu, 15 Apr 2004 08:32:14 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C422FE.D3D5327E" 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=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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_01C422FE.D3D5327E Content-Type: text/plain I believe this object should have been defined as read-only as there is no advantage in having it read-write. Moreover, the RFI specification, in Annex B, defines a min and max value for it. I do not see how such a timeout can take multiple values. There should have been a unique value for it. Andre -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@cablelabs.com] Sent: Thursday, April 15, 2004 11:07 AM To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Hi all, I have some questions regarding the MIB object docsIfCmRangingTimeout Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96 show docsIfCmRangingTimeout with syntax read-write ( the only CM read-write object in RFI MIB). The questions are Is this object really need to be read-write? particularly if there is any management case where read-write is used. Currently there is no Compliance statement to allow read-only access, is that needed? Is there any instance (in general) when the T3 timer is being adjusted by the CM and retained in Memory after CM reboots ?, or would be ok to explicitly not require persistence without incurring in spec changes? (just a clarification) I am Not planning to deprecate the object but The new revision of RF MIB is being updated to address IETF OPS MIB revision guidelines related to persistence and would be good to precise CM usage of the object. See ipcdn mailing list for current discussion about draft 10 updates http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h tml I will post OSSI DOCSIS reflector with a second revision of the changes as well as IPCDN list soon Thanks Eduardo PD: In Annex A of OSSI spec the obsolete object above docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being tracked to include in an Omnibus ECR) ------_=_NextPart_001_01C422FE.D3D5327E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

I believe this object should have been defined as = read-only as there is no advantage in having it read-write. Moreover, = the RFI specification, in Annex B, defines a min and max value for it. = I do not see how such a timeout can take multiple values. There should = have been a unique value for it.

Andre

-----Original Message-----
From: Eduardo Cardona [mailto:e.cardona@cablelabs.com]
Sent: Thursday, April 15, 2004 11:07 AM
To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; = DOCSIS Macup Majordomo
List
Subject: RE: [ipcdn] Changes for next RFI v2 MIB = (draft 10)


Hi all,

I have some questions regarding the MIB object = docsIfCmRangingTimeout

Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 = Annex A page 96
show docsIfCmRangingTimeout  with syntax = read-write ( the only CM
read-write object in RFI MIB).


The questions are
Is this object really need to be read-write?
particularly if there is any management case where = read-write is used.
Currently there is no Compliance statement to allow = read-only access, is
that needed?

Is there any instance (in general) when the T3 timer = is being adjusted
by the CM and retained in Memory after CM reboots ?, = or would be ok to
explicitly not require persistence without incurring = in spec changes?
(just a clarification)

I am Not planning to deprecate the object but The new = revision of RF MIB
is being updated to address IETF OPS MIB revision = guidelines related to
persistence and would be good to precise CM usage of = the object.

See ipcdn mailing list for current discussion about = draft 10 updates
http://www1.ietf.org/mail-archive/working-groups/ipcdn= /current/threads.h
tml

I will post OSSI DOCSIS reflector with a second = revision of the changes
as well as IPCDN list soon

Thanks

Eduardo


PD: In Annex A of OSSI spec the obsolete object = above
docsIfCmRangingTimeout should be = docsIfCmRangingRespTimeout. ( being
tracked to include in an Omnibus ECR)

------_=_NextPart_001_01C422FE.D3D5327E-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Apr 26 12:35:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01123 for ; Mon, 26 Apr 2004 12:35:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8ul-00039v-IU for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 12:25:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QGP3Y3012138 for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 12:25:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI8dJ-00055Y-Do; Mon, 26 Apr 2004 12:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI1IM-0001Op-W7 for ipcdn@optimus.ietf.org; Mon, 26 Apr 2004 04:16:55 -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 EAA01965 for ; Mon, 26 Apr 2004 04:16: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 1BI1IK-0001j6-A4 for ipcdn@ietf.org; Mon, 26 Apr 2004 04:16:52 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI1HR-0001Wr-00 for ipcdn@ietf.org; Mon, 26 Apr 2004 04:15:58 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1BI1Gv-0001JF-00; Mon, 26 Apr 2004 04:15:25 -0400 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i3Q8Eqrm005294; Mon, 26 Apr 2004 10:14:55 +0200 (CEST) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i3Q8BCQo004861; Mon, 26 Apr 2004 10:11:12 +0200 (CEST) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i3Q8BBri004859; Mon, 26 Apr 2004 10:11:12 +0200 (CEST) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 640BE123451; Mon, 26 Apr 2004 10:11:10 +0200 (CEST) Date: Mon, 26 Apr 2004 10:11:02 +0200 From: Juergen Quittek To: Eduardo Cardona , Randy Presuhn , disman@ietf.org Cc: "Ipcdn List (E-mail)" Message-ID: <2147483647.1082974262@[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 X-Scanned-By: MIMEDefang 2.35 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 Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit 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-mib-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 basicPingGroup OBJECT-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 From exim@www1.ietf.org Mon Apr 26 13:26:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04405 for ; Mon, 26 Apr 2004 13:26:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9iz-0003mU-Hg for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 13:16:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3QHGvah014530 for ipcdn-archive@odin.ietf.org; Mon, 26 Apr 2004 13:16:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9dG-0001tA-0V; Mon, 26 Apr 2004 13:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BI9T6-0006bI-0p for ipcdn@optimus.ietf.org; Mon, 26 Apr 2004 13:00:32 -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 NAA02715 for ; Mon, 26 Apr 2004 13:00: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 1BI9T4-0005ry-5f for ipcdn@ietf.org; Mon, 26 Apr 2004 13:00:30 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BI9S6-0005le-00 for ipcdn@ietf.org; Mon, 26 Apr 2004 12:59:31 -0400 Received: from pacdcoavas04.cable.comcast.com ([208.17.33.53]) by ietf-mx with esmtp (Exim 4.12) id 1BI9R5-0005aa-00 for ipcdn@ietf.org; Mon, 26 Apr 2004 12:58:27 -0400 Message-ID: From: "Woundy, Richard" To: "'Lejeune, Andre'" Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Date: Mon, 26 Apr 2004 12:50:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42BAE.67A08636" 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_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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_01C42BAE.67A08636 Content-Type: text/plain; charset="iso-8859-1" Andre, My apologies, this email was stuck in a "potential spam" queue for IPCDN for way too long... -- Rich -----Original Message----- From: Lejeune, Andre [mailto:andre.lejeune@Terayon.com] Sent: Thursday, April 15, 2004 11:32 AM To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) I believe this object should have been defined as read-only as there is no advantage in having it read-write. Moreover, the RFI specification, in Annex B, defines a min and max value for it. I do not see how such a timeout can take multiple values. There should have been a unique value for it. Andre -----Original Message----- From: Eduardo Cardona [ mailto:e.cardona@cablelabs.com ] Sent: Thursday, April 15, 2004 11:07 AM To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10) Hi all, I have some questions regarding the MIB object docsIfCmRangingTimeout Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96 show docsIfCmRangingTimeout with syntax read-write ( the only CM read-write object in RFI MIB). The questions are Is this object really need to be read-write? particularly if there is any management case where read-write is used. Currently there is no Compliance statement to allow read-only access, is that needed? Is there any instance (in general) when the T3 timer is being adjusted by the CM and retained in Memory after CM reboots ?, or would be ok to explicitly not require persistence without incurring in spec changes? (just a clarification) I am Not planning to deprecate the object but The new revision of RF MIB is being updated to address IETF OPS MIB revision guidelines related to persistence and would be good to precise CM usage of the object. See ipcdn mailing list for current discussion about draft 10 updates http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h tml I will post OSSI DOCSIS reflector with a second revision of the changes as well as IPCDN list soon Thanks Eduardo PD: In Annex A of OSSI spec the obsolete object above docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being tracked to include in an Omnibus ECR) ------_=_NextPart_001_01C42BAE.67A08636 Content-Type: text/html; charset="iso-8859-1" RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)
Andre,
 
My apologies, this email was stuck in a "potential spam" queue for IPCDN for way too long...
 
-- Rich
-----Original Message-----
From: Lejeune, Andre [mailto:andre.lejeune@Terayon.com]
Sent: Thursday, April 15, 2004 11:32 AM
To: Eduardo Cardona; ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo List
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)

I believe this object should have been defined as read-only as there is no advantage in having it read-write. Moreover, the RFI specification, in Annex B, defines a min and max value for it. I do not see how such a timeout can take multiple values. There should have been a unique value for it.

Andre

-----Original Message-----
From: Eduardo Cardona [mailto:e.cardona@cablelabs.com]
Sent: Thursday, April 15, 2004 11:07 AM
To: ipcdn@ietf.org; DOCSIS OSS Majordomo List; DOCSIS Macup Majordomo
List
Subject: RE: [ipcdn] Changes for next RFI v2 MIB (draft 10)


Hi all,

I have some questions regarding the MIB object docsIfCmRangingTimeout

Both the RFI MIB and OSSI spec SP-OSSIv2.0-I05-040407 Annex A page 96
show docsIfCmRangingTimeout  with syntax read-write ( the only CM
read-write object in RFI MIB).


The questions are
Is this object really need to be read-write?
particularly if there is any management case where read-write is used.
Currently there is no Compliance statement to allow read-only access, is
that needed?

Is there any instance (in general) when the T3 timer is being adjusted
by the CM and retained in Memory after CM reboots ?, or would be ok to
explicitly not require persistence without incurring in spec changes?
(just a clarification)

I am Not planning to deprecate the object but The new revision of RF MIB
is being updated to address IETF OPS MIB revision guidelines related to
persistence and would be good to precise CM usage of the object.

See ipcdn mailing list for current discussion about draft 10 updates
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/threads.h
tml

I will post OSSI DOCSIS reflector with a second revision of the changes
as well as IPCDN list soon

Thanks

Eduardo


PD: In Annex A of OSSI spec the obsolete object above
docsIfCmRangingTimeout should be docsIfCmRangingRespTimeout. ( being
tracked to include in an Omnibus ECR)

------_=_NextPart_001_01C42BAE.67A08636-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 29 15:26:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22490 for ; Thu, 29 Apr 2004 15:26:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJH4s-0003cL-Ss for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 15:20:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TJKAY9013900 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 15:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJGkP-00054n-Ky; Thu, 29 Apr 2004 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJG8E-0004qv-GH for ipcdn@optimus.ietf.org; Thu, 29 Apr 2004 14:19: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 OAA18153 for ; Thu, 29 Apr 2004 14:19: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 1BJG88-0007aG-Jd for ipcdn@ietf.org; Thu, 29 Apr 2004 14:19:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJG7B-0007Jm-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 14:18:30 -0400 Received: from mails1.terayon.com ([63.201.251.54]) by ietf-mx with esmtp (Exim 4.12) id 1BJG6j-000733-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 14:18:01 -0400 Received: from scbh01.terayon.com (SCBH01.terayon.com [192.168.0.23] (may be forged)) by mails1.terayon.com (8.12.10/8.12.10) with ESMTP id i3TII32P006301 for ; Thu, 29 Apr 2004 11:18:03 -0700 (PDT) (envelope-from david.raftus@Terayon.com) Received: by SCBH01.terayon.com with Internet Mail Service (5.5.2657.72) id ; Thu, 29 Apr 2004 11:18:03 -0700 Message-ID: From: "Raftus, David" To: "Ipcdn List (E-mail)" Subject: FW: [ipcdn] wg review of draft-ietf-ipcdn-docsisevent-mib-03.txt Date: Thu, 29 Apr 2004 11:15:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C42E15.E61B7DAE" 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=HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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_01C42E15.E61B7DAE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Forwarding event mib review comments to the list. Thanks, Dave -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Thursday, April 29, 2004 12:24 PM To: Raftus, David Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail) Subject: RE: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt Hi David, Thank for your DOCSIS review, this is the most important. Can you still = send your DOCSIS review comments to the list? This was requested by Bert as = it is standard ietf process... Thanks again,=20 Jean-Fran=E7ois > -----Original Message----- > From: Raftus, David [mailto:david.raftus@Terayon.com] > Sent: Thursday, April 29, 2004 8:30 AM > To: Jean-Francois Mule > Cc: Greg Nakanishi (E-mail); Azlina Ahmad (E-mail); Raftus, David > Subject: RE: [ipcdn] wg review of > draft-ietf-ipcdn-docsisevent-mib-03.txt > > > Hi Jean-Francois, >=20 > This event mib draft is actually not too different from the > v2 version created in Jan/03. >=20 > I'm afraid I don't have the necessary background to evaluate > the mib according to compliance with the mib guidelines and > conformance with ID-nits. Sorry for that. Therefore, I didn't > CC my comments to the IPCDN list. >=20 > I did examine the mib from a Docsis perspective though, and > have the following comments: >=20 > 1) Not sure if the default value of NULL is appropriate for > the BITs defval for object docsDevCmTrapControl. This doesn't > give any real guidance as to whether the traps should be > enabled or disabled. The original value of 0x00, while > perhaps not strictly conforming to the octet string nature of > BITs, did signal that all traps default to off. >=20 > 2) The intention of keeping the deprecated mib objects within > the trap definitions was to maintain back-compatibility with > existing 1.1 applications that implemented the trap defs > using the original docs-if ext mib. With the deprecated > objects removed, it is possible that these pre-rf mib v2 > draft 1.1 applications may not be compatible with the new trap defs. >=20 > 3) The event mib is not in sync with the MTA event mgmt mib. > It is not really fair to compare them. The MTA event mgmt mib > uses a generic definition for all informs and traps > pertaining to MTA events. The Docsis event mib creates > individual trap defs for each event. It may be a nice idea to > add inform defs in the Docsis event mib though. >=20 > Again, sorry for not commenting on mib guidelines, etc. >=20 > Regards, > Dave >=20 >=20 > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: Thursday, April 08, 2004 1:05 PM > To: Raftus, David > Cc: Richard Woundy @ Comcast > Subject: RE: [ipcdn] wg review of > draft-ietf-ipcdn-docsisevent-mib-03.txt >=20 > Dave, >=20 > Thanks a lot. > For your review, please consider the following: > - compliance with mib guidelines check-list > - conformance with ID-nits, > - is this MIB in sync with the other ipcdn ID on event mgmt > for MTAs: > =20 > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-event > mess-03.txt > - etc. >=20 > Also, please send your comments to the ipcdn list. > thx, > jean-francois. =20 ------_=_NextPart_001_01C42E15.E61B7DAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt

Hi,

Forwarding event mib review comments to the = list.

Thanks,
Dave

-----Original Message-----
From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]<= /FONT>
Sent: Thursday, April 29, 2004 12:24 PM
To: Raftus, David
Cc: Greg Nakanishi (E-mail); Azlina Ahmad = (E-mail)
Subject: RE: [ipcdn] wg review of = draft-ietf-ipcdn-docsisevent-mib-03.txt

Hi David,

Thank for your DOCSIS review, this is the most = important. Can you still send your DOCSIS review comments to the list? = This was requested by Bert as it is standard ietf process...

Thanks again,
Jean-Fran=E7ois

> -----Original Message-----
> From: Raftus, David [mailto:david.raftus@Terayon.com= ]
> Sent: Thursday, April 29, 2004 8:30 AM
> To: Jean-Francois Mule
> Cc: Greg Nakanishi (E-mail); Azlina Ahmad = (E-mail); Raftus, David
> Subject: RE: [ipcdn] wg review of
> draft-ietf-ipcdn-docsisevent-mib-03.txt
>
>
> Hi Jean-Francois,
>
> This event mib draft is actually not too = different from the
> v2 version created in Jan/03.
>
> I'm afraid I don't have the necessary = background to evaluate
> the mib according to compliance with the mib = guidelines and
> conformance with ID-nits. Sorry for that. = Therefore, I didn't
> CC my comments to the IPCDN list.
>
> I did examine the mib from a Docsis perspective = though, and
> have the following comments:
>
> 1) Not sure if the default value of NULL is = appropriate for
> the BITs defval for object = docsDevCmTrapControl. This doesn't
> give any real guidance as to whether the traps = should be
> enabled or disabled. The original value of = 0x00, while
> perhaps not strictly conforming to the octet = string nature of
> BITs, did signal that all traps default to = off.
>
> 2) The intention of keeping the deprecated mib = objects within
> the trap definitions was to maintain = back-compatibility with
> existing 1.1 applications that implemented the = trap defs
> using the original docs-if ext mib. With the = deprecated
> objects removed, it is possible that these = pre-rf mib v2
> draft 1.1 applications may not be compatible = with the new trap defs.
>
> 3) The event mib is not in sync with the MTA = event mgmt mib.
> It is not really fair to compare them. The MTA = event mgmt mib
> uses a generic definition for all informs and = traps
> pertaining to MTA events. The Docsis event mib = creates
> individual trap defs for each event. It may be = a nice idea to
> add inform defs in the Docsis event mib = though.
>
> Again, sorry for not commenting on mib = guidelines, etc.
>
> Regards,
> Dave
>
>
> -----Original Message-----
> From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com]<= /FONT>
> Sent: Thursday, April 08, 2004 1:05 PM
> To: Raftus, David
> Cc: Richard Woundy @ Comcast
> Subject: RE: [ipcdn] wg review of
> draft-ietf-ipcdn-docsisevent-mib-03.txt
>
> Dave,
>
> Thanks a lot.
> For your review, please consider the = following:
>   - compliance with mib guidelines = check-list
>   - conformance with ID-nits,
>   - is this MIB in sync with the = other ipcdn ID on event mgmt
> for MTAs:
>   
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pk= tc-event
> mess-03.txt
>   - etc.
>
> Also, please send your comments to the ipcdn = list.
> thx,
> jean-francois.
 

------_=_NextPart_001_01C42E15.E61B7DAE-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 29 17:39:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04310 for ; Thu, 29 Apr 2004 17:39:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJAV-0003Dn-S2 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 17:34:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLY75t012328 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 17:34:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIuA-0006pe-4u; Thu, 29 Apr 2004 17:17:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJIhs-0007MR-Na for ipcdn@optimus.ietf.org; Thu, 29 Apr 2004 17:04: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 RAA01376 for ; Thu, 29 Apr 2004 17:04: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 1BJIhl-0005b7-7C for ipcdn@ietf.org; Thu, 29 Apr 2004 17:04:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJIh0-0005ZP-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 17:03:38 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BJIg8-0005Tt-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 17:02:44 -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 i3TL1nGj007482; Thu, 29 Apr 2004 15:02:14 -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: NCS Signaling MIB SC Objects Date: Thu, 29 Apr 2004 15:02:13 -0600 Message-ID: Thread-Topic: [ipcdn] RE: NCS Signaling MIB SC Objects Thread-Index: AcQoa4fbd5V1ZomvTKCScYzP0A5aTwFvlUvQ From: "Jean-Francois Mule" To: "Thomas Anders" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Thomas & all, I would like to summarize the list of open issues first. Once we agree = that this is the list of issues we need to address, and reach consensus = on how to solve it, we can figure out the best way to get it done.=20 Here's a summary of the key issues raised by wg participants, please = review & comment. 1/ Should the MTA MIB provide means to create dynamic DOCSIS SFs for NCS = Signaling, or should it simply be left to the CM config file? 2/ Are the DOCSIS Service Class Name provisioning on the CMTS (and all = the associated policies to authorize flows based on SCN and other rules) = too open to vendor differentiation, hence opening up security risks? =20 3/ Should we clarify any specs and if yes, to specify what and where? Should some informative text be added on the Service Class operations = for NCS Signaling & mandate that "some kind of" configuration parameters = be provided to set up authorization policies. Should this be in the = DOCSIS RFI 2.0 SP-RFIv2.0-I04-030730 Section 10.1.3 Service Classes p = 207? Does this belong to DQoS? Shoud some normative requirements be added on the E-MTA to define what = operations the MTA needs to perform upon setting those MIB objects? 4/ Should we allow an MTA to support multiple Service Class Names = simultaneously and define a more complex NCS SF MIB table to allow per = CMS configuration? Did I miss or mistate anything? Jean-Fran=E7ois=20 > -----Original Message----- > From: Thomas Anders [mailto:thomas.anders@blue-cable.de]=20 > Sent: Thursday, April 22, 2004 6:52 AM > To: ipcdn@ietf.org > Subject: Re: [ipcdn] RE: NCS Signaling MIB SC Objects >=20 >=20 > Hi all, >=20 > AFAICS most people seem to agree here that the dQoS specs=20 > should be changed if one wants these SC objects in the SIG-MIB. >=20 > How to proceed? Anyone willing to write up an ECR (and,=20 > preferrably, Cc: to this list)? >=20 >=20 > Best regards, > Thomas >=20 > --=20 > Thomas Anders (thomas.anders at blue-cable.de) >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 29 17:56:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04715 for ; Thu, 29 Apr 2004 17:56:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJPk-0007oU-7h for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 17:49:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLnq3A030030 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 17:49:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEq-000537-Gh; Thu, 29 Apr 2004 17:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJ4F-0000QY-Lv for ipcdn@optimus.ietf.org; Thu, 29 Apr 2004 17:27: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 RAA03750 for ; Thu, 29 Apr 2004 17:27: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 1BJJ48-0000T3-0C for ipcdn@ietf.org; Thu, 29 Apr 2004 17:27:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJ3F-0000Q2-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 17:26:38 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BJJ2W-0000MJ-00; Thu, 29 Apr 2004 17:25:52 -0400 Received: from h-68-164-86-185.snvacaid.dynamic.covad.net ([68.164.86.185] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BJJ2Y-000093-00; Thu, 29 Apr 2004 14:25:54 -0700 Message-ID: <000601c42e31$1d229f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <2147483647.1082974262@[10.1.1.171]> Date: Thu, 29 Apr 2004 14:29:54 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , 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-mib-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 basicPingGroup OBJECT-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 From exim@www1.ietf.org Thu Apr 29 18:06:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05342 for ; Thu, 29 Apr 2004 18:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJVD-0000fp-A7 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 17:55:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TLtVjn002583 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 17:55:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJOv-0007bP-Dq; Thu, 29 Apr 2004 17:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJJEl-000525-T6 for ipcdn@optimus.ietf.org; Thu, 29 Apr 2004 17:38:31 -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 RAA04286 for ; Thu, 29 Apr 2004 17:38: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 1BJJEe-0000ym-5m for ipcdn@ietf.org; Thu, 29 Apr 2004 17:38:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJDm-0000wQ-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 17:37:31 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BJJCp-0000tq-00; Thu, 29 Apr 2004 17:36:31 -0400 Received: from h-68-164-86-185.snvacaid.dynamic.covad.net ([68.164.86.185] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BJJCt-0002VD-00; Thu, 29 Apr 2004 14:36:35 -0700 Message-ID: <000b01c42e32$9ad4db20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: "Ipcdn List \(E-mail\)" References: <5259D0D7419C6149B347837A2E64F46F03E264@srvxchg.cablelabs.com> Date: Thu, 29 Apr 2004 14:40:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [ipcdn] Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi - As a technical contributor... > From: "Eduardo Cardona" > To: "Juergen Quittek" ; "Randy Presuhn" ; > Cc: "Ipcdn List (E-mail)" > Sent: Monday, April 26, 2004 7:16 AM > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... > - 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. > > > I understand the desire of having normalized process and applications > that may tune themselves by just reading static values (read-write with > read-only compliances) as a subset of the full module compliance > > It is also understood that some vendors later may complain of 'static' > requirements as a waist of resources in terms of memory and code. Just > my note in the disjunctive of the implementer vs the manager > approaches. Since a management application needs to be prepared for missing rows, missing columns, and "holes" in tables ANYWAY (due to access control), I think there would be value of read-only compliance is limited except in the case where there would actually be useful information to read. > I always though the AGENT-CAPABILLITIES is the best tool for minimize > devices implementations plus adding a robust layer in the manager side > to create the vendor, compliance/specific "what if cases", but not very > used I guess by current tools. AGENT-CAPABILITIES isn't useful for stating conformance requirements; it's just a way of saying what a particular implementation can do. > We Will be ok with the disman group decision in this matter, > > ... Ok, but we do appreciate ipcdn's input. We need to be sure the end result meets their needs. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Apr 29 18:41:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08420 for ; Thu, 29 Apr 2004 18:41:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK9E-00085a-Oj for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 18:36:53 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3TMaqGG031069 for ipcdn-archive@odin.ietf.org; Thu, 29 Apr 2004 18:36:52 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK1i-0006IQ-Qt; Thu, 29 Apr 2004 18:29:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJK0A-0005mC-JE for ipcdn@optimus.ietf.org; Thu, 29 Apr 2004 18:27:30 -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 SAA07636 for ; Thu, 29 Apr 2004 18:27: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 1BJK02-0003xx-As for ipcdn@ietf.org; Thu, 29 Apr 2004 18:27:22 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJJz4-0003u4-00 for ipcdn@ietf.org; Thu, 29 Apr 2004 18:26:22 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BJJy6-0003nx-00; Thu, 29 Apr 2004 18:25: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 i3TMOrGe023736; Thu, 29 Apr 2004 16:24:53 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Apr 2004 16:24:53 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E29A@srvxchg.cablelabs.com> Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQuNH2J7hU6Mj2lSvqCkVD7gCDb1AAAoPfQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable A comment, =20 Eduardo > We Will be ok with the disman group decision in this matter, > > ... Ok, but we do appreciate ipcdn's input. We need to be sure the end result meets their needs. In my opinion Holes would be better, It minimizes objects maintenance from the vender POV plus applications are developed (sub-setted) around the minimal compliance. Although some read-only can be benefitial. pingCtlType, pingCtlByPassRouteTable read-only indicates characteristics of how function is implemented pingMaxConcurrentRequests, pingCtlDataFill can be removed --implicit or not required minimal compliance Others in IPCDN group may have a different perception. Comments? _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Apr 30 04:03:10 2004 Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01880 for ; Fri, 30 Apr 2004 04:03:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSxq-0006MH-Vd for ipcdn-archive@odin.ietf.org; Fri, 30 Apr 2004 04:01:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i3U81gpu024300 for ipcdn-archive@odin.ietf.org; Fri, 30 Apr 2004 04:01:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJStL-0005RF-1s; Fri, 30 Apr 2004 03:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BJSrH-0004xm-89 for ipcdn@optimus.ietf.org; Fri, 30 Apr 2004 03:54:55 -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 DAA01503 for ; Fri, 30 Apr 2004 03:54: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 1BJSrB-000183-1E for ipcdn@ietf.org; Fri, 30 Apr 2004 03:54:49 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BJSqF-000115-00 for ipcdn@ietf.org; Fri, 30 Apr 2004 03:53:52 -0400 Received: from astra.telenet-ops.be ([195.130.132.58]) by ietf-mx with esmtp (Exim 4.12) id 1BJSpg-0000u4-00 for ipcdn@ietf.org; Fri, 30 Apr 2004 03:53:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by astra.telenet-ops.be (Postfix) with SMTP id E3530388116 for ; Fri, 30 Apr 2004 09:53:19 +0200 (MEST) Received: from tcomlabs.com (D5E0B8ED.kabel.telenet.be [213.224.184.237]) by astra.telenet-ops.be (Postfix) with ESMTP id C3EDC3880DB for ; Fri, 30 Apr 2004 09:53:19 +0200 (MEST) Received: (qmail 17180 invoked from network); 30 Apr 2004 09:51:06 +0200 Received: from localhost (HELO gateway) (127.0.0.1) by localhost with SMTP; 30 Apr 2004 09:51:06 +0200 Received: from ([10.5.5.72]) by gateway.tcomlabs.com (MailMonitor for SMTP v1.2.2 ) ; Fri, 30 Apr 2004 09:51:06 +0200 (CEST) From: "David De Reu" To: "Jean-Francois Mule" , Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects Date: Fri, 30 Apr 2004 09:53:18 +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.4927.1200 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Dear all, The summary list composed by Jean-Francois looks complete to us. We are willing to provide further input at any time. 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 _____________________________________________________ > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On Behalf Of > Jean-Francois Mule > Sent: donderdag 29 april 2004 23:02 > To: Thomas Anders; ipcdn@ietf.org > Subject: RE: [ipcdn] RE: NCS Signaling MIB SC Objects > > > Hi Thomas & all, > > I would like to summarize the list of open issues first. Once we > agree that this is the list of issues we need to address, and > reach consensus on how to solve it, we can figure out the best > way to get it done. > > Here's a summary of the key issues raised by wg participants, > please review & comment. > > 1/ Should the MTA MIB provide means to create dynamic DOCSIS SFs > for NCS Signaling, or should it simply be left to the CM config file? > > 2/ Are the DOCSIS Service Class Name provisioning on the CMTS > (and all the associated policies to authorize flows based on SCN > and other rules) too open to vendor differentiation, hence > opening up security risks? > > 3/ Should we clarify any specs and if yes, to specify what and where? > Should some informative text be added on the Service Class > operations for NCS Signaling & mandate that "some kind of" > configuration parameters be provided to set up authorization > policies. Should this be in the DOCSIS RFI 2.0 > SP-RFIv2.0-I04-030730 Section 10.1.3 Service Classes p 207? Does > this belong to DQoS? > Shoud some normative requirements be added on the E-MTA to define > what operations the MTA needs to perform upon setting those MIB objects= ? > > 4/ Should we allow an MTA to support multiple Service Class Names > simultaneously and define a more complex NCS SF MIB table to > allow per CMS configuration? > > Did I miss or mistate anything? > Jean-Fran=E7ois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn