From ipcdn-bounces@ietf.org Tue Aug 09 16:36:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aqD-0004yC-Dt; Tue, 09 Aug 2005 16:36:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aqB-0004xY-Ei for ipcdn@megatron.ietf.org; Tue, 09 Aug 2005 16:36:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13027 for ; Tue, 9 Aug 2005 16:36:48 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2bO8-0006Oc-2R for ipcdn@ietf.org; Tue, 09 Aug 2005 17:11:57 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j79KaXoB006162 for ; Tue, 9 Aug 2005 14:36: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; conference call Date: Tue, 9 Aug 2005 14:36:41 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; conference call Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYALbFMcw From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, There has been a suggestion (from Phillip Freyman, Motorola) to move the 'dBm level', currently under 'PktcSigDevToneTable' to 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that require this structure. To discuss this and finalize other things, I am inviting interested IPCDN members for a call tomorrow. Call details are as follows: IPCDN, Discussion related to: draft-ipcdn-pktc-signaling-08 Date : Aug 9, 2005 (Wednesday) Time : 9 AM - 10 AM (Mountain) Dial-in Number : 1-888-742-8686/1-303-928-2600 Access Code : 1097107=20 =20 Regards Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Aug 09 16:38:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2arL-0005k7-K2; Tue, 09 Aug 2005 16:38:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2arK-0005jX-P4 for ipcdn@megatron.ietf.org; Tue, 09 Aug 2005 16:38:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13110 for ; Tue, 9 Aug 2005 16:38:00 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2bPI-0006RP-1E for ipcdn@ietf.org; Tue, 09 Aug 2005 17:13:09 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j79Kbq5R006399 for ; Tue, 9 Aug 2005 14:37:52 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; conference call Date: Tue, 9 Aug 2005 14:38:02 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; conference call Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYALbFMcwAAAtm+A= From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Note: The date should read Aug 10, 2005 (Wednesday) - Sumanth=20 -----Original Message----- From: Sumanth Channabasappa=20 Sent: Tuesday, August 09, 2005 2:37 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; conference call Folks, There has been a suggestion (from Phillip Freyman, Motorola) to move the 'dBm level', currently under 'PktcSigDevToneTable' to 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that require this structure. To discuss this and finalize other things, I am inviting interested IPCDN members for a call tomorrow. Call details are as follows: IPCDN, Discussion related to: draft-ipcdn-pktc-signaling-08 Date : Aug 9, 2005 (Wednesday) Time : 9 AM - 10 AM (Mountain) Dial-in Number : 1-888-742-8686/1-303-928-2600 Access Code : 1097107=20 =20 Regards Sumanth _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 10 12:09:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2t8i-00041c-B9; Wed, 10 Aug 2005 12:09:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2t8h-00041Q-9B for ipcdn@megatron.ietf.org; Wed, 10 Aug 2005 12:09:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08331 for ; Wed, 10 Aug 2005 12:09:08 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2tgo-0002zq-EV for ipcdn@ietf.org; Wed, 10 Aug 2005 12:44:28 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7AG8w1D007238 for ; Wed, 10 Aug 2005 10:08: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 Date: Wed, 10 Aug 2005 10:09:21 -0600 Message-ID: Thread-Topic: draft-ipcdn-pktc-signaling-08, further changes; result of conference call Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYALbFMcwAAAtm+AAKDJ+AA== From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; result of conference call X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, As per the discussion on the conference call today (thanks to the attendees), the proposal from Phil seems to be reasonable. Further, there was a suggestion to include the following examples in the draft for clarity and ease of implementation. Note: Example B was also the cause for the latest suggestion. =20 Example A: Call waiting tone defined per ITU-T E.180: 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm 2) 400 Hz AM modulated by 16 Hz, off for 400ms 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm 4) 400 Hz not AM modulated, off for 450 ms 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm 6) 400 Hz not AM modulated, off for 3450 ms 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm 8) 400 Hz not AM modulated, off for 450 ms 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm 10) 400 Hz not AM modulated, off for 3450 ms 11) not repeated, not continuous Assume userDefined1(17) is assigned to this tone: ToneType|Freq-1|Freq-2|Freq-3|Freq-4|FreqMode|ModePrtg|DbLevel|OnDur|Off Dur|Rep-Count =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 17 400 16 0 0 1 90 -40 500 400 0 17 400 0 0 0 2 0 -40 50 450 0 17 400 0 0 0 2 0 -40 50 3450 0 17 400 0 0 0 2 0 -40 50 450 0 17 400 0 0 0 2 0 -40 50 3450 0 pktcSigDevToneTable: ToneType|ToneRep-Count|Steady =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 17 0 false(2) ------------------------------------------------------------------------ --------------- Example B - Congestion Tone - congestion(17): This example of an embedded cadence is based on an operator variation. 1) 400Hz on for 400ms -10 dBm 2) 400Hz off for 350ms 3) 400Hz on for 225ms -4 dBm 4) 400Hz off for 525ms 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is shortest period) ToneType|Freq-1|Freq-2|Freq-3|Freq-4|FreqMode|ModePrtg|DbLevel|OnDur|Off Dur|Rep-Count =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 17 400 0 0 0 2 0 -100 400 350 0 =20 17 400 0 0 0 2 0 -40 225 525 0=20 pktcSigDevToneTable: ToneType|ToneRep-Count|Steady =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D 17 5000 false(0) =20 Please feel free to provide any comments.=20 Regards Sumanth -----Original Message----- From: Sumanth Channabasappa Sent: Tuesday, August 09, 2005 2:37 PM To: 'ipcdn@ietf.org' Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; conference call Folks, There has been a suggestion (from Phillip Freyman, Motorola) to move the 'dBm level', currently under 'PktcSigDevToneTable' to 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that require this structure. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 11 12:44:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3GAC-0005DT-3w; Thu, 11 Aug 2005 12:44:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3GA9-0005DK-Qh for ipcdn@megatron.ietf.org; Thu, 11 Aug 2005 12:44:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12801 for ; Thu, 11 Aug 2005 12:44:10 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3GiS-0001Zk-EV for ipcdn@ietf.org; Thu, 11 Aug 2005 13:19:43 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7BGht16005719 for ; Thu, 11 Aug 2005 10:43:55 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 Aug 2005 10:43:57 -0600 Message-ID: Thread-Topic: IETF63 - IPCDN wg meeting minutes Thread-Index: AcWcNEOXOYZ0b+qySouBm0pyfZ29vACXuwPQ From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.4 (/) X-Scan-Signature: db9593dc6d0eec61f891ddaf1f57b0dc Subject: [ipcdn] IETF63 - IPCDN wg meeting minutes X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1597401917==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============1597401917== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C59E93.DDF2D1A1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C59E93.DDF2D1A1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, =20 Here are the minutes from our ipcdn wg meeting last week.=20 Will wait until Monday to send those as part of the proceedings of IETF #63. =20 Jean-Fran=E7ois =20 ------------------------------------------ IETF IPCDN Meeting Notes IETF#63, IP over Cable Data Networks WG Paris, France Monday, August 1, 2005 =20 Reported and edited by Jean-Francois Mule' (jfm@cablelabs.com) =20 =20 --- WG Meeting Summary --- ------------------ About ten IETF participants attended the IPCDN WG meeting at IETF #63 in Paris on August 1st 2005. Total meeting time was one hour. =20 There were no meeting materials prepared for this meeting as the goal was to use the time as a working session to resolve known issues on the main active drafts. The meeting essentially focused on the cable device MIB v2 and the top 4 remaining issues. =20 The action items (AI) are outlined and called out in the text below. =20 =20 1/ Agenda Bashing A jabber session was also initiated and Rich Woundy, ipcdn co-chair participated remotely. The jabber chat room is: ipcdn@conference.ietf.jabber.com. The proposed agenda was accepted by the wg without modifications, it is also available at: http://www.ipcdn.org/meetings.html and as part of the IETF proceedings. =20 =20 2/ Administration We briefly discussed the re-chartering & milestone updates. Below is the newly proposed date corresponding to the "wg done" milestone. o DOCSIS Cable Device MIB version 2: Oct 2005 o RF MIB v2: Oct 2005 o MTA MIB: Oct 2005 o Signaling MIB: Oct 2005 o Management Event MIB: Dec 2005 It was commented that those dates look aggressive for some of the work items so co-authors should review the above. # Action Item (AI): # Upon review of notes by wg, if there is no comments on the above # milestones, Jean-Francois to send updated charter proposal to Bert # for approval. # Due by end of August 2005 =20 =20 3/ IPCDN DOCSIS mibs =20 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt =20 We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html =20 =20 + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces=20 Raised by Randy, the issue is, in the defval we have a 4 octet value =3D> How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored? =20 Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that. =20 Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL. =20 Proposal for wg review: a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } b) consider the following (NICE TO HAVE kind of fix) adding a sentence to say something like: bits set corresponding to non-existing interfaces is implementation specific (to warn the mgmt admin/apps that no assumptions should be made on existing implementations of this object. (Randy's suggestion) =20 =20 + ISSUE #2: docsDevNmAccessStatus -- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. =20 See issue raised by Randy and the email summary provided by Rich for the context around this issue #2. We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out. =20 In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding. =20 Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior"). =20 + ISSUE #3: docsDevEvReporting and local(0) rows Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised. in docsDevFilterLLCTable: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated. =20 Proposal: DELETE above text if nobody complains after reading the meeting notes =20 + ISSUE #4: docsDevFilterLLCTable=20 Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal: |"Table entries MUST NOT persist across reboots for cable modems." Rich also proposed to apply this requirement to: NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables. =20 It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok. =20 =20 + Other items on CD Device MIB: Randy added for consideration: wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects. Proposal: add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading. =20 A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section. =20 Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that. =20 # AI: [authors: Kevin Marez & Rich Woundy] # Authors to summarize list of agreed changed and the technical # changes in the text per wg consensus and issue new draft after AD # review comments are in.=20 # Due by early September? =20 # AD review by Bert due by August 15 =20 =20 3.2/ RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt = =20 =20 Not discussed due to time limit. # AD review by Bert due by August 15 =20 3.3/ IPCablecom/PacketCable MTA MIB draft-ietf-ipcdn-pktc-mtamib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt Not discussed due to time limit. # AD review by Bert due by August 15 =20 3.4/ Signaling MIB draft-ietf-ipcdn-pktc-signaling-08.txt = http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-08.tx= t Not discussed due to time limit. # AI: authors to close one open issue on tone table by August 20. # Ask Randy to review final proposal. =20 3.5/ Management Event MIB draft-ietf-ipcdn-pktc-eventmess-04.txt Not discussed due to time limit. # AI: chair (Jean-Francois) to ping authors to understand the status # of the document and define next steps accordingly. http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-eventmess-04.tx= t =20 =20 =20 4/ IPCDN WG next steps Beyond the action items noted above and implementation of the various decisions the wg agreed to, the following is our work plan: - Finish all DOCSIS MIBs by September 2005 - Update PacketCable/IPCablecom MTA MIB PacketCable/IPCablecom Signaling MIB and request publication by October 2005 - Advance expert + mib doctor reviews for Management Event MIB for MTAs =20 =20 >.end of the IETF#63 ipcdn meeting notes =20 =20 ------_=_NextPart_001_01C59E93.DDF2D1A1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,

=

=A0

=A0=A0=A0=A0 Here are the minutes = from our ipcdn wg meeting last week.

=A0=A0=A0=A0 Will wait until = Monday to send those as part of the

=A0=A0=A0=A0 proceedings of IETF = #63.

 

=

Jean-Fran=E7ois

 

=

------------------------------------------

IETF IPCDN Meeting =
Notes
IETF#63, =
IP over Cable Data Networks =
WG
Paris, =
France
=
Monday, =
August 1, 2005
 
Reported =
and edited by Jean-Francois Mule' =
(jfm@cablelabs.com)
 
 
<=
font
size=3D2 color=3Dseagreen face=3D"Courier New">--- WG Meeting =
Summary
--- =
------------------
About ten =
IETF participants attended the IPCDN WG meeting at IETF =
#63
in =
Paris on August 1st 2005. Total =
meeting time was one hour.
 
There =
were no meeting materials prepared for this meeting as the =
goal
was to =
use the time as a working session to resolve known issues =
on
the main =
active drafts. The meeting essentially focused on the =
cable
device =
MIB v2 and the top 4 remaining =
issues.
 
The =
action items (AI) are outlined and called out in the text =
below.
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">1/ Agenda =
Bashing
A jabber =
session was also initiated and Rich Woundy, ipcdn =
co-chair
participated remotely. The jabber chat room =
is:
ipcdn@conference.ietf.jabber.com.
The =
proposed agenda was accepted by the wg without modifications, =
it
is also =
available at: http://www.ipcdn.org/meetings=
.html and as part
of the =
IETF proceedings.
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">2/ =
Administration
We =
briefly discussed the re-chartering & milestone updates. Below =
is
the newly =
proposed date corresponding to the "wg done" =
milestone.
 o DOCSIS =
Cable Device MIB version 2: Oct =
2005
 o RF MIB =
v2:   =
            &=
nbsp;         Oct =
2005
 o MTA =
MIB:           &nb=
sp;           &nbs=
p;   Oct 2005
 o =
Signaling =
MIB:           &nb=
sp;         Oct =
2005
 o =
Management Event =
MIB:           &nb=
sp;  Dec 2005
It was =
commented that those dates look aggressive for some of the =
work
items so =
co-authors should review the =
above.
# Action Item =
(AI):
# Upon review of notes by wg, if =
there is no comments on the =
above
# milestones, Jean-Francois to =
send updated charter proposal to =
Bert
# for =
approval.
# Due by end of August =
2005
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3/ IPCDN DOCSIS =
mibs
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3.1/ DOCSIS Cable Device MIB version =
2
     =
draft-ietf-ipcdn-device-mibv2-09.txt
<=
font
size=3D2 face=3D"Courier New">     Editors: =
Kevin Marez & Rich Woundy
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv=
2-09.txt
 
We spent =
most of the meeting reviewing the 4 top remaining issues, =
see
summary =
sent by Rich and Kevin in:
http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html
 
 
+ ISSUE #1: DEFVAL for =
docsDevNmAccessInterfaces 
Raised by =
Randy, the issue is, in the defval we have a 4 octet =
value
=3D> =
How can systems with interfaces in a number not =
multiple
of 8 =
interpret the DEFVAL value. Are bits =
ignored?
 
Randy =
commented that he would be ok if there was some mention =
like
'octets =
containing bits corresponding to non-existent interfaces =
are
ignored.' =
That said, if there are implementations that would reject =
a
SET, then =
we need to say something about =
that.
 
Rich =
commented that the DEFVAL was added due to prior MIB =
doctor
comment =
and that the object is now deprecated. Bert asked =
whether
there was =
any concern deleting the =
DEFVAL.
 
Proposal =
for wg review:
 a) in =
docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h =
}
 b) =
consider the following (NICE TO HAVE kind of =
fix)
    adding a sentence to say =
something like:
    bits set corresponding to =
non-existing interfaces is
    implementation specific =
(to warn the mgmt admin/apps that =
no
    assumptions should be made =
on existing implementations of =
this
    object. (Randy's =
suggestion)
 
 
+ ISSUE #2: =
docsDevNmAccessStatus
-- Also, we should change the DESCRIPTION of =
docsDevCpeStatus
-- and docsDevCpeInetRowStatus to document how the =
agent adds rows.
 
See issue =
raised by Randy and the email summary provided by Rich =
for
the =
context around this issue #2.
We had =
some discussions around the persistency of those tables, =
the
fact that =
the CM config file drives the row creation at boot-up =
and
the fact =
that they are read-create tables so admins can also =
create
entries =
as Bert pointed out.
 
In most =
cases (except for docsDevEvControlTable), entries do =
not
persist =
across CM reboots. Even in the case of =
docsDevEvControlTable,
after =
some discussion, we believe that the entries are cleared =
and
"recreated" after the CM reads the =
config file. That is the common
understanding.
<= pre> 
Bert =
said: add a statement ("this is a deprecated table, this =
is
vendor =
specific as to what vendors do with this table, mgmt app =
cannot
expect a =
certain behavior").
 
+ ISSUE #3: docsDevEvReporting and =
local(0) rows
Comment =
close: ID authors agree with Randy's comment re: local(0) =
rows
MUST =
persist. Text will be revised.
in =
docsDevFilterLLCTable:
       &nbs=
p;     Any attempt to SET the traps(1) or syslog(2) =
bits
       &nbs=
p;     without setting the local(0) or =
localVolatile(8)
       &nbs=
p;     bits MUST result in an error being =
generated.
 
Proposal:
<=
font
size=3D2 face=3D"Courier New">   DELETE above text if nobody =
complains after reading the =
meeting
   =
notes
 
+ ISSUE #4: docsDevFilterLLCTable =

Issue is =
around text for the level of requirements on =
table
persistence. Agree with Rich's text =
proposal:
  =
|"Table entries MUST NOT persist across reboots for cable =
modems."
Rich also =
proposed to apply this requirement =
to:
  =
NmAccess, FilterLLC, FilterIp, Policy, =
Tos,
  =
Cpe and InetCpe tables.
 
It was =
suggested to use SHOULD NOT rather than MUST NOT but other =
than
that, =
proposal is ok.
 
 
+ Other items on CD Device =
MIB:
Randy =
added for consideration:
wherever =
we have this "must not persist" langage in table =
definitions,
it would =
be a plus to indicate that they may come back as entries =
may
reappear =
when CM reboots and comes up with config file. Or =
consider
adding =
this in the front paper as a consideration for users of =
the
MIBs if =
that is too many little edits in the MIB =
objects.
Proposal:
<=
font
size=3D2 face=3D"Courier New">  =
add a note on persistence model explaining the persistance of =
some
mib =
objects and the CM re-creating them upon config file =
reloading.
 
A comment =
was made that in general, we should indicate the =
persistency
model in =
each object rather than in the compliance =
section.
 
Bert also =
commented on the compliance sections: if =
different
requirements apply to CM and CMTS, suggestion =
is to make 2 different
compliances. Rich added that the new =
compliance statement is =
designed
like =
that.
 
# AI: [authors: Kevin Marez & =
Rich Woundy]
# Authors to summarize list of =
agreed changed and the =
technical
# changes in the text per wg =
consensus and issue new draft after =
AD
# review comments are in. =

# Due by early =
September?
 
# AD review by Bert due by August =
15
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3.2/ RF MIB =
v2
     =
draft-ietf-ipcdn-docs-rfmibv2-13.txt
<=
font
size=3D2 face=3D"Courier New">     Editor: Eduardo =
Cardona
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmib=
v2-13.txt
 
Not =
discussed due to time limit.
# AD review by Bert due by August =
15
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3.3/ IPCablecom/PacketCable MTA =
MIB
     =
draft-ietf-ipcdn-pktc-mtamib-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-=
06.txt
Not =
discussed due to time limit.
# AD review by Bert due by August =
15
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3.4/ Signaling =
MIB
     =
draft-ietf-ipcdn-pktc-signaling-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-sign= aling-08.txt
Not =
discussed due to time limit.
# AI: authors to close one open =
issue on tone table by August =
20.
# Ask Randy to review final =
proposal.
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">3.5/ Management Event =
MIB
     =
draft-ietf-ipcdn-pktc-eventmess-04.txt
Not = discussed due to time limit.
# AI: chair (Jean-Francois) to =
ping authors to understand the =
status
# of the document and define next =
steps accordingly.
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-even=
tmess-04.txt
 
 
 
<=
font
size=3D2 color=3D"#804040" face=3D"Courier New">4/ IPCDN WG next =
steps
Beyond =
the action items noted above and implementation of the =
various
decisions =
the wg agreed to, the following is our work =
plan:
 - Finish =
all DOCSIS MIBs by September =
2005
 - =
Update
   PacketCable/IPCablecom MTA =
MIB
   PacketCable/IPCablecom Signaling =
MIB
   and request publication by =
October 2005
 - =
Advance expert + mib doctor reviews for Management Event MIB =
for
   =
MTAs
 
 
>.end of the IETF#63 ipcdn =
meeting notes
 

 

------_=_NextPart_001_01C59E93.DDF2D1A1-- --===============1597401917== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============1597401917==-- From ipcdn-bounces@ietf.org Fri Aug 12 13:04:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cwv-0004BJ-Sn; Fri, 12 Aug 2005 13:04:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cwv-0004BE-5J for ipcdn@megatron.ietf.org; Fri, 12 Aug 2005 13:04:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05916 for ; Fri, 12 Aug 2005 13:04:01 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dVS-0007Xd-Nk for ipcdn@ietf.org; Fri, 12 Aug 2005 13:39:48 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7CH3lRg021784 for ; Fri, 12 Aug 2005 11:03: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 Date: Fri, 12 Aug 2005 11:03:50 -0600 Message-ID: Thread-Topic: Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcWfX+nGl7KzUmWITOSlDwC3FYv6+g== From: "Sumanth Channabasappa" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks, This mail is to solicit feedback on draft-04 of the "Management Event MIB for PacketCable/IPCablecom MTAs". Comments received so far include: - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. And a few editorial nits. We plan to wrap this up in the next couple of weeks, so comments would be appreciated.=20 - S=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Aug 15 18:19:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nJ9-0004ZG-AY; Mon, 15 Aug 2005 18:19:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4nJ8-0004Yl-0z for ipcdn@megatron.ietf.org; Mon, 15 Aug 2005 18:19:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08732 for ; Mon, 15 Aug 2005 18:19:47 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4nsI-0005vC-Rl for ipcdn@ietf.org; Mon, 15 Aug 2005 18:56:13 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7FMJbVJ027168 for ; Mon, 15 Aug 2005 16:19:37 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Date: Mon, 15 Aug 2005 16:20:01 -0600 Message-ID: Thread-Topic: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Thread-Index: AcWcNEOXOYZ0b+qySouBm0pyfZ29vACXuwPQANTemlA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.5 (/) X-Scan-Signature: bfc9ec46aa2f66e5aee6a3bbffb0ebe9 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0078310274==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0078310274== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A1E7.7A9560AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A1E7.7A9560AD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, As you may have read in meeting notes from last week, we spent the = IETF 63 meeting discussing the closure of open issues on the CD mib v2. The meeting notes proposed some changes to get final (yes, final) = closure on this mib. Please review the text below and please speak up if you have some = concerns (it's also welcome that you express your agreement). Thanks, Jean-Fran=E7ois [extract from ipcdn minutes] 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces=20 Raised by Randy, the issue is, in the defval we have a 4 octet value =3D> How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored? Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that. Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL. Proposal for wg review: a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } b) consider the following (NICE TO HAVE kind of fix) adding a sentence to say something like: bits set corresponding to non-existing interfaces is implementation specific (to warn the mgmt admin/apps that no assumptions should be made on existing implementations of this object. (Randy's suggestion) + ISSUE #2: docsDevNmAccessStatus -- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. See issue raised by Randy and the email summary provided by Rich for the context around this issue #2. We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out. In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding. Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior"). + ISSUE #3: docsDevEvReporting and local(0) rows Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised. in docsDevFilterLLCTable: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated. Proposal: DELETE above text if nobody complains after reading the meeting notes + ISSUE #4: docsDevFilterLLCTable=20 Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal: |"Table entries MUST NOT persist across reboots for cable modems." Rich also proposed to apply this requirement to: NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables. It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok. + Other items on CD Device MIB: Randy added for consideration: wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects. Proposal: add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading. A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section. Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that. # AI: [authors: Kevin Marez & Rich Woundy] # Authors to summarize list of agreed changed and the technical # changes in the text per wg consensus and issue new draft after AD # review comments are in.=20 # Due by early September? # AD review by Bert due by August 15 ------_=_NextPart_001_01C5A1E7.7A9560AD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ipcdn] cable dev mib draft09 - WG consensus requested on = proposed changes

Folks,

   As you may have read in meeting notes from last week, = we spent the IETF 63 meeting discussing the closure of open = issues on the CD mib v2.

   The meeting notes proposed some changes to get final = (yes, final) closure on this mib.

Please review the text below and please speak up if you have some = concerns (it's also welcome that you express your = agreement).

Thanks,

Jean-Fran=E7ois

[extract from ipcdn minutes]

3.1/ DOCSIS Cable Device MIB version 2

=A0=A0=A0=A0 draft-ietf-ipcdn-device-mibv2-09.txt

=A0=A0=A0=A0 Editors: Kevin Marez & Rich = Woundy

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv= 2-09.txt

We spent most of the meeting reviewing the 4 top remaining issues, = see

summary sent by Rich and Kevin in:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html


+ ISSUE #1: DEFVAL for docsDevNmAccessInterfaces

Raised by Randy, the issue is, in the defval we have a 4 octet = value

=3D> How can systems with interfaces in a number not = multiple

of 8 interpret the DEFVAL value. Are bits = ignored?

Randy commented that he would be ok if there was some mention = like

'octets containing bits corresponding to non-existent interfaces = are

ignored.' That said, if there are implementations that would reject = a

SET, then we need to say something about that.

Rich commented that the DEFVAL was added due to prior MIB = doctor

comment and that the object is now deprecated. Bert asked = whether

there was any concern deleting the DEFVAL.

Proposal for wg review:

 a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h = }

 b) consider the following (NICE TO HAVE kind of = fix)

=A0=A0=A0 adding a sentence to say something = like:

=A0=A0=A0 bits set corresponding to non-existing interfaces = is

=A0=A0=A0 implementation specific (to warn the mgmt admin/apps that = no

=A0=A0=A0 assumptions should be made on existing implementations of = this

=A0=A0=A0 object. (Randy's suggestion)


+ ISSUE #2: docsDevNmAccessStatus

-- Also, we should change the DESCRIPTION of = docsDevCpeStatus

-- and docsDevCpeInetRowStatus to document how the agent adds = rows.

See issue raised by Randy and the email summary provided by Rich = for

the context around this issue #2.

We had some discussions around the persistency of those tables, = the

fact that the CM config file drives the row creation at boot-up = and

the fact that they are read-create tables so admins can also = create

entries as Bert pointed out.

In most cases (except for docsDevEvControlTable), entries do = not

persist across CM reboots. Even in the case of = docsDevEvControlTable,

after some discussion, we believe that the entries are cleared = and

"recreated" after the CM reads the config file. That is = the common

understanding.

Bert said: add a statement ("this is a deprecated table, this = is

vendor specific as to what vendors do with this table, mgmt app = cannot

expect a certain behavior").

+ ISSUE #3: docsDevEvReporting and local(0) rows

Comment close: ID authors agree with Randy's comment re: local(0) = rows

MUST persist. Text will be revised.

in docsDevFilterLLCTable:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Any attempt to SET the = traps(1) or syslog(2) bits

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 without setting the local(0) = or localVolatile(8)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 bits MUST result in an error = being generated.

Proposal:

=A0=A0 DELETE above text if nobody complains after reading the = meeting

=A0=A0 notes

+ ISSUE #4: docsDevFilterLLCTable

Issue is around text for the level of requirements on = table

persistence. Agree with Rich's text = proposal:

=A0 |"Table entries MUST NOT persist across reboots for cable = modems."

Rich also proposed to apply this requirement = to:

=A0 NmAccess, FilterLLC, FilterIp, Policy, = Tos,

=A0 Cpe and InetCpe tables.

It was suggested to use SHOULD NOT rather than MUST NOT but other = than

that, proposal is ok.


+ Other items on CD Device MIB:

Randy added for consideration:

wherever we have this "must not persist" langage in table = definitions,

it would be a plus to indicate that they may come back as entries = may

reappear when CM reboots and comes up with config file. Or = consider

adding this in the front paper as a consideration for users of = the

MIBs if that is too many little edits in the MIB = objects.

Proposal:

=A0 add a note on persistence model explaining the persistance of = some

mib objects and the CM re-creating them upon config file = reloading.

A comment was made that in general, we should indicate the = persistency

model in each object rather than in the compliance = section.

Bert also commented on the compliance sections: if = different

requirements apply to CM and CMTS, suggestion is to make 2 = different

compliances. Rich added that the new compliance statement is = designed

like that.

# AI: [authors: Kevin Marez & Rich Woundy]

# Authors to summarize list of agreed changed and the = technical

# changes in the text per wg consensus and issue new draft after = AD

# review comments are in.

# Due by early September?

# AD review by Bert due by August 15

------_=_NextPart_001_01C5A1E7.7A9560AD-- --===============0078310274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0078310274==-- From ipcdn-bounces@ietf.org Mon Aug 15 20:49:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pdo-0003bi-Eb; Mon, 15 Aug 2005 20:49:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4pdn-0003bd-51 for ipcdn@megatron.ietf.org; Mon, 15 Aug 2005 20:49:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16790 for ; Mon, 15 Aug 2005 20:49:17 -0400 (EDT) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4qD1-00016q-OU for ipcdn@ietf.org; Mon, 15 Aug 2005 21:25:44 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j7G0tu7g018189 for ; Mon, 15 Aug 2005 17:55:56 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j7G0ruxd025710 for ; Mon, 15 Aug 2005 19:53:56 -0500 (CDT) Received: by ca25exm01 with Internet Mail Service (5.5.2657.72) id ; Mon, 15 Aug 2005 17:49:04 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: Sumanth Channabasappa , ipcdn@ietf.org Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Mon, 15 Aug 2005 17:49:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org My comments --- 1) I suggest "PacketCable" and "IPCablecom" be defined in the Terminology section. 2) There are a number of places in the document that makes reference to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom device"? Or more simply "MTA device". 3) The naming convention we've been using on other MIB modules in IPCDN adds "-IETF-" to the module name to distinguish it from the corresponding MIB module being developed in CableLabs. So, it this case, the MIB module name should be something like "PKTC-IETF-EVENT-MIB". 4) I think the ORGANIZATION clause should be IPCDN rather than CableLabs. 5) The DESCRIPTION clause is missing the mandatory copyright notice. 6) The OID layout doesn't conform to the recommended layout given in "Guidelines for MIB Documents", Appendix D. 7) pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION clause states "... Defined by PacketCable by default." Should this just PacketCable or PacketCable and IPCablecom. 8) pktcDevEvThrottleAdminStatus - The description makes mention of throttling events using SNMP and Syslog. What about the local log? Are events written to the local log not subject to throttling? - "A value of stopAtThreshold(3) causes event message transmission to cease at the threshold, and not resume until directed to do so." How is the device directed to resume sending event messages? 9) pktcDevEvThrottleThreshold - Same comment as above about the local log. 10) pktcDevEvThrottleInterval - The DEFVAL clause should be on a separate line for readability. 11) pktcDevEventDescrTable - Should the reference to "PacketCable" be "PacketCable/IPCablecom"? 12) pktcDevEventDescrId - "The event identifier can either be PacketCable defined or vendor-specific." Would be good to provide a reference to the PacketCable spec where the events are defined. 13) pktcDevEventDescrReporting - Should define what each one of the bit values mean. 14) pktcDevEventDescrText and pktcDevEventDescrClass - These objects are read-write. It seems odd to me that these objects would be writable. Is it really intended that these are writable objects? 15) pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" Reference [3] doesn't exist in the references section. 16) [PKT-SP-EVEMIB1.5] - There is an odd character after the "PacketCable" 17) Reference section - There are number of reference in the body of the text that do not exist in the references section. Need to make sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. 18) Security Considerations - Per the MIB Guidelines, need to explicit discuss all MIB objects, even if to only state that there are no security issues with the object. greg -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf Of Sumanth Channabasappa Sent: Friday, August 12, 2005 10:04 AM To: ipcdn@ietf.org Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Folks, This mail is to solicit feedback on draft-04 of the "Management Event MIB for PacketCable/IPCablecom MTAs". Comments received so far include: - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have MIB Objects for 2 and 4) - The Reference in the description of the MIB Object 'pktcDevEvLogCorrelationId' seems to be out of place. And a few editorial nits. We plan to wrap this up in the next couple of weeks, so comments would be appreciated. - S _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Aug 16 16:34:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E588b-0003XY-Im; Tue, 16 Aug 2005 16:34:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E588Z-0003Wk-OV for ipcdn@megatron.ietf.org; Tue, 16 Aug 2005 16:34:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11226 for ; Tue, 16 Aug 2005 16:34:17 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58hy-0006NI-Ng for ipcdn@ietf.org; Tue, 16 Aug 2005 17:10:55 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7GKY5Fn008296; Tue, 16 Aug 2005 15:34:06 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Aug 2005 22:34:05 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D32092@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Woundy, Richard" , Jean-Francois Mule Date: Tue, 16 Aug 2005 22:34:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail2.lucent.com id j7GKY5Fn008296 X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] AD review: draft-ietf-ipcdn-device-mibv2-09.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org In fact I did a review of a somewhat updated document: draft-ietf-ipcdn-device-mibv2-10-discussion.txt.=20 as per below email exchange between AD and WG chairs. Note that I did not re-review the decisions we took (and that are being verified by Jean Francois on the list) in Paris. The changes resulting from that should also go in. So here we go: - ID-Checklist - OK no nits found - References - NOK I find: !! Missing citation for Normative reference: P088 L036: [OSSI1.1] CableLabs, "Data-Over-Cable Service Interf= ace !! Missing citation for Normative reference: P088 L041: [OSSI2.0] CableLabs, "Data-Over-Cable Service Interf= ace Also: !! Missing citation for Normative reference: P090 L008: [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen,= "An You have it in the IMPORTS clause. Possible solution OLD: SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- RFC 3411 NEW: SnmpAdminString FROM SNMP-FRAMEWORK-MIB -- [RFC3411] Also: !! Missing citation for Normative reference: P089 L036: [RFC2863] McCloghrie, K. and F. Kastenholz, "The Inte= rfaces Group Possible solution OLD: InterfaceIndexOrZero FROM IF-MIB -- RFC 2863 NEW: InterfaceIndexOrZero FROM IF-MIB -- [RFC2863] Also: !! Missing citation for Normative reference: P089 L008: [RFC2021] Waldbusser, S., "Remote Network Monitoring = Management Similar solution possible Also: !! Missing citation for Normative reference: P090 L035: [RFC3617] Lear, E., "Uniform Resource Identifier (URI= ) Scheme and It is listed in he REFERENCE clause of docsDevServerConfigTftpAddress. A possible solution: OLD: REFERENCE "RFC 3617, Section 5" NEW: REFERENCE "RFC 3617, Section 5" -- [RFC3617] Another way to solve it is to put some text just before the MIB Module that states something aka: This MIB Module IMPORTS (normatively) from [RFC2580], [RFCxxxx], e= tc It also has REFERENCE Clauses that refer to [RFCxxxx]. etc That way you will also be covered. Further, you may want to update refrence to RFC3291 with reference to = RFC4001. Pls make sure to also correct the citations. - MIB Module contents - SYNTAX check: docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), localVolatile(8), stdInterface(9) } causes SMICng to bark: E: f(ipcdndevice.mi2), (1196,16) Named bits for BITS must be in contiguous positions =20 I guess you do this to not cause backward compatibility problems? Would it be good to do something aka: docsDevEvReporting OBJECT-TYPE SYNTAX BITS { local(0), traps(1), syslog(2), -- the following are extensions to the original set of -- labels. The extensions start at octet boundary. So=20 -- for bits 3-7, one MUST set them to zero on send and -- one MUST ignore them on receipt. localVolatile(8), stdInterface(9) } - More module syntax checking: W: f(ipcdndevice.mi2), (427,24) Item "docsDevNmAccessCommunity"=20 should have SIZE specified I guess theoretically we could specify a size of (0..255) because that must have been the intention all along (a community name=20 is limited to that size). But since object is deprecated I won't mind to leave as is W: f(ipcdndevice.mi2), (2428,4) Row "docsDevCpeInetEntry" has indexing that may create variables with more than 128 sub-ids I see that the InetAddress object DESCRIPTION clause instructs=20 implementors. So no problem. E: f(ipcdndevice.mi2), (2801,11) Item "diffServDataPathStatus" should be IMPORTed E: f(ipcdndevice.mi2), (2808,11) Item "diffServClfrStatus" should be IMPORTed E: f(ipcdndevice.mi2), (2815,11) Item "diffServClfrElementStatus" should be IMPORTed E: f(ipcdndevice.mi2), (2822,11) Item "diffServMultiFieldClfrAddrTy= pe" should be IMPORTed E: f(ipcdndevice.mi2), (2829,11) Item "diffServMultiFieldClfrSrcAdd= r" should beIMPORTed E: f(ipcdndevice.mi2), (2835,11) Item "diffServMultiFieldClfrDstAdd= r" should beIMPORTed E: f(ipcdndevice.mi2), (2841,11) Item "diffServAlgDropStatus" shoul= d be IMPORTed E: f(ipcdndevice.mi2), (2848,11) Item "diffServDataPathStorage" sho= uld be IMPORTed E: f(ipcdndevice.mi2), (2854,11) Item "diffServClfrStorage" should be IMPORTed E: f(ipcdndevice.mi2), (2860,11) Item "diffServClfrElementStorage" should be IMPORTed E: f(ipcdndevice.mi2), (2866,11) Item "diffServMultiFieldClfrStorag= e" should beIMPORTed E: f(ipcdndevice.mi2), (2872,11) Item "diffServActionStorage" shoul= d be IMPORTed E: f(ipcdndevice.mi2), (2879,11) Item "diffServCountActStorage" sho= uld be IMPORTed E: f(ipcdndevice.mi2), (2885,11) Item "diffServAlgDropStorage" shou= ld be IMPORTed E: f(ipcdndevice.mi2), (2891,11) Item "diffServAlgDropType" should be IMPORTed Most of those were also imported in the subscriber MIB, so it seems to= me we have dealth with this before in that other MIB module. W: f(ipcdndevice.mi2), (3140,4) OBJECT-GROUP "docsDevNmAccessExtGro= up" is not used in a MODULE-COMPLIANCE in current module I am kind of surprised to see this Group at all. It is deprecated, and it contains one object docsDevNmAccessTrapVersio= n which is also deprecated. The object nor the Group existed in RFC 2669 (which this doc obsoletes). So why are we having this deprecated object and object group at all?=20 OK, OK, I see in DESCRIPTION clause why it was added. Mmm... Not exactly right... maybe I can live with it. But possibly this would be added to some (new) deprecated MODULE-COMPL= IANCE. I guess it could even be added as optional group to the deprecated docsDevBasicCompliance, since it does not make old claims for that MODULE-COMPLIANCE invalid.... (borderline I think) So maybe accept the warning that the group is not used. Nits: - "IPSec" (I know it was incorrect in the mib security template too, I= just fixed it) should be spelled "IPsec" Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, August 10, 2005 16:29 To: Wijnen, Bert (Bert); Jean-Francois Mule Cc: Woundy, Richard Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews OK, that would be terrific, thanks! -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 10, 2005 10:07 AM To: Woundy, Richard; Wijnen, Bert (Bert); Jean-Francois Mule Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews So hwo about me reviewing=20 http://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussio= n.txt.=20 and assuming you will fix the 4 issues we discussed at the WG session last week. If I indeed do keep my promise (I have a bda track record) then by the 15th you can incorporate all comments in to the next official revision. Bert -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, August 10, 2005 15:24 To: Wijnen, Bert (Bert); Jean-Francois Mule Cc: Woundy, Richard Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews Bert, Jean-Francois, About this one review: 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt =20 # AD review by Bert due by August 15 As you know from last week's working group meeting, this draft is undergo= ing editing to address Randy's comments. There are three versions that could undergo AD review: The officially posted draft-ietf-ipcdn-device-mibv2-09 version. Randy sen= t a number of emails to the IPCDN mailing list with numerous MIB doctor c= omments against this version.=20 I generated an interim version, http://www.ipcdn.org/drafts/draft-ietf-ip= cdn-device-mibv2-10-discussion.txt. This is the draft version that was th= e basis of the review in the working group (e.g. the "four issues").=20 I would like to submit a real draft-ietf-ipcdn-device-mibv2-10 based on t= he working group meeting discussions, but I cannot finish this before Aug= ust 15 at the earliest. This would be incompatible with your review being= due on August 15. Bert, if you choose to review the posted -09 version, or the interim -10 = "discussion", then I will wait for your review comments before I post the= real -10 version. If you want to review a posted -10 version, then I need to know soon, so = that I hurry up on incorporating the working group comments (and Randy's = email comments as well). Then we probably need to push back your review d= ate a week or two. For me, the ideal choice would be for you to review the interim version h= ttp://www.ipcdn.org/drafts/draft-ietf-ipcdn-device-mibv2-10-discussion.tx= t, and then I would incorporate your AD review comments into a posted -10= version. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Tuesday, August 09, 2005 5:21 AM To: Jean-Francois Mule; bwijnen@lucent.com Cc: Woundy, Richard Subject: RE: IPCDN wg - meeting minutes and dates for 3 AD reviews looks fine to me. Bert -----Original Message----- From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] Sent: Monday, August 08, 2005 18:17 To: bwijnen@lucent.com Cc: Richard Woundy @ Comcast Subject: IPCDN wg - meeting minutes and dates for 3 AD reviews Bert, =20 I'm finishing up the meeting minutes from ipcdn and I just want to mak= e sure we have realistic dates for AD review. I snipped most of the text = from the draft minutes except for AD review lines. =20 Here's a recap, let me know what to change or if this still looks ok. = Just want to make sure we're in sync. =20 Thanks, Jean-Fran=E7ois =20 =20 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt =20 # AD review by Bert due by August 15 =20 =20 3.2/ RF MIB v2 draft-ietf-ipcdn-docs-rfmibv2-13.txt Editor: Eduardo Cardona http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-13.txt =20 Not discussed due to time limit. # AD review by Bert due by August 15 =20 3.3/ IPCablecom/PacketCable MTA MIB draft-ietf-ipcdn-pktc-mtamib-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-mtamib-06.txt Not discussed due to time limit. # AD review by Bert due by August 15 =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Aug 16 18:30:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59x5-0004mo-RL; Tue, 16 Aug 2005 18:30:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59x4-0004mj-Bs for ipcdn@megatron.ietf.org; Tue, 16 Aug 2005 18:30:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17383 for ; Tue, 16 Aug 2005 18:30:31 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AWU-0000lU-Cm for ipcdn@ietf.org; Tue, 16 Aug 2005 19:07:10 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7GMUKbG016587; Tue, 16 Aug 2005 17:30:20 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Aug 2005 00:30:19 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D320AA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'Jean-Francois Mule'" , "'enechamkin@broadcom.com'" , "'Richard Woundy @ Comcast'" Date: Wed, 17 Aug 2005 00:30:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail2.lucent.com id j7GMUKbG016587 X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org In fact I did send some review comments back in January, see my attached email below. They also need to be answered addressed, in addition to what I am writing here. I also see that various comments/questions were posted to the IPCDN WG mailing list, so those need to be answered too. Here are my further comments - $ idnits draft-ietf-ipcdn-pktc-mtamib-06.txt idnits 1.74 draft-ietf-ipcdn-pktc-mtamib-06.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 20= 05, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) So if you do a new revision, pls make sure you take care of above. If you use xml2rfc, then it is taken care of automagically by the latest version (I think) - References: !! Contains embedded space: P050 L006: [ETSI TS 101 909-8] ETSI TS 101 909-8: "Access and Termi= nals (AT); !! Contains embedded space: P050 L014: [EN 300 001] EN 300 001 V1.5.1 (1998-10):"European Stand= ard !! Contains embedded space: P050 L022: [EN 300 659-1] EN 300 659-1: "Public Switched Telephone = Network !! Contains embedded space: P005 L029: - the ETSI MTA MIB [ETSI TS 101 909-8]. The ETSI MTA M= IB !! Contains embedded space: P005 L031: defined in [EN 300 001] and [EN 300 659-1]. !! Contains embedded space: P005 L031: defined in [EN 300 001] and [EN 300 659-1]. Not sure if sapces in citations are really forbidden. But I know the RFC-Editor checking tool has trouble with it. !! Missing Reference for citation: [RFC2119] P003 L011: interpreted as described in RFC 2119 [RFC2119]. !! Missing citation for Normative reference: P047 L040: [RFC2863] McCloghrie, K., Kastenholz, F., "The Interfac= es Group !! Missing citation for Informative reference: P049 L042: [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewa= rt, !! Missing citation for Normative reference: P047 L043: [RFC3411] Harrington, D., Presuhn, R., and Wijnen, B., = "An !! Missing Reference for citation: [RFC3495] P004 L025: Configuration DHCP specifications, RFC 3495 [RFC3495] a= nd RFC 3594 !! Missing Reference for citation: [RFC3594] P004 L026: [RFC3594]. P048 L027: [RFC3594] P. Duffy, "PacketCable Security Ticket Control= Sub-Option !! Missing Reference for citation: [RFC3617] P048 L031: [RFC3617] E. Lear, "Uniform Resource Identifier (URI) Sc= heme and !! Missing Reference for citation: [RFCxxxx] P009 L016: module (DOCS-CABLE-DEVICE-MIB [RFCxxxx]). My tool may have gotten a bit confused in that it is seeing the refernc= e as a citation instead of the oterhway around. In that case there is no citation. Pls check carefully - what is the persistency behaviour of the various read-write objects? pktcMtaDevEnabled ... etc .. - For pktcMtaDevEnabled a better name woul probably be pktcMtaDevAdministrativelyEnabled And how is the NMS going to see what the real Operational status is? Is a AdminStatus and OperStatus (as in IF-MIB) not more appropriate? - For pktcMtaDevTypeIdentifier OBJECT-TYPE SYNTAX SnmpAdminString I see that it is an identifier as per DHCP option 60 (RFC2132. There it is specified as a "string of octets". How are we sure that such a "string of octets" is a valid SnmpAdminString? There are other such objects too I think - Where are the suboptions of DHCP option 43 defined? are they all valid SnmpAdminStrings as you seem to assume for several of them? A REFERENCE clause migth help too. - You have pktcMtaDevServerAddressType and then follow some 5 objects of InetAddress SYNTAX. The latter 5 objects MUST specify which object of SYNTAX InetAddressType controls their format. =20 I also wonder if in the future all these servers need to be of the same InetAddressType, and so I wonder if it is wise to use just one object to identify the format of the 5 different server addresses. - Mmm do we expect we can get away with pktcMtaDevProvConfigKey once the Security ADs take a look? - The comment lines on page 26 probably better go into some object DESCRIPTION clause, no? - pktcMtaDevRealmOrgName Is this really an SnmpAdminString of max size 64? - Page 44 OBJECT pktcMtaDevServerAddressType SYNTAX InetAddressType DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore, is not required. It may be defined in future versions of this MIB module." In order to say so in machine readable form, yopu do: OBJECT pktcMtaDevServerAddressType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION " Support for address types other than 'ipv4(1)' is not presently specified and therefore, is not required. It may be defined in future versions of this MIB module." You then also add the InetAddress objects with alength of 4. You have done this in other MIB modules, so you should know I think. and is a similar refinement for pktcMtaBasicSmtaCompliance also not needed/wanted? - Refrence RFC3291 can now be repalced by RFC4001 After all these things have been addressed (responded to or fixed) I suspect we need another serious and close review. I do not have all the details of Kerberos, DHCP and all such in my head that I could quickly ensure they are all correct. Did the WG have any DHCP or Kerberos (or Security people) do an early review for this doc? Bert > -----Original Message----- > From: Wijnen, Bert (Bert)=20 > Sent: Monday, January 24, 2005 14:22 > To: Jean-Francois Mule; enechamkin@broadcom.com > Cc: Richard Woundy @ Comcast; Randy Presuhn (E-mail) > Subject: RE: IPCDN MTA draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt >=20 >=20 > I did a very very quick browse through the MIB module, and I think > there are a number of things that still need to be fixed. > I will try to type them up later today. >=20 > Things I can report right away: >=20 > - object pktcMtaDevProvUnsolicitedKeyMaxTimeout > is a read-only object and has text in the DESCRIPTION clause about=20 > If this object is set to a zero value, the MTA MUST return > an 'inconsistentValue' in response to SNMP SET operations. > That seems conflicting, no? >=20 > - Same for pktcMtaDevProvUnsolicitedKeyNomTimeout >=20 > - I wonder if for an object like pktcMtaDevProvKerbRealmName=20 > it is wise to use SnmpAdminString while the content MUST be > uppercase ASCII ?? >=20 > - Same for pktcMtaDevRealmName >=20 > - Why is=20 > pktcMtaDevRealmAvailSlot OBJECT-TYPE > SYNTAX Unsigned32 (0..64) >=20 > While=20 > pktcMtaDevRealmIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..32) >=20 > Should they not be both limited to 64 or 32 (i.e. same value) ?? >=20 > - Same for > pktcMtaDevCmsAvailSlot OBJECT-TYPE > SYNTAX Unsigned32 (0..128) > and > pktcMtaDevCmsIndex OBJECT-TYPE > SYNTAX Unsigned32 (1..64) >=20 > - I wonder why: >=20 > pktcMtaNotificationPrefix OBJECT IDENTIFIER ::=3D { pktcMtaMib 2 } > pktcMtaNotification OBJECT IDENTIFIER ::=3D { > pktcMtaNotificationPrefix 0 } >=20 > is not specified as: >=20 > pktcMtaNotifications OBJECT IDENTIFIER ::=3D { pktcMtaMib 0 } >=20 > as suggested in the mib-review-guideleines. > It is not forbidden. I just wonder >=20 > - I wonder why > pktcMtaBasicCompliance MODULE-COMPLIANCE >=20 > STATUS current > DESCRIPTION > " The compliance statement for MTA devices that implement > PacketCable or IPCablecom requirements. >=20 > This compliance statement applies to MTA implementations > that support PacketCable 1.0 or IPCablecom requirements, > which are not IPv6-capable at the time of this > RFC publication." >=20 > MODULE -- Unconditionally mandatory groups for MTAs >=20 > MANDATORY-GROUPS { > pktcMtaGroup, > pktcMtaNotificationGroup > } >=20 > OBJECT pktcMtaDevServerAddressType > SYNTAX InetAddressType > DESCRIPTION > " Support for address types other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." > ::=3D { pktcMtaCompliances 1 } >=20 > Does not have the following: >=20 > MANDATORY-GROUPS { > pktcMtaGroup, > pktcMtaNotificationGroup > } >=20 > OBJECT pktcMtaDevServerAddressType > SYNTAX InetAddressType { ipv4(1) } > DESCRIPTION > " Support for address types other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." > OBJECT pktcMtaDevServerDhcp1 > SYNTAX InetAddress SIZE (4) > SESCRIPTION > " Support for address formats other than 'ipv4(1)' > is not presently specified and therefore, is not > required. It may be defined in future versions of > this MIB module." >=20 > .... and similar swtuff for the other InetAddress objects >=20 > ::=3D { pktcMtaCompliances 1 } >=20 > - Same for the pktcMtaBasicSmtaCompliance spec. >=20 > - At cvarious places in your MIB module you have FQDNs present. > I wonder if it would not be wise (for interoperability) to=20 > specify WHEN such FQDNs are supposed to be resolved to IP addresses. >=20 > As I said, the above is my first set of questions after a very very=20 > quick scan. Not a complete and detailed review. >=20 > Bert >=20 > > -----Original Message----- > > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > > Sent: Saturday, January 22, 2005 01:55 > > To: Bert Wijnen > > Cc: enechamkin@broadcom.com; Richard Woundy @ Comcast > > Subject: IPCDN MTA draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt > >=20 > >=20 > > Bert, > > Eugene and I worked on the MTA MIB draft update. It was=20 > > submitted tonight per our earlier email exchange to allow it=20 > > to be potentially on the next IESG telechat.=20 > >=20 > > Please let us know if you have any comments and what the=20 > > next steps are.=20 > > Thanks, > > Jean-Fran=E7ois=20 > > PS: Idnits 1.58 is clean on the ID, so is SMICng on the mib=20 > > module (just 2 warnings due to imported grouped non used=20 > > apart from the module compliance) > >=20 > > -----Original Message----- > > From: Jean-Francois Mule=20 > > Sent: Friday, January 21, 2005 5:50 PM > > To: 'internet-drafts@ietf.org' > > Cc: Richard Woundy @ Comcast; Jean-Francois Mule; Eugene=20 > > Nechamkin (enechamkin@broadcom.com) > > Subject: IETF I-D submission: IPCDN MTA draft06=20 > > draft-ietf-ipcdn-pktc-mtamib-06.txt > >=20 > >=20 > > Please find attached an update to an existing IPCDN wg I-D. > >=20 > > Title: Multimedia Terminal Adapter (MTA) Management Information Base > > for PacketCable and IPCablecom compliant device > > =20 > > Author(s) : Eugene Nechamkin, Jean-Francois Mule > > =20 > > Filename : draft-ietf-ipcdn-pktc-mtamib-06.txt > > =20 > > Working Group: IPCDN > >=20 > >=20 > > Thanks, > > Jean-Francois Mule. > > jfm@cablelabs.com > > IPCDN co-chair. > > =20 > >=20 >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 17 10:51:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PGi-00027I-6c; Wed, 17 Aug 2005 10:51:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PGf-0001ww-QU for ipcdn@megatron.ietf.org; Wed, 17 Aug 2005 10:51:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05443 for ; Wed, 17 Aug 2005 10:51:47 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5PqE-0001kX-Hi for ipcdn@ietf.org; Wed, 17 Aug 2005 11:28:35 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7HEpQhA016376; Wed, 17 Aug 2005 09:51:27 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Aug 2005 16:51:25 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D3235B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Eduardo Cardona (E-mail)" , david.raftus@terayon.com Date: Wed, 17 Aug 2005 16:51:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for details. Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up. I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should have SIZE specified I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference, -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*) I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection? So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean Either createByManagement(0) or updateByManagement(1) - Eduardo changed (after my questioning why we have a deprecated value added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*) >> I am not sure if this is appropiate or will breaks the regular applications, To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this? How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause. - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string" (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 18 14:14:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5orU-00054l-W1; Thu, 18 Aug 2005 14:11:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5orT-00054e-1F for ipcdn@megatron.ietf.org; Thu, 18 Aug 2005 14:11:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21006 for ; Thu, 18 Aug 2005 14:11:29 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pRG-0000pw-6B for ipcdn@ietf.org; Thu, 18 Aug 2005 14:48:30 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7IIBCee005184; Thu, 18 Aug 2005 12:11:12 -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] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Thu, 18 Aug 2005 12:11:46 -0600 Message-ID: Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcWh/LCyHu+WAoFKRkeCNEkj7zvsZQCI5XTA From: "Jean-Francois Mule" To: "Nakanishi Greg-MGI8179" , "Sumanth Channabasappa" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Thanks Greg. This set of comments is considered as one expert review. Jean-Fran=E7ois > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Monday, August 15, 2005 6:49 PM > To: Sumanth Channabasappa; ipcdn@ietf.org > Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess- > 04.txt >=20 > My comments --- >=20 > 1) I suggest "PacketCable" and "IPCablecom" be defined in the > Terminology section. >=20 > 2) There are a number of places in the document that makes reference > to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom > device"? Or more simply "MTA device". >=20 > 3) The naming convention we've been using on other MIB modules in > IPCDN adds "-IETF-" to the module name to distinguish it from the > corresponding MIB module being developed in CableLabs. So, it this > case, the MIB module name should be something like "PKTC-IETF-EVENT- > MIB". >=20 > 4) I think the ORGANIZATION clause should be IPCDN rather than > CableLabs. >=20 > 5) The DESCRIPTION clause is missing the mandatory copyright notice. >=20 > 6) The OID layout doesn't conform to the recommended layout given in > "Guidelines for MIB Documents", Appendix D. >=20 > 7) pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION > clause states "... Defined by PacketCable by default." Should this > just PacketCable or PacketCable and IPCablecom. >=20 > 8) pktcDevEvThrottleAdminStatus > - The description makes mention of throttling events using SNMP and > Syslog. What about the local log? Are events written to the local > log not subject to throttling? > - "A value of stopAtThreshold(3) causes event message transmission to > cease at the threshold, and not resume until directed to do so." How > is the device directed to resume sending event messages? >=20 > 9) pktcDevEvThrottleThreshold - Same comment as above about the local > log. >=20 > 10) pktcDevEvThrottleInterval - The DEFVAL clause should be on a > separate line for readability. >=20 > 11) pktcDevEventDescrTable - Should the reference to "PacketCable" be > "PacketCable/IPCablecom"? >=20 > 12) pktcDevEventDescrId - "The event identifier can either be > PacketCable defined or vendor-specific." Would be good to provide a > reference to the PacketCable spec where the events are defined. >=20 > 13) pktcDevEventDescrReporting - Should define what each one of the > bit values mean. >=20 > 14) pktcDevEventDescrText and pktcDevEventDescrClass - These objects > are read-write. It seems odd to me that these objects would be > writable. Is it really intended that these are writable objects? >=20 > 15) pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" > Reference [3] doesn't exist in the references section. >=20 > 16) [PKT-SP-EVEMIB1.5] - There is an odd character after the > "PacketCable" >=20 > 17) Reference section - There are number of reference in the body of > the text that do not exist in the references section. Need to make > sure all reference are cited. The ones I found are PKT-SP-PROV, PKT- > SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. >=20 > 18) Security Considerations - Per the MIB Guidelines, need to explicit > discuss all MIB objects, even if to only state that there are no > security issues with the object. >=20 > greg >=20 > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf > Of Sumanth Channabasappa > Sent: Friday, August 12, 2005 10:04 AM > To: ipcdn@ietf.org > Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt >=20 > Folks, >=20 > This mail is to solicit feedback on draft-04 of the "Management Event > MIB for PacketCable/IPCablecom MTAs". >=20 > Comments received so far include: >=20 > - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have > MIB Objects for 2 and 4) >=20 > - The Reference in the description of the MIB Object > 'pktcDevEvLogCorrelationId' seems to be out of place. >=20 > And a few editorial nits. We plan to wrap this up in the next couple > of weeks, so comments would be appreciated. >=20 > - S >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 18 14:46:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pPO-0004no-Mk; Thu, 18 Aug 2005 14:46:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pPN-0004nj-Iu for ipcdn@megatron.ietf.org; Thu, 18 Aug 2005 14:46:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23004 for ; Thu, 18 Aug 2005 14:46:32 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pzB-0001vA-3q for ipcdn@ietf.org; Thu, 18 Aug 2005 15:23:33 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7IIkNkJ010778; Thu, 18 Aug 2005 12:46:23 -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] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Thu, 18 Aug 2005 12:46:47 -0600 Message-ID: Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcWh/LCyHu+WAoFKRkeCNEkj7zvsZQCI5XTAAAE4WmA= From: "Sumanth Channabasappa" To: "Jean-Francois Mule" , "Nakanishi Greg-MGI8179" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Greg, Thanks for the comments. I shall incorporate them in the next few days.=20 Additional comments from the IPCDN WG will be appreciated. - Sumanth =20 > -----Original Message----- > From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com] > Sent: Monday, August 15, 2005 6:49 PM > To: Sumanth Channabasappa; ipcdn@ietf.org > Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-=20 > 04.txt >=20 > My comments --- >=20 > 1) I suggest "PacketCable" and "IPCablecom" be defined in the=20 > Terminology section. >=20 > 2) There are a number of places in the document that makes reference=20 > to "PacketCable device". Shouldn't this be "PacketCable or IPCablecom > device"? Or more simply "MTA device". >=20 > 3) The naming convention we've been using on other MIB modules in=20 > IPCDN adds "-IETF-" to the module name to distinguish it from the=20 > corresponding MIB module being developed in CableLabs. So, it this=20 > case, the MIB module name should be something like "PKTC-IETF-EVENT-=20 > MIB". >=20 > 4) I think the ORGANIZATION clause should be IPCDN rather than=20 > CableLabs. >=20 > 5) The DESCRIPTION clause is missing the mandatory copyright notice. >=20 > 6) The OID layout doesn't conform to the recommended layout given in=20 > "Guidelines for MIB Documents", Appendix D. >=20 > 7) pktcDevEnvetReportStatus - The last sentence of the DESCRIPTION=20 > clause states "... Defined by PacketCable by default." Should this=20 > just PacketCable or PacketCable and IPCablecom. >=20 > 8) pktcDevEvThrottleAdminStatus > - The description makes mention of throttling events using SNMP and=20 > Syslog. What about the local log? Are events written to the local=20 > log not subject to throttling? > - "A value of stopAtThreshold(3) causes event message transmission to=20 > cease at the threshold, and not resume until directed to do so." How=20 > is the device directed to resume sending event messages? >=20 > 9) pktcDevEvThrottleThreshold - Same comment as above about the local > log. >=20 > 10) pktcDevEvThrottleInterval - The DEFVAL clause should be on a=20 > separate line for readability. >=20 > 11) pktcDevEventDescrTable - Should the reference to "PacketCable" be=20 > "PacketCable/IPCablecom"? >=20 > 12) pktcDevEventDescrId - "The event identifier can either be=20 > PacketCable defined or vendor-specific." Would be good to provide a=20 > reference to the PacketCable spec where the events are defined. >=20 > 13) pktcDevEventDescrReporting - Should define what each one of the=20 > bit values mean. >=20 > 14) pktcDevEventDescrText and pktcDevEventDescrClass - These objects=20 > are read-write. It seems odd to me that these objects would be=20 > writable. Is it really intended that these are writable objects? >=20 > 15) pktcDevEvLogCorrelationId - "...per section 5.4.5 of [3]" > Reference [3] doesn't exist in the references section. >=20 > 16) [PKT-SP-EVEMIB1.5] - There is an odd character after the=20 > "PacketCable" >=20 > 17) Reference section - There are number of reference in the body of=20 > the text that do not exist in the references section. Need to make=20 > sure all reference are cited. The ones I found are PKT-SP-PROV, PKT-=20 > SP-MIB-MTA, PKT-SP-MGCP, RFC3435, PKT-SP-CODEC, and RFC2119. >=20 > 18) Security Considerations - Per the MIB Guidelines, need to explicit > discuss all MIB objects, even if to only state that there are no=20 > security issues with the object. >=20 > greg >=20 > -----Original Message----- > From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf > Of Sumanth Channabasappa > Sent: Friday, August 12, 2005 10:04 AM > To: ipcdn@ietf.org > Subject: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt >=20 > Folks, >=20 > This mail is to solicit feedback on draft-04 of the "Management Event=20 > MIB for PacketCable/IPCablecom MTAs". >=20 > Comments received so far include: >=20 > - There is no MIB Object defined as 'pktcDevEventThrottle 3' (we have=20 > MIB Objects for 2 and 4) >=20 > - The Reference in the description of the MIB Object=20 > 'pktcDevEvLogCorrelationId' seems to be out of place. >=20 > And a few editorial nits. We plan to wrap this up in the next couple=20 > of weeks, so comments would be appreciated. >=20 > - S >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 18 18:57:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tKX-0006t1-Rg; Thu, 18 Aug 2005 18:57:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tKV-0006so-JV for ipcdn@megatron.ietf.org; Thu, 18 Aug 2005 18:57:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10665 for ; Thu, 18 Aug 2005 18:57:44 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tuK-0001hd-JJ for ipcdn@ietf.org; Thu, 18 Aug 2005 19:34:49 -0400 Received: from h-64-105-34-173.snvacaid.dynamic.covad.net ([64.105.34.173] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5tKT-0002FV-00 for ipcdn@ietf.org; Thu, 18 Aug 2005 18:57:45 -0400 Message-ID: <007101c5a448$75b194e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Thu, 18 Aug 2005 15:59:16 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Sumanth Channabasappa" > To: "Jean-Francois Mule" ; "Nakanishi Greg-MGI8179" ; > Sent: Thursday, August 18, 2005 11:46 AM > Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt ... > 8) pktcDevEvThrottleAdminStatus > - The description makes mention of throttling events using SNMP and > Syslog. What about the local log? Are events written to the local > log not subject to throttling? ... I'd suggest that if we don't leave it up to the implementation, that it would be best for throttling to affect all destinations equally. Swamped logs are the same kind of problem, whether on the local system or a remote one. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 18 20:53:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5v8U-0005Yd-4a; Thu, 18 Aug 2005 20:53:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5v8R-0005YQ-O2 for ipcdn@megatron.ietf.org; Thu, 18 Aug 2005 20:53:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20080 for ; Thu, 18 Aug 2005 20:53:25 -0400 (EDT) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5viH-0006U8-8a for ipcdn@ietf.org; Thu, 18 Aug 2005 21:30:30 -0400 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Thu, 18 Aug 2005 17:52:59 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Thu, 18 Aug 2005 17:52:49 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BPQ41418; Thu, 18 Aug 2005 17:52:03 -0700 (PDT) Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id RAA19629; Thu, 18 Aug 2005 17:52:03 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 17:52:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Date: Thu, 18 Aug 2005 17:52:01 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B03123023@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Thread-Index: AcWkSL5Ywu1ad9A3S76MtFLa52WFRAADmRVw From: "Eugene Nechamkin" To: "Randy Presuhn" , ipcdn@ietf.org X-OriginalArrivalTime: 19 Aug 2005 00:52:04.0557 (UTC) FILETIME=[37868FD0:01C5A458] X-WSS-ID: 6F1BF2E10B04882581-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is especially important on the MTA side as the device usually has = more limited resources for local events storage. Having local events = throttled on the MTA will also allow the MSOs to fine-tune the logging system as a = whole and to reduce the risk of the events being lost. Eugene. -----Original Message----- From: ipcdn-bounces@ietf.org [mailto:ipcdn-bounces@ietf.org] On Behalf = Of Randy Presuhn Sent: Thursday, August 18, 2005 3:59 PM To: ipcdn@ietf.org Subject: Re: [ipcdn] Comments on draft-ietf-ipcdn-pktc-eventmess-04.txt Hi - > From: "Sumanth Channabasappa" > To: "Jean-Francois Mule" ; "Nakanishi=20 > Greg-MGI8179" ; > Sent: Thursday, August 18, 2005 11:46 AM > Subject: RE: [ipcdn] Comments on=20 > draft-ietf-ipcdn-pktc-eventmess-04.txt ... > 8) pktcDevEvThrottleAdminStatus > - The description makes mention of throttling events using SNMP and=20 > Syslog. What about the local log? Are events written to the local=20 > log not subject to throttling? ... I'd suggest that if we don't leave it up to the implementation, that it = would be best for throttling to affect all destinations equally. Swamped logs = are the same kind of problem, whether on the local system or a remote one. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Aug 23 15:59:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ewB-000637-9O; Tue, 23 Aug 2005 15:59:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ew8-00062Y-3n for ipcdn@megatron.ietf.org; Tue, 23 Aug 2005 15:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28571 for ; Tue, 23 Aug 2005 15:59:53 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ewH-0000LB-8g for ipcdn@ietf.org; Tue, 23 Aug 2005 16:00:05 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7NJxUEp004283; Tue, 23 Aug 2005 13:59:30 -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: Tue, 23 Aug 2005 13:59:51 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FF70685@srvxchg.cablelabs.com> Thread-Topic: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKA From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Bert Thanks for the comments. I am posting comments to your pending items by tonight Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 12:05:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xkh-0002Hc-Ue; Wed, 24 Aug 2005 12:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7xke-0002Gx-1x for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 12:05:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00659 for ; Wed, 24 Aug 2005 12:05:17 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7xkz-0005aZ-20 for ipcdn@ietf.org; Wed, 24 Aug 2005 12:05:41 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7OG53lE006138; Wed, 24 Aug 2005 10:05:04 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus Date: Wed, 24 Aug 2005 10:05:38 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FF707C9@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpchannelStatus Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IA= From: "Eduardo Cardona" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Bert,=20 Here is my first of a set of postings answering your questions,=20 I am keeping them in groups to not be very extensive and keep them organized way=20 As I am adding the proposed changes to the draft as we speak=20 If they are valid for MIB Doctors and deviations are "negligible" of the IPCN technical requirements I guess with your consent we can proceed to have a draft before IESG if that is your preference. Topic: docsIfUpChannelStatus:=20 Below is an intend to clear the definitions and present then in a ordered manner. RFC 2670 does not have RowStatus =20 Upstream physical interfaces are hardware Upstream receivers (CMTS) components associated to the implementation with is own organization and constraints to RF MAC interfaces - MAC domains - reflected in ifStack, etc. The Created rows -Temporary Interfaces (createAndWait, that cannot be set to active) are like buffers to do modifications of parameters for a physical interface offline and then update physical interface. because implementations might reject some parameters combinations the clone mechanism this mechanism provides commanded way ( update object ) rather than SNMP traditional asynchronous SETs 1) verify all parameters can be supported 2) reject the update if parameters are inconsistent each other and/or to the hardware capabilities 3) do an immediate update of the values=20 avoiding asynchronous SNMP Sets - steps 1) 2) - directly over a physical interface minimize service interruption due operation mistakes Now to reflect this ( simple or obscure artifact depending of judgments) - I agree is quite late to propose other mechanisms ( implementations already in place with this IPCDN group design guidelines back in DOCSIS 2.0 specification work) such a scalar group to represent that US interface playground buffer=20 Also the problem with the compliance statements you mention is that the object is used for two types of entries rather than per device compliance like CM or CMTS=20 In CMTS Physical interfaces - always active -=20 Temporary interfaces - fictitious interfaces - not settable to active In CM clone mechanism -> do not care, not applicable Note that docsIfUpChannelStatus is in the docsIfBasicGroupV2=20 With the read-only requirement for CM Would that be clear NOT to require instantiation of the RowStatus cloneFom and Update objects in the CM ? Now defines that this object is only defined for Temporary entries : docsIfUpChannelStatus, docsIfUpChannelCloneFrom and docsIfUpChannelUpdate out of docsIfBasicGroupV2 add those objects to docsIfCmtsGroupv2 ->=20 As CM does no longer require those objects the below compliances are not needed:=20 OBJECT docsIfUpChannelCloneFrom MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems, read-only in Cable Modems." OBJECT docsIfUpChannelUpdate MIN-ACCESS read-only DESCRIPTION "Read-create in Cable Modem Termination Systems, read-only in Cable Modems." The updated object compliance in docsIfBacisComplianceV2 will read:=20 OBJECT docsIfUpChannelStatus SYNTAX RowStatus {notInService(2), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} DESCRIPTION "'read-create' in Cable Modem Termination Systems and=20 only for upstream temporary interface entries. Upstream=20 physical interfaces do not instantiate this object in=20 their conceptual row entries. Temporary entries support values 'notInService' 'notReady', 'createAndWait' and 'destroy'." Note --> Reviewing RFC2579 I think both notReady, notInService applied,=20 notReady after createAndGo,=20 notInService after CloneFrom is set It does not impact current implemntations based on draft 05. Other updates: Introduced in Entry Object the definition and scope of physical/temporary interfaces docsIfUpstreamChannelEntry OBJECT-TYPE SYNTAX DocsIfUpstreamChannelEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of attributes for a single upstream channel. For DOCSIS 2.0 CMTSs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstreamChannel (205). For DOCSIS 1.x CM/CMTSs and DOCSIS 2.0 CMs, an entry in this table exists for each ifEntry with an ifType of docsCableUpstream (129). =3D=3D>Added For DOCSIS 2.0 CMTSs two classes of interfaces can be=20 defined for this table:=20 o Upstream Physical Interfaces: The traditional DOCSIS 1.x CMTS upstream interface ifType 129 and the DOCSIS 2.0=20 ifType that are functional. In other words, interfaces that represents Upstream receivers within an RF MAC interface.=20 Entries of physical interfaces are exposed to the=20 management interface with their corresponding ifStack=20 hierarchy and not administratively created=20 o Upstream Temporary Interfaces: A fictitious interface=20 created with the purpose of manipulating the parameters=20 of a physical interfaces parameters offline and validate=20 values consistency prior to update a target physical=20 Interface. This mechanism helps to minimize service disruption originated in situations where a group of interface=20 parameters values are inconsistent each other in SET operations. Instead, a temporary buffer (temporary=20 interface) is provided to allow the CMTS to validate the parameters offline." <<=3D=3D Added INDEX { ifIndex } ::=3D { docsIfUpstreamChannelTable 1 } =20 Updates=20 docsIfUpChannelCloneFrom OBJECT-TYPE SYNTAX InterfaceIndexOrZero MAX-ACCESS read-create STATUS current DESCRIPTION "Intended for use when a temporary upstream interface entry is created to adjust the parameters values of a upstream physical interface channel. Refer to the descriptions of docsIfUpChannelStatus and docsIfUpChannelUpdate for details of this procedure. This object contains the ifIndex value of the physical upstream interface whose parameters are to be adjusted. Upon setting this object to the ifIndex value of a physical interface, this entry objects values ( listed below) are=20 updated with values from the ifIndex referenced by this=20 object: =20 docsIfUpChannelFrequency, docsIfUpChannelWidth, docsIfUpChannelModulationProfile, docsIfUpChannelSlotSize, docsIfUpChannelRangingBackoffStart, docsIfUpChannelRangingBackoffEnd, docsIfUpChannelTxBackoffStart, docsIfUpChannelTxBackoffEnd, docsIfUpChannelScdmaActiveCodes, docsIfUpChannelScdmaCodesPerSlot, docsIfUpChannelScdmaFrameSize, docsIfUpChannelScdmaHoppingSeed, docsIfUpChannelType, and docsIfUpChannelPreEqEnable=20 =20 Setting this object to a non-existent or temporary upstream returns an error 'wrongValue'. This object MUST contain a value of zero for physical upstream entries." ::=3D { docsIfUpstreamChannelEntry 16 } docsIfUpChannelUpdate OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-create STATUS current DESCRIPTION " Used to perform the transfer of adjusted parameters from the temporary upstream row to the physical upstream row indicated by the docsIfUpChannelCloneFrom object. The transfer is initiated through an SNMP SET to 'true' of this object. if the adjusted parameter values are not=20 compatible with each other the managed system returns=20 'inconsistentValue' error . =20 Reading this object always return 'false'." ::=3D { docsIfUpstreamChannelEntry 17 } docsIfUpChannelStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "This object is only used for the creation of a temporary upstream row with the purpose of adjusting channel=20 parameters of a physical upstream channel entry. The following restrictions apply to this object: 1. Physical Interfaces do not instantiate the RowStatus=20 Type object.=20 2. Temporary Interface entries are created only by SET to=20 RowStatus createandWait(5). 3. ifAdminStatus from the Interface MIB RFC 2863 is used to take an physical Upstream Channel offline consistent=20 with DOCSIS 1.x operation indicated in RFC 2670. 5. The only possible status change for a temporary interface=20 entry is to destroy(6). 6. Temporary created rows MUST never be given the status active(1). 7. Temporary entries MUST NOT persist at reinitialization of the managed system. Below is a mandatory procedure for adjusting an upstream=20 physical interface : 1. Create a temporary interface entry through an SNMP SET=20 using createAndWait(5). At this point the RowStatus report 'notReady' as status value.=20 Manager entity uses an ifIndex value outside the operational range of the managed system. 2. Set the docsIfUpChannelCloneFrom object to the ifIndex value of the physical row whose parameters require adjustment. Now this object reports 'notInService' 3. Adjust the parameter values using the new temporary row. Ensure all parameters contain desired values before proceeding to step 4. 4. Update the physical row by setting the object docsIfUpChannelUpdate to true(1). 5. Delete the temporary row through an SNMP SET using destroy(6). If a Manager entity does not delete the=20 temporary entry after the physical interface update=20 operation the entry is aged out by the managed system as indicated in RFC 2579. This specification does not define a required aging time period, RFC 2579 suggest and interval of 5 minutes, therefore is advice that manager entities perform the parameters update defined by this=20 table within that period of time." ::=3D { docsIfUpstreamChannelEntry 18 } =20 =20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 12:39:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yI2-0000hD-KY; Wed, 24 Aug 2005 12:39:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yI0-0000h7-K7 for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 12:39:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03319 for ; Wed, 24 Aug 2005 12:39:46 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7yIL-0006wy-Ua for ipcdn@ietf.org; Wed, 24 Aug 2005 12:40:10 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7OGdaiB013478; Wed, 24 Aug 2005 10:39:36 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmStatusCode Date: Wed, 24 Aug 2005 10:40:05 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FF707E1@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmStatusCode Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUA== From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Let me restate the problem=20 Back in DOCSIS 1.0 the RFI specification had a Error code section=20 You can find it in : http://www.scte.org/documents/pdf/ANSISCTE2212002DSS0205.pdf appendix I You can see messages such T00.1 and R101.0 as examples=20 Just as an illustration example:=20 That section was merged in DOCSIS 1.1 to indicate the way to generate log, syslog and notification information=20 RFC 2669 docsDevEventId is a mapping of the text to a number R101.0 would be for example:=20 Two digits:=20 R -> ascii 0x52 -> 82 decimal=20 Four digits: To map the two or three octets (decimal numbers)=20 101 -> 0101 Two digits for the final decimal value .0 -> 00 Event ID =3D 82010100 -> This is to indicate that we will probably not extend the size beyond this construct Back to the issue=20 What can be done in the spec is=20 IPCDN list please indicate if this clarifications are ok -> (SIZE( 0 | 5 | 6 )) -> Add a example -> zero-length OCTET String meaning=20 docsIfCmStatusCode OBJECT-TYPE SYNTAX OCTET STRING (SIZE( 0 | 5 | 6 )) MAX-ACCESS read-only STATUS current DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal.=20 An example of a returned value could be 'T101.0' The zero-length OCTET STRING indicates no status code yet registered." REFERENCE "Data-Over-Cable Service Interface Specifications: Operations Support System Interface Specification SP-OSSIv2.0-I07-041210, Annex D." ::=3D { docsIfCmStatusEntry 2 } Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 13:16:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yrP-0005MW-4G; Wed, 24 Aug 2005 13:16:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yrM-0005H3-Ni for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 13:16:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06318 for ; Wed, 24 Aug 2005 13:16:18 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7yri-00008p-Kt for ipcdn@ietf.org; Wed, 24 Aug 2005 13:16:43 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7OHG9q8020804; Wed, 24 Aug 2005 11:16:09 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfObsoleteGroup Date: Wed, 24 Aug 2005 11:16:30 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE446@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfObsoleteGroup Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAzrIEA== From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org I believe I missed that Sorry about that... Added to docsIfBasicComplianceV2 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." Thanks Eduardo =20 =20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 13:53:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zRW-0001va-2I; Wed, 24 Aug 2005 13:53:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zRT-0001sR-3y for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 13:53:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08387 for ; Wed, 24 Aug 2005 13:53:38 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zRn-0001PP-Dp for ipcdn@ietf.org; Wed, 24 Aug 2005 13:54:02 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7OHrFcL028502; Wed, 24 Aug 2005 11:53:26 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsCmStatusValue Date: Wed, 24 Aug 2005 11:53:41 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE458@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsCmStatusValue Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAzrIEAACFojA From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org I used the "reserved" form in the description since was added in a RFIv2 MIB draft. A reader won't find operational(8) in RFC 2670, as a reference to say why is deprecated=20 And not sure if the label for=20 Current IETF draft reads:=20 Value 8 is considered reserved and should not be defined=20 in future revisions of this MIB module to avoid conflict with documented implementations that support value 8. What about the description (extended to indicate how 8 was used):=20 operational(8) Value 8 is considered reserved and should not be defined=20 in future revisions of this MIB module to avoid conflict with documented implementations that support value 8 to=20 indicate operational state after completing the BPI=20 initialization process. In terms of the SYNTAX: Would be ok to say=20 INTEGER { ... operational(8) -- value 8 should not be used ... } or do you see more clear=20 INTEGER { ... operational(8) -- deprecated=20 ... }=20 As I said there is no formal RFI MIB that previously defined operational(8) in order to indicate formal deprecation, as the word would say =20 I am fine with both forms or any suggested alternative Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 13:56:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zUK-0002eW-9k; Wed, 24 Aug 2005 13:56:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zUH-0002dA-DJ for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 13:56:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08584 for ; Wed, 24 Aug 2005 13:56:32 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zUd-0001WG-KM for ipcdn@ietf.org; Wed, 24 Aug 2005 13:56:56 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7OHuMQ0029005; Wed, 24 Aug 2005 11:56:23 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpChannelScdmaActiveCodes Date: Wed, 24 Aug 2005 11:56:39 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE459@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfUpChannelScdmaActiveCodes Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAzrIEAACk4cw From: "Eduardo Cardona" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Added docsIfUpChannelScdmaActiveCodes OBJECT-TYPE SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88 |90..96|98..100|102|104..106|108|110..112 |114..126|128) Thanks Eduardo -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 19:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E84Ik-00005j-5N; Wed, 24 Aug 2005 19:04:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E84Ih-0008WT-5k for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 19:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00615 for ; Wed, 24 Aug 2005 19:04:52 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E84J4-0004M8-7W for ipcdn@ietf.org; Wed, 24 Aug 2005 19:05:20 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7ON4Zd8022306; Wed, 24 Aug 2005 17:04:36 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsQosProfilePermissions Date: Wed, 24 Aug 2005 17:04:35 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE4F9@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Topic: docsIfCmtsQosProfilePermissions Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAzrIEAAB9BiQ From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 7118f330e2af0a096ba071c5e99ca10e Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Will update : =20 Either createByManagement(0) or updateByManagement(1) MUST be set when writing to this object. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Wed Aug 24 20:58:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8655-0003tG-DL; Wed, 24 Aug 2005 20:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8654-0003tB-7p for ipcdn@megatron.ietf.org; Wed, 24 Aug 2005 20:58:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07197 for ; Wed, 24 Aug 2005 20:58:56 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E865S-00081j-Eh for ipcdn@ietf.org; Wed, 24 Aug 2005 20:59:24 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7P0wjPx005032; Wed, 24 Aug 2005 18:58:45 -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: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: References and NITS/Editorial Date: Wed, 24 Aug 2005 18:58:45 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE513@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: References and NITS/Editorial Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAzrIEAACFojAAACXq0A= From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 3.5 (+++) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org The nits v1.74 and v1.77 seem to produce the same error based on IP normative text=20 I believe that can be covered after getting the IETF last call and IESG revision ( I will check the detail log attached below and compare the little odds things that might be I add manually the boilerplate of RFC 3978 since I believe XML2RFC is still handling the requirements from RFc 3667 See more details inline:=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. Done Added: [IANA] "Protocol Numbers and Assignment Services", IANA, http://www.iana.org/assignments/ianaiftype-mib. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" docsIfUpChannelPreEqEnable=20 DESCRIPTION "At the CMTS, used to enable or disable pre-equalization on the upstream channel represented by this table instance. At the CM, this object is read-only and reflects the status of pre-equalization as represented in the RNG-RSP. Pre-equalization is considered enabled at the CM if a RNG-RSP with pre-equalization data has been received at least once since the last mac reinitialization." 6) EDITORIAL: "ie" -> "i.e.", or better "that is" done 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. head-end 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 -> changed to cable modem, and cablemodem termination system (lowercase) for cases where indicates quantity (cable modems, "each cablemodem", "individual cablemodem" etc. or when no referred as a device requirement, e.g. in CMTS requirements that poin to CM properties like in docsIfCmtsCmStatusTable "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) -> zero-length OCTET STRING I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: idnits 1.74 --> here is=20 I ran idnits-v1.77 ( I will check the verbose mode to see where the inconsistencies are)=20 bash-2.05b$ ./idnits-v1.77 --verbose draft-ietf-ipcdn-docs-rfmibv2-14_version2. txt idnits 1.77 (21 Aug 2005) draft-ietf-ipcdn-docs-rfmibv2-14_version2.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? (Expected a match on the following text: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79." ... but found this: "By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79") ...................................................................^ Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 25 00:01:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E88vl-0004Ud-DF; Thu, 25 Aug 2005 00:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E88vj-0004UV-Bg for ipcdn@megatron.ietf.org; Thu, 25 Aug 2005 00:01:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13258 for ; Thu, 25 Aug 2005 00:01:28 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E88wA-0004Dr-0k for ipcdn@ietf.org; Thu, 25 Aug 2005 00:01:59 -0400 Received: from h-68-165-5-34.snvacaid.dynamic.covad.net ([68.165.5.34] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E88vY-0004VD-00 for ipcdn@ietf.org; Thu, 25 Aug 2005 00:01:20 -0400 Message-ID: <00f101c5a929$e22a3f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <5259D0D7419C6149B347837A2E64F46FFEE513@srvxchg.cablelabs.com> Subject: Re: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: References andNITS/Editorial Date: Wed, 24 Aug 2005 21:02:58 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Eduardo Cardona" > To: "Wijnen, Bert (Bert)" ; > Cc: "Ipcdn (E-mail)" > Sent: Wednesday, August 24, 2005 5:58 PM > Subject: RE: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: References andNITS/Editorial ... > I add manually the boilerplate of RFC 3978 since I believe XML2RFC is > still handling the requirements from RFc 3667 ... With current xml2rfc, just use ; Thu, 25 Aug 2005 00:10:21 -0400 (EDT) Received: from pop-gadwall.atl.sa.earthlink.net ([207.69.195.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E894l-0004SQ-Ll for ipcdn@ietf.org; Thu, 25 Aug 2005 00:10:51 -0400 Received: from h-68-165-5-34.snvacaid.dynamic.covad.net ([68.165.5.34] helo=oemcomputer) by pop-gadwall.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E894H-0006KO-00 for ipcdn@ietf.org; Thu, 25 Aug 2005 00:10:22 -0400 Message-ID: <00f601c5a92b$281b68e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <5259D0D7419C6149B347837A2E64F46FFEE4F9@srvxchg.cablelabs.com> Subject: Re: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsQosProfilePermissions Date: Wed, 24 Aug 2005 21:12:06 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - > From: "Eduardo Cardona" > To: "Wijnen, Bert (Bert)" ; > Cc: "Ipcdn (E-mail)" > Sent: Wednesday, August 24, 2005 4:04 PM > Subject: RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsQosProfilePermissions > > Will update : > > Either createByManagement(0) or updateByManagement(1) > MUST be set when writing to this object. ... Just checking: is the intent of this to prohibit setting both bits? If it is permissible to set both bits, then this language isn't quite right, an it might be better to say: Attempts to set both createByManagement(0) and updateByManagement(1) to zero MUST be rejected. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 25 12:33:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Kf7-0000qi-Om; Thu, 25 Aug 2005 12:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Kf6-0000oe-Cc for ipcdn@megatron.ietf.org; Thu, 25 Aug 2005 12:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28345 for ; Thu, 25 Aug 2005 12:33:05 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Kfe-0000XX-SZ for ipcdn@ietf.org; Thu, 25 Aug 2005 12:33:43 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7PGWvx4000008; Thu, 25 Aug 2005 10:32: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: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfilePermissions Date: Thu, 25 Aug 2005 10:32:57 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE561@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfilePermissions Thread-Index: AcWpKzZ3D+oRhshfTvqPnVKTyAYTiAAVnsyg From: "Eduardo Cardona" To: "Randy Presuhn" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Randy,=20 Just checking: is the intent of this to prohibit setting both bits? Yes it is, as I interpret the text=20 I believe is correct based on the meaning of either that refers to select one of two options (http://en.wikipedia.org/wiki/Either) Perhaps just following the link examples, adding a 'comma' would make that more precise rather that changing the whole text? Either createByManagement(0), or updateByManagement(1) MUST be set when writing to this object. I will be fine with "Either one option, or the other" -:) - Other technical questions might come up of this XOR exclusive issues like : If 'createByManagement' means that you can create entries but not delete (*update), that could lead to undesired cases of exhausting the possible entries and potential denial of service (?) =20 In my impression that object should've been deprecated long time ago as way to provide access to another table such docsIfQosProfileTable, but we didn't. Keep in mind that for DOCSIS 1.0, RFC 2670 (more, DOCSIS 1.0 ) didn't contemplate SNMPv3 as DOCSIS 1.1 and 2.0 does, so those kind of access control issues are now handled under the SNMPv3 framework, plus DOCSIS 1.1 and 2.0 does not use docIfQosProfileTable more than for backward compatibility with DOCSIS 1.0 CMs. RFIv2 deals with extensions to support DOCSIS 2.0 and not touching the DOCSIS 1.0 type of behaviors as possible. We understand also the need to keep clear requirements as RFC revision come and correct the previous non-clear definitions. Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Wednesday, August 24, 2005 10:12 PM To: Ipcdn (E-mail) Subject: Re: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfile Permissions=20 Hi - > From: "Eduardo Cardona" > To: "Wijnen, Bert (Bert)" ; > Cc: "Ipcdn (E-mail)" > Sent: Wednesday, August 24, 2005 4:04 PM > Subject: RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsQosProfilePermissions > > Will update : > > Either createByManagement(0) or updateByManagement(1) > MUST be set when writing to this object. ... Just checking: is the intent of this to prohibit setting both bits? If it is permissible to set both bits, then this language isn't quite right, an it might be better to say: Attempts to set both createByManagement(0) and updateByManagement(1) to zero MUST be rejected. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 25 13:52:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Ltl-0003IE-ED; Thu, 25 Aug 2005 13:52:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Ltk-0003HX-8o for ipcdn@megatron.ietf.org; Thu, 25 Aug 2005 13:52:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03896 for ; Thu, 25 Aug 2005 13:52:18 -0400 (EDT) Received: from pop-canoe.atl.sa.earthlink.net ([207.69.195.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8LuG-0003RQ-TO for ipcdn@ietf.org; Thu, 25 Aug 2005 13:52:55 -0400 Received: from h-64-105-136-149.snvacaid.dynamic.covad.net ([64.105.136.149] helo=oemcomputer) by pop-canoe.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E8Ltb-0003AO-00 for ipcdn@ietf.org; Thu, 25 Aug 2005 13:52:11 -0400 Message-ID: <002501c5a99d$f5b274c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Ipcdn \(E-mail\)" References: <5259D0D7419C6149B347837A2E64F46FFEE561@srvxchg.cablelabs.com> Subject: Re: [ipcdn] RE: ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfilePermissions Date: Thu, 25 Aug 2005 10:53:53 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi - Ok, if XOR really is what is intended, there are two "legal" ways to punctuate it: either Either createByManagement(0) or updateByManagement(1) MUST be set when writing to this object. or Either createByManagement(0), or updateByManagement(1), MUST be set when writing to this object. That is, either no commas or two commas. A single comma won't work in this case. I suggest changing "be set" to "be set to one", just to be painfully clear. But the XOR itself sounds like an error, though that's largely a moot point if the object is deprecated. Randy ----- Original Message ----- From: "Eduardo Cardona" To: "Randy Presuhn" ; "Ipcdn (E-mail)" Sent: Thursday, August 25, 2005 9:32 AM Subject: RE: [ipcdn] RE: ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfilePermissions Randy, Just checking: is the intent of this to prohibit setting both bits? Yes it is, as I interpret the text I believe is correct based on the meaning of either that refers to select one of two options (http://en.wikipedia.org/wiki/Either) Perhaps just following the link examples, adding a 'comma' would make that more precise rather that changing the whole text? Either createByManagement(0), or updateByManagement(1) MUST be set when writing to this object. I will be fine with "Either one option, or the other" -:) - Other technical questions might come up of this XOR exclusive issues like : If 'createByManagement' means that you can create entries but not delete (*update), that could lead to undesired cases of exhausting the possible entries and potential denial of service (?) In my impression that object should've been deprecated long time ago as way to provide access to another table such docsIfQosProfileTable, but we didn't. Keep in mind that for DOCSIS 1.0, RFC 2670 (more, DOCSIS 1.0 ) didn't contemplate SNMPv3 as DOCSIS 1.1 and 2.0 does, so those kind of access control issues are now handled under the SNMPv3 framework, plus DOCSIS 1.1 and 2.0 does not use docIfQosProfileTable more than for backward compatibility with DOCSIS 1.0 CMs. RFIv2 deals with extensions to support DOCSIS 2.0 and not touching the DOCSIS 1.0 type of behaviors as possible. We understand also the need to keep clear requirements as RFC revision come and correct the previous non-clear definitions. Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, August 24, 2005 10:12 PM To: Ipcdn (E-mail) Subject: Re: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfile Permissions Hi - > From: "Eduardo Cardona" > To: "Wijnen, Bert (Bert)" ; > Cc: "Ipcdn (E-mail)" > Sent: Wednesday, August 24, 2005 4:04 PM > Subject: RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsQosProfilePermissions > > Will update : > > Either createByManagement(0) or updateByManagement(1) > MUST be set when writing to this object. ... Just checking: is the intent of this to prohibit setting both bits? If it is permissible to set both bits, then this language isn't quite right, an it might be better to say: Attempts to set both createByManagement(0) and updateByManagement(1) to zero MUST be rejected. Randy _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Thu Aug 25 15:00:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MxE-0000CE-0q; Thu, 25 Aug 2005 15:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MxC-0000C9-O0 for ipcdn@megatron.ietf.org; Thu, 25 Aug 2005 14:59:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07740 for ; Thu, 25 Aug 2005 14:59:57 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Mxl-0005Rn-Dr for ipcdn@ietf.org; Thu, 25 Aug 2005 15:00:34 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7PIxlDN026356; Thu, 25 Aug 2005 12:59:47 -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:ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfilePermissions Date: Thu, 25 Aug 2005 12:59:47 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE592@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE:ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfilePermissions Thread-Index: AcWpnrQVPQsxin7pR/mF20knY6MKqwABqe0g From: "Eduardo Cardona" To: "Randy Presuhn" , "Ipcdn (E-mail)" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Ok =20 Either createByManagement(0), or updateByManagement(1), MUST be set when writing to this object. Agree, moot point, although the deprecation would come up in a further RFC update after this work is completed Thanks Eduardo=20 -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Thursday, August 25, 2005 11:54 AM To: Ipcdn (E-mail) Subject: Re: [ipcdn] RE:ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosPr ofilePermissions Hi - Ok, if XOR really is what is intended, there are two "legal" ways to punctuate it: either Either createByManagement(0) or updateByManagement(1) MUST be set when writing to this object. or Either createByManagement(0), or updateByManagement(1), MUST be set when writing to this object. That is, either no commas or two commas. A single comma won't work in this case. I suggest changing "be set" to "be set to one", just to be painfully clear. But the XOR itself sounds like an error, though that's largely a moot point if the object is deprecated. Randy ----- Original Message -----=20 From: "Eduardo Cardona" To: "Randy Presuhn" ; "Ipcdn (E-mail)" Sent: Thursday, August 25, 2005 9:32 AM Subject: RE: [ipcdn] RE: ADre-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfi lePermissions Randy, Just checking: is the intent of this to prohibit setting both bits? Yes it is, as I interpret the text I believe is correct based on the meaning of either that refers to select one of two options (http://en.wikipedia.org/wiki/Either) Perhaps just following the link examples, adding a 'comma' would make that more precise rather that changing the whole text? Either createByManagement(0), or updateByManagement(1) MUST be set when writing to this object. I will be fine with "Either one option, or the other" -:) - Other technical questions might come up of this XOR exclusive issues like : If 'createByManagement' means that you can create entries but not delete (*update), that could lead to undesired cases of exhausting the possible entries and potential denial of service (?) In my impression that object should've been deprecated long time ago as way to provide access to another table such docsIfQosProfileTable, but we didn't. Keep in mind that for DOCSIS 1.0, RFC 2670 (more, DOCSIS 1.0 ) didn't contemplate SNMPv3 as DOCSIS 1.1 and 2.0 does, so those kind of access control issues are now handled under the SNMPv3 framework, plus DOCSIS 1.1 and 2.0 does not use docIfQosProfileTable more than for backward compatibility with DOCSIS 1.0 CMs. RFIv2 deals with extensions to support DOCSIS 2.0 and not touching the DOCSIS 1.0 type of behaviors as possible. We understand also the need to keep clear requirements as RFC revision come and correct the previous non-clear definitions. Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Wednesday, August 24, 2005 10:12 PM To: Ipcdn (E-mail) Subject: Re: [ipcdn] RE: AD re-review:draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic:docsIfCmtsQosProfile Permissions Hi - > From: "Eduardo Cardona" > To: "Wijnen, Bert (Bert)" ; > Cc: "Ipcdn (E-mail)" > Sent: Wednesday, August 24, 2005 4:04 PM > Subject: RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsQosProfilePermissions > > Will update : > > Either createByManagement(0) or updateByManagement(1) > MUST be set when writing to this object. ... Just checking: is the intent of this to prohibit setting both bits? If it is permissible to set both bits, then this language isn't quite right, an it might be better to say: Attempts to set both createByManagement(0) and updateByManagement(1) to zero MUST be rejected. 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 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Aug 26 09:09:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dxT-00017n-L5; Fri, 26 Aug 2005 09:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8dxP-00015s-R5 for ipcdn@megatron.ietf.org; Fri, 26 Aug 2005 09:09:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18161 for ; Fri, 26 Aug 2005 09:09:18 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8dy7-0005tF-7H for ipcdn@ietf.org; Fri, 26 Aug 2005 09:10:05 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7QD91kN010070 for ; Fri, 26 Aug 2005 07:09:02 -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, 26 Aug 2005 07:09:01 -0600 Message-ID: Thread-Topic: IPCDN wg charter update Thread-Index: AcWcNEOXOYZ0b+qySouBm0pyfZ29vACXuwPQAur8zeA= From: "Jean-Francois Mule" To: X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] IPCDN wg charter update X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Folks,=20 Per the minutes of IETF#63, I have completed my action item on the wg re-charter. Pending Bert, approval the updated charter should appear online soon. > 2/ Administration > We briefly discussed the re-chartering & milestone updates. Below is > the newly proposed date corresponding to the "wg done" milestone. > o DOCSIS Cable Device MIB version 2: Oct 2005 > o RF MIB v2: Oct 2005 > o MTA MIB: Oct 2005 > o Signaling MIB: Oct 2005 > o Management Event MIB: Dec 2005 > It was commented that those dates look aggressive for some of the work > items so co-authors should review the above. > # Action Item (AI): > # Upon review of notes by wg, if there is no comments on the above > # milestones, Jean-Francois to send updated charter proposal to Bert > # for approval. > # Due by end of August 2005 AI Done. Jean-Francois _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Aug 26 09:14:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e2q-0003Qy-J2; Fri, 26 Aug 2005 09:14:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e2o-0003PP-Fh for ipcdn@megatron.ietf.org; Fri, 26 Aug 2005 09:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18432 for ; Fri, 26 Aug 2005 09:14:53 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8e3X-00062i-1Q for ipcdn@ietf.org; Fri, 26 Aug 2005 09:15:40 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7QDEXk0011029; Fri, 26 Aug 2005 07:14: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Date: Fri, 26 Aug 2005 07:14:33 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE647@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txtTopic: docsIfCmtsCmStatusEqualizationData & docsIfSigQEqualizationData Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgE4cWKAACga3IAAAh6FUAACaROg From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: "Ipcdn \(E-mail\)" X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Still don't get the 512 size constraint (rather than future growth)=20 I have now a draft with all the comments I send last two days=20 And looking from a set of vendors and experts a clear idea of what is the size constrains I believe we can defer this question after IESG commentary if is OK with MIB doctors Thanks Eduardo _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Aug 26 09:18:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e6I-0004Xf-Kf; Fri, 26 Aug 2005 09:18:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8e6G-0004Wb-LK for ipcdn@megatron.ietf.org; Fri, 26 Aug 2005 09:18:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18642 for ; Fri, 26 Aug 2005 09:18:27 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8e6z-0006B0-Tc for ipcdn@ietf.org; Fri, 26 Aug 2005 09:19:14 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7QDIFBm011482; Fri, 26 Aug 2005 07:18:16 -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] draft-ipcdn-pktc-signaling-08, further changes; result of conference call Date: Fri, 26 Aug 2005 07:18:15 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; result of conference call Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYALbFMcwAAAtm+AAKDJ+AAMfJunw From: "Jean-Francois Mule" To: "Sumanth Channabasappa" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: quoted-printable Cc: Satish Kumar at Texas Instruments , ipcdn@ietf.org, Beacham Gordon-CGB005 , David De Reu , Eugene Nechamkin , Freyman Phillip-FPF300 , sercu@tComLabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Sumanth, Thanks for inviting anyone from IETF ipcdn to attend the discussion = and for the notes. We have not seen one comment on your posting in 15 days so the = proposal should be good enough. Per the IETF#63 meeting, the action item = on the signaling MIB was: # AI: authors to close one open issue on tone table by August 20. # Ask Randy to review final proposal. Can you put out the proposed changes in the form of updated object = definitions to the list so we can see all the aggregated changes? Based on our discussions, we are getting close to the end on this one = and I would like to set the date of next Friday, September 2nd to have a = consensus on the technical changes to allow a draft09 publication by = mid-September at the latest. Thanks, Jean-Fran=E7ois > -----Original Message----- > From: Sumanth Channabasappa > Sent: Wednesday, August 10, 2005 10:09 AM > To: ipcdn@ietf.org > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result > of conference call >=20 > Folks, >=20 > As per the discussion on the conference call today (thanks to the > attendees), the proposal from Phil seems to be reasonable. >=20 > Further, there was a suggestion to include the following examples in > the > draft for clarity and ease of implementation. Note: Example B was also > the cause for the latest suggestion. >=20 >=20 > Example A: Call waiting tone defined per ITU-T E.180: > 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm > 2) 400 Hz AM modulated by 16 Hz, off for 400ms > 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 4) 400 Hz not AM modulated, off for 450 ms > 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 6) 400 Hz not AM modulated, off for 3450 ms > 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 8) 400 Hz not AM modulated, off for 450 ms > 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 10) 400 Hz not AM modulated, off for 3450 ms > 11) not repeated, not continuous >=20 > Assume userDefined1(17) is assigned to this tone: >=20 > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 17 400 16 0 0 1 90 -40 500 > 400 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 >=20 >=20 > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > 17 0 false(2) >=20 >=20 > ---------------------------------------------------------------------- > -- > --------------- >=20 > Example B - Congestion Tone - congestion(17): >=20 > This example of an embedded cadence is based on an operator variation. > 1) 400Hz on for 400ms -10 dBm > 2) 400Hz off for 350ms > 3) 400Hz on for 225ms -4 dBm > 4) 400Hz off for 525ms > 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is > shortest period) >=20 > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 17 400 0 0 0 2 0 -100 400 > 350 0 > 17 400 0 0 0 2 0 -40 225 > 525 0 >=20 >=20 > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > 17 5000 false(0) >=20 >=20 > Please feel free to provide any comments. >=20 > Regards > Sumanth >=20 > -----Original Message----- > From: Sumanth Channabasappa > Sent: Tuesday, August 09, 2005 2:37 PM > To: 'ipcdn@ietf.org' > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; > conference call >=20 > Folks, >=20 > There has been a suggestion (from Phillip Freyman, Motorola) to move > the > 'dBm level', currently under 'PktcSigDevToneTable' to > 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that > require this structure. >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Aug 26 10:23:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8f7X-0006Tt-9X; Fri, 26 Aug 2005 10:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8f7V-0006Tb-Ip for ipcdn@megatron.ietf.org; Fri, 26 Aug 2005 10:23:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23353 for ; Fri, 26 Aug 2005 10:23:47 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8f8D-0008Nz-4z for ipcdn@ietf.org; Fri, 26 Aug 2005 10:24:35 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7QENZLk019926; Fri, 26 Aug 2005 08:23: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; result of conference call Date: Fri, 26 Aug 2005 08:23:35 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes; result of conference call Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYALbFMcwAAAtm+AAKDJ+AAMfJunwAAKOOXA= From: "Sumanth Channabasappa" To: "Jean-Francois Mule" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: Satish Kumar at Texas Instruments , ipcdn@ietf.org, Beacham Gordon-CGB005 , David De Reu , Eugene Nechamkin , Freyman Phillip-FPF300 , sercu@tComLabs.com X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Jean-Francois, I concur. Unless there are objections, I will be presenting the final = proposal to this group in the next week. Regards Sumanth=20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Friday, August 26, 2005 7:18 AM To: Sumanth Channabasappa Cc: ipcdn@ietf.org; 'Freyman Phillip-FPF300'; 'Eugene Nechamkin'; 'David = De Reu'; 'T, Shivakumar'; 'sercu@tComLabs.com'; Satish Kumar at Texas = Instruments; 'Beacham Gordon-CGB005' Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further = changes;result of conference call Sumanth, Thanks for inviting anyone from IETF ipcdn to attend the discussion = and for the notes. We have not seen one comment on your posting in 15 days so the = proposal should be good enough. Per the IETF#63 meeting, the action item = on the signaling MIB was: # AI: authors to close one open issue on tone table by August 20. # Ask Randy to review final proposal. Can you put out the proposed changes in the form of updated object = definitions to the list so we can see all the aggregated changes? Based on our discussions, we are getting close to the end on this one = and I would like to set the date of next Friday, September 2nd to have a = consensus on the technical changes to allow a draft09 publication by = mid-September at the latest. Thanks, Jean-Fran=E7ois > -----Original Message----- > From: Sumanth Channabasappa > Sent: Wednesday, August 10, 2005 10:09 AM > To: ipcdn@ietf.org > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result = > of conference call >=20 > Folks, >=20 > As per the discussion on the conference call today (thanks to the=20 > attendees), the proposal from Phil seems to be reasonable. >=20 > Further, there was a suggestion to include the following examples in=20 > the draft for clarity and ease of implementation. Note: Example B was=20 > also the cause for the latest suggestion. >=20 >=20 > Example A: Call waiting tone defined per ITU-T E.180: > 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm > 2) 400 Hz AM modulated by 16 Hz, off for 400ms > 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 4) 400 Hz not AM modulated, off for 450 ms > 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 6) 400 Hz not AM modulated, off for 3450 ms > 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 8) 400 Hz not AM modulated, off for 450 ms > 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 10) 400 Hz not AM modulated, off for 3450 ms > 11) not repeated, not continuous >=20 > Assume userDefined1(17) is assigned to this tone: >=20 > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 17 400 16 0 0 1 90 -40 500 > 400 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 >=20 >=20 > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > 17 0 false(2) >=20 >=20 > ---------------------------------------------------------------------- > -- > --------------- >=20 > Example B - Congestion Tone - congestion(17): >=20 > This example of an embedded cadence is based on an operator variation. > 1) 400Hz on for 400ms -10 dBm > 2) 400Hz off for 350ms > 3) 400Hz on for 225ms -4 dBm > 4) 400Hz off for 525ms > 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is=20 > shortest period) >=20 > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 17 400 0 0 0 2 0 -100 400 > 350 0 > 17 400 0 0 0 2 0 -40 225 > 525 0 >=20 >=20 > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > 17 5000 false(0) >=20 >=20 > Please feel free to provide any comments. >=20 > Regards > Sumanth >=20 > -----Original Message----- > From: Sumanth Channabasappa > Sent: Tuesday, August 09, 2005 2:37 PM > To: 'ipcdn@ietf.org' > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;=20 > conference call >=20 > Folks, >=20 > There has been a suggestion (from Phillip Freyman, Motorola) to move=20 > the 'dBm level', currently under 'PktcSigDevToneTable' to=20 > 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that=20 > require this structure. >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Fri Aug 26 12:51:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hQ6-0007vL-VP; Fri, 26 Aug 2005 12:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hQ4-0007vG-W6 for ipcdn@megatron.ietf.org; Fri, 26 Aug 2005 12:51:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01469 for ; Fri, 26 Aug 2005 12:51:06 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8hQp-00053E-Fz for ipcdn@ietf.org; Fri, 26 Aug 2005 12:51:56 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7QGowjb010921 for ; Fri, 26 Aug 2005 10:50:58 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Date: Fri, 26 Aug 2005 10:50:58 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE68B@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Thread-Index: AcWcNEOXOYZ0b+qySouBm0pyfZ29vACXuwPQANTemlACGL+b0A== From: "Eduardo Cardona" To: "Jean-Francois Mule" , X-Approved: ondar X-Spam-Score: 0.2 (/) X-Scan-Signature: 6dc4cf1a21586e21f06beb9265c2e883 Cc: X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0974227880==" Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. --===============0974227880== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5AA5E.5528FF08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AA5E.5528FF08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Some comments: ( I missed the last meeting and latest discussions, I = apologize for that)=20 =20 #issue 1=20 a) I probably missed the DEFVAL added=20 Normally a configuration will try to allow access to RFI CATV (bit1) = interface only ( as DS interface and US interfaces - bit 2 and 3 are = not set) My preferred DEFVAL would be DEFVAL { 'c0000000'h }=20 =20 As today '00000001'h is pointing to interface 32 which I do not think is = part of any CM implementation =20 b) OK with the text, but also recognize that the object is already = deprecated=20 =20 Issue #2=20 Agree =20 Issue #3 =20 in docsDevFilterLLCTable: (you mean docsDevEvReporting ) Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated. Currently the specs require (for backup ) a message send as a = notification and traps need to be send to local log I see that the recommendation is to not require that, so just to confirm = that our specs need to align with that=20 =20 Draft 09 says: SYNTAX BITS { local(0), traps(1), syslog(2), localVolatile(8), stdInterface(9) } =20 >From early 2002 CMs (DOCSIS 1.0 ) support ( see early drafts 03 CD MIB = v2 )=20 =20 SYNTAX BITS { localNonvolatile(0), --> local(0) traps(1), syslog(2), localVolatile(3) } =20 Would it be needed a note for compatibility ? =20 Same kind of notes for the requirement of local /localVolatile when = configured notifications and/or syslog (back to DOCSIS 1.0) =20 My concern is that normally those values are set through config files = rather than SNMP SETs , which are going to be hard to map = capabilities/behavior for provisioning systems =20 =20 Issue #4=20 =20 As today ( I missed the discussions)=20 I do not see in operations (but probably in theory) that CMs currently = persist those values, because prior to registration the CM does not = forward CM traffic (moot point of the tables applicability ), and if the = config file comes with same entries it will fail the registration = process e.g. createAndGo for an existing entries =20 I would say "SHOULD NOT" , (otherwise specified) , there could be = options in the future to streamline the provisioning process and reduce = CM unavailable time in case of a forced reboot by Management system, = just not to close the door if I understand the suggestion of using = "SHOULD NOT" =20 Thanks =20 Eduardo =20 =20 _____ =20 From: Jean-Francois Mule=20 Sent: Monday, August 15, 2005 4:20 PM To: ipcdn@ietf.org Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on = proposedchanges =20 Folks, As you may have read in meeting notes from last week, we spent the = IETF 63 meeting discussing the closure of open issues on the CD mib v2. The meeting notes proposed some changes to get final (yes, final) = closure on this mib. Please review the text below and please speak up if you have some = concerns (it's also welcome that you express your agreement). Thanks, Jean-Fran=E7ois [extract from ipcdn minutes] 3.1/ DOCSIS Cable Device MIB version 2 draft-ietf-ipcdn-device-mibv2-09.txt Editors: Kevin Marez & Rich Woundy http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-09.txt We spent most of the meeting reviewing the 4 top remaining issues, see summary sent by Rich and Kevin in: http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html =20 + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces=20 Raised by Randy, the issue is, in the defval we have a 4 octet value =3D> How can systems with interfaces in a number not multiple of 8 interpret the DEFVAL value. Are bits ignored? Randy commented that he would be ok if there was some mention like 'octets containing bits corresponding to non-existent interfaces are ignored.' That said, if there are implementations that would reject a SET, then we need to say something about that. Rich commented that the DEFVAL was added due to prior MIB doctor comment and that the object is now deprecated. Bert asked whether there was any concern deleting the DEFVAL. Proposal for wg review: a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } b) consider the following (NICE TO HAVE kind of fix) adding a sentence to say something like: bits set corresponding to non-existing interfaces is implementation specific (to warn the mgmt admin/apps that no assumptions should be made on existing implementations of this object. (Randy's suggestion) =20 + ISSUE #2: docsDevNmAccessStatus -- Also, we should change the DESCRIPTION of docsDevCpeStatus -- and docsDevCpeInetRowStatus to document how the agent adds rows. See issue raised by Randy and the email summary provided by Rich for the context around this issue #2. We had some discussions around the persistency of those tables, the fact that the CM config file drives the row creation at boot-up and the fact that they are read-create tables so admins can also create entries as Bert pointed out. In most cases (except for docsDevEvControlTable), entries do not persist across CM reboots. Even in the case of docsDevEvControlTable, after some discussion, we believe that the entries are cleared and "recreated" after the CM reads the config file. That is the common understanding. Bert said: add a statement ("this is a deprecated table, this is vendor specific as to what vendors do with this table, mgmt app cannot expect a certain behavior"). + ISSUE #3: docsDevEvReporting and local(0) rows Comment close: ID authors agree with Randy's comment re: local(0) rows MUST persist. Text will be revised. in docsDevFilterLLCTable: Any attempt to SET the traps(1) or syslog(2) bits without setting the local(0) or localVolatile(8) bits MUST result in an error being generated. Proposal: DELETE above text if nobody complains after reading the meeting notes + ISSUE #4: docsDevFilterLLCTable=20 Issue is around text for the level of requirements on table persistence. Agree with Rich's text proposal: |"Table entries MUST NOT persist across reboots for cable modems." Rich also proposed to apply this requirement to: NmAccess, FilterLLC, FilterIp, Policy, Tos, Cpe and InetCpe tables. It was suggested to use SHOULD NOT rather than MUST NOT but other than that, proposal is ok. =20 + Other items on CD Device MIB: Randy added for consideration: wherever we have this "must not persist" langage in table definitions, it would be a plus to indicate that they may come back as entries may reappear when CM reboots and comes up with config file. Or consider adding this in the front paper as a consideration for users of the MIBs if that is too many little edits in the MIB objects. Proposal: add a note on persistence model explaining the persistance of some mib objects and the CM re-creating them upon config file reloading. A comment was made that in general, we should indicate the persistency model in each object rather than in the compliance section. Bert also commented on the compliance sections: if different requirements apply to CM and CMTS, suggestion is to make 2 different compliances. Rich added that the new compliance statement is designed like that. # AI: [authors: Kevin Marez & Rich Woundy] # Authors to summarize list of agreed changed and the technical # changes in the text per wg consensus and issue new draft after AD # review comments are in.=20 # Due by early September? # AD review by Bert due by August 15 ------_=_NextPart_001_01C5AA5E.5528FF08 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [ipcdn] cable dev mib draft09 - WG consensus requested on = proposed changes

Some comments: ( I missed the last = meeting and latest discussions, I apologize for that) =

 

#issue 1 =

a)       = I probably missed the DEFVAL added =

Normally a configuration will try to allow access to RFI CATV =A0(bit1) interface = only =A0( as DS interface and US interfaces – bit 2 and 3 are not = set)

My preferred DEFVAL would be DEFVAL = { ‘c0000000’h }

 

As today ‘00000001’h is pointing to interface 32 which I do not think is part of any CM = implementation

 

b) OK with the text, but also = recognize that the object is already deprecated

 

Issue #2 =

Agree

 

Issue = #3

 

in docsDevFilterLLCTable: (you mean =
docsDevEvReporting )

           &= nbsp; Any attempt to SET the traps(1) or syslog(2) = bits

           &= nbsp; without setting the local(0) or = localVolatile(8)

           &= nbsp; bits MUST result in an error being = generated.

Currently the specs require (for = backup ) a message send as a notification and traps need to be send to local = log

I see that the recommendation is to = not require that, so just to confirm that our specs need to align with that =

 

Draft 09 = says:

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SYNTAX BITS =
{
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
local(0),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
traps(1),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
syslog(2),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
localVolatile(8),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
stdInterface(9)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
}

 

From early 2002 CMs (DOCSIS 1.0 ) = support ( see early drafts 03 CD MIB v2 ) 

 
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SYNTAX BITS =
{
=A0 =
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0localNonvolatile(0), --> =
local(0)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
traps(1),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
syslog(2),
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
localVolatile(3)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
}

 

Would it be needed a note for = compatibility ?

 

Same kind of notes for the = requirement of local /localVolatile when configured notifications and/or syslog (back = to DOCSIS 1.0)

 

My concern is that normally those = values are set through config files rather than SNMP SETs , which are going to = be hard to map capabilities/behavior for provisioning = systems

 

 

Issue #4 =

 

As today ( I missed the = discussions)

I do not see in operations (but = probably in theory) that CMs currently persist those values, because prior to registration the CM does not forward CM traffic (moot point of the = tables applicability ), and if the config file comes with same entries it will = fail the registration process e.g. createAndGo for an existing = entries

 

I would say “SHOULD = NOT” , (otherwise specified) , there could be options in the future to streamline the = provisioning process and reduce CM unavailable time in case of a forced reboot by = Management system, just not to close the door if I understand the suggestion of = using “SHOULD NOT”

 

Thanks

 

Eduardo

=

 

 

From: = Jean-Francois Mule
Sent: Monday, August 15, = 2005 4:20 PM
To: ipcdn@ietf.org
Subject: [ipcdn] cable = dev mib draft09 - WG consensus requested on = proposedchanges

 

Folks,

   As you may have read in meeting notes from = last week, we spent the IETF 63 meeting discussing the closure of open issues on the CD mib = v2.

   The meeting notes proposed some changes to = get final (yes, final) closure on this mib.

Please review the text below and = please speak up if you have some concerns (it's also welcome that you express your agreement).

Thanks,

Jean-Fran=E7ois

[extract from ipcdn minutes]

3.1/ DOCSIS Cable Device MIB version = 2

     = draft-ietf-ipcdn-device-mibv2-09.txt

     Editors: Kevin Marez & Rich = Woundy

http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv= 2-09.txt

We spent most of the meeting reviewing the 4 top = remaining issues, see

summary sent by Rich and Kevin = in:

http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html

 

+ ISSUE #1: DEFVAL for docsDevNmAccessInterfaces =

Raised by Randy, the issue is, in the defval we have a 4 = octet value

=3D> How can systems with interfaces in a number not = multiple

of 8 interpret the DEFVAL value. Are bits = ignored?

Randy commented that he would be ok if there was some = mention like

'octets containing bits corresponding to non-existent = interfaces are

ignored.' That said, if there are implementations that = would reject a

SET, then we need to say something about = that.

Rich commented that the DEFVAL was added due to prior MIB = doctor

comment and that the object is now deprecated. Bert asked whether

there was any concern deleting the = DEFVAL.

Proposal for wg = review:

 a) in docsDevNmAccessInterfaces, = delete DEFVAL { '00000001'h }

 b) consider the following (NICE TO = HAVE kind of fix)

    adding a sentence to = say something like:

    bits set = corresponding to non-existing interfaces is

    implementation = specific (to warn the mgmt admin/apps that no

    assumptions should be = made on existing implementations of this

    object. (Randy's = suggestion)

 

+ ISSUE #2: = docsDevNmAccessStatus

-- Also, we should change the DESCRIPTION of = docsDevCpeStatus

-- and docsDevCpeInetRowStatus to document how the agent = adds rows.

See issue raised by Randy and the email summary provided = by Rich for

the context around this issue = #2.

We had some discussions around the persistency of those = tables, the

fact that the CM config file drives the row creation at = boot-up and

the fact that they are read-create tables so admins can = also create

entries as Bert pointed out.

In most cases (except for docsDevEvControlTable), entries = do not

persist across CM reboots. Even in the case of docsDevEvControlTable,

after some discussion, we believe that the entries are = cleared and

"recreated" after the CM reads the config file. = That is the common

understanding.

Bert said: add a statement ("this = is a deprecated table, this is

vendor specific as to what vendors do = with this table, mgmt app cannot

expect a certain = behavior").

+ ISSUE #3: docsDevEvReporting and local(0) = rows

Comment close: ID authors agree with Randy's comment re: local(0) rows

MUST persist. Text will be = revised.

in docsDevFilterLLCTable:

           &= nbsp; Any attempt to SET the traps(1) or syslog(2) = bits

           &= nbsp; without setting the local(0) or = localVolatile(8)

           &= nbsp; bits MUST result in an error being = generated.

Proposal:

   DELETE above text if nobody complains after reading the meeting

   = notes

+ ISSUE #4: docsDevFilterLLCTable =

Issue is around text for the level of requirements on = table

persistence. Agree with Rich's text = proposal:

  |"Table entries MUST NOT = persist across reboots for cable modems."

Rich also proposed to apply this = requirement to:

  NmAccess, FilterLLC, FilterIp, = Policy, Tos,

  Cpe and InetCpe = tables.

It was suggested to use SHOULD NOT = rather than MUST NOT but other than

that, proposal is = ok.

 

+ Other items on CD Device = MIB:

Randy added for = consideration:

wherever we have this "must not persist" = langage in table definitions,

it would be a plus to indicate that they may come back as = entries may

reappear when CM reboots and comes up with config file. = Or consider

adding this in the front paper as a consideration for = users of the

MIBs if that is too many little edits in the MIB = objects.

Proposal:

  add a note on persistence model explaining the persistance of some

mib objects and the CM re-creating them upon config file reloading.

A comment was made that in general, we should indicate = the persistency

model in each object rather than in the compliance = section.

Bert also commented on the compliance sections: if = different

requirements apply to CM and CMTS, suggestion is to make = 2 different

compliances. Rich added that the new compliance statement = is designed

like that.

# AI: [authors: Kevin Marez & Rich = Woundy]

# Authors to summarize list of agreed changed and the = technical

# changes in the text per wg consensus and issue new = draft after AD

# review comments are in.

# Due by early September?

# AD review by Bert due by August = 15

------_=_NextPart_001_01C5AA5E.5528FF08-- --===============0974227880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn --===============0974227880==-- From ipcdn-bounces@ietf.org Sat Aug 27 15:28:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96Ll-0000So-JA; Sat, 27 Aug 2005 15:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fpm-0000kM-Ey for ipcdn@megatron.ietf.org; Fri, 26 Aug 2005 11:09:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25544 for ; Fri, 26 Aug 2005 11:09:31 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fqQ-0001Ki-RP for ipcdn@ietf.org; Fri, 26 Aug 2005 11:10:20 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7QF9Cpg026373; Fri, 26 Aug 2005 09:09:12 -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_01C5AA50.1DC4AC82" Date: Fri, 26 Aug 2005 09:09:12 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE669@srvxchg.cablelabs.com> X-MS-Has-Attach: yes Thread-Topic: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Thread-Index: AcWjO0pm5pwkSOJYSvioQGI2vEiOhgHEwNMw From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 91a4853b4617d3c1ce94290cc3eeb886 X-Mailman-Approved-At: Sat, 27 Aug 2005 15:28:20 -0400 Cc: "Ipcdn \(E-mail\)" Subject: [ipcdn] RE: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C5AA50.1DC4AC82 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert,=20 Here is a draft version based on the topics you identified,=20 The draft is ready to go of you are ok with the changes and comments to defer the equalizer data size to include with IESG revision Attached current diff file ( change zzz to zip) Compiled with : ( some little corrections made vs the postings in the list to compile properly=20 * operational(8), =20 * and removed object group definition of complianceV2 and added the comment in the bottom in the GROUP-TYPE to have happy smilint (see diff file)=20 used :=20 smilint -m -s -l 6 -i namelength-32 idnits 1.77=20 tmp/draft-ietf-ipcdn-docs-rfmibv2-14.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. No nits found. -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Wednesday, August 17, 2005 8:51 AM To: Eduardo Cardona; david.raftus@terayon.com Cc: Ipcdn (E-mail) Subject: AD re-review: draft-ietf-ipcdn-docs-rfmibv2-13.txt Summary: - No showstoppers as far as I can see now. - We can do an IETF Last Call now and you consider the below as initial IETF Last Call comments. So after IETF Last Call completes you would address the below plus whatever comes up from IETF Last Call and only after that will I put it on IESG agenda. - Or you can go do a quick new rev to address the below. If you can do so in the next few days, then I prefer that. Here are my review comments: - In the MODULE-COMPLIANCE statement(s) I see OBJECT docsIfUpChannelStatus SYNTAX RowStatus {active(1), notReady(3)} WRITE-SYNTAX RowStatus {createAndWait(5), destroy(6)} That seems weird. I think that active(1) also needs to be included in the WRITE-SYNTAX, otherwise, when somebody does a createAndWait, and that results in a notRady, how are you then ever going to get the row in active(1) if you cannot write that value? But then I see in the DESCRIPTION=20 clause of docsIfUpChannelStatus that one should not (never?) set a row to active. I do see that notInservice is possible in the description=20 clause. So I am confused. Are you also aware that agents may remove non-active rows after some implementation-specific time? See RFC2579 for=20 details.=20 Just want to be sure you have specified things as intended. I find them strange.... but who is me. It has to do with the "complexity" of your cloning mechanism that both Randy and I have brought up.=20 I do not have a quick alternative available. Would take serious time I guess, cause I would need to better understand your requirements and constraints first. I guess if the WG is OK with whatyou have then we can probably leave it. The WG members (at least some of them I assume) will have to implement it! - SYNTAX check with SMICng: W: f(rfmibv2.mi2), (1488,21) Item "docsIfCmStatusCode" should=20 have SIZE specified =20 I understand this was already the case in RFC2670. If we can add a size such that a compliant implementation of RFC2670 is still compliant, then I suggest we do so. If not, then leave as is. I see that you had a SIZE (0..16) in revision 12, and then Randy commented that that did not fit with the DESCRIPTION clause: DESCRIPTION "Status code for this Cable Modem as defined in the OSSI Specification. The status code consists of a single character indicating error groups, followed by a two- or three-digit number indicating the status condition, followed by a decimal." Which is true. In fact, I am not sure what the content is. Is it=20 - either 3 octets (1 for error group, 2 for a number, no decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 3 octets (1 for error group, 1 for number, 1 decimal) or 4 octets (1 for error group, 2 for a number, 1 decimal) - either 4 octets (1 for error group, 2 for number, 1 decimal) or 5 octets (1 for error group, 3 for a number, 1 decimal) See why we wonder?? And in any case, the way I read it, MIN length would be 3 or 4 and the MAX length 4 or 5, depending on the above interpretations. I see that Eduardo posted a response, and no-one reacted (at least I cannot quickly find it). So ?? W: f(rfmibv2.mi2), (5036,4) OBJECT-GROUP "docsIfObsoleteGroup" is not used in a MODULE-COMPLIANCE in current module I understand this was already the case in RFC2670. So I am OK to leave it as is. I had suggested (in y review of Dec 2004) Might be good to add a ASN.1 comment about it so we know=20 it has existed for a long time. Seems that was not done. Eduardo responded: >> will add after : -- conditionally mandatory group GROUP docsIfCmtsGroup The group reference,=20 -- obsolete group -- RFC 2670 already had a obsolete group, even though RFC2670=20 -- was the first version of this MIB Module GROUP docsIfObsoleteGroup DESCRIPTION "This group contains obsolete objects." But I cannot fond any of that addition? Am I missing something? - There was discussion/question Bert commented: 5. ./DOCS-IF-MIB:2400 [3] {range-added} size `(0..512)' added to type used in `docsIfCmtsCmStatusEqualizationData' Probably OK. Can you add some text to explain why this is OK? Eduardo answered: >>(*)=20 I do not have other explanation than "enough" room, probably for future enhancements (?) Current DOCSIS MAC may constrain to 256 bytes total the equalizer data maps. Does anyone recall the reasons for the number selection?=20 So where are we with this? Same question for: ./DOCS-IF-MIB:1167 [3] {range-added} size `(0..512)' added to type used in `docsIfSigQEqualizationData' - For object docsIfCmtsQosProfilePermissions I still see in the DESCRIPTION clause: Either createByManagement(0) or updateByManagement(2) MUST be set when writing to this object. while I see=20 SYNTAX BITS { createByManagement(0), updateByManagement(1), createByModems(2) So that is inconsistent (still). I think you mean=20 Either createByManagement(0) or updateByManagement(1) =20 - Eduardo changed (after my questioning why we have a deprecated value=20 added): docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), operational(8), -- deprecated registeredBPIInitializing(9) } to docsIfCmtsCmStatusValue OBJECT-TYPE SYNTAX INTEGER { other(1), ranging(2), rangingAborted(3), rangingComplete(4), ipComplete(5), registrationComplete(6), accessDenied(7), -- value 8 not used registeredBPIInitializing(9) } Not sure the new thing is better. I much more wanted to see an explanation as to why the deprecated value was added. If some implementations do use it, then better to add it in deprecated form, so we understand that it may indeed be encountered in real life and if so waht it meant. At same time we see it is depreacted, and we have an explantion as to why (and best to have it in the DESCRIPTION clause). See... it is all not only about being pure, but also about representaing realistic behaviour and explaining to the readers of this doc or MIB module what exactly to expect and why. =20 - There was discussion on list: Randy: docsIfUpChannelScdmaActiveCodes - since the primes can never be set and can never be returned, they should be excluded in the SYNTAX Eduardo: (*)=20 >> I am not sure if this is appropiate or will breaks the regular applications,=20 To exclude prime numbers 67,71,73,79,83,89,97,101,103,107,109, 113,127,the SYNTAX clause will be=20 SYNTAX Unsigned32 (0|64..66|68..70|72|74..78|80..82|84..88|90..96|98..100|102 |104..106|108|110..112|114..126|128) Do you prefer this?=20 How do you break this for the 72 columns ID text file format? Bert: I tried this and broke the line after the 102, and both smicng and smilint are happy. So it can be done and it would make the valid values machine readable instead of just being in the DESCRIPTION clause.=20 - Reference/citation problem: !! Missing citation for Normative reference: P139 L016: [IANA] Internet Assigned Numbers Authority, "Data-Over-Cable An easy fix would be: OLD: IANAifType FROM IANAifType-MIB; NEW: IANAifType FROM IANAifType-MIB; -- [IANA] If we're going to do a new revision, then pls update all citations and reference to RFC3291 into one for RFC4001. NITS/Editorial - From an earlier review (6 Jan 2005) by Randy and not yet addressed: 5) EDITORIAL: "reinit" -> "reinitialization" 6) EDITORIAL: "ie" -> "i.e.", or better "that is" 12) EDITORIAL: "head-end" or "headend"? pick one, preferably the former. 13) EDITORIAL: there are some strange capitalizations: "Lineup" in 2.11 "Addressed" in 3.2 (although that is fixed now, now it is in 3.1.4) I checked the above 2. Not the next ones. But did you? "Downstream" in 3.2.5.1 and elsewhere "Cable" in 3.2.5.1.2 "Unicast" on page 12 & 14 & more "Multicast" on page 12 & 14 & more "Broadcast" on page 12 & 14 & more "Upstream" in 3.2.5.2.1 "Contributions" in 5 15) EDITORIAL: "empty string" would be more precise as "zero length string"=20 (This could potentially be technical.) I really wonder why the editors do not take such comments of a carefull review into account when they do a new rev. For completeness, if you do a new rev: $ idnits draft-ietf-ipcdn-docs-rfmibv2-13.txt idnits 1.74 draft-ietf-ipcdn-docs-rfmibv2-13.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... * The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. (The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted.) Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Run idnits with the --verbose option for more detailed information. Bert ------_=_NextPart_001_01C5AA50.1DC4AC82 Content-Type: application/octet-stream; name="diff_draft-ietf-ipcdn-docs-rfmibv2-13-14.zzz" Content-Description: diff_draft-ietf-ipcdn-docs-rfmibv2-13-14.zzz Content-Disposition: attachment; filename="diff_draft-ietf-ipcdn-docs-rfmibv2-13-14.zzz" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAKpIGjPzWzFlfMAAAKznCgAsAAAAZGlmZl9kcmFmdC1pZXRmLWlwY2RuLWRvY3Mt cmZtaWJ2Mi0xMy0xNC5odG3sXetz2ziS/75/BU5bdZtUWW/Zlp1HnS3bE9/Gicdydu5qKh8oEpJw IQkOSEpWtvZ/v27wKYkSIYmmNfIqVbEeILr7h0aj0QAaf/nL+/+4+tp7/N/7azL2LJPcf7v8fNsj lWq9/lu7V69fPV6R//n0ePeZNGsN8ig022Ue47Zm1uvXXyqkMvY857xen06ntWm7xsWo/vhQf8K6 mvhw+LbqpZ6sGZ5R+UiAdLVKfqE2FZpHDTKYETHUDTYcAq3W8Xn8qUqqrmdw3yOe5dQNoQ29KqPe sMoc3bCrBtfdqhhabDBpVZvtmvekVLAjC1arESMKQEgcOrVGcw6ICvmI1QS19GeuR61z8pnZ/hNx x0xoP2smnfzgU+r9rOncIq1ap9bsVgdDeEP+2iR9bpMLR5BmhzTOzo/b560u6V33H0mr0WgRdtI9 Ib98+VYPakz4/eYye0S06Y9zUvddUR8wuz6SH6E0uZj+IO1aEygsPoGQph4JPkqc3+CD+M73mOm+ BUa7tebS89OFCsLP+Kx8Sxq14/AhBFL+pZoBfwl5b1FPI6gyVfqHzyYfKj1ue9T2qo8zh1aIHnz6 UPHok1fHx98RfawJl3ofmMur3e7xWbVZIfWc2vrezKSZdequGz/uMc+kH68CAFS0qppXTOrU+3pQ saThIifEA05SDMifCBlwY4Z//0ksTYyYfQ7QdejTu/BjVbDR2Dsnmu/xd+RfwTOeICR4JvrCiL6Y jplHq66j6fScOIK+I0MQvTrULGbOzonFbS5/fEcmVHhM18yqZrIRkPW4ExZ22U94+Mzx3kXVj6Pq U783m1AgYqDmWpppLpQ4xQLBZwTgnDAPaOkLLP2DCkOztSPyiZoTiiwdERc6VtWlgg0TCiYdepKH gab/GAnu20ZV5yYX5+Sv19fXSUGJ2IqCNzc3SUGpqCsK9nqpgubA5PqP7IKXN5cp0msK3tx0k4LM Bum87ILdOR6pST2aXfAizeOEM2OVMDdpHrErKOFoMpsOxArSFxfzBW0OBcNfBTXerQQ/pR9d1A/s D5EKypZ7RxzNMMDIQE8gLecpoUNN5rjMVWAIVSUQNLPw1dXVorqsKT0PStDCa4qfXZ0tKcRaXk6W 1GJN8Uaa9VA51hTvXkTF39dlJ0RLXA9N8Xtpe0IzqA3ARA24MKj4UGmAxaSmGTZE/BktR/g5fEqQ wUjS+lDhMBqOaOXje2/8EazfWL75T3vgOu9U7GpQMn6QbFZFJ6OK4E3dE6GllfzCLwbRTc11P1QC va2QiVQ/MM3cqeADxlwh0KXkW8nX3O9SfTIeW103crQzQ7f3hIMFJz3ZblcajIFfqDfl4gf5Df7D MXrd66pGHgBQ380VrGhCWwH08b1GbM2C4RNtdqPRkMN/MXDKHlr5+At0HGe1HFmv99Af7KieoC9C vyCP4MrOwJ3rwahmaOSzZ0Dfg5Ifa2vALoiLwIBUPl483gIf+tiGvjli1CW3tr7IRWmqCq6XsKlX vcI+vF6Y5dd1DYAUBvjY+apaMKFiVLVVuKpePzlMUPc8WwEv/JHveuT4CKcOx6vlnX/J7v1ZG7ih luSraszFDXgJviZm2ZrYOpWMnOSzQFZzUYKqhlKt52/tK8YBcc/HLxOtfCorXmGrt06OQujmuCir q+d20bIZgsHHYJzcCJgbUlufkTcPN2+JNBRDmAWRO7DRI2rB1BC+HHJhaTidJ5eaS8FTFeTqa69/ 288Vq1gypYGT+WrVGuDIW47JNGD34YawSIx8Z2HrGosxte3CTW2WODmuaKZRbiub1V0pRpakU74J 3U8T0Pc0cD8JHxJvzFxyRy2ey+OaZw4Dx6Wu03mOrpPZFR4RUVBgX5pDeA9FFjw3zTbwB9cf/B/V PeJxgsElR/AJc8FuqvsowMPlDOuxmOfhVEU25zy1I0I1fYwBtjFYYkEdcGqAMxfKasjKrMSWz3IN kokF6mMfAMGho40fHm56pH1yclqLxnxVaZWQ0xyw2Lqc9jkaRk8J4MO9MUwGb+8f8AFmyT4yHTMA cEzxdxf+YJtONUHLBw65XtmOygIpoTPWJpQMKLWxkikD/RxQYjBXN7lLjSOpw0g0A59Mez2gMETS F3V8V7XjBrKqKZasNKMeZhNN1znGg3Us4I2zsYo6wQmie9m7J6dntX0CLrP/Bg0c9dQNMMjH9EWE zhQytEjdxebYC973dIpCFkw09DpUjTC4Fo2UoTdC48Lk2h4BFSqgVK5QRRIpEZhHzf1BbriAnvDm 9vrx5i30j4B1zQ3MDn6MpMDYt+PWCPnCPSrNvgouRdHYCpYlP+z4OfywYIwLWCeWBiOh6XI0Op5g A9/L0gNt3WRvx5qzjXqsny9pyTON2kLP2cC2rQjxZNfzbws4b5zkrDelOFiTIcMlGqjaE7N8C82V y55wWdsbK4UnCiVUIkBoh7B/gbPgOwZulTlCH9fUdHyHfuzA5aiucgtN0C1TfW5uIrMOnyLplAiP xywKRvlWTiiZDZ6+4I5gGtpoTnyXLje8C3INqaDgZqkAUwyFEiGxgDXgz8RGAw51JscraoWNBkOX jSxW5FIeeJ0gzwimTG6togLH7rW/ZnP3CC6WCYMkmhXdFyIIDM+rjw4IQi+EyQDABt1N0ZvZqeYS IUhtGcTAptw0iG/qTWZUtQE4EJoOY6T35K1bNo3l3qK6fytgoCYLwbf+WDP4lFwxAbNsLnDxeHdV 3IXGCyulK3mt4T7ErTUxq47DUL+lCczJc0xgHpcDmUHshMpFaMJtlbVw9W0YW5CM3PtkFThc+H6p bRd7Z3Z63JkFm+1g7swUvK5VD7xmw51g8qb3VprYOFTT5zoYnBl5g7r+VslWbV7bq8X+IvQhchlb LPiatVUaUYtanBh0CE/CpIg4XMjgfRhpXLc14s3d7eVbFT0ukk6J8GCIAWeOcqXDDndVWgmjMGny uM5NnHDOh2V1blm+zbyZUjcvkk6J8NzCtFHDQwq+qQmMyqZa16XSrwyEMAiXK8WulLT/5e6+OoB2 NVSwKYxIEcAU3LUzySY7tkdCm1WIrDisYJy4cwhK1Qw2L8rDHR/dH8xx5LIyx/M49ohKJz348T21 PgKQ8F3riCB58H3e1+HL98s7uudpiC1otEMaZ2kSRqa426tfEOHncpX92mAwTyFvHsDGTGiwsA7c awChM4b+w4IwiOMPcIUZLctbaZRUNLBIOiX2TmlumbS0ghu+7sVrR/e9qy/zCybS8izYFhVoiqJR IiypBbPU0lINfS0rDJLC7MHl0H4Mo6gYcHXH3DcNmP6qYFIIgRIB0QxDBFN6UFxsnLlW+xsuGzET P8tYgeYRucXtv6K5swokBZEoExTbqGNXBl6DDStK4/jqp8piPZfLshl6lNt5wCqEpz7zLe7KJ14t hvBws0bmpn/VvgfKpgkj7TffCBi1pe9YW/oHr46KChdKqESAWkD5F5O7LoZ2lrnK/wevdYcCYoAK JbQVQEshvdPn2VadGbFr1ZrxZkY5OZN+3r1gE01XxyMH7JVcxIdWas3UnspFLjZgo8wTGArYthJs exeP/1AWZF6oXbFtJdhKLrZkY8+wbaewhZmLTc3NBdsd23YK25CLTZnIrDmpdt9w76Rwv8Pl6OCk 6h03qKXaArvj3knhvsSFGhN/MtyP07g/9hdlfqTCYnYQZAvyoTwL7sdp3JW4yGRjz7A9SWELcoAr ZKxVnax/8DrZDduTFLYRF1uwcbJf2J4m2MrT7Pea/oN6mwm2O7apMxtpLjZhIs9e7Bnu3YQz49La 2vfYEfduApDkYks29gzbs5ROy6OkWwm1K7ZnKZ0OuNiKjZfCdjW66TlJKBkmQttEKGVs16DbXMIX udiIjT3EtpWBbXMjoYrAtpWBbfNPj217CdvWC+htewnb1p9Fb1fFKBqJRHxqu56gmqqbnwi1q71t NmJgU1xszMa+YZsY22tf8Oo2Qwm8TnfENjG2aS42YSLPPzvdM9wTQ/yJakaV2lvNOXbFPTHEMRdb sLFv2CaG+O6it42zXwi2iSFOcbExG/uGbRIAuut92cbzLQTbJAAkudiSjX3DNgny3DGbVV2Tb6Ew O2ObBHkSLjZj4s9mi5MA0K/3/b9DwV99zRCa5wtK7se4Z60/ZkOP/J3OcF37mXBPAkBKXKxgY9+w TQJAv17czQt1gUmKPN+Q4UPfDOKGz4NtEgBS42KZiT+bTicBoIebTFXJ/1cA7kkACLjYmo19wzYJ APVn1oCbVTyu6G4o1M7YJgGgOS42ZGPPsG0lc71vzlYzvSKwbSVzvZiLLdgoE9to60QbCH+dUDFh dLoxywHbpLsGvXjrRKGEtgJoaetEt8StE+10mLLvCV+Xo0m0//32cmMMtlHVdjpMmcmFIhu7tcT2 2K5GN40vZuC7HeLWkK/hrnAloZSxXYNuCt9lLvKZyHMb9hD31iLuPWsD1CXuZ7vj3lrEPeFChYk8 3M/2D/f2PO5sqFueyzfS9wJwb8/jPs/FQeKe2tLyQAP/3x0zJ9rdHOeVdaU9tXCSQNPtQQgGqHfF PbWlRZ0LZdwTDkvFvQPoXOEBH3lvz4a+aYBttp+4mG91Le6LXGzKRG2Vn/gCWV9DqTJRgTqPgdcL /YfNpyY1RsEBhfWyRSpSy0Z6DoVmu6WMeyZiUu5Oekx9oEGWUfKJuR4XG2z3zCSwzOHLt8nJGmm3 EjbdNtAm6tmOV7dJ0CppX1LnDiWLbGzE5j63CbZK2n+X0u4mbtIqhbZJyg+6fvKo7WaHpxSZ3Pc2 SfmeibTbi/tMbbKw7XcEg/JQcEueKWydnOav+Utm9gn3he3UyxJtiXvigCQSbzPP7aT7QZ/qvmDe DM8UuczAuwwVx/Vm+2W2nmaCc5ovkYJIubjvtOW3k9b124svF3i332aYLzGZ2KCThR758m3SXS/t NuLO2aDTBYm3859Sc4W5RAswRYBxTGgDZqIy8WFq59qR3GKFx1PD7UB71yar7NPZztKu95+6O7dJ alv8Q5SDcIvJTvYcLoPDl2+T1GaoOZk3FTm7YZrtswL6yXHan/0S5CCZ0I1baEU/2b82ka3SXC+x isDP2yapcTzODLNxq6xok0UO96RNWnkSb90mnYZymxC8tQpPsbt/IxfhCf6NbNQK6xQ3Z7PTfJFx nGRLpi5YmvO1+OGQY5pU93zNJPdy8IFxBweZJLMX3mVDM+Mu+fi1Xgy/DSVbwq+Vj1+Jsu3nuf/N zuLnsr9dda8WfXj4RqYYN6inMRPzS0Vr1+FiaZJXW15hY1BXF2wg8yxHuX1zpSqUSonQqCnREXFM ivvQZKJtXJlww6thTtdfRpNK/1UcnRLhkfesdJoN8ju8wzffayrSrnnsNffDu4UEb5hAKU5EPGEa dJ8JE3IoYqncgRgwp0cEFMhSyzVXJJ0S4clLnwj25e72Eqw/rgOmZRtRG2bDpql080BxVEqEJm49 byy4PxpLKfrMAnMRX5OdEuo+TLRI3mD+QLUcrQWRKAKUgrt0JtmN0hO2N08deBymDsRjRkrpCQuj YWTKu73uhSvuctRmbuqG1XCBvn93O2kdhZeT4Z2L4chuYJbP/uMVOe4eqShgkXRKHiJbx6ddOdbh m+9HETfRb2fRb2ff5dRi/ufuuj0Uc0NqQWRKBCdgqKvoNiyXfrXeQjo9Vy5zWYVfLXIkmB2iFxPm GU7fAyvvYaKCTcBsUObhHTJyuc9GJ8Ak8tZOFVUtiESJoLhBWhrfhZFD3rAkmZqfmcETXMe7howg hzP+KtOG4HZnFVgKI1IiMEEenz7OVvXUdjPSd6jOhmH6W0wMi/6Rkh3brsbD6LFLW9PPCt+a3sKM CYvZ8tZIlTyWHYmMg9Sr6nzNtjReoGexGrtzagxuGFRDg4vswnXIxHdTNqhF0ikRHgMNV2D1wsAW tV1fUHRPZe/HBLpg9mIpsLzO7SEz8FsNF3BV4CmSTonwhHmyZfpFx4SGqmFLU/L75f1t4KTiu/vP 3/pqHuI29R2mXW02nsGutoJMmWskSYrm2NJ0Pa/Zfn4F0szGsBGp9KJbLsgFpoS2NfJIzXBjbOUI HMQpXp8hs4vHAWDF+zQLJFMiOMEl+WDPx7OBwLtQYTovZDcOfondyYBbA0Zn8BHJBIwaJzgcaKbS 1QdF0ikRHmyXDa9gWfHIgdrA5jPYwHac0XaNMEnpPDM4X9VrtoQXsUMHs0L6h09tHe/xBiQDl0VO BgHLhxtiUYP51lH0gLwEWEX7CyJRpgUMkydPmQGsgXvzCRToJ3mjz3QTnDsHrJBLwY8z3kpzNZgR naKDnMinZBYKJFMiOL8lN61860ez6sAHPiJ+dDw9lG2LpaAi6i8RjlCRcQoURVWOq53W3aefRMg1 gumYmRhpmeJa3hLvKogURKJEUOIGyeS9UT09biTcG9ShtoELK1w2uwokhRAo06JoTrAxGG+7Dfde jMCdsUMvJ9w9480cmCuaZCC4Zuia60UNqWROCqJRIiyx5Qt7O3PJCbRbLZVtY85Iuuk4w0QTana2 OCqv2VPAnUSYDdGh6FqlPPRMs4ywyRGL+7YHCErdU2msAsmUCI7v4GhNjZFMdrHIZ8rbiVim3pRC z2wdE7RTMEE4Ubogpkg6JcIDtI+kD4M90OTTlAxGkrx0lRQqwBRDoURIopbpnMqWQda7pzXZTHmG OjZoKsAUSadEeAITgKa6m3CqBTuC8U5Ei4IjHHh/0MTgJOtU2HJvXmAsVKApikaJsIArY3KZby+d mNaj+tjmJh+pjYfKlRzGcLcUoGg9Q4Cik3H1yxqxkufyQhWrKj2MttmuF1wgLJrcAojXg1ZcU5vQ Csx9goACeHraisUouQSj0kcKIlEiKKGTryLcQtED7ebtZ+jmx6o3Dan0/ePcvr8JpddtEGRAgOly +w/0yElwRa4WdklcXxjJtYbgs+A+xtFkLx6HmcaVek6hhEq2mKBMkUFDJ9kCTw8jjAUbzWKolG83 CbmVO1yRaW6bs5hlua7vCc12Lea5qdlEMN9gSsdwCiNSIjDg8HqCmwG3rj6mhm/KIFpq4hmy7Lpy KgUTcTa3l0wFmgLJlAhO705x19ndoe8la3aeYZw9SW6dWyNNUjxvJF2o6zBaYtuhAKb3Amw0jFyu ByNZGCq+4WKKR+CuhUCfgwsRnnLDPmnRYB1eG8CIp6L3xVEpERpkMFyF1IipzajazexrHnvNioZb wCq4h7iKe4irSvtv3XPyoBmMq8BeRP0lwnETr32v2nvcv68+3NxOWrVG9bZxWm10mq1mo6ICxa51 H4aaLo1Mx88wMp3O3dm5RqDkiZzBKaO612w2MAjraDOTawZxuJDaGyUQjy8uUrLLm9V0oH3g5Bn6 QDe4P1VF+bs5yp+u5zVr/QW4D5obJssHZyLY30gm3PTwUKkW3QqDRy25C3otl7hMOqEmTChVekMx FEqExMDlF4vZcheY7LULLiWzHGpotk5rKN1PKjioUySXZF8FlwLJlAgOcwkM+QwK0+AwbqdbOz0O rjUOWYtbNIi6wK9fx9YmYeKiaByoZT19Bst6Ft2SukaWpHCeYzFX02u2rpX4KKPaMcCK7OoyxCs3 42OMV6XHFEmnRHiipP6P36qP5L+bzRb5PXxfgw/fyYVt0ydyidHKIE3OMA5wWzkLnckkuSAaJcIS LvNvsKR28LG+4q80knebp+80XyNR+hEl25eu7zXbv17Sj+Lzir27ulytmUvpgXEEJsK8ejCk//5w cwsYfkc7pdINCiVUIkB4OAdmhyJKgoksJiq0nE4gXMOJFihUoCmIRJmghNvA/vCpjysyFsVvmGsR vNHDxiW+Hj6CE4pooHvT+9pXS220e+0HamOf42z+GZ4ijbVNIb+ofETVxpaZafUAbaz0g1S6TEEk SgQldO5qaWVJTOCKPC3wJWbfUkGkiPpLhEPLyLISL3LjQn9qr/KvvhYlko/N36+qxrVQQiUCJPcj 43Qobs4nHAjlquBSW8ZHpQccRFTyIOdiw4URKlODoO0SVVfThexHDsNWL46erefIwHCG549DCFuq M5S8Q8jL9R1Gi2yn1wc+ei6pafGH5IkcDVut77W0boFkQlDX4bbhRjGY4FBxeIYyXBXL1+nd6s/O Ny9wLb76Ytck4ONZFxkEbMWnrKMuuyIJkpvc9bLOHkeJ57NwAEZ2oXagpvw5zmk0G6C9se+T31z4 RJ4hX6ruNRtydKwMFu3qis9kR5ufwUbg/q9wt6c/CLLFqu2z2rHqA+0lz3HModkk6bNhSt0kLyKb Ud9r7ifrvRGZ/zzMNY3qHJ+IxrHAE75SxLEgEsWoafG7hMmK0ftzqHJQl+8E+aRWencwlgYLTzeJ oxe5Oflav8hBpPRmwRwcqOV6ju15zRYhn8IBIb8BsXyO2Vqs7DXbLByAuZA57eQQ7HCGCxU22Bg3 OsUTGZpwo10yDgeJ23LFKpZMieCEGekw63cqOY0bGNco3UDEr7TBaAYctAJqK8wF1H+ghuQ59jg2 2//f3ps2N44jCcPfn1+BqA9P2zu2ypLvniPW5aPas+2jLblnZzcmnqBFyOaURKp52OWeef/7iwRI ihQvAIQA2SYnptqWxUxkIpFIJPJAmShRLlXS5PEpgvvIyuQk8SLcnt1zLYDSF96pRK8itqy/R0Tw 9JrPmm+qS5AF9JGl+NNVNA0dlvrD7O2kLQ/Lzv6U09c+nk+tMbtioOX4OUsoqsOikTXNLrGUvo/h z1pF8FR/n6xFx3W2g6nHt0s1VR0oQPvIy/vSTUoNQiI288mSN6mZRdbjou/RogxhHEROLTAo/Msj /wrRaGQOKy54ekVDNWkGO/kZvAlxHjuNCXcX986p747Vh+dhjCIUGpmSO8HzkFj6wjvVgCtpO3KA 0C+3w/8igH6JLNu3QshxuX2CtoHDJ2cSov/Cr/Xx2xlYDcpRBNFH1psnNMLGGUdTy2c95Kxslrfn 5go+J/0ibn3P+uYEO5ydyZQheZ+rbXcVoRD9QyL9J1f5NXCSZgFdpbPAtdyaUmOFMHXrrW4pZNfB fRDRgwL+PvdZe1EIElOz5PjxqBHylQRSEBzR7IEWbrLpvTtck4Cb0fkdJy62DPVjzw2gYz37bQP3 HvkuD9qjQWTH0idti5GTTZeszU0xxb14veHdd6qPVxLPcARdSJuZDt9sULYLMB9Zk9LyIIuCGlyG SNU771SOVxJxcEzUwevswZtuw4m3LqM9806DRJcB/MiyXVWUCfbs5b08Uc+8V+IZE0ERkne6elZR Lm2ws+hlwLNyBk0xbcvAPvKqqQg7y1w5ZwPPhMqJtgT9YWdllygOyLJ/dvBL4+DKvvyx5dkJ0NXl l6S3/9z3IGYCylwHOAR17T38E0MN1zhQyY69r1DN1bUeaeASn3QrRKSRQWmAdSZsK1uDeeP0inXk qijMzMMbVTik2FLYk9RHYiGUlKcuC9ELko1mA+4vNsE2SMPdg7gRQ77RMKRjxe3bm9MDl8egAo1G +Uv3gWwTCiIKZP2E3hhK5ZJFRPcHWyhqMRU+JQg+tgrF6Bt+RVBTNkCfru6Ho09b7L/o+ob+fHf+ y/3l3fkZ/Dz86eTnn9Mf2Df4FKgyNBqZQ9Df3P8cjwh+Woz19Obq6vz6jA6X0HHy90+svvWnm9vR 5c31yc+fkuRLHvYoRaSRQblk5NBDD5ippbmP4WbXWl5+dxeng37/mG9ttwb+PtZ1YYtTHyO4C3Vr hqEfjcO4qh6oVGLv1FC2eLXJdVED92Nr3rxNSX4LElbZrOmAjzF69L1oHvzIs2DkIKoRSvVhfuR1 D6Gr1HwmaxzyPOJAaiJkAIxmIdBcdmZdltpo1OTMGmrUHm2WbaTq0ShduaFXtVsp5dIwaQWWs2c3 iBYOLidfrADfsCNObdkGZXOX6JErVjGtfOq08pOTIG45hK4ZvDLINZEJy5JmOtzzqI+N73rNqVwW vCsiK0Qa9y7yxAJ1OuNRC+kWVfuimp1IfWyq6LSJuFHey1bDs6XQPkHp9IfBSjYUeVW5vuqwkXG6 ln7jEjegi0Yw4QGNxyGnQGyNn+KDRpCYuuw/qYt2Ern0loIG9GyjhhiXhXWtEI9G9hRrYm2h07hg Yf56M9iieV207UvGbc3l31GHRc0moD48l7yOw3EPoTvvJUBjH9PYdSsKPdBCYzrJLJApCWi3Ma1A Zo3Hnm+z9HSuBc+JphoLfK5fmSHWPohMtv0CHhvIy3ceI1Y3Z5NM9Sv1Wz2myT0vznRKvv5MBo9m zvfYRcDFIlVINK7D3EjpIKFjXhSk6iJWLISHs2T6aZoAkDnDLOGeZykqRaSRQQ84FfdYtBfaIe0u CGN8zKSHBaHvjOEVPt6owmFMbjZ8uDlnNGwmM8q1fYnAeR/mxPKmsKc+iny3B1U6UeFs3azE6JtN HWWqwL6P+ZFbD4wpi0pVsZVBrTNiZVEfaEh/SW4HWMgJ/g7mB1/zA1U4tLIlrYIal6MOaAiCFTey haJSZIQ+HmN6J1z8Ph9jVGHRyJpkgHwXystf7tZaEkG3upXWFoNGlqT5mXXyP458HyyK0q6/PGxR h0Uja5Iy+ELrrfKlbt394gW3vjdxprhxQQBYO3MI5196CpBoZExS1XvOhhykUXaLvusibcEkwHVi OXSgelMsBiVCk9QeDz0081wnJCxNe/Txy6UKLBpZ81u8KpZ8XeAPS42hpOwVDxNk4HWieUb+dQI4 MJ1ac+vBoSxM5IYdcrOCE+cq4qy/jOdY0BqJRsY8kdHjIIy7Xy5idZ+xH1BnR6LrmBtxDFUzozn0 mOWSUwXg34fYFpwN6rN5wWUwSKQwvT6tISv7HperoQC0UymnsytrzLf/gOEQi//VySm/QmmNQiNT FqXcaS1YIlIP1AkfODamQWYuOZyF2KWLPy7H60zO3dDnyz9VAb8T2tPZkLr8S4RqZhEWk/8Hi5R9 orXzNwQioqsEkUYGsRLGkUszBZYac8aJFD5dehZNZyHWF/yZkWSFvJaCOiwaWQPOha10YsMgN7lb ceWuxbQGzsyB2hkLOn2Pr5i3Qjwa2QOqhvpfWBFfIsyQhsel1Rpe7RQWEQF2FG90QqTOroC9IKSr WuLQyBZoJQnphc8Wkf1UKzhQ9V6ZklKFw6CKimeU7v+J5sjPZTyFCbGyOqoVIs1KKqdksmW0uXVV M4T3obIKhzb1dW3g8LXLVJAzGRNJaraxsm9yHNtKwXZbCqzazLnqLLdYrTAkv0Qhph41GstH92fB c1s7DBpZkh6rxA5hnYWSm+zKs06xHID1+OjjRwg0EpOnVig0MiU1xtlW6HvT6XY0h5epSUGOP/iZ NoWhkWXeeBz5UFKPWlcuOcpPG+qYLu4HVSLSyKAgetjOZOjzkFrxSrf2CofESj/Zkze1s6kBYouv HQ6NbLEevCiMm8tvOD0oPuVb7iOR9C1EdIIThOAso3ninz2f6A787HhRMH2FTAKCaZOHL8qQqGCM YpktRYseHsfe1PP//OnRt14/IQo4BvC0MBWhlMb2lNW+CmbWdPqX4Jszn8eh1xDP8AjbP7HR6B// hGd/QXNoXdDf2UKAH+3/6TP5kEB+opBR+lMeh98Gx3EWh11Kr7z8JVEpIhEenULLKxuILozjnU7Z Hle369PY5IAmAPDwXCEancyBeAsaCBSGxGAujR8MiMKZk/HOfegJD0ntjjsnegpem3oWn7mlEI9G 9rAGKGRqxnHpQb71V/NatxJhidzPNazDlkiMrsJCNOJK1qAslm4FGl+BBT+a+rq64A3bQ+gOxxx8 cubJ/e9lemZCi+InNQRnITYVkhZF95E1KlVlQVwBlPzRdyZO7A3zs3yk/mQnV6kmn7NYt5aUIVEj 6CvpBbwkYbSw1dHB7j9ojeFnyEuDHDWLehbHnp/QTRPXSvPwT2KBtm3WvKB5cagcRbKsrIpRaBRR lvZItpDp1HuB0xTUp2XClFRRdGbzKc0HhGYGUM9zgn2fnfw5RVQZEo2MWZpsOym9RmjxfJtW72X+ NGKbxOkHcYok9RbT2yIe3qjEo5E9Ic3yp+LOe4lW+P772BoKGlB9wVW6MUNa5c9QIwAWEFTzqLO3 8y827OnlUN/p7KivFUheP4G+frBAx7SmXxx/x7KyWLgTve+6uyjfjRZ5lcmcpF7vLXi7eaLlx5CI g805Bg1ikSn8UMe1RR37svGyd7lenHqPcLJMy3OAnuXlei1PI9ERVr3YMEKNej+hN61YwqX9q996 H1pGjpfU7pkMyWn/G3N+pBYlomWAH7JmEUudsMmPzuSV/2ygAoNGlmRPLAGyZh4zFkUvDgXAfHQB XBjl+LsFsoCc6TQi6scK6d16EqORCUSHcinIc7klUAEKjUzJeL6pwf3iLRxxgmIoCOoji2L982/0 f6fhH//8Z9BQbtwdne4jPLPQErQBJvxhu/Cg7e2ST3PPH0SY0RKFCqYols5StEI32Pstbpf3djmv sFshOVzlHXZBKv7APst++Ic/ZEQo/wdO6VOBYg300r8rfs7/oY16EsNgliV0mtg/uZ+r/iDJF1k0 ZplD5uv0abtPf2I/D9inFX+QZI4sGsPM2Tj5PDq7OtmEwW0Mt0/jn6v+IMscSTRrsKy2M2K9nZX3 4h/aLCsJNLqY00jWeszW4rmAsoJk35acj2pAH5njJ0GS/RxgnDZUdILkULlF70ZiJ9PiJEm+QM15 bCO+6FeVeKTYU3BZr6STCPl7kse0dEwtOaJupSW2OJ2xNYxWPoQKp6lGEV2QVCEPCalWRaeRhHvo 57yjN+iJ8FMQ+TLfUi9zHG60jPsjK59Lt0QHkK+QV2fsDpZw38bfARykYYy9aGqDDrGC2P3F17BI JZ6PPF+wGiaXlFPJb6PXOUZlD0tTm/NmR7QE/cFnhTxw+qBxoLQxxZU1pqpqoz843Myw7vRk9Cvd Yn8W8/O1ga6dFbu5wS6ugclwjxbDpYNd/HGh5/m5ogiRdgbt5cadbJNk1MeF2bwv2Az87FGCRjtz 9lWMupk5StBoZ85B6ahju2pjsLO/WRz1KX/dZ2VIVDBG8RZQilbIk34g4eTuJ07uPqcnXR0Su5Ti thJIn4Wz9rDsw53FZ/xStwSDF7D2Jbg0pKOyD1UwgBewaQYcl32oggG8gHUxQFbxrHJGIBAhINoj c0qG4mNT6uyxpgHtpkwzmh0Xjci5fP7kua/I8+GXMVcvFUUoNDLlDoeR78YVnSEU+wTNweFIx5P/ K9rI9pEjx80XPJ2S//IwRiEajcyp6pvHWuRtohd69na9kHVTStwoW+ghCpt6maasUYZEI2OyuaF0 +GlCM4rHHSQ1bWFLpg1tc1Nd32s45Y1KPBrZw8ZabFgAWoCsfubSefCeE+0AsU5QWID85kygMjKZ f748cpWI3sfeUPCdr6T3aU7Iyh26se90aW42gs1sfy0nQGQ+oJIrnatg7M25G75VjyH166oYg8Z1 Qx2fSf4LZ1JJ2RvvVJLVN3Bk2SEDhH51/DCCWwfHH0cObym2vcYa2lVw38cMyUk5TdecYduJZkR0 cUD39ngXQ88xw8Yxw+I7L6g5SZYwrFXybZ6VoQ6LRtZY8/nUYZsaTfvLJatyKQQ+CO9TQeyvppnf HhRrdCYjHIQ0hYBXNzQVaiwB+bHVAs6yhG7L9N7IYp2g4hr3p1efabR8mrXB0hzocYBPLyhDo5E5 Tqy/5nhMDVfoQuq4k2mE3fGicSmEZFx+4dITUgDfqdpYTVuOPahN4Uzuxs8nLLtdSHk0VaGoBNyp kCXGiK5wfiWiCJFGBoHLRLkqkQb6TtXJagpG7/X2UZLSzKtE9huVSA7cx1YdmRoyyYE6oP5FFp5H 5hb7IM1BEhAJ1WV+ixyfrmkuL7AyJBoZEy9p5rKH8ZTWOqIFYMB/YoWZTxtyyFO+qMKhkS1jbxrN XDJ3MyeExOF0uuxFwFOAHvDU42sHIgPvnerPFRUK6+0vlQFJPJWpHmSbdqwdS2KAuL1Cy5hSzZtH ZXOgeqdzvJIaWcwqW/C3vNJIDdMT/xCtHdY82U0o08Iioig16jFn8pXVUrpcVK/+6nvRPA02dya3 1vgbDtmncbR6XkE3Co9qRBoZlO49dPMGD6EL1wXz+PIxc9PNOuAs+nETIxjR8pQ87FGIRiNz4tZt aUH+bRoY/B/kvy8OGZbP7mZ+x76Xp4xV7eS9IVaHRefCKk5YOl3xxJbRdROFCWFcq0oZFo2syU4Y D5Fl33+n+6L6ymmlm2BqphBDZekwWLNzVtfHgjq82UCOGq6VDSvZKDPDKhxSa7ZX8XFpkJ6FjZA+ 2eiWUg7HIR0iGU884BNGMfBdTlPG+GGOu8Vz6s24T/PNb2sk5c+5BxU+qX14qM2/IYlAjZJcSQHD fEYTPOeV5fPuLphSSfRNWcIIq+E693FAK4txLWaeMSSLGULqJfBrFMni8/BKzTKB3s+8MD64FlvK voNT6eXJ9QkAiGgtzKrEJ767QhUIPvYMDecY2xkGxlFrNN6M/impTV7sOsI5RSowGFUOI+rrhkGT wTK5cuIi7tYLeiCnmhfHDp/AontwwuAz1x6tEI1R5iSTl6r3zEmXTvHr7MEjR2ErFEhra4nAKENm 0TR05lO4M6CVEmGMi5byMHNoTn5mw5bcauRwfGxF9xPBnVVF6hWdCgxvRNGtWsOtx0rGjxbTtJxK SHIxy6IxyhzQt5x6SI4tEgiMMqSVQn+XmrpwPF5JsSRncvv0GsThThRgmmFUfkbGs3n4ioj+pb12 6Tm1btYkMCUnYfALb0+x+0gk9+Z0dD5Cw9Hd5fXXZazvY7rlFpIzObFnjst62VJwsEtY8JkTQBlq 5xknNwVF9ciz2tRg+NhzdEO0bIaBlIPjyPdp3SPyNysOLmw5UcrQfOzZugojlH2AjYHzO06urqeW /4iDEE18yIhmvcpZXT2+aWoPXyM7ik9Axcldkp2tfLCXNw5xyFdKXg0GoyyBGYwNcnc8jey4SV28 d8XTCjWZnrBlczYWUYflY6/mS/eGSgrf2lz+toqhKmZXKVqhGjaHEuVlduPyMru81eDVIbFLKW4n E+e+7/lBsrLuBAMX+CB89HV3735zvRf31vdCL5DicTOEj83jmygUUW6Fr2sd7E+nKX4KDraz0AuJ PbpwSbBNHZFjhRvEAdOxHcBHoRocGtlSfIrOq2Szh619TiMpA8EqNeqwGGUN7SMej40VTa43hORY I4vFKGtaGZaG7EUU66T7sRWEt98EtFjhDakhFxxsK6moEiuldMhMKS3UUW2RFdeB19L1KKYXJcew XGSFfwyd3lx/vSmpIkpB6CKqccimNNcV3K8Ia6/St7QOnWoDicFXv6dGAasvBITKnszNcoMevop1 YEJysgRq2NUOcaJ8Zw2IjeqTki1A0FctC9Mo2Tz6nipKOQ4IgzfKjHbbSbeTLO0kX3zPsoV3ktK3 9O8kEoOvfs+oVJcq6IdkmGU2sJz8y+Mxyh5Vyv6tK/iW2k8ez4fXk2dOMLZ8u8a7F4UPXuTaKUvp /SmfUmoP36j4vmAfSo1QArBNDqi3XhA4D1OIGrQCKDNh+ZirV1Nb2B9ZTIvPQwTVX1Dw5Pmh9Sir M6ugfHiVkLuIy/u1cms07igG5ax4IzXaQjcqdtkTlR3RsqGYEqPghFYO72OL4q3vzYiCjLwogJzk xMabWNOAN4CLC8T74PKy7+dgVTVeIet8UOrcAY5n6gOVVnHJp5nzZ3BX4a6qGMSBvMvvziy2Lr8b Hh5q829IIlCzxNXXY0UsTqTL71YpksWny+9ekRbr8rvXfIa6/O5G5QAytZSWCINfdXI3Bw6jbOFL Ruwyu7vMbsMqrsvsVqbiFrnIq1VzRTydqutU3cdRdYWTpfrS/Ij647rU6Le8s3Wp0es/R11q9Fua rS41unbf9/EYkzWfdnnISpDKBGl5PEbZA7P53KVJr+XKNp8mzT3Un04T9IsJr0jySxeKYBZhawRG 11l1kko2qGyFuTANaIwyJxNu15TdJ8cWCQTGGdJK4Xa6tKBLBVMaS16QGnDhXKy+5RJKFGQmmXAp Lkoko1FAQUsOoCGdsVPgb1iBt1BYXWR1XmNJZANWvKR14KAIpBIZVQ6+oHZX0gWt+LTPY0zVXw3b VpvQWBiBUd1STExp0IxyCkgajVHmJJkp7RVwHaSProglkukqXtKuiKXyAFUOvqCI1bfdQmUPvyL+ EqvBQqqfNkX8wDuCN6SI5bSQHA6jbMnkB7bXwg3AProizqUClvoA07Njmq8LLayfrGfO2w41OIwK 5APGbiYvUE4QK4AYJQzmYl6W46gonU8c/kdfj/mCm3mPj+Pmk3LpIhl7bmgRNFw5+mowGBVZlo2H 5j5+xm5Iy60+4Rm7I3zA8DuxQogu8VkKhIzUSqEwypTQQ0+EIDKJU+sVyyc/VoFRQZzihViKVqhA 8JFE7d79uHbv3jFngeBWSA5XWyC4q8iyZhVZuMsG80H42Hvpcp0L8dLMPBA+PI9z5oQUjxshfGwe F9PlwXAmWwi4QS4XedRXl184eS4D8X3MQcF1pr4Zc5ITz5ONn1wXzwtZ8TVsqMVTkXkfNSL6yGuM pjEH0XxOzqI0njBJUo7D6ELIL01TSO/naQLp8SaaRQG/M0QpIjULYCXt1ixyZvR9HMw91wZ7N8mH ZsfNrGDWRlHILAt57MshFObXCnk5FhYWVeVMvmKXnDqnly4Z/YxGc3/1vWhOA7DYN27pyZ19yh/f pRCNRuYsbVWLbClIwXfnEbRXmr5mlpkV0uGfXo2GlBZy7uLhjko8GtnjRSGMLQ72H3sRjC9A28zq +g/yw4szncapeMziypLGwxlFKPQzpWrCkumK57WMsEv3PwRYowaRRgaVTBkPuTWv6Rp84zBbDaiw c6rvo1C6GaZ2Xq+fFFTh2EHjzSt5Y7GHoXy5JTTC/sxxqY6v4V/ZAJP9MjPAXvMI0122zQg1SFTJ NXQpp4evQShSMgvlnlLWMJBdIazMGbgrhAUPD7X5NyQRaJ3b0qJSSQ0rdF8ww/lLV+WuvZQg0ciY 4tPVp1qRcuEvH5UKCj2Tc7rb2sP/2PNTUztqZn13ZlFaR4V8Rk6kj09gUW9Akdq59Tr1LE4doQ6P UTWxGNtmxtdEFj49uadRYHL6QxC4CkYoltVStEL3xscSV7oHSc/XPc5741ZIBqu8Ny4+L09QNz2x 6JNFQgN9IHhk4jxGPpESMnq6jpzfJeMy5PEYXZALo2KxeiSXXy2oj71L1JTfUrpLqMPT7RLrwIhR ZuIyE0bs/7E1HUdTC4YObgwY+9gKJHWXNBqjzOk0u7hmR+jehbpkbDLJBHsP/8TjEGiRY44sFqOs 2eh/7qOdnR34/yb6D3TJzGtJhdIE7X1sfQUX80o6RXYF3964pdMVfFv/OeoKvlUyp/jQC2EfT6Zk A2MhCCw/aDFquCilhlFsGPBwRyUeo+yJXBv7yxOH0NAjAgAXylMMCY6emw5bjjvSaIwy58kiViKa k33GIYY0GIsumV2nkPUIX5TjiwwGoyxZjFDS2ioB8LG1eVcQslbgarta5ys1ygmkBAKjDInLUbKJ fOao0ijHFmk0ZjU2K6K2iAPLus4yezBbFt5EjjeyWIyyZtn8KN+T5RgiBvtj6/t3USZ0I4hmm/W1 PDnjX9VhkWLNslvkUH0TRVT2wGrhik8vWVI1bBVCWRWUXoPSqAbLnhxqaz11RVm7oqxdUdYV7Fxr UpT1cEVtMMtqoi5Xk5EszVrDsFYj4K/NuhaLMjEUi7dxXNsbhwnKA7nbxd7ALtZCa3d1uPJqu6tM Kz/4wt6zkkZZxScT+sO1BaUUJ0kvzYX9VKBPi9M2oNcgOHXkLB0Za45fS6lD6o5fjUOoyl7qNrI3 upHROlcKtrNyOB99U+uq/MoPvrCpraTLRfER3dRSis1sag8N6LtNrdvUeJavQjTGN7XudKaSx3IV jLfia/rV1kkuw6Jmt9HU3CNfFLlZS9Zeg0gqSM4x8F3FrIUSUHJhvJ6Rgl296vXSjMVq0ss6a1VV q+XwGBXfrnZ1yfMWaldLE3dbqkzAxLo4HbLJkqRXBPJHV1L37jfXe3FvfS/0glLlQSMriSXvhE+Q nRKxF2JdwqujFKExuxpf5+zAgwNM0+9AolpzRyUeFexRLL+laIVqCvR3JPL9j+J8//4uZ1GBdlj6 eqsKdDXR1avCruJ/V/H/XUt3V/F/9TzuKv5zDqjgVFPfqHFRfJOr3nyxpjXKV9sMuAtZVmGuqkDf iLoreJlZZl3BS3h4qM2/IYlA69x2BS9LGVN8uoKXK1IuXcHLtZ6fmkKUAf1TUsehuKlyzpAKDEZV A4gUqzVPBsvEKs7x9K0X9GC59otjh09yOkMQuFFGEBvqwQmDz7I1ROQgfuz1WVMCUNH6VIGhW59r sj5n+NFSv0a5oL6PdVo4R6vv2gY87eqivW213NVFW/856uqivaXZ6uoe1e7tXd2jpaere1TDnFaF Dj5CkQPFYyhFKxaU0ZcIlziOwyUGO7xBGW2w9I9WFpShde65t6TlKCvx+0ceCO9yffEbaVEoUv+q 8HWtg6XxHZnaVGVhd3FRqpLtlI9CNTiM7j7V2UyZfJ8V5kzVYzHKmmw6V1PZJHmjRRaLUdZ0NotC nSpYmansDakhF9xnK+n5HmvJTGUk0JJyRZnEFLXkGBrKMnWK/E0rckmdVQriw2suiQo/VW9pHTrV BlLliZQOv6CA1bcOR2VP5tawqTJRrAMTksu0YA3r2g0irU8kMAijeqbgipNUNtVwjJLHo+9V6Fp5 PB9eIXdJHGuxUkp1W1qRRlCJ1qwUeTydnuz05AfWk7lknlKvXRTmqwbQS0Y+pdQevlHxfYGWm2nZ k15FRrmcyIrBNsoGNYVDuvIgFSswl+qV98bklgQae9HURtAmmTd6oC10o2KXdS/ZESiOuHSHpAA2 w/vYonjrezOijyIvCiDbLDGpJtY04A0q4gLxPrhc8Fio70Sb5A/u8uQtVpTcqmFCLZaqHMUGNB95 BdH8sUUv96TFfXxfBdU8ikk9p+xLG4Od/U00iwKuUiFKEWlkEJTgQxbZaHwfB3PPtSGKQyR3jQvA +1QvRyvp6AT2QHZ5i1UUjEWQ3s4265kmdI3FA8vQaZReZ/IVu9i3ppcuGfuMxsd+9b1oTm+qQ0ra LbWo2KfxcrxMk7l5JFwZEo2Mubr8kmkiCKmk7jyCNrjT14U/AtrjwkhPr0ZDSgsUkCRHP/JNHr6o wqGRLXHgNDGrYXwB2mb2+H+QH14cMjA/E1SF0NnN6fBySIZOz31ghvOwRRUOjWzx8W+R45Nti5jf 8YpGU++RNg4udL3h2hXkIL7TbUJ9T6nSPSE1Gnv9pBY2x0ayVD37NNHs+SoXaIT9meNS3VfDvbLh JXtIZni95vFVVfcWGJ8GaSq5QSzl8vA1CEWqlKDcU8oYBrKrPpKxBbrqI/DwUJt/QxKB1rnlLAyS nLuc1dUeqUehkSnFp6s8siLFIl4ZJN6nED3cc3rqlKH52LMlXiUkXtKc09QevlElAVLV1ThAECy6 XDFERA5k4H3sdSleHURsXbaH363LNVmXJVVCWq9NDpjvY30W/A8r6Sva1R154+q4qzuy/nPU1R15 S7PV1R2p3dezHR3raoIkhTJ4mKIOi1HWwEw+c1QEaZfZKovlY6/qSzeTQo8q4mXZN5Zlj29ZK0Bg VHirky67xqbZuPem9Hk5tkggMM6QVlqsU1AFBSWYol/ygtYBQ8dxwSGXviI16MLpWFODctDqcmUF BHYVyQE01BTodp03vOu00LJdXlZezUqk5Fe8pF3dSlUTUDn4gtrV1KlbQTGBRP3VsG3FlQSWR2BU txTTWhs0o5wCkkZjlDlJXiuoT9rQt6Uabob30ZWyRFp+xUvalbJURQGVgy8oZfWd3lDZw6+Uv8Qq sVA0QJtSfuAdwRtSynK6SA6HUbZkKg20N4kbgH10RZwrKlDqxEzPkckSCp+skCaQ8Sk/NTiMCuQD xm6mwoCcIFYAMUoYzMW8tLe/mkoF4vA/+nrMFRlY8v44br68B10kY88NLYKGO1y6PQajIssKDaC5 j5+xG9Lq5U94hia+NyNLDH4nVgjRJT4E3MpJrRQKo0wJPfRECCKTSI8b0nUdqsCoIE7xQixFK1Zx fyBeC3/Qj2vh7w14K+63wbJ7uLKK+6UCIFrgng/Cx9bpXQW9Naug10m3WunOmffiLTJ4IHx4HueM NikeN0J4HzwuOMfUt29MUqL3gLOLROgkDOtnMJ1qiFyGUl4sqDTXuhTFR14bcHqpZFCuzAmqrAfC s4JU4tHIHs5KJyhbEyQtATL3vWfH5iu2ohSRmnW/kr4TZKFaj48+frRCjJ4d/AI0xvHViVxMvRc4 QJGz47TcO37mvbj58giEfc0Koy36RLXYdeg1COeCHK7SFqmc1B5qK4BW1aMoAfqR1WhXhIE9PNTm 35BEoHVu6yskLO6owdcVvq6gCAMnCo1MKT5dEYYVKRb+6ghX1phKyUZ/cLiC4gvl4D/27FQURRA4 WfJAeJc8VjyGUrRi7uxdCUfzIGkge8jrzm6Fpf/BGshWFDcQWF88ED62DlvOr4w51N/f2eHkMQ+E j83jJNmNj5/L39a75E7zmXll4SY04qlV9p8qLBpZU3wyObYhJCFDCWxamnw+h5BV6FhNtp92V8py OD76ajOUGlZwoq2kd6CTzwtD2rOshAbwprOsuoW9Zgu7S0ZSqJ3U9wlBZU+XjKRaP5UU+ajRIXL6 SQ6HUba00sedos0p2i7BSJ2iPV5Jx5Ti0yUYdYq2U7RvTNF2CUQcAtclEEnS3CUQia7HLoGoQWS7 BKKSp0sgYmjFblz3JO5Cd+O70P4u741rGywHevOHHBfetNuXi6sB9NEV/L37zfVe3FswqIMl9Utr yAboxQmfIBQpYl+NtTHtZ8p5JaoMjVGtxgKNg6XzXK4CTfaoIieqkkiMMqbUSd9abFTi+dir/CYK c9Vly4487GZ5a3H0oeYF5TjfGleERCtjaGZhZtTLokUTETLd6YvVT/h4ow7Phxdkwbvssjekhlzw Yqpv6LkQlcxlsvRltuhSlhxE/YX2uiz14rOapa4Sz4df6hJXxFVv6d9VpO63lQ6/oLFW0gKo+HQX 3Kp11UJ18qoTOV0lj8coe9qq6E71FlRvV2JkLSS7VJE9yFxT14i/JJJOI3Ya8QNpxNylcalvIwrz l1W09xaf+mkPXwU7FE9JKVqxG5F9ibuKvaTY2QHvjYg6LHYpzS1X9jD0fIITclO5V3PJO6YU0sXd zRUaXl/dPg+2R6fpx9vb6H/vLk4H+4fH/+AmSwKmbrJvvvz1/HS0/fXu5v52i5uw0rc+ss6lz9XN 2f3P59unN1e3P1+eXJ+ec/Oz8s11WAWnN9cX8cepxB7ttFsFDTB1kx3XcNhaVOuhv9/4/4N9j5tQ LihGZ/TyYvvq8kv244T7Rwe7kjPKB1M32ZcuDuP2y7Cr8Ku2qhcNEiAz9lbDLrjiVt9vjInS9flo ++Ts7O58OGRCFYtSqTtud3Acu8P6daLbHmHifdvb2Skg1C4WJ9cnrPAHv1QUXlEjFKvvhsTmKB0+ zNAfZWd6CUrZ/CI2/fDVf8QTrXuaGyfVgNxBDZnLyZXzkJgpl2fn16PL0d95JLDxZTWyuLomMD+f DEfb97dnJ6PzM/j904BogTJ1tNfvDwb9w52d//kEYnTtPWN6Fob6H+SdvSWJapbfRsyJ3O7vHA0O do4TzCfRYxSEaHBA8e4bkuSEipu7ryfXl/9zMrq8uaZUXJ6PLtDl7enZNfqb53+DwystmPiJR5wk Qeommpi3oxNyQLq8vrjhJqvsJd0Dp+xMfjiznh0b3VmTMBLzR9ZCMEESuvWC0Jr+iEbYt149l9bo i+DuHwqUCjpb+WAZITN5dvd2YHj+K7rwvqMz33nGW2gYOSEmKmEgRq4YTKNk34Sh9WKhGze0fIf/ 3MYBwyhZp5Zr2ZYcOfl3zay9J8/FPyL0hz466O+i/eMB6u/sDxD+HvYGA0Fp5ARmhNDz7ZnlEMVg g9br+VTr/WfItERv7M3EKOWFZlQ0z+3I8m2PiBn515WU0QogKgiroKVxnBVjKEUrdkdwIOG9308q yHG3XVGHxS6lWakMxYKOe2MmAP85hsygqfUQgJz/ceY8BPmPJMVMGo+uJSYrlnrWfJWVLTYbTVCM kBYXrUdwqxkFAbHjfkTOfGy7/+ngcNLz/EcxIvnhGSF3GD0EY995IBvpUxjOf/z8+eXlpZcM7TMs k5nlfp46Qei4E+8zHboYB1qhMMKUE3/8RGzaH9GEDpf8uxgu/EC1x7bFviXDkhYIjDDk1Nsm24Xj Bz+iO4f85NtkxUau/bqV/P7/2O9MaYLChAgccQWtAJERBmWev2LL3b7wLXfsOQG6iqbkbPTPSW9G fshvKfxejvYodDPl7Hx4end5C24ZbipL3jExl5+yeWxwEXDl2YSxtITH2c3p8HKIBr0dRLg7nzqW G6I7yxY8YbZDIcWUgptUfTugLIXowse/Rdgdv6KNu4vNTJ8J8mNcDb88sNqz8SxAG6dXm6JNQeSR J95Titx0M5DFEzcNgEGBu2XmuNSvVM644WsQxpwbDaGsu6CLmR9jwi2GcRmTriXbuODULpeVdNHJ MN6bv9Jxk/nbZMX7QWhdHKKhNyYmARHlytuGeAY2445ConMugTq9bqhAbUJvo2fsg3nNui05tMcS mjHFSn6D0zD86e7iFP03ef6IAixY1aIFAiMMgd0FRuOEAZ5O6O4yiaZTNMWPEJ/phQ70/RE0QwSB vlN1sJJ6wPS5O//1chjfZsHTdMkYr0C48eNf+I1Ilu4TS5Dolui3bFHe4WdnoTkwc3zcXWQVSN70 Ewt+bwHfiF6i1m+iTOfRAzn5P2EbWUGqOwWD/wUAmiM4Mxl+Ml+OO55GNrFLrZnnPiKPTB45+koQ Lw5cjR5cceXh+wDc0VBOizU4IobI/iaIcm02edzjDv3sPTpjsimBp9vFU1HDiA/5chZ5E3IjAnhi 204YK4hF20OaCJR0BERR6Eyd36m9LyaAksCNMGLsRWDcipb1KrymYvX0d1ZcTjaZGCKFw5DwPiC2 GbFTcdXyqeoNWcesFngbe1LqVNpldHBxKV7fUNtv4jxGPjswRwHcZljkZc91yY+CHOTikxhmI8tt hmGQTjATXG/F90ypTWJGwN4adzamZpSLX7JeOrrtyqlNGeBGGGGFoe88RGF979kSIkteVKM6V1LD ZvGcR763Hc9DZk+jqglaCpfrhmfotUgPvzLONzGciVaIcer3wsUkNBNZFWC9eE7sf0ZBSDvlQmQC GO2Dg8MdZOOJ49KtJEAPVkBTld80oYm/H2x0stAfIwfqn7rERqfp2snZ7U3TeEM2ehb/SE3AK8sl ZjTMLToh8ow2bm6Hm4Ulolur0ajsECfShonB4vn8B6/61w0QsxgFjMnH8yk0lIeTLysySP2V8CWW lS1CqCRoA0w4o2qYDcgl0yNCZdW7ushoHKspvqauwk/94+PjnaP+8c5Og7Mxz9wmALoJesuOxEvY Dcmx6lfm69oqOrtg3xT0HgoCNUE4XEk6E4eM6OEVXTnfMDlY/tV7cqm5MHG+Q4mThylcf5IN1Q2T rwrxoSUOI2wBg2Hi+LTWTRAk7l+wMGxvTDR2j2zHExTM8dhhlzMC2a9tERhhCMsxu7PcR3L0vcPB nNog7NPTWRhcUouFSDm94yTQ0Qv2Ba8B2+FQwRbFe0gpWrFQ5kOJIOOjOMj4mDeSWRkSu5RiSfmT 5foqF0Saannz8E88hjqorEwHYimXF5fnd+jHH/+M/pVJyuyj/49nHbQErZ0JX8i5MRlq40iTLwrx oi0G7Sw5naVzxz/ggQhL2mIwwJIwEJ7DXTGWtMOgkSXb2zxkLb6ldWjoy8nwHNFyQ3yjLHmh4+Va 7lpaeFXwJK+ktjARO4ikm3jTqfdCzRQaWQlRv7P5lLrDWOHFB4+6UHAu9LLUuZwJia1hk6IhaJz9 3IhpacolbnCGvi5FvsaBEQnRvCwTGkB5JGwFZr1a0scWTO70ld4qUYquuPwCTe92unMtdSczHc7S a6NTdjk8okIY1+gb/f2Wqw6dKCyNZNJn+Pfr0cl/xz+f/3J/fn16jm4u0Fn5uM/d0Od3BbUBrpsR Vyf/vX1yeno+HCLwvWxb4zFmLSK5yW0GoX12Ryej+yH7eRz5Ptmn+Cev+l3dZLz5DCi2f9mY5W6y XKXFdX4+2IubwnbgTTAjDeBDG5M0reiBmAnBpmjoPA8kFSQq3rZK0Yq5B49aeO52uftDqsNil9Ks QpoWqWlpZVA0BPf5JK4ahIa323cXl8+D3s725c7h9s5ef9DfEXTbt8ViZKFR+yJAB9v9gy1qh5Of DkXXWAMQ3YRl/TpZPyGng5EXhi6yZFWIAcuXGmaKLN9KWLrFKWucKrd2Owu3s3A/ioV74iJMF/Xc 954dmiSDoAAJ2J0ZKxT8HxaCiGrBDuhtEEgxpODWXHGd5lJH3FnsAVsEr8Ymr2gGQamXzW6EbkKU UDrTTtwPkZ1s8Hcy22yCsTV+Qs6E7SJxz18haWqJwwhb4qQpeo4bB9SduthaNvqDI+HjkwhE3SRf Xp+d/zex0uK6/wLWXeWbuknImpkVvj9Zq7UZnC5iG4dvgPt1dhdlY+qG/BcP9yXAmVAQC8mIB3hp o/wDR9dH7O8OxA6/MoDXggGLQ3vlOOUYwAF4LRjwN8cm+1bmUcUADsBrwYCrNNsrGef16Pzr+V1L 8hvBqiBescItRSvmdDyWcAcex+7AQ16fozIkdinFq5CyW+8F+9lvjIht+WR/mf3aUs44AK/FMjsh /3zPfkPNMmsEuxbEZ/rrsW/INOmThqybBfz2ameKls0psZ2kXai1IHQLQtbRme7+aGOn1xvs729y SwkfGN3EZV2cELyzDcE73DTVvq19njrfaFvfaMEVuNruXJ9GNeFycWheVUDjaJhW+UySqsZNpRQk h5CHH2cyaRSPMjdnnE61CHRIa3qABy/x9YGl6YyJBe+TpXoqxhkx2OtTemUxkApX8+UkERzgYPp1 CG8Fkrfoxx69KSVKDdrEi5Z/KvVBO+Jo6UczL9Cpi8roSYaRqEYAEQF/Lyul8PKMN3J28QhCR5H7 zQXOGeZOMgy2LJZm0GLUwHrdqfVal/OdF6DuTarWRcv8hco8vgVwuohtHL4B7td46Npa27WQdAtY tbXc30keFbZ3CTTdpN5fX45i0xN9eiJ7xe/8t1s17+omo3AWePEdgUIa9a9rF7/uLGE+khijMWQa +SXG7iIKlrzujR0LEpLAOuUmUwEOE2xhNkESvRDnC8UmwoszncZ2AqUlsafCyBWo26MEixHWpBPG bEcLwSlxEUVzeYG8KJxHYc5SE+NLKxRGmJKdrp0tYqxOcRCw0dGxO7SzxdgjRpY3XTrb8vGkDQYp lhS8FKvr20yfiQP1SDOaofRYeXeB4gNeVkiGGLP8hFSF1DCXCzkfdCOylnSdGacHWRakxlI15on3 BMDaKR0OFuyc2xaLIbVthWhmvaIHjMCyCbELd30ZLSHeTYEfom6S784vzu8gUISbpMIbJmbp05kV Wts3z9jfZi7BIfafnTGuSoWAVmPiHZxaIjEivl3uSSVrhmSlwdAOervkf4KLuOJl3YRw+F84i7hI gNNFbOPwDXC/It6orSunEopuwapxvBwodOIsw1JBpmIpKkUrFJU02BEPGNrdjQOGjjijktQhsUsp VihPLFo1Kaqf1S5SItUMTvfi6TKYOs+a4mHD8+nn+mSiReuVhQPowhNzILXEYYIt2d4J4LcIIAm4 IXdGiCdtEBhhSFliUFkqzZLOFGNKSyRGGEPbOQm2s8i/Y2TYF4tGbv3edyKDn6kY0lz3nGzmJVOM zpZIjDCGPy9uIZliXGmDQYolBR/pips2F9ZpReBWf3BcbOHA6QptwJEE2jAcb7oRRmYRpbsFCl88 9hKrcZNpTT0m4B7wm6aY9mvBdlw2LlksP741mt70HCDkoXRp3T69BrQLYeqKC36kVSFD30p7tDEZ feNEo3ijGg0XVmkmPI+pY6JT0gKP74Rq0CwxdfQuwfIxmkTumM1tj0w8a/yJXjzfDrbePL0ZhUnp 9fHcxwGGzlHpvPt4jB1oBxuHur55oslXoJvvUoDuGycKDCaH7YLzRE1lZhcEGX+fe9D1i96Ive2t EZ7ZohXWQjXFPZSw46Ox5xNZnnuuTfs2vvWVOhmG1vgbenKwb/njp1eqel2P6Ch75rjEfoY2Yc94 +orGZNnSa+/OTtA3RRkzYYRnc49M0mvOTjhBE4fsI2QniYL3s28kwpYuPDSPfFAzoIjICnXmNFf6 HSxASpvlk/MjtC6mfrxSTbv4zpsn2ZtMAC/VNIDYJjMNP0RwvvLcgCgdejM99x3azu7NExzNKYkW OWn5jzgsmd83Zyi8+TmhcZZpB2P0hKdz2kMMNr2Z8ztGQRwrYjuBH81ZuttbX3i+8wgJd0SvOi4K nDCKW4C+kLMHyOej70XznMfjzdOc0a2xigGb1XFTRRMy3yA7f72DY8jwfIS8tLsrnC0JlZa9Beon tSAeoskEQojfOK0bC4pSid2EKNg4TJgeSixorUH3WXA8vH2DwVtsmgXjgW6sxvv2vrM6a0v3Ye2q rDUB00Vo4+ANcL46LkS6wpoAMN0iBk8iE4sqHGVPqwpb4sDXgBGFYmhVY5VhBDfwNWBEoSha1Vhl GMENfA0YsSiPdut7E2caVy+6J1bco4vtlpzgh74GrBhOvXAIR5T8o4gV/NDXgBWj7yNyWnMfbyaT gBysawYrwwp+6CpYoXijLkUrFgXblwhQPYwDVPvcYbBtsOz19TQEscL0AEFOGjbkSCR3WxYcNua+ g0M4hli2NQd/OWTpCUTHqkBiYjlmPCgOdZ88YBQF2C5NmAPn3sTzZ5BPJsaZtliMsCaTMUcT7GFg 7DqfhWhNiW4J41O6YC6LFGjdTOgy06pnsMtMq5TtN52ZdtTb7e2xlkbHvT3ZFLUqKLpJq/FbxJWC dtR4QYrQdJHaOHoDvF82yMf2zDoZw4Z/6kHpA6mUNSFwUsQW4mAPVxYHm0kmWhjjFWGwO+jf6GCv 14PWE8LBsByI0ljYnX8DmoODfx8c9XqHO/8+HPz7kHxwePTvo51e72jw7yPy29HRm3dALz3/PibU HR/8+/iIlnj6d39nQP4PDN85ID+8P3r7fciD7BMq+1SsCJVF0dKtqjPZZ7SkE4uf4FEPHK/rJiaT fNYib61LW5M2gU/m8ymxtsAwhTPG8PTs6iStCBm+ziEg0J2+iuXlCEM1QTq6jmYPrEaVRfdIcrQi myQ5ad7FVSF/x74nnpAmDNYM8Z67XTItPfhLGMcuT/GjJZh4JgzWCPHPLDxg4nuzxGBAV/fDEXgb XELB3HdmWNSkFwSqm/DujF6jr7ozepVUr8MZvYIbjYRUjKEUrZi7fCDhyE66zOzxesvbIBkcd+2z 16aE0aDXly9hlHtZNyHNjpx9pW6h/c4tVOLHOZ16Lr4Au6KdP6gWjm7RWi48RFc1DQW78f+HWMjc UsULSDeBhdrL8gf1NTupdyVmjOwon0C6XTvO544CDMHcbi7YN0m55CZNEq4U+QWv8dFqqyf43ktS CSNIs4xKPccsP54386jZl8yJPvFDQi5Cgo7lyrA0khhvLiFIm/iVkZQJQK7iYzLmTGpToSqRICNL eeZNRDCZWK7oDk+wH+fKZuvoBkkJnuxVTWiFEb3RF1q6LXEYYcvSqO5ZxhQsQRuHljMNWDVrFto/ xnbkYzHvYysMuljSSJHROcqWpoca45YT901KovWfk3Y5VG3G609sltrhMMKWRUUDottfnmCryKhE yDZiEUuW/c8oIOpeUG6lwb8PoS3YB8ertQ/u5+SAHeAwpH4VkMbSTY2JaFKpgwrjM3P11tarksCY 7m1sUcRavbAcrMxieMMXrsuJh3nOVlhKT0l5+gBNIafPJusBcr6o1/2t16RIZtqHTR27ZGeii37s zZ2k6AYRGWpTrnMNJ6Tq0a3ecsirMkkEXZeNYNaBOJod0o6wPIh1IKqQ6NGOwGpw60BsksrRjsYC lHUg7c5yH8l++cUaf/MmUMPGD9tRWQdw/Qg+d22V5GbBrQOxo+/qJrYC1lqR2Xo6SyGthQpaijZt qYqqoK0NqXRYt9gHpamA1lJwa0PsBRxDFWww5bDWhsyfPHrLPsS45SqthLYWyuh1jrfEfY1NUKRI Wz7093dWX1I5Q8Stj89/O3dp0E/N1QA5doFPBk5jc4/56ZOulTJXA9WD0CgmZcfShOrcaGk/ymwp RACchrrBX4E3mUPrwytlmRxv2jzryL24a1zi5EDDrPtn4emxaIwgLWMOhYpA6pLbN0EGyiPQx7bc gDN1YuNu7C7Cvk9GWMrdF99zH3+l3ezlJIwTX+Ki+WGB8AcDxdvqnfM0wDT2nme72Ccxxgp888Io 1OwD/dXuA6kQlMoYUWjxTNcn7PJDTqQJ0yq7ReC6Jak5FutAaWTXQRfZBdwqv5psF9ZVDUS3UGVD sUZ+FD5RrcktRfWv6yami9/ieVc3GW85fgvdx8XT59iHuhXUdg59yw0mccJQfLFbEvHDtW+3wmCC JYsjRDHWjJ4q4jvQQoSPEFtaYzHCGhhYUhsmPlPhZdW/iOiNjxlguglWXGmPRwV7FO/hpWjFcjx2 xdMv9nbi9IsD3hyPNkh29/TkePyQLaHLzkHIYVE5RXXCzgeCzefbYDCyNsERBJ0ToGu+FULnT1a+ flFfWDD0RwCgEYLviAGz7FSwpi/WaxCfotEPE2sakBOyYKKLBGDdDGg+3BwqPSoddkelklNOHL3a siJKJRDdQpU969x5L2xg3EJU+7ZuUrqDUndQanDmDVbqzPuUdVdWhXE+Yhf7xJJi9ePduGJ82uCR VhmMGyXWia4o+jSm052+lqFimSGQ6kkjO9fFJ18xqvyxqSkHJJNSI8bRGjQJPzOXb1k8izMuGBVj pvUN87JsSNWNgDhOuA2pOeXwUsyVbulXc61pcqSUDjTjmee/9tGtexsVre4B5fhKTuxE60CLDBBE HxO5cMZxJdH5nCjGJMKYqbIfG6lRAl3NBrO72tuifq9cGpOeiXHvssU2AEWk4dKVBjBt9DfhgCd3 W7mMOlmxJa1kibVLD5HkK6Hlhk4mhRBUpAlDkfuanDz4O9mXgzR5Le5dXNYhLe3dI75ZU0rK+Mn6 g+cu6w3rweWRJnxbtM67uvyC7i5O0eDoYLeXNvBMck0fXuUkblAhcSVdCRGOcdI8hRgvmDrgRxye j9Jp0pmFX8HLVPzLucpGb7n23ywn3NinK5YFtfiQhxFkTTMZrqIKuVsMa3kEBjvF8SxXx43rm5Et OWA2baGB31pszSJEjcHRnTGm1tLW4Fm0CYEnKGDSRW+BaOFwdh2Sbk2LNVoOgewol25cEGtjwF9Y dU1nmGYBE+PEe904oA3EYMecY3/mhCylck1tyxwRRNs7kxNo2xvrjvSG67J0cwA6YYXWkFVi0rXF IsWagmm3t1rTDtE+a6H1DSovlK+AtC9v7EVMu69J7wRVGJNNofr0lnRUXdyXrPEusddDC6Mhv18k lREToyEKRAptNOdSkoca5Wc3p8PLIbGivy9aJWauOx2XSe/B4c6ab7eMUSeV1gGn8O336EmN2mhz LwjoVVO8RcSXjqXMzZX2KP1GlX2kj4+tCE3TvScVdGY8EKuUWidnW6c+Q9YNZbFz6bwObCOmaMPp 4R5aMiI2YRsmn8Ht3+vG7jobFcsEVk7EmpoKB1kdnMjtQgW7+Bn7oIgfiWp26eYeiN1FKcFihDXk Sa1gwfv60leliCjYO/vK7Z1mCc0RVqqmDrMTnJz66dxe34zAfgZrBPpa+dhxyTGDjOt3utma21XV 6OO4/szMcq1HItPBKzG6ZqbyABqFVK0oHqzW9C4/sCY7HuG4bYUeEbe0ShO9NFvcpVTZ60FcGjaB xJEDwb0OvtByI2QTsOTHmcBaXPWsg8FUf/RJzh9OsFx6hPeCKjnSlLJiYfWYq2ySG26/h07pNpa7 /qwyCBfuaN+LHp9gxofXV7e0Q3tsIwoxiwN7kXM5e7FkJIY5ikrOMFVSF6QXF+SPSwWQojBwbCzn +adzUTKMUs6ehOxKZ+4RHi/foKyDjJInPdOSheXTQ028X6X7VBOLuDZBHxMRDNEPicn+AzjE48PU c1kqniGODHqQ/lgfwVwqcRMHT+2MJzRcFN5SxMIrakD4sEqd8BX8ZIGIjOtjqPiqqhTCUsbEllRC /JKgri2dwqKVr+ZWL1saqC49/jyXlVgsLz8IhascXzC3oBUKKaYUbNjVtaZLHmbozcjC5lC3dS+X qpFryE/JRBYwVRxQXZy6VH4wdB7JkbLbQyeUGjbVS/H68d4Lf3LxC1d2e/mVRAscppYZBC0hdO4G cDawprnorySz2saBAzfNzxL5E61QmGLKAyanJMwOTdiO817IXjBHe+LOGB5gRgjd66E4P7eg/x5e M7VAk9gTMcploZua8/LMZdgT/UjOC8cN0QjJ+z10Ri1MOgeLkxxNOpQ4K5bwoBUKNVvsiuv4k0fI 3V7zcrmFdgkBs0v2ue1hFhpgp8xdm0Nf6QlGiXe25RknzI3hFVkT2Jtzqmnhrsj1ONDPVK7brMVl YNYHXO50ZOeYT2o5urizhgGk7SToMMgpcRHjlx2gAWYKL8pS6hkPwbdQvKHfPzzusbo0Qa7zFyzU t37HwPQMxLsSRRSfgmwyyXTzdmYYVrDj2VspJ946wUH0+IhBI7k20wgEOZwR99HMcaMQB1sgzz4z 6kDebTjlvHWqaffTWXafATWdLdWQMdpNq0c1JCdR3HFJOBRaSWqz4zJ+MNGmDoK4P6rRk2xzeu6R 0mTfoy7ZF7hVU5axXcZvAyTd4tVVSOJ/X/vcdIm/xrvRM7/e6dVouJWkFJCdkq5eCNx2Avrj3Mfb xEpKTzEIDjKcpCrCY4I9dMyFiGAfk2EGROAK2yzLAxuLts9qi8UIa9IZ3cp5y6FwL2gWGgYK1iax Kae0fUwoWiepDQYjLInvZ4llVZBjK8hNqMOOl3fXX7fvhreC4tIajRHm3C6P1QlYTL2N4ezFdIEN LhM26VCPyBJjTCsURpgSzwyLnC/MJjmPWOiJzOkDxi6Z2DF2nun4xdjSEokUYwouyxW3Fptii5xu PaIVUeDAvzDDU/hsZo1jJ5xwYVkeoOUhQil748OVuVpKZ+cXv578jP5Fazrxn6PKX9M9+ObT3LHS s+FxdzYEbm1vLxUXYHYH63b6gFnTSCsMyS/gOoKdiJZNo3Dqm/SlM6IKh162BOz2n1VjTP3+dJtN zbM0jZnV5l80yuNiigIMelnC1lMcFhFnxLPRvyJa/B6MEovQBa42uNeJbVhi9tu0ky4nY5Th0cse YnhEY0z/49qWC7UiwPmYpMXlyRrBmLmswXaQtbKAjxxTam5xqiKrbDaf4hkznYmR+ODRGiPUUoRz RnKA5Z2gdsClGLFsdg3UN3epIV7ETy39mHNXx1sWmTAXJ1U3ZpbDQn0STZ1WGYOX2b4Vq3RuqWmP QreKyzaiccIgVj2nMzm1JgStU2V1K9Lw9cIvXhD37hzJ3yxwANFIGH2ytwLD81/uz69Pz9HNBTpb GvA5SxBpplQeqm7Ss1cIrhduW+MxZrne3HQ2g9A+n91FhOmLiLOqgx/sdrmTX3pEEit83QqDCpYo 1t6laMUK7u9J1MLvx7Xw9w55K+7LYBkkFfd3Vl5xv1v76732LfC9Pk5xcXUqXP7NSEwwBl1O8sfG IHtrn9zunFKr6MqzsWCTFlnoRlgxgoJhLnNuDGnU4lauZnK5p8wRzOtoi8UIayDbxPemU5w2k3mO U8DEiG+GY4S85PgXBgsT+BbmKaClSwUvT3mh6SK1cfTrqIDAL7FVWor0wRIuetcOhxG2UAdrztl6 d/51++78F3K2OUUzcpohVkywuEwFD70YU9pgkGJJwXO44nagp9UdoOlmE6CNU9afmUXb0w9z+rn0 Xaa05QpmlPotx3Scs3hImaJsmY2xelgJFDasza3kZQCjTX658y/SZUgpyY6WrbllqcTfQ98ah80C XsZtDoh0DxpdjG6RN2d1VB0TDbtzwy4bUrkobmQlZIm1y9Ub2kgoCGVWGg2WMc4N9rJgQDYvX5aP kgreIs4r3gcE+SUyhPxSbR6CkY2H3fzOPFD5zgS5Hpp6LiQ35LzmYluNGEwjZC+MNuEbBW4gughr HLRRTp+4Sc5b7oTDagp6IVQUTGTl5QlUnxMKH7La4TDClvyllJUhoOxyKjVdRLjSCoURprDdhoZv ly4ttFGheMUY0xqNEebEFp+gjlp+q1NK8FQojOFPN/c/n9GEa6hrTd3J9A9UayjRSXwojDDFiSPh m7RGqz2zJRIVjFEssaVoxa5N9iUuNA6SaxPeW5M2SFbbpziOKyPftKa/QCB5+Nridp8Pju4VVn8V nxuzyjv+asC6GdBd83dXfSvYtT5lcrryod63P/0dBVT80W9M/mlPMu/FbezOWHLZ1xqNkS09Tv2D sOZcviQHCULsUYHICIOWkyQLBGSPkyd/R/j7eBrZgqZgSyRmJMeDFrvxVQGr7hGINoavh6GbrGyy zhcrwDc0+TNAe5IJPxUwpMgq3JWo77ZcQ+M7j7IuMQupJaTAvKyEo1u4s1agUpOyMyM7M/LDm5Fk 36aXiL4ThM6YtefmprAdeBPMyFivicnCa9cJcUUBHiPsydj5ZMNctu4EHWKcwIwQWuHDpMmRmShn Z8L2QVoOwBJ0xrfDIcWWgrW14tbjzoR1pp5QE4LeLZylkr/RHxxtosWNe00Ai+Qdvzz6xAik6Nck COCCDDXtCNkXCwZglyFBehWfOJ4FGSozhIpggOURGFnmDWttIUBiK1sYrKG9Ll4TaZ8ksiSORa/Z mqCo0VMr7qObketBb6dSruOIuNJom1iutxQsreYhFLF0y8f48onrn6CNwc7+pqjHiBeablIvr8/O /xv9K+3xw+8xqnxTNwlZ11XJFVlf0gtWD0qN2ltBO83GyNU2D3/9cP2yUOXPoZOa3h/+i0cWBEGZ UE+pjP5y6VKfenC68Elnyq9uCakpYahmSb93se97PraDxV9PvQg88rsDWcr5gJol/NTzfQyx3yoJ 5wNqesbHbJSgj4OqMQrPOA9Qs4QzZXTtOQFO/zoiC/PJ/iJLNg9Is0RfOWNYibRkKWScwV8vybQ8 tpltPqBmCT/PVJ08g6KT5Lk5HZ2P0HB0d3n9VZZ2briGyf8eFrRwvCAP9qRp5wJqnPCCFlZBOAdQ FYRX0No47ooxlKIViz88kAgNPI5DAw944w/bINndX3nVhspDDbNpD1ScjwqgdK0jWdla5cKu0bey F/NckHTrruxtenYXQRvDy/85Rxs7vd5+f7C5yS1eogB1E1zoCQHJbtzU1b6tfe66i/k1upj3cRj5 LrsKLlYcj4sYchPYCroJVnBcl2dpsJ6xTzZRIX60Q2GEKZVTVbxLR+guHrzoJXVLJFKMKbhBD1Z7 +1PqE8WzefiKCIm04yi7s3RYI/BnWsrFCVDkfnOJ2EA+HfsTa/jm1tVh5s5F/x373vYUu4/hU26z 4xqMRsEsI6goNdaz5UypkxySD1ljNeEmAhkOC6PQvUTvzi/O78APzL3eCm8Y2XXAeNy+Ieptm11B xslo1AXCep8Osy0sgx/RnWU7XJXHlSExom4voLcldsevVaNEw9vtu4vL50FvZ/ty53B7Z68/6O+I ncpbYzHCmiFzlaGD3qDX3xe9+qx6WzcpDYfXQ3Xn4MPuHLx0es353uQPwU1gdItU9sCautS4paj2 bd2k3F9fjuIzHfo09mz84vl2wL/UG97XTc6aH9UVr+JStGKe0kNxJ+b+rmimdhskq83Upk9n05VT qQKJCcZ0Nl01axKr7LjX7x1s0f7WPhrtyhp3lWB0E5d0Y0ODHQGDrvQt3UPPWpWnsytrzKxJ2TTO chC6iGocsgEur3eDpdOrpF1pyF1+puY1vYOvbuDEes8mjlZeqoThSZFb8EQedgGZ7361NY7KAK8S jT2kK7lFjaBGEBqJok99FZ9kuPJp3JwwdZPdZXN3l8aKhw3Pp8y+mDS7g1aebjR7IIY3NOOIO56z +h3c9LUBLsWIwtZ7tNpLQGgcOWZOtiCTFcq6ddRlfAnfYtVhWg/v9+ksKe8ykD5blEDQRVLjiA3w 2C5uPe028EoQ2pV+oWZK+02726i7jfqdb9QnKMBhcc8s7g5pP62rk1NuKtujkGJKYdM+Xu2mPbVe ieFBrJDQcse0z1bpVm2VNBqpczTwoSoDpkGUuKuaIVWPyXXyXiuxtGVLSWmTK2tMhXSjPzgUzj/n h6eb3HeWgZ53wMgmn1dC0UVa46gN8LrEapRO7uaBYmLh56f/Vxr8mX8ur0fnX8/vZLLBRMCaJ/6U 7LxLg2ydBCkM2zwbRt9vvRdimmSfOE139msbHvABNs+AO0zM3ExOOjytcr7FAKtggGIlW4pWLNzn SCISZy+JxDnijfeRwbIfYxmsvp91F+9TvVS6eJ8qzrzteJ9+vzcQ7bRU9qoRIoRlUoxQafBGmHEz xz4bBxpG87nnh3H1uKrxijFDGrwZ8b7dvhkO4yV3s7e9s7tzuLuzlUk+2O3tEfEVDW8TBaub+LJD IzvTtD16FqDoIq1x1AZ4XXJ6aHW7UwVBiqRlr+zuzsq8slUZ+jUc4IVQ2qOBJv5voB30b7RP/n+A IPnfVLsF+nQ1AJre1U2GyVuiwtJbbSv4T0x7IMivoX7r0usQ6uKOl0m2zqwVJGmzzBFed8PJg5wL tm5poA/s2XnjpIfQ6AknN2WUhDExbeACgFto5EEbYQLU3U8u/tJGDGR2bDpuchCnmXTo0feiebBF ZnQ69V6wLcaOlkiMMAYac6LwxdtGtNSBj/G27Tw6YRLolBl9mE6sGFtaoVCjidQ3WspRSETcdkD8 F5PKqC5VSTZZLzNrCnayTKF/PmSJ1ZAgM1bWv5m65o5UcGf53YK4d7bGWHUSQvczdd6PvWhqQ6Pd H0b9nX5v54c3TSzoz6p6GMlawbQsRFbLvuLwTVPt40eySWCflbEwatV+GE8oN33twJtgRucQyj45 z83CB0v0qou/o7NWjqA6cLqJrXbdyMf2VkCRIq1gl6hvSVRDJbcubvOYbgC5fKHbLnGoGohu0c66 itKLaW6Rrn1bNym56hjpaCSraxTf101O5wRrelc3GW87p4mccRLjwpqi0LfcYEYOy3OqiZKChFYY WuMncgJKKhNyE6oEiwnWpLUXRftTL7+me/BdZEWNJK5BZEUFLxrpqBhDKVqxgKRj8VChg504VIg7 HqkNkr3dlccjddtq07vdtsqvy259vF1V3tcJoG6INQFn/dhzn71pRL8CqQ/chCrBYmRbpWNM/IrJ jRW6u/66fTe8pfc5ZOjsSwEFbqOXJyzoL2mJxAxj6Fnwfh53JySTe/7buZuUYYF0M6ItQz/C7NJL kCFywI0w4pl62Yc/3dz/fAZudiLQM2Iaknks3HTGVxK0jrQIO1qhMMKU1EbbIuN9dFwXtk+aLQVj hJIBKLTmaOrFYZATB09twWDDdjiMsAVOFiFkV0HiZXyDQYdFhPoJSnbHk+jjCSab2ZhM68R5jHzB 5dMajRHmXN0PR+j6ZgQS7rCmgqIiUQtCiqiCU3LF/YcXhfMVFaOvYaAI/pa16DUKlupy8ZyMK1T+ 7+rSr0ZPdDkNVQq0y2moZg3d3tDR9kC4bmnpq7qJqAm7lq1GXw1GF3GNwzbA7Txv7k9PJYvQN0HQ LUDZOy540uxFbtlphKCbpOxNFzyf4EhEzCPJUvTlIHQTlXXNwdPOuVcKQQVJild0KVohr3CcySDm sB2UJpDWuIWlsCRl6Q9X5hWWZbsWRcoMp9H34dQLg8vZjBw2ZTUqHyiTqrWdWl0rlfpp5rjOdgCs low+KAFgUp129yRl7+om462HHyxKnKZtDxdyjl6enPETerKeMXrA2EVRQHRUKHj2bI3GBHMWURLU 1XF7dh+Am9EBLe1YIUYbY48oNxdOiJto5tk4vtgQ4k1rLEZYE7siA1aRPnzyAsyGHj5ZIbLI6XLu 4yCa0Umk0yrGFHn4Uuwo+ET3V1yQ1/edZ7jsYKX8n4gmxq6NNpwe7m3F5LIV8QLeN/x9PnXGTlir 6DnxlPpAt2Nnp9ggjEieNQb36xTbj9jubaJLsm48mh4RJkID6SJsTQUBOG+SE5CYBLbHY4Q9np/V qlSLPryiO3BwBWEgePnACcwIoWdOAIrRcSMndHCQXAA9Uze9N2E38HElUDQmIu+NiZ0gRn87HGaW R0jEksxZ6Fipp96bxPeHLjm92SigiQtb9CqNfN0DD7/g2miHxMxm7szIDFpBJirh4TU3nWI84Idn ZoOexEevrAy/jsigF9GeQeCNHRafwapIihfWbIVEN2O666Hqueyuhyql/I23uNuTb2u3p3atVoy7 cXQVYyhFK+Zi7Us4P4UrAUphSSsB7n9kH+v591Chm5UDmu61+l6bKHee1s7Tqp6MztNaR6kaNCaY 03laq1nz3j2tB52ntfO0dp7WztPaeVo7T2vnaa3apTtPqw4jvfO0Vgh552mtZE3naeXxtA7EfaCH /aT6wAGvp1UGSxIyu7u3yhoH29so02Ga/OBAecsZOW0SfU2PXvHJ4fRqNOQyHuUgalwiZIDElofd ivbSnhPL7fQqKWLpuCzll5rzaRJZbPaJ8EAFCq1M4aNL99BkVcMqeZW478Mg3xJQ8haAA4zuDSTr wE978N1cpH36FkM+l+43LQBXN/ld/+nO16542PAsmkMnXaEzSn+L1lGA/YJsk0n7W24K24GXYkbB Y3q4Wo9paZJ+3O4gdl7Srgdk13UJ9cwvHNe7IXuqaJZ5qZd0TNHNRNDpFrR84mkY3MSysCudvFoK QxdZjWM2wOfixs0ye1vv/5VgtO8VmX1a5Z7f7fPdPv8G9vnC1nakpYNQ9mAIW3TaxKVu64NNaLmr Bt8WJ4Z2aQssQ6tBRMp2aujKQRUnNXdSzwP+Dt1+UlunkYlyXVBkkJew0nCrCfrQi3V6nZWzaJj9 uPDisP44CaWirsWWSHQz5vL67Py/c7ZQsnHRmwwBm4obkm4Sl429vDNCvmNlDSRdJDaO3ADPK0wg yrzUJfIvHp6LQTKhUqpkPf/AncqjfN94UeDrwYgra3xi2z6xFRffWnzWlhOc0NdEJub5saa/b1FH uo3nPqbX623FQxTPerDnzHtx4+qsl5NYxNNrSPr7jf8/2PfayowwnvVgT1q6Nh30atgjjEcFexTv a6Voxe5Ld1vcZO7t8d6XymBJiv9ATZcV14Qvl5BfIernZysI7+c2hO3CA5Ew5K+zeVvx4wO+Hkvy J0LQHQ7iyuJklGT2biYTcE7fuwGBjW2Bsj0KcOhmC7/J3JnEpbPLNGxrf2olGN0CkfWBphYp2uj3 eoP+3uHe0e7B3uEmt9AIQdNNaudT7XyqK9hlPrG1/Ewja4klELnObxGeviLHBnfR5BXqaJd44sTi 3VtjkWJNwd18vNqb1Atw8ro0bPnZsSNrynu3usVIdjJMYq0SapgsMYDq29bGAZgQTVoGP7ZM7QjK xTNnZjSHCHFRByknMN2EVvn2mMtJhZewAEkXiY0jN8DzWpdOa7uoHpZu0cqaM4uRcctT/eu6iemS s5ve1U3GOl0k7+2s9iL56uQUWfHKpulYpRs7xChlLo/JIYJlbpUEUz1ZdQtRfAjJ1o5R9h45HUFJ fFVmBLolhz6zaBo6c+DLgjAcJIZIQIedpdlK0524pU0RHiPsSbtAncZR7LFHVNTsaYajm7wuV6x6 urpcsUpBftO5Yke9AfmfZLbY0su6Cak/VwyUnVAG3Qml/FSxuF9t77itA6VbsHLu1mRg3MJU+7Zu Ut7p6UQiRKD+dd3ErNUZpb/aM8rlbf58QGzbxvjWhiMKcuvMF5lBlEW7NpxSMoPQLT70yZBEvuLA DegWimswZP626BTJzhbc8qYCiRoBHazWPc6yp6C2D+vPCSBYtZedHvtfKgm8OUnCx2jpQdRkKq3N SXohKOkBd4ncvDiJiWhrNEaYYy2qpFQehcX4IALRCMmjzIyA/qRV/xZ7MS0c5OP51BrTyjpi1EsC N8KIssAFHMam4ijuLi1GvhDI9SN6Cy5fMWtDf3n7fJAsUeF+7m2xGGFN0l8+IlpK2JFW8bJuQurP 0G2SUSsh6SKxceQGeM4Vztv6WM4HU7eoLYdDLUfkcksaLyAVBCqWrVK0YpG9exIxt0nNee7A3lZI dlYe2Nvd3ja9q5uMtxuy9gminM5uToeXQzTo7WylZSLZuSOuhZhUzZx6j+SPU24a2yIwwJBF1e8x 20PQhjOhtuhgZ38TxbUzlpNDxU497VCYYEpmEvu97w2TmJAnxJNWGEywpDB5/cGxIvmQA22ECZf5 CUlHvuxbi0+5YmyQBG6EESU+sN+JNSZ6MGoEo5u4+oPNvrIj0n7LI1LB/7qr3P9aQ2nyjTInJ1L1 mCu/UJy0u++33gv225/WagDpFvXsyWpErMkn+8vsV27xrn1bNym5bkCjp2Q4ku2ESgDoJqg78zS9 q5uMt95OyMdj7DxjNKfqx6L1b+knrPJganTQdjcT3xMzZ9uhkGJKYQfcW+0NZOOleOZar87+5YNd fWW4FgZwfqorDNTEuhOSpFYYjLCkpQm8NqZvF1tbo9+62Noq+X3TsbUHvUGvfyQbXLv8tm5S6o+Y B8oOqwfdfV75aS5X4qJ9pfkGaLrFK3vEW9TvQBs7vd7e4Hjv+OBwcLwvVyGhGZwKYhXLVilasfu8 /TZXbbu8F3oyWPb1Vurpdu1u1263ax+22rUP13XXPlS2ax92u3b5Pnv+W2QlDRJBQyioEc8B0eTu fXM6Oh+h4eju8vor2hhe/s853Xb3+4NNuf2bB6BugjufadO7uslYqwya/dVm0GRVQOzhpCkY9BK7 h9BdctPpljsRoUfxKwpCnwa6ylSOlx1B4moE79P2FLuP4dN61JB3mCfwmbrHFh5ASG1hf/Lpx66H cIb0Zq41X1tm1VvMC/7RGOYanflFCzsyPBtPCDRbuNsOLghUPVjd6qVzWJZTqQKJCcZ0R58a1jiP EVEwR9uDXdFzT+mruomoP6ocKTv0HKmOqzno4mqUSUJx0n6lu2nr81clGN1instWuB6dfz2/4+sb 0fy2CbXjgVmz0d8U07CFt0wM3bfcR2JKbwwEB1/ynsHhnzx4fojtjV05KkpeN0jMqQedhEK8sSdH Tdn7Jshx5ulI9gUpKX/VyJzgR4ecNqnBk47pQHRiGoCYIIwVpj7DrkME/1CQoKqXpQgp2BKrbca6 vQ3vkH3wCAp0oyiorbxSAqDU7PDmmM2vNd04AoYY8gyIkZLhRSlVwZMXTe3kaA/sKv3aA06+kuWm ueWKfWx/ub28dJ3QIe//DhvVMb8HlxeQbgLXuDVDgrhzLje9q5uMtXIur7gX6SljtWi7befZoT5l K8RbEI8bMC+H6L5Qjr65/XYjehOKNKnFcHdR5f5JXeXYpoOPBANYWyAwxJBFq1mH5R+eXsUDg2kj 70UzWpAl/ttoKOhxa4PBCEugEE0+I3PiTafeC8TR4GeyFIIfxTggANAIwcmRXYyq5beMDB1Bv99Y zbAREf4SNfWACX8FE1H5YBkhc+GXECOp+J6pWRrFS5uWforD+6HmE4qtUHTHhkqU428RDgSTZ1sg MMWQGTlqQuwdpMLEim+Lagqa/xCPde5747h6HzmmCPOkBQ5TbHnFIbEgmDNBfP2Wvm1yxS58cFIL t/i6CmIqxt84wooxlKIVi4w9aBGzujfgjYyVwXKgNzIWnpwmC8D0tlLllfjZ0qWd9moXXywt8RhZ VjkXqhjFpa+u2XaIzn46vaVVEF9TzgtXGpQGb4oZ5HzwYvk2GaETthHoBjhm9oFyJ7kYbQ1A1kKI EwWSGSr5JZh7bpDVImq0FCcSU4yRFeB1ENilSxAxGipeXlsBje2rRHTUC2cFAmOCKa9cFenTgvNU fWfNGtK4Q2zyF1/mgmYWz6/xjRariBU4NtzikJ2BDP45rp7M7rXohdYDTiI0xSa6LRYjrHHcuLgu GeizE0BAY9pD4OryCzQLiKbUhLWePccGyiZTR7RAV1ssSpbL/mrb1bG65LY3jmZEmYEhBcYG/Mzi RMEhFqIgms+JWgPwUUXF/aOeVBi7iiEk6/mIGgJre2HNFeaXeI2z+ih2UFqTEPuJs4MeZIl2/nJ7 +fZJjm+l2QYae6eWxcmInlF2Db+W9/DJ88UKMLyObn3n2Rq/og0yxk3YEVhhdjv1IFLLxwniOy8x DihAZIpBicOUKP/M8iNjX5LdXtzzgK5XYe60wmKKNVcnf0fk7yFNPrIQpPnTi09iGLPcIrpjOjMo coomljMl26ngBWtbLKZY443HkZ80EAehrlB0CJ2AZhdmiiR8U+xIZJqMjExWiVxvLVb+izOdgteK bPjCbGmJxxR7Kjw+4se2JkBSBBasUvUNykqtymXipB9u49SoHKTeBQgYQy7GdgDHCyahTOEH4Ook 2p+G4Yh61+ThG2GHTWRgHIomQC2/pXvoXZ5i9eR0eYqVYvumS7T0+/I9i/Pv6iajPr/wWFmm4rHi TMV99R0YP+4OXJy0exf7vufDBtk6XbEelm6Bz2YdnnoR6BoIdeAU8tq3dZOSK+M99mz84vl2IFkG vPi+bnK6pIOmd3WTsU5JB/vqWz6gzPPpNJH/RfgIOOa9KERUfSUxhSsriy09gnUtnn3mBGPPDR03 ckIHJ85MAMPqP1NKxkyJojGhh3p0uAVNAQ4jbLGgjveSryrufDSzXOsR0iRegxDPWOQq+ToNzRbj S0skRhgDDkyaIJFcAqUpEsl0ivGAH54Rcp1JbEBkZfh1BF7cSdzO3Fr0T457ZAm3Ym2HRDdjOt9B 9Vx2voNKKX/z5V332lR33VtX70F/R5n7IAtKF5GNQzfA9SJ/Tj1yRIBugQpO6vWwdAtXd1LvTuqr F7LupG66X1fFuZcc26g2orYOPQAHixMwN5GtMUixpOC8WHG3rhU16urcDEpwGGFL52aoYEznZujc DJ2boXqz7NwMVVLeuRkMEdLgG+irczP0OzcDsKrsEj9jLCsJCmiCp1vIOncD7/u6yencDU3v6ibj PbobInf1Dgc+HFJsKbgcVtsBqHM5dC6H5SF3LocKxnQuh87l0LkcqrfLzuVQJeWdy8EQIQ1+goE6 l8OgczkAq4r8GZK3rOm15wQKeiY1ANMtXll3wYgc5J7sL9zyVPOubjJyjoJ4LJJuhuW3dZPSORma 3tVNxlt2MjB185npG5qMDub6HPuxNwBM1GgehERWZnH3Wt+bcZOpAIcUWwpOBvX9ArMkohWmW5TA Xld3wyU73ubme9GSd4tR4j38k1hORPnQtsdCktQGgRGGWPAGc4NAG2dRE7Pydd3EdIfCGvXWHQqr 5PdNHgpH7KJvb7tP/XJ728IJ83UQdJPUcKbbVXc83O2Oh+UnuitnDFnlkylzGCi4k+aBqFvQck1y yWp/hHtltLHT6w32BQrC84FRQZximSpFK9Zr4VCiC8JR3AWhv8/ba0EGy3GM5VBPq4VudxLYnVpv Tuu6N+2p25v2ur2pfCc5/x6qrKDSCM7krhRfwx3scUtV7du6SelipXjf1i5knRtTeRGV1fbk7oqo KDdMulCjUrZ0oUYVjOlCjbpQo86rXDmXnVe5UsrffKjRfptQo/219SXvqzuv73fn9coDtso6Ko3g dItYd17vzuurF7LuvN6VUqnDIMWSggvjqMtrWpH4dM6GcrZ0zoYKxnTOhs7Z0DkbqjfLztlQJeWd s8EQIQ0eggN1zoaDztkArKq4zVdbTYULpG5R65wOvO/rJqdzOjS9q5uMrqBKJZkKcEixpeB4ODbn eIhdA5wdxKrBLjkeysBqEKGKPvjSTzNHTK6PzqtSzpbOq1LBmM6r0nlVOq9K5Vx2XpVKKe+8KoYI aXCFHKrzqhy+c6+K4jGUohVLHztqkdi1v8ObPiaB5WgnxrLX15M/RnOc0NF2/1gqdXfpTe3KpmFl ifS6FoD1LlcpJ9+L/Ll0cXhi2z4OgtHrXEFdJw6ABna1fLptboQiC4cDjAHi2nkPmwCYmK0WPsT6 1w0QI+NJLH/NwODh+TQih7EQ1jI5qDtgxxLJRxYTfeHDLz88Q+TW67ReWpwn47IT5UALFFJMWfac Huys1nOKKpynl7Frc3nOaWkj8k2Chhz2oUrWotARpo6zGg7zDCBxszqtB2BKKJ9zjsO49NOiJNTG zqaoCSgI1ADh9TbdQKSZqRA0NWusr3yNNS+CUqFHqh79FxNcdqtSm3W97VUReW8AYYCozk7t7FR+ /TlYtY3y6bJoeyKhVPjUUKN/q+FaqwHUBKeXD8CA8NCH3oqjJytArocKtFmxebWF4vud5Bsi0qYC jyn25IzNhXlZaYXVm73lrGmBQ82q3TVzssCzefiKgtB33MckgCJdHE2BHMn3QaJm0TR05lMu6RQ5 eUBd0+0pdh/DJ3RzOjofEe1/d3n9tX6wJeEhmcFqFOgKUmNxw0FpSdrc6ku+K87PwpRwoF0D1ixu r2lgVKqly8Vxw+nhVBbuLoipc7rJnCNwaVh7tqsYQJliLB+RfmYpWlSUaVscXDOg8huOmyItMoWg 6SK1cfQGeF/kz6+w7/1sBeH93CaS3/6oyAHQgLDlOlA4M0zGOpuLyFctAAMEdUfF7qi4osHDQ68g Ups4eA3u5zT07AW8vRWLXoTStjgMsQW9EAuY/D1EEdVutoRPuRqEAaIatk2RplFC0FSQqnjfLUUr FnhzLBES009CYrjrNstgGcRYdo+0BN4sRCAOdbzGLwtfso2/L0p6C60fCbi6FxX/guks0rIZvbTl bdBaELoFoaKAfb/X6x/sHu22roRfAKSbwKwF6XrhtjUek1O0U+/ozZPWDEL7rHXZeaaz8y5twjhn AklBFgriUPnfIhzhfIOwB8u1Xxw7fOqRI5mgK7gtEhOMITt76DsPUYgX9yD5kVs+RsET+ddGDzh8 wY2hISUWakskUowpOMn3zCYu0syqhT+SfTbC/sxx46SE2KVGE7FUFlbKYc9+FmawB6XYjYgkHOFO r0ZDROxNDzK1gpKlA8ZpVpDEBLIVCiNMYevkwQogVMpFNMUlCNMsXyCHzrHHUh4pIOEwwZZIjDAm USRWwdFOZo4SJHqeFoGom+Tl03BsncYB9y0SbKoA6SKwceAGOF7gTv5Y2PZI0QhNt3BVt8c62N/f VdJnKw9IN4HvtOKHjec+pinN/DNU+7puYt7yyeLWo1efYCwQCwxT/emU+ZpZ9pfDzgivjvvITaoi PFLsKZjR+6vudcwfOhIF1EsJ23KS/fwL3Z5pXEcSwVDDZq4B1ISDiA1Ag3jKHEwSy58ewqooygc0 CbK0iZ0tRmBiyS+Hc9HuyUKLuRaCEZJGmQFBRNYDHMEXGwO1+n08n1pjWjdDjFpJ4EYY0XgbsAUa eOJ8RxaaOcHMCsdPYtxog8EIS+JKMWzp+fQ+iJ6HfBzMYUrJaMui+wklYoxpj8cIe8BpPujvHe4d 7R7sHQpnBFW+rpuY2hOhyKUtLyBdBDYO3ADHC9w5sWeOy0S69cGyAZZuwcqdBq9H51/P79C/uKWp 9m0TCx67YLnYG/1Nsbo0Je+pGL5ioS9FKxSxsLcjEUuwm8QSHHBGLEhh2YuxDI71lArpaph9+Bpm tZthm4pIVYC6XbUulKft1soD0Oj+mvO2ZuxKbjkTgqab1K5kc9O7usl4D67bjWfHqjpabi45XLmJ bI1BiiUFd+3Bat21HO5nEZduDXeVYa/252oUxjJq+LzJQv5cQX7KjKDBn2tygXP6kpe8sUIrvB0K I0yhzmZBozv/ju5h15q+R6ps6KPOhgZGbW/zsHPxLa1Do4FbE2869V7osqM6Z+57z0TjZ0K4wAfg 4iloo2jK4tvIlybOFAdcFzVKEellEMhyWvoeag3QkUOt+weuGDlOEHqJ8vF2FDBnh+diKDEx8+Cq cGkaoIjbiVv4mJNsNUj0MubFmU7Rk/WM4a6oIIPUIYKt8VO6D3GyQhasXuKZHic2D026J6/dB9Yj hh4pvIucA4IKkhRr/1K0Yi7avrjz9LgvWs1ZCstAXzXns/OLX09+JgaBSNxk2UsaxZ4+y2bMVbpE z8WL9IkA00Wo7MpYJedzHDplSr9d8eZmOLoFK+v7OyPjdIL7eJsTqtnMB0Y3cQXv35j8G8rllZW8 r32uOv+haf/hGQ7GvvOAWc2ljKGUHAtovWV2K0Xs6MUXuClVg8YEc5g7UzAsLv+O1LALDtDD1TpA T4ilTO8cx6FD7GW8ODuVms4bpd47B6ces2ndcUX5ABLnXfhkMb9UYRRGZGeJFjo6mh5IaBp7s5nn 5rdR5kcXk7V2OIyw5ep+OGLHMpjwgEh5egKrNCtEPX3tcOhmS9chrG7f6DqEVQj5m+wQ9rb7DqXn 5tCeWTLn7fx7uoffeEpuk3tZB0wXoY2DN8D5HIeGoedbj7j1kbsBjgryFLO4FK2Yv2/QwhO3e8zr 75PBkgZ+7qzc37fGVZQSxAUfw4vvtHFR5F7XTUznoTDuochmXgXMwCFnnTnU/QghPHaGwyfPplVZ qDdLOCu1BQITDMkej9mu8IsX3LKjMbWSJBwWXOCMEMsclF9er2iP7xkZ7MbOJqIFTchpf5KOnl3t xl/nzyFXgMMIW1jIzvD66raH4oKZufH3s+OnfxddFu1QGF0Yi5HDCNOF3MvMNA3x2hgI+ltaIDDC kCYRXpTJcdyJ58/EHbvtUEgxpeAdPVqtd5Toxbvzr9t3579AlXiyGwRwwR4Q42SMnWdCG60sxNn5 pTZ2RxH26rYvRgJ6Fs/lQgLSwJxFAjkEsiNrPp86bOCOYGKRLHQjrCjdaWGczmw+pfoVcsqD7CWd 4LbeBoMRltyET9h/cQK8tTx3ZSMWLeveBr4RdrCCAqwvSWFXEZQFPlhqtPHxarXxuQPTWG6ylepg 2pSzaL3AziwTrs+NP9HCWxUDoCm0ukP2K+5jyHYNmzgtMA/H7djnkVkmggInCtUI6ddeiNmd2ZfL 0TAeUkALuGB3TJYHOfp5ATkTEqjUq+6G6MER7DrWEokRxkwcPwiJMXsBMZLfLdCOW2DhkXGhQWzx leQGiDGmJRIjjMm1P0PeOCTizVqHoR8GOz/8JHqpwQ9PN7nL7v2bWG4PWlwRlMDQRVbjmA3wOePR t8Yj73TGLDT5e4EGKLpFKBtBNzz/5R4urNHNBY2my42YXhhxS5UcWN3EdzXg9TrDFa/7UrRi11W7 LS6SBru811UyWJIKIv09PRVExp4P5a881w6Y/Qc1mH8IoO1e2nGPOjfifoObW3Bg4ZYsBTh0LyT6 DH+6uf/5DJY2csgIyfkAbeDeYw99xeE1/h4SInwvenzazGQwiRoY7XDoZkuVwdCmxEgJDF1kySof rUYHi9Zoa3RUQtG+RS2F7SsyNDrj4iMbFyJkvOWb9hPkey/Md44rDhZifiAhiFIkL7sfD3dWHCqf KVudSSzG3x3aYyJJKuW8Daphpirk1ZdBJkUNxcH6xG5zXbI/Y3thtY2GC4d8WpdCyvppiUQ3Yy6v z85hv8l3iiRrRcD84YChmyxqkVW4KYQjTpvh6CKvcdwG+F1uplDOpa4SrqqlQoCMKBCEChIOD/nv CTvhCYbT88NbB3JvQ59+JtctlBuablK7HqGShzkmsC161Fe8roIYxQwtRSvmmtuTcJodxU6zQ17P XBske4daPHMLATjzXtzTJ3d6Gvr3Aba/vEI3OfbElWp3B2IKVRK2CeVaOtTz7+HIC61pMtx4qAd7 CtjQDHud2JCbtHSoSrhQD7rbfd7I7pOZ1DZdqhvB6BaImjLC+0o6yWXB6CauK0Pc9K5uMky6Dgt+ tP5K/WifoDRhZRNh2r+33Ie2Aa6bTRS7seIauXHCcw3TJIdQDl+3XNAnbixkEx25VLcR+gslDkGw PZ1xNLV8uOzklqLWGIywJL3YZaV9YfCLu14yVKCERZDFcVZxCKwYW9piMcIaVmQnCBOVBgCiDAUl k3x5Jlw3uC0WI6yJ3G9uPGWLIPAkONpiJMBa2BH1NksA1s2A5ctxZnHRmYmtb+bna1MIgAOmmh1q oHyHKo8fV/Vwx5sbkI5SIzxzRlVh09eD070UskZ56obgFvrat3WTcn8NkeXs+UQZzK+5at7VTUZ3 IGl6VzcZbzqWIUxvepl1FoL6QW40e8A+bMMPVBPFoQm31uvUs8RiDtuhMMEUNPd8erwhY7u6Pf9K xjT+hsMAbTjEaqNBgu54GtngqaZ/fyILCftCXGmJwwhbPJ+Mmhr1/2/i4Km9iULfcgOgJOlOFxv6 4kXZ1WExwpqAzFYSL+E6oUNe/50ehntxS+Q4d2V3QBN3nrEfsMkX401rNCqYU8GPRkoqxlCKVuyi al/8DqnfT6sR9XmvqqTQpH0oV1r06Orm7P7n82yhe+eBR7Tq3tO1kGQFZ5Urm/Ajcseeazuwusic vqKZ5dpW6JEj2qPvRXMuH4AAGI3EXZ1cn52Mbu7+vv317ub+dsgX61L9lm6NyyT1ixU446/AQ57R 176om4DuBk10MdauIc6VyAVDI1l0GaU+AG5JrnlNtxyv1U3M7qpvYohtRUVluRQGLZlCTi+NzfqS QgaxeV/DMgUDKOvVVzEADWJTFqbdxK+Sm6YAfMIy5SiaWIPCDK6gAleng9+5Dg4DSS289OKH1sN7 666Hs3pFSpsoUMVZfWOsI23zPU6sdZf2jeadTkBNl3IqN4iAYxBlu12nvzN6gl0lJUegzOVjWh+f R3PwQ9GtAv92dzk6347vmzLRY/t7O/Tp9Y4O2E87/BFpMkB1E351ed3mOqjubd2krNU2tr/abewu LdktumUlSvmPcntXDWJOu3gZsQYxKTPpU3Hl25GS3YN2+32GIJMAWQ8e9D0V7p1ejbp0H+JCrXux 0ceaz31v7jtQ8ALyYi3EBj6fQn01Vr7XImZA9LA9nE+dUO5Gpy0WI6yBwbEQrbOb0+HlECw9/D3E rs3yY8dk/nzkhVDlEJqyBcKXOW0wGGFJEpwGAw/QBlTLnKTddciBzoubC21mQ7vEeNIKhRGm0P7J D3StQ0F8G1njsefDve30VTQ0jg+WLjIbx26A75UG6N8cO3zi4TYfBN2iVGVpHqgyWZcB6SawM1PX ItznMin0QGuAk92X7DOp/yIXkZst8CxYzaQlEinGFOz3g9UWOLmstzmzxeQLdbSt6Yv1ulxOu4bF PPhritmL4TchlhkhYEYys46pqUwHvGRAUiKFZLIVBiMsocYxWR6R64J9HBGr0EfoejQ8RRvXFnOh k2PhFD87gXA3CkngRhgxDOGWwLcDdOrNaAMRvImC5MMaA1qMJa3RGGHOi+d/o3lH8TkhGXBcvvA8 IlKNiZZICdlk2kCMN22xGGFNrO9U2udCINVsY+pbWn/c7I1K0/9KqFu7ABjdgp+3/q9H51/P7/ii uzheN7KKi89v1uxgD23sbopXLmqEtD4kDvYP0MaeYN8tHkhrQSJ/AFz967qJ6U6xq7lsWW1rsu6y pS0HRS9bJKO0BO9Vuvt9DtuGdr2fYuuZ68AsAEa3wnq3tk1ozYOjS3fsU2dM/0DatKkDZJrA/kE6 sCNijcgTWAXINIG7g3Rcexv7LQisAmSawIO9dFyDjYMWBFYBMi6ig8zi2TiUs73rAJkkUNbk7kzt d2Zqr7bvZGdqt+VgZ2pnl1DjejGwpitt5Fvvha8KAB+ETuO+C417tNpWG53G7TTux9K49/P2qQvV MHSrqsocgyTFYG+gLG2hEmS31UiTslZbzYqr0XZbTUsOdkkL7RYbfbqkhUrWdEkLBZZ0SQtlYWNd 0oJGvleYnpIpC+Xv6xajKhtzEJuYuwNFRmsVQN0EdybrakxW9eWpUebpTNa2HGxlslZH2Ytxs5Xx 2jwI3QuQPmmawWpD/VujMcKcLui/hjld0H8la95k0L8E0Y0kGJiFCjN1ERV/63sThy9xSxSWbmHr rMHVWIMrLuLYWYMtOdjdlb1RLTyceuHQ+b2N8l0G0enc96FzdRRsLCSfc+uRbCZ7XR0CFahrkujb VSdoISr0SSoqzOZTh7ugArdktUehRhBXW3JNfMeP539RDVhE+MT3+Qp03WZW2InuLPeRHLy+WONv 3mRCDvE+142NOLRui5MmZa22uNUWg+mOFa11c3eseA+a+Nzlag0nCqvTwu9DC6uvZYIyT6eFOy38 QbXw6LsiU7gcUKd/34f+7apsdPq3Fkunf1vq33YGcBmYTve+D93bpV13urcWS6d7hXTvL14AISC3 vuMR4ZPIAKwA0Onbd6Fvj1ecdN1darYSFfp8iEvN49WmZHaXmu9kI7uyvt/Pv1iu/SKXFVQLptvU pElZq01txbky3abWbWp8grjaMN1uU3snm9rXyPJV7GoVcLptTZqUtdrWugDUbltbi22tC0DttjWO bY0csqBmo5LTWimgbmOTJmWtNrYVh512G1u3sfEJ4moj77qN7f1sbKPvXyI/kIghqwTRbWbSpKzV Zrbi6LFuM+s2Mz5BXG0oTbeZvZPN7IsVYABz6zvPlkyN6Ho43bYmTcoabWuDnS5QpNvW1mBbG+x0 gSLdtsaxrQ1DK4y4SrlxvN5tYtKkrNUmtt6BIckWQhe4mB5pu4mVotYgKmUqsc3TzDVT64A+H2OH 7qJeuh06vwLyW+zpLAyG2H92xvjEJnyT3arr4ehe4N2erWTPbqliP0npP8Fat22RdKogt4Rf3TFt m04ASCqBEgjd8u+W/zte/opXfCla9PA49qae/+dPj771+glRwDGAp4XVN7f8cHu6x4I4gpk1nf4l +ObM51A8HzodPVnuI0ZWSOwi+sc/4dlf0Nwin/X7R1sIRoB2d//0mXxMgD9R4Cj9KY/Gl0NzHKMZ DLJo7FKq5aXw6ubs/udzhLa3Y9105TzwCFbdex95qyD8iNyx59oOa7pAjrEzqKEfev4revS9aM5l NAqA0Ujc1cn12cno5u7v21/vbu5vh+hfXKJS+ZZubcsk9YsVOOOvwMNfBzzjb3hVNxH8zf619/df 0wVZu444VyMXDI1k0aWUmpMC0lz7om5ZXitHq45UBSouYIilthe2EbefdSt20yDXI9acW8MyBQMo 87ZWDECD2JR5ucQ8agvfloSvWtCdVoGr08PvXA+HgbQmLrz6oXXxarN1FOjirG5pcfvVSh1ndY6x a7BSRmUJTTTv0t7BcavIr6pLOZUbRMAxiK5MU4OeyHsxIb0prm53kbRE5tEc/FB0q8CqPrV7hztx p9qjA9aqVkHz2zqgugnvHMGr2cbWvjfBltzeVYOY0zZeRqxBTMrMeh1xLusf0VIM+jhBPnVNexO0 v3f10+/grT462IGfnFybXdqD1mJdaLnXW3sURphCm+yiKADvvYWuPT98Qicz7DtjMqPD6GF7OJ86 IfXqk92Mfr0urreEJ20wGGEJ9GAO5ngc+tEsns8nK0APGLsIfydizFrq0oaqMyLf9d2hSzjSAoER hlho6r1gH2GbifbeIQg0GSb5P4rm88yfyLZP/ibGDmnwRpgBCzfwZnjRUDgrubVB7yW080IzQmpV M2k09p7JpLA2y+HrHAcwN/HAxehvhcKYwgzQBojnJLHtkTUlWyS1BYLN3MVz3IVZXGNKozDClJmC vtX1MHSR1ThmA3yuPFz+Ta6aRxUE3aJTdYo8YCdH9G90pOpgWg1SN9HdsXSt4pNcsgPP+GOHuOlU gUSKMYXz+opraVyK3PFlSV5kR2T9xFZdKMmqshQ0SOBS1gMnccvMrb2/FGGuiTWXkXB2BiLvR9Ss P0AVJ2SJI3hLJEYYQ4/IRANErgun5IgYwT66Hg1P0ca1xS4G0Yisq2cnoNciIvyQg22EDcMQrj59 O0Cn5NzrhCHGmyhIPlyez6N4PsXY0Q6HEbaUymv5vJ6Phpdi/JAEboQR2Wm68JLToY8fmRSnf96i qlCMD3KwjbAhf+5TcvYSAqmL6EYSDMxC5UGKGDrRNL61bua8ABjdIpY/QV2Pzr+e3/HFxHK8bmS9 FJ/frNnBHtrY3dwSWyY8kNaHxMH+AdrY4z87c0NaCxL5Q4brX9dNTHf+X8219No3C+2upYWupbuG dbrXdKVRQlM6p9h65jqKC4DRrbDerW0TWvPg6NId+9TT0z+QNm3qAJkmsH+QDuyIWCPyBFYBMk3g 7iAd197GfgsCqwCZJvBgLx3XYOOgBYFVgIyL6CCzeDYO28hoFSTzJDrpuA43juSOF3WATBIoe6ro ThPv7DSx9u2vu9NEd5pIl1DjejGwpiuPAbcQ7MezwvkgdBr3XWjc/orrGncat9O4SnkjSFebx4B+ yOve+3n7nLhqGLrVXlWM4H6Su3awryrssBpkt21Jk7JW29Zqq6Cz3YOcki0z+1YF5i4f7r3lw8W5 anuDVWXDCSIwwpAuF67Aki4Xbmm8hZS0AyraarPCWiJRs7Opr9HfrFKba160edZB6XY5dRWKVyzh TVztysE3wg5FQZ1dIGcNtysOp5IZdeXv6xaeqlPoIDmE7ik61lYB1E1wd6hdzaF2tY1DukNtex5K HmqZvW09EEMAcEZ46Sgmxk7JQy/vIHQvQfo05MCoyspqjcYIcxqTp6pMTzHmtEZjhDkvnv+N2I7k RM8s7GTAaAP3HnuLM1tKyKZMnlJbLEZY02UsrZ2hu0g0gi6LDp9rTxSWbmHr7MHV2IMrriLe2YOt edjdzr9RPTyceuHQ+b2N+l0G0Wnd96F1ddQL7zq9y4oKfT5EH9n+aiv+im/58fx3fWTXbTO7s9xH cvT6Yo2/eRNo3e6HPMIuDq3b4qRJWastbrW1ybqDhQLt3B0s3oMuPndtntUuCqvTw+9DD+sontHp 4U4Pf0A9PPquyBwuB9Rp4PehgXUkHHcauNPAH1kDtzOCy8B02vddaN+BjuTjTvt22vcDat/h2J5Z J+PQecanhGlc4U6CoDot/D60cJdL2+XS1iNZ21xaiGh2o9kD5FdNkEV1FBqDkkIvT5jIz+nZ1Qnt ie2iKCD8uR+OWLoj97JThMcIeya+N0MHe3B53R8cbdHmfnRoDxgRJeC527e+M4vDwQWTJeVgG2HD re89OxCcyi7uWbor5KG9BDQiPHyCZGj4Hb4zIfoi8vl2TFU4jLAFZmxsza0HZ+qEDg5+FKO48nUj xJCnv4loiSo0s1zrkUVqkPU43KaLM5iDfsM+0XBEdsn+JzjBLRCYYgh5NmjMuoV2kf0lHqFU6cg6 OKbIG2yik2fPsS13TLO1QR+jHWHq6sGYIm53E11M8XeHbriO62wHUy9EgfM7bDl0Lsjygx+8KKTK BbYdbyJMfUs8BkWbzZNg/kLpq7qIaByqAa7Wnfnoae8W+xDpysNmUVi6hac7QK7mAKm+ZAXKPN0B sj0POzfeW9bDF2BNts1WKAXUaeD3oYG7ygGdBm7A0mngFhr4J28+d9zHIcZtrrKrQHVa+H1o4S5f t9PCDVg6LSynhU+nnosvfG/Gs8p5YXR6933o3RVn7HZ6t9O7H1Xv3s95awtzAeg07vvQuKtNTe80 bqdxV8qbNk8zgwxoiCqHQ2iFUavQzxwANbpjdcnnccVc+tx5L2zw6F+lws9iuDb6sUBubiHXC2H1 v27sbta1o5TAmSwFguHSHWL/2RnjjUE9Zt3bS67mcIYQpgtPXPtvlhNCU1tk4yD0vdeNg1o25Tei VtB1s6IzGlZjNKw227l0lWf383i96TUoSvXApx/8xbB+qBoXp7kBATrGdtVSRmbpzxsICoKUKSgI qCzlVTQn2gNbwKjZ3PMtH9ASpk2sMUbYDX0HBz10H39rjdl2zsaKyDe8MVRnpp0kUvLi7hEB8iG+ lHDWmYyAt9w8LeVebgTzp9fAGVvTBQMDYh3AXkU+gTK3IW0ilC2F5bjrYd5RGSnlcRDNiViEGal8 ppWwE2tgk18qmzkYPmHHR2PPHeN5GBFOkslKhfANyF4U4ESzFFdc8uZ46tEC2vPIn3sBTqp2oYTT lL91Jig3O0fpko55WI6qXDH8kLW9fkA/JCbXD2tyWivlbWoXDohhtGwqJdRDfGbp2wtLSuBw1zwN P+QG8kPlMFLOx+P4oXO3ZayzivPWrY/Pfzt3mSpvGLUQFI2k0aezoVdjQ3f1KjrHWwOW7qpDSPf+ 4gVQPv/WdzzfCbl0FBeATuO+C427u+IaFV056FaiQp8PUQ56d7Vp+uLbfTz/XTno9drIrqzv9/Mv 5Dj2ItdTsRZMt6lJk7JWm9qKM7a6Ta3b1PgEcbWJK92m9k42ta+R5avY1SrgdNuaNClrta2tOAGj 29a6bY1PEFcbkd5ta+/nrHbmvbhKTmulgLqNTZqUtdrYVhxv3W1s3cbGJ4ir7RzVbWzvZGP7YgUY wNz6zrM1lr9Uq4DTbWvSpKzVtrbi/kfdttZta3yCuNqwmm5beyfbmmw+Venr3SYmTco6bWJ7XYBI t4mtwya21wWIdJsYxyZ2ZX0f+ZYbzJzwS+QHEpV9GwB1G5s0KWu1sXVBIt3GthYbWxck0m1sdRvb 6SzulD5yZtiLJHa0KgjdViZNismtrKVa/SSl82oVQVGxtkXSLf/F4g2DOLP3xCZqU9ZLUw+nUwWd KnjHqkDx6i9Fix4ex97U8//86dG3Xj8hCjgG8LSw+uaWH25P99hVczCzptO/BN8cWjUbOAO1L6C3 Gtmk2R//hGd/QXOLfNYf7G8hGAEaHPzpM/mYAH+iwFH6Ux6NL4fmIEbT38uisUupViCFTD8Nncdf Lt3xNLJxcOq5IREOYh9uCYkaFyQTC20xsHsX+77nYzuQJa0EglmSTj3fJ8u3BUklEEzP0pgNCU4t LWaqFIpZ0sj/XWt67TkBlqWrDIRZoq6cMSyJyZQwm6x16RmrhGOWvPPfIvLq7/TEfGaFliR1VWB0 E8dfWc9Ylbzh6GR0P4wZiOdkEUOVKu5x17+um5i18ruuOIvhq+9Fc2h0yWzKYGFqYhucUw9e+NRc tyJ2SrHqc5UcU4O/rKJFCX4NQlPmzxPzHS68eHT8YrwTdBxW4NK9uH788c/oX7GSpZMfoL6Ahqt/ XRcxjcM1wN3EbcFWFHNmbH+9u7m/5WFu89u6BYWNYYj+xS0bhTd0DxllGAn+oxPb9nEgZV2VAzBK UKa7tyRFZRBMkpR388sRVQHDJFnMVfkrFECUo6kMgHmCoGlwG3py75snZ/Sdto9vQ9EyCBVEKd7x StGKuf6OWvnk+ryuv1Zo9g41uv7I9LOLiTj0xpnKrotKMEaXBxvV6Dt0Bw8uZzNstyKvFND6EHim hryzdSPuDtO6vC1pW4ayFqSdfx9jbEs6cGvhrAF5d7+pmLkilLUgLeV4O9oKYHQT17kE9RKzVi7B FXc4bHLJccdhCsbCiSGui8LUHhaTkFDinRq0c24NOucWsCfRwGHQzr1V975uYXnjDq4waO8RqoBh lqzhqzu+hDYnBIIsWaUwzJJ1P7bbUlUGwixRV9b32Ci7lLXGq4CYJezSfXbIthd7F09CaGEUSlPY AM00qbCTt5XNCigqSFO8T5aiFXOJHcv4qg4Tl9gxr0tMCs1RjEavR4ysYs8ejn1rRsxBSadqBQyz q2PhnLuF29wgkI3XaQZmltDT2W3oS9KVe1c3Gd1ZXC8xbzmAvOmIWxEpIrQs2iIxwZhsKIwAqcXX dA++5Mi+2+7Ev/veTvwF/5X6+oU1BCwcTaXuo+1tskoCD5xY6BEmQH94FDcNpQQQrISGu4tTNDg4 3EHWFFJCXtGTZSNribQthJ+xi8InL3p8glfgjbdJ74sVQEdNNHH8IETP2AdLBlQezY+5uvwC6i0q tEBdJ+qQqke3tkCJ5XUTS1cbl1wzDN0a/Y275eIz/h0O5irimsrgmCQvOeiT5Z6c9aXIq4Gjm7w3 dn5I9hTuUde9rJuQd3V2SJhpi2aY8kDSTWKJJbzXzpDee+dXZ4rHUIpWyC25v9PGX7jP6ZVsh2Vv X6NbMu3BPPpO9lAyzJvJJMBSG3ITKBMaaWlkscXwxRp/8yZQ3tJvR2kdvLUj99yViuLjgLYGpI6+ K5vUClDrRGTbqSwFtAYEDsf2zDoZh84zhlB4qUuEZmDrQigd1S32ITi2PaWl0NaF1AufbI9D53ep KPAmUOtC5E8e3eiHWC5cuhnYOqig13m7OcwBkCKo4KxdbY+P0ljCJaJOp56LL3xvtsWdJqtxTst8 lQkhNTN1P7etEL8nilhK0lpS1LTubn18/tu5C9dirZZfGRxz5MWX/be+4/lO+CpDWRUI40TlG1K3 IK0CkHECl3qTtqCwCtI6zGGuTV27WSwHZZzIpZ5FLWisgmScxFTxy1K2BGAdBDNXyrydYJaDMkdk VziOk7QVFY6roKJxkBVjKEUr5rbtt3Go7u7w+m2l0ByXBq3apVQrlZ+u7lsNZW+k7psseZVwDJP3 PWyv1cqBGCesfVHMciBrMGMqSmNWAzJH4Bn51wnALE2TuMS6STSD0U3cGwvFGEdEIFyuDgdN7+om Y60SqlfcebSrsaiUn12NxabFVRIMs98ulmb/ncfScHKX8SSukvjroF2VxYr3dQtLV2exq7O4YpK6 Oov8AMwT1NVZbAKhgijFu14pWjE34KCNf26wy+sGlEGzu5O4AQcm6ix2xew4iOuK2ekmTc3MlcFZ A/LOv4fKKoBWwVorMs8EEvJ5AekisHHgpjjeOfR0kbFWDr3jrkLi26mQeNDONXXQuaaAPcl2EFc4 bOGcqoegW2BMuaeWdUqcdqZSp4gt/tK1zeasOVRaw6y1LuuQPktElYdKv2WKykOlda+sxcC6Yp61 ZHXFPPUQ1RXz5KKwK+ZpSjzHw9DzrUcsm6dVA8WwlqQbEhEsAoAKFr7Dv0kLaAO0dSA1WTwPni8b c9YMbJ3mFD+qm9ElWCrIrKCscbgVYyhFK3YbsitzTTEQrWXRCsvu6vrNyzJ+5TLeOfR0kdGVWa3X jl2ZVY2DL/H7HbZzGx52bkNgz/n1GQ8XM197H9wquPf66t17ZbcA+z2ETsbfXO9liu1HUBbBn3gD U0vdTHu9fi8JzUV3+NmhlVB/cgJyyNAZR19H9BuscjCCOrJEYUQwRYj8bKG579kRzXdihWYxurw9 PbtGL57/Dcw2WmMXPVgBUf+g5t8czZDD6TsPEU3pQhPfmyGX0E/ICtAMzx6wHySU073tZ+shQGc3 p8PLIRr0dtDNcPgGqf5bPH10XyCr8zKebj9ZS4TkpLzyFvp0Z9mOhy58/FuE3fEr2ri72HyDVFPf ysQaEwPFcsmxgor5pTvx/BmLZYeEHER+TSZ47BHrxrHIt+4u3iC9TkJv8An9b1z6+h9ktq+cbxgN w796T0TkLddGXyMw4Hx05+HxN0R07DNZzqza9BskG9sO2Qfosp2DQMNSjqtlB7ly2TNaLrsHio8c O6PwCd56cYInchp9i3R/n0NAN9HJRJrDyMZwqL5zxk/olmhxy91CJ8/OM/rqkRPWFln6+BFdW98s lxDsbNEvvklNFrn2KyHNtX2Mfsb/xJGLya+2g4ZPBPBzTOnfnpyQfH5GgBBKyU9Xjus65I3oDRIN KoqsTccnGiq7fdmRT30pRJzTbdz2rUmI5th3PJuKuuV+C96mgCfmx5L1MX6yHD9gEmz5diwSVLH9 FVvu9oVvuWMP1nw0fZPVp/LT7bgRaDTLhvseSuUwms89PySze0HO29MpWQ7BHI8da0pee7vT/YXY +uhvzj8JKErmnQXTekt03FPkVq4B+KaNQ8uZQkjgmyM6scAETkjrMfa3Nt6D5hPkWtBgwi8w0OMX OOj10zkYjr15XXn9MjhZd0DGIZAD9T5mSGJAiJm1CzsX3LNh7oT/REz8B0y0q42f8ZQwzQaL0RqT Yw95xeJrd6AMiUbGZM7vZFRkG2XbBttOWEIzGmfienpFMrma6avEo5E9ZIVFNP6MHiCSLkvpCZIc kcInaoxZNjlqEcVJDA0HKnUQK8SKfUU87FGJR43i211FDHUsBTDz55Hvbce/UxNt4owZJaUKEhwu jk/9FEGPe4NdoCzVliCNhMeX5L//SHSmwNgSMNmxof89v36DoYq7Oztob3D8j2XWvo89oyDce7p2 9UG6FZ9/D7Eb1N8yNu3sg141uPcxU3Ja+m+Y7K3PGM0sxyXHHRfTjYVuHsnlLNl6bTyhfyL7clHD 9hrpUoxHI3suXRR4M0z214Bsuy5+yY2YUkTNkrGPobEr22wcG+o5jvn6a6nBoJElk8gds23UCV8R OTCjRzo0nxohY/hww+mBQ3R3AFvywR56cMJgs0dpJZMecFmECtFoZE7ghJHFCvux4kAg5B6hClwq MFIyxoXAMyuOTjobPg9jFKHQyJRkMLMoCIkwZ6M9uHQHz/vvQ4cXdtt9Xbvtbro9ntIAuvgWM9HC NWQ37by7PT7Q72MGJVcIQvfzICQKboZc7wUFeG75FouGIrrth/nTawDqPnMZ9wNd2z9MvUfenUYZ Eo2MIc+YZf4EP0D8h0sGF4SWO8bJfXqSIMQIS7p50AAy/N0JQq4jtkI0epkD/mtsjZ/SOUro+CH2 AlyeXJ8gZwIR8/TLIgKjAr4hWYFAhMHOftUgy0RdVE5aoNDLFHK8JgY3sQVCqDrDteNWv6VmWzPR x7wx1bDVYy4jkaj1G2ogxToK2jnE+umE/PMd/F7UXcoz8cLA1MjDqlolLYgo6u1eHKrGrMvEgo4j kGnMSpNEtcdR7hSjPjRjnrAYQpmZmHHuJTZdzscX1CmX5mXIBVkfI3gFQMFjRm1ckxfoyTA9LcaL u8HiIVJ943Id4pUh0btj2jgY+84DprFryY6PQtjbybqNAhjchRf5yPJxKqdouH16dnXCwxZFKPQy BQ4LM6IGfHbB5GNMxxYFC21GfVRx4KeFILvW863am/AsS9ojULMZraqmNdH8tOsnipJTmA+nMK9c 12bEItGICwahmfUKnpCZ5TrzaAo7Cq+2qhxFBnqpjoZAyMSmXRoYG41+Dc0g/OBNJvDaDxy7D3sj w7aSt7sdRp1hSnR/bPukN/ip/se03d9n2wnoMXru422caR+C+LLK1GHRq05hfadLMF5PvGez2nfV KEH1dcCahf2jnNAqOpyVCG/9MaTy1CaFQK/45wbqTDFzpZER+Xg+heQKG5OlOqYqmq1tzrUhD9gg A2CmvtM5Sk6ME+c7prk0NJuddh1CY4vaQg+8BpUKFHqZErw44fiJzdbY820IzwaZfQ3JSMEliy0b bL+Z4zrbAZTs5FWZLSArUagHJoqgvWOFys4Hi2tNNPYilxqvJedL1k7uF9j1w9dEIXAqVnWI9C4l DFEu7PI3vTAn8k0vK0D444vihBredSQLVs0iWkGq8UdeRCdUriHvNrGfE2dmsbHYsvHw8kRTvbjW kDI8epfQzIE9kXlo8uEo8aVgaZzj/94Mh3FYJNeKUoRFL2uSQK1FrFJuShfTuRVrDKYpHdbzlpMz apDoZcwiWJtXo5a8oUZZriD/4iMrywtwmjU4stO2JwsPNhFHGxYt5gpEUIlHr+BTi4DVXWJpB0xP gUc7viIPiOFNTIdKfce5XtQh0ssgLm1eovM42dIWvBqds5LUB4Ryev9mjn2oDbUFtgGxsMkLvjN5 ZTnLVoiI+WnN51MH7laaXCjqkJQ7zU9vhp/X8SYXxvXLTXrXCg0ZUXzyZ2qGJhrF6yl8cnw7o5K4 VFrzhqAQv96VnPMf21ZoQZAMjPr0ioz4Zysgv714i+JmyWiJpITWtKENae6wpQyRXgZNaN40uj89 RSE4IK1xY3RALuis4XU1qmoFiSxtVoOCx6xDhggip5dk0fpK0BWjAIVmTfEenTAriEn/yAuHJ0CG tghYsvnTCAnO1aMMj94ltLTYt+iOR4aOnPnzwSLv+XULedlDULxNci4oNUj0Mmbp7BOHDZWNcAqG QpIj7cxwUvWEkznqEOllUEDFGL4fJaOF664nQhvyceBNoySUCMZOxguq05tMAhzC+YiTO4qw6GUN UwG8283St9XsIl0IuNJdBM5JLGSfyhc7J3G6lnnEQBEKzRpAtZNFk1tFmuDiLs68GdyeDE4+KMOj lz10u2aej0qXAycHRECpUZjqcyQ+tMLMBA1WGMJLJ0iIl0miZTg1phIcepcICwNyoFbe4jzJaNhi 6zhTiikJpOI+t7YCrmYZqY/u/tDL6Bzml+dYeZWeIpKD5RA/Y94QX1Vo9C4mZgIFOM32QCejs6uT zyyNI836WETeJ3sn0OSRf3zOhaUOkV4GLbJgModMK2SFOMmntLybC7NsTafLB1Fud5kiLGr0TxdY rXwbz9wMsXonScReCCogoyrmvvfs2OCyGQ3TAHpODaQOkd4lRivZpsmpqSqIQid3s8S7lkTBKVk0 h13wrNpNmzanoCHwz+C3CqijbinEKk38pg0PphgqUaXlqDgXjTpEehcN/k4mJx9ORszybG1DSg7/ fY0YODWLpguW1b1oYgM06b56H1iP+BScAyDO6pYMFxq9C4ae2crEHHbHTAFbRhLvupGEqmb5dOGT hpYPraGzKHyYzL/y9dOAR+8CUrVkNC8S9fF+H3qRnMatosaY3ivGdZEXMsruVqkq9PFkCiKd84nw RZYpRaR9maQujrJS04vakOwsMsFWGPlCy6cdfDXLqotNU7qsRk+JZ2xOIwmzrWczvviSVt0CS0oN Er3LaXlcFzTyMhlWpvgwvctz+D398oDVLKAuRk3pAhqmpULJboB97I5p1jTRli5re/jMekg5SRvE Z76zcUvQamSli0RRKivNl55LdzTMZmVxZJxCowSHXlULPaHIOZ2F0CXRYKx+LDQeY3kkIJGwBkIH Qugm1hgaSQkkDKhBopcxUYBp97WJ8xixhiy8m0zNm2o0QxdyoVQzfMUuOZlPoY1k4AQhXjp9wDnd x5a9zVodUK1Pf3/xHW7NoASH3gUQG4li0ZiqTxxdWIRSUb+Pz89n58PTu8vb0eXNNZW1++vL0RBe iIKcZ4pTumXB6hVotgsPncdfrpyx78UOBJEMMA4IasS+u41XKvannu+TiVqSUCaXi/PwUhL7r9xX aWowKJGco+5KeiUK8/L2Dl17YdKU+MwJxlMviPy0u9/uwcEhZPhT99t+r0+/Rv7AKT/K8OhVqWQ0 R1Cv7AVPp/DfU2/+SukqG25AxrtHx7vf2+dVuQow6GJJI0VqV/oK7tGz6zhJyT+M1x8NWRxHPuRQ nBJWOzZmhxvZbPu9tJVeM+j3MYVyy4wWRcx0TfXxlGW2echK+qzSalToxSFrJInxmuHQ9+be1Akt rrAYhWg0MmcePUzh+gNiDlwcQutdHECh7pMABdH4aQtuRsgAyYk8ra6cyXvjzKdTh0Xn7hU7+X0I WQ9oWzKWCJKfZyiSTf4eTaF+BbKxC531+VrcqsGgkSUBS2tgMj21/EeM3Gj2QKYN0tRdextcN3yn AUFQH1uBYZ/VzLcyPCILxXqk7o/FddSizWYqQ5B+wae+FCHRyBh632Shq5P/3j45PT0fJkdlGPnC +4PyviHYLInKSejh4Y1KPBrZEzcTGMcWAZmzABrk0qsXMtbnaAo+tQfWl502KyW6+cXzv/HwpDVw jYzA7rPjey7rlB3XEovmc88PqU9leD5CsPcwk4nmMSHXc7cDsKm4HJRKEJhhCG0860Uhivdf8p8w Ph2Nic0Zi76LH9mVHZ5M4BzOV8NfIRqNzInlNDNjXBtazWsfefNiTXvR6RXthMwSk9zpa05vMt+O s4inuLPcR8d9HDkzTGRmi4f9KvFoZA87ETiw0xIL2fGigIwZ9AXoV9cLqYINnTCCSw00JnTQRi3s di+2j3nYoxKPRvYkVqKNH33L5r9FrHvvfazGgjtDfVwzSmpDBGFyEiPLy8e/RQ7s99l+5lljMD61 1FcwUoWivDwjXfQm6zOWeoLoqEApJeUR47ICQBG1qp04wMyHv4AmK4vm3GpY8g0+ZbX4NaqCmfVP z08LkHgBzkkHiAJRYaHvTac4LdgAeXq9+GxDDDHMtZMoRaRzK6GbHHOtJIEzNFExO3xQ9zCtvjdz 4m0y1pVcJyFVODSyxYOomLgtSHJ2fcBT74Xvaqrx7fexncjxdpRMvxP3O0wWBnMeeAutnulCJ1yj SB0Wjay5u7hEl0mL6C2gIWAbVpjEbgVxsjF2/PTsTNTOZx6WtIeukRWJL4CW2vuRh7zyN6SGXLCT utQWhbo1aVAWm2dJpOYXK3DGX30vmj8P4NDBDhqLg8cDxCXyCIISBBoZQh4rDK3xNxrBGE3tjOPe Wrju0/MJdghN1NyKP+FhijIkehljO4Efzdm9jp87mSF0a/nkwBlNLZ8dS+l0J/YEqHKq0jiZow6R ZgalifPFtslb8V/LWipzWbUq4JtgR1nQNytWAX9d7ge4ASpiCuVKPb5O1irx6GUPkVtiCP0zrs1I /asZKzxD1WLst9gnFnkAh7xNTuYowqKXNeBRtqbEOkodylN2TEsbHcPMErDfyBy+grWYMRzJ8Y2T N6rQ6GVO2mC2vOQLdywnNxwp8gpmW5c6qdRsgzPVzfIaHjLz4MSeOS6LsEyOUYvvxEYXj5AoRKN3 iTwCcvTyhN1yw3JhfoUe+sHGRPK9V2z/wKwxzvWjBonuPYfoLrCt0h79DhmuRTQhbIpQL3WWWp0P cPcy857BeeIQ4woylXh7QSnDo31LBgl2CiVAeXVqMwBdBDUO2ACHhxBFEGsK8KVTYai5Hthweri3 lX6D2i4Wz0woRaSRQZkAFVr8kQyU6BHXC7eZx9YhdGw2RG7w8EclHo3sqY5JWQ7guAyZr5HsTA7o n9ByIV6ahzfKkGhkTOxQRVBRFX0lmxEx6T6To/P1zejy4u95d3+wWAlg+M09Ot1cil0hGo3MIeOh A8bu2H+dsz5dz6wCkTdZGirdzYmU26w6OtmlvGe+Yq/qsKhgjeJNoRQtengce1PP//OnR996/YQo 4BjA08L8J0emcHu6z8z/gFhJ078E35z5nNLu0dPGIzmph8Sapn/8E579hZyzyGf93cMtOH1htP+n z+RTAvuJwkbpT3ksvhyWgxjL3k4WjV1KtLwYWhGZaTdMehTQReE7z9b4dZPLuuB5/yMbFxeRD1vZ FlQon3qvLOR1gobXV7foGZKO4WaccMyj9jh8/LwL+psoLx72KwCvkRl356c3V1fn12fnZ7BRkaM9 sYK2oNUDGVLmj6yuEhCUDJleOnFtlKpwaGQLdum+TjW0R7TW/MkZoyDOvMns6NDkHI2jICS7v/+Z BQTyWVZqMGhkiY+DORh4cZN32MZclm73FPe0pCIOmof8+dGhx7TFTs93C6QMiUbGOESgaeQM3b7z 5wUniMNgp69pnQtW7OSRlsVJRs7DG5V4NLIHJi29doE4TWr2QbANUYLu2Jlb0wBt0ByQTRS3kCBD nuJHcoCYcVaUUYZE54KC0VOxdVwbk9kCQzmOId9gdshnlmDwmcWVbVITkMsGaAv7fdgHBdfyCoqK lYX/HS2yNS9Prk/Sg3HLJNBdLrDvY+rklhTNzLS9cUStLmhF45JNIU54hvwM4BvXAhKD9E6Xywrq qpUtl+OFXF8tstBo0BO1d2JjgGx7cS3Pfm9ni/zDMvoHvR3pFbWnCvPHXnQ4a4qA78dysnmD6TJi NWkDWoxgcHC4g/6X/AQ//IMrsEEpIo0MIibIjN1rkP2Y7L123LYnk3IZx8GzEle5gEZCAw9vVOHQ yJY0qjGzvqDM9f9eju63R+ivvf5g8I8eWkxiPOFBZuQ8rFGJRyN77i4yI6+aRtiJFqqJFUJJfu1z bXQK0Xx0JViz1k7h69QNFN9lbizYuQml7kDgeHWgKjwa2RNXoKHLKwleDoipAcH2ZaqbiliSgJEo eR7+KEWkk0Eskrs0Bi2J2DudZS+KYeRcHGkFWSMLCmEj/BfqDa9+ZMW00NNZtQ373y+RlVi3ibao 0Cw8U6ASj0b2wNLP1blIbaLMGHNNowPWNZoQ+g/eJagMiUbGLFpjg08WEvgh6JFrNTa8+j5WY+Gw vIJSw2WH5f7O4sx6l9Zbr6G17gS8Xwfrnc7TCurkls9Tr59k36LrtBB++ymjBjcH3PcxfZLK6/wa 7e7soL3B8T8ax1fxfY3DzTzQsmaOybSPiBxBW9vITbeEYUi2Asu36RUqLeCwhT6dj4aXPCSqwmGG LemwFhO1hX5lt+nE5hj0+j+iM+fRCa0p+tWxMdeFmgr4anSS+iLGefK++J5ljy3Wrh2RQ+GvXza3 0IVvzeCDIPSjMTRB2kq7wY49CDlqVlE1aHiRaLZvSgcOFmumazS4O1gAMqvmGHzaQidz35mi/vHx UZ0NVApdHPL70N3LYn6svuIyef1/4SbmHxTSZVJ18iQIyLvE2r6m9e0CdBKFT7TUw1Z5wY5PZ1Zo bd88Y3/7FKZnKWOjdqZbDSDZ1j8VXjVW1KSUQSj3JOe4hedwmDu9/IhufS/0xt40MVUSPpQCpxqA n+GZpxRswtOU55+2kmH8NXIxGuzs7Om8B+DnK5t7ehyMWRzUjb3GdNSsSPJk/N9p+MenMJz/+Pnz y8tLzyGH3J7nP362UvKCz/ChM4E2N9sz5+Hz/30M/8ibO6EKzfvQsnKztbj86A/4TOSyF8yIV8Fs Tc23pIH9ECfFzJhapZ9aU0H5ao1nTdgToHuX/IcY8iPfcoM4ZRcNmQUikAarAIMUSwqGhPqC7nkC 6Wxa1HGFqD1ASX52KFXp9hcQ240Yst/Rlx4x464sf/xUw0hViDQKV+mQyQ7U3yro3jDqOW74mSqJ z0EY2a806zH4TORk57hRvZdiohxVgK/T8/ElN88yL32h0/NvS8+T8Xquvc1aqVEKsnq5LXtE8Zhh T2bzqVeziZLN6FZer1ELFGaYcobHmFZ8J1p1IEpu+ctmCFG8//AcL7otR3DLOdoV23Ey3+82nLe1 4bApvKN/xi6rwdWWKXzQzbAChHVj7/Px4eZWei8wi6ahsz33IZuLjDPx8NLdIUz3AkGutEckxaDC iWslNaczT+BFEIgFBYas0EqryGYc5rYThL7zEMHk9xK3eQ031aDRKGalA+4fHx/qOW2l1xAt8X3o rQ/CzPv943/AXZhlu5AGPOwRDfZf+BW9eL7NJA0ayjguBCrSFK1LgdbpajCYUZp3i1Av9DN+xlO4 /fpyeov6e1ssapMQFjtSqCCKWmzyCN6H0Ba0tvoKuCgWwf3DIyKCV+PTqff45Dt4C/0XkcJb7H9z 3IBsVb2Ki7bh+MnD7ouFpzaI7l/J906tANOfhC7dqgdRehd0bqfwa0ZZ9m3YLEq/9NfeOl/RLXPl zgMuX/UqyUpnqIf+Zk3thyggZKZc+DRM7u9Rbcc7/np6S5KQZXkOWT4za8IinrTafxXOybJRpTEj A7QxvLp8HmwSDTQcnaH9I45buzyGGlBMmRHxz0QPHOtUZqUDrh3U+txVatbB6stZolT9Ha+DDi4b RKeD4VGtg0f4exjVehvUqN8YD3QYfiYKzklynqkaMn8mqhjWsnI8FtRDS/zhAfZOVZb6Mgko0RZH O/Uqi66Jv/aWxFNAHTUhKF0aOUVTiV3XbOcF8RMRd2pfQOmXYdqcqUbyj3ZEPfutcJhhC9/SLiP2 3a5jOZ7SZXN0sFtYNnQxXPTQf1lBiN0nb/o7xHc8ZaL+AkSLN/PwXx0WM+J2dfnlUyz7hIqtNBhv R1T6mgG9001FfTERxMSq1ILaHRz3iaydWa6Dp9To2kI/WQ8YdNwW+kKNsSh8cpj/LK/+axhTgzmt KrKzI4B5qxy1GSFfsgkr7cA0Vvmav4u0QjRq5FF9vl6eyhPb9jGx34N4uVeKKTgkX+mdepKNxyWA vKiycrmFLvCDH1k+xbe/jO+Db4MsZxWx8I2frQdiLy7nBRQj33lkvy1sQ9pgKaT/zrIdD11AwjZ2 x69Vwf+iyqAdFkOsud0mU/pM5nT7cudwe2evP+jvkMWXjZCpDdMv5YQQUDOEL10M0itT2qShN/Zm n/Mp7CqCbgQQvA/lVdim9KUrJ9sPWji01SQsD3qckD/0/vPl9pIlkaHh6egcweaQhgUFaBg9QPSL E4YYV28dPItNKSIzWqg67SxTpOqLFWDAgG5Z8XNBRdQKx1qxhU3zYLA9oEYm2VFkgj/lgK/FLhWM Q0wTw4JEylVsTU1QP7oyu/35fviPVRjTLWGbEcllJbKsOdDtNArEGNEe+hqwAqxeMqF/2L7s94nJ S/53mKbESxnRUsDXQk29N2Nasb4qRSvWWmZfounL3k7S9OWIt7eMDJrd4wTNwSp7y2SewkqBql2q j7RtcHSLsrMoFhbFre9Z35xgZ4cvp6T4dTPidDX+6lsv2z850ykYKXEE/2kuz2EL7YVP6Nx24Ddm QYtfK7XF86GFK6kODoWgeuiv3hMwCy5uPi27IzfuLjYzZ6FFFCCXVCrEY0acs6GOYGTSe5qr0+vh 5/hUTHTYfOpAf8O7C9bclV7hCqdWtkdkhkFJ8WFiZkaPURBKRSjUA3kfK7Xg6FxJDTRYcbt7/R16 WIxDHNFV5NqvW+gOAoMsWhG7IlDyLHcx/KVHVi1+IW/wxyOJ407cpmf5q+ES5BrkoPS2EUpV+Z4d 0WYodHAnc7IUx0m3jHz8EBerpKGX8y65ON42Fhyap6lUuNJBJr7XZLozkeVQPA/D1Xd8sQvixCF8 POGfgkjzyd/GQ83LR1PDkXelOyUGhNgtdJ/dQq/4hkElIo0Myjxc3v8lm42HNYpQrBVT0iuA/irv F8qBm2FEd79gUpWxso7BD4uwp8YhVr/ykTeEM+vZsYmKmYQRX4uHku9LDXfJ9t/dWUlh2FKra4R9 65WolZxnJDaCOCIclsGmpUZHl2iEx0+uN/UeHbwMUOOk7u7tkJH4/iu68L6jM995JpvsMHJCiDIe 8EwzHwSNJN2EofVibaEbN7R8h6u0d8UrGgd9Sgxq2+IZa/6bH1kh3T55Lv4R/aGPDvq7aP94gPo7 +wOEv4e9wYBLdvkgqFFaKylCeT6znOmPyAZV2/Opqv3PUkUWMkWWhPASi7qGPwLwE41GFGMJ7I8s ned2RKwwj6xX8q/LtbQrXtGqhh7ypeh+th482kLegbKil+6Yy0wVAKORuKP9I7KRwz2Hj/E3dOr4 4ynXCbX2RY0E/OxFTvDsTCFP5PSGjIucbeq62aYE1L6okYD74QnPcDNf+8gaZLE77e7sooMD8t/d w30eBta/qVMJsv0D98ZMpf0nvb+eWg9Bwxa00IlcEN6smPyf7IDaIi1Q+qdCyAv52hMiH8BW/edP +59QPK4xBofKp4XVgl3701/+r/sQzP947tpQWIXFowQ99uGfPluA6WkJHRtdJfxk4DSghWB78D// hfZOfwpnUwSWEnqxAjSnLn1so4dX5E/G9PN+b7C/haxnIg50d5n43gyR4T75ePLnTxlPCNl0vnkv OPydRkg4OJx8Dj0yos8xpM+f0F9Evg6UojxnyQ8whvjnB89+jX8EMv7yf/5/UEsBAhQAFAAAAAgA qkgaM/NbMWV8wAAArOcKACwAAAAAAAAAAQAgAAAAAAAAAGRpZmZfZHJhZnQtaWV0Zi1pcGNkbi1k b2NzLXJmbWlidjItMTMtMTQuaHRtUEsFBgAAAAABAAEAWgAAAMbAAAAAAA== ------_=_NextPart_001_01C5AA50.1DC4AC82 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn ------_=_NextPart_001_01C5AA50.1DC4AC82-- From ipcdn-bounces@ietf.org Mon Aug 29 04:58:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9fSy-0004sJ-7P; Mon, 29 Aug 2005 04:58:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9fSw-0004sE-5B for ipcdn@megatron.ietf.org; Mon, 29 Aug 2005 04:58:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25201 for ; Mon, 29 Aug 2005 04:58:04 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9fUF-0008T9-2P for ipcdn@ietf.org; Mon, 29 Aug 2005 04:59:27 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7T8vlBO008969; Mon, 29 Aug 2005 02:57:47 -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] cable dev mib draft09 - WG consensus requested on proposed changes Date: Mon, 29 Aug 2005 02:57:46 -0600 Message-ID: Thread-Topic: [ipcdn] cable dev mib draft09 - WG consensus requested on proposed changes Thread-Index: AcWcNEOXOYZ0b+qySouBm0pyfZ29vACXuwPQANTemlACGL+b0ACJ2AHQ From: "Jean-Francois Mule" To: "Eduardo Cardona" , "Randy Presuhn" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a961490db2a74c7613bf0201229f176 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org, "Richard Woundy @ Comcast" , Marez Kevin-MGI1375 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Eduardo, Thanks for your response and input. More inline. Jean-Fran=E7ois Eduardo wrote: > #issue 1 >=20 > a) I probably missed the DEFVAL added >=20 > Normally a configuration will try to allow access to RFI CATV (bit1) > interface only ( as DS interface and US interfaces - bit 2 and 3 are > not set) >=20 > My preferred DEFVAL would be DEFVAL { 'c0000000'h } That is if we were to keep the DEFVAL. Do you have any objection to deleting the DEFVAL clause? Per the wg = meeting minutes, that was the proposal. Can you clarify your preference? = Note that the DEFVAL was not present in the to-be-obsoleted RFC and = given the issues raised by Randy, the preference so far is no defval, = add text per the meeting notes. > As today '00000001'h is pointing to interface 32 which I do not think > is part of any CM implementation That is yet another reason for getting rid of it. > b) OK with the text, but also recognize that the object is already > deprecated Ok, the clarification text should take the deprecation of the object = into consideration. > Issue #2 >=20 > Agree ok > Issue #3 >=20 >=20 >=20 > in docsDevFilterLLCTable: (you mean docsDevEvReporting ) Yes - sorry for the confusion. Thanks for the input, I think you provide some elements of rationale = behind the added text which based on Rich's email from 7/24 was not = clear we had. >=20 > Any attempt to SET the traps(1) or syslog(2) bits >=20 > without setting the local(0) or localVolatile(8) >=20 > bits MUST result in an error being generated. >=20 > Currently the specs require (for backup ) a message send as a > notification and traps need to be send to local log Is this requirement in section 7.4.2.3 of = http://www.cablemodem.com/downloads/specs/CM-SP-OSSIv2.0-I09-050812.pdf? = =20 Section 7.4.2.3 does establish default reporting modes based on the = event priority. If this is the right text, is the requirement pretty = much the translation of the "error" events row, row #4? In not, just so that everyone can read this DOCSIS requirement, can you = point to the DOCSIS spec, section number or paste the relevant txt in = email? =20 > I see that the recommendation is to not require that, so just to > confirm that our specs need to align with that Ok so the point of the added text was to align the MIB object setting = with the above requirement more formerly. Note that if the text is deleted, you can still mandate the same = behavior (all the text deletion does is move the MUST requirement away = from the CM SNMP agent to the CM config file and sysadmins who must must = make sure the 2 set commands are in the config file). The proposed text deletion does not prohibit the DOCSIS spec and you can = still have the Docsis requirements right? Now Randy, what was your comment about? about the fact that with = local(0) you have persistency? Based on the above explanation, and the = fact that the DOCSIS spec pretty much makes it a MUST for CM to do that, = can you elaborate on (or summarize) the issues and is there a better way = to word this behavior? Or do we still prefer a deletion of the text, = leaving this legacy requirement outside of the MIB? We need to get closure on this mib module soon. Thx for everyone's help = to resolve this. > Draft 09 says: >=20 > SYNTAX BITS { > local(0), > traps(1), > syslog(2), > localVolatile(8), > stdInterface(9) > } >=20 >=20 >=20 > From early 2002 CMs (DOCSIS 1.0 ) support ( see early drafts 03 CD MIB > v2 ) >=20 >=20 > SYNTAX BITS { > localNonvolatile(0), --> local(0) > traps(1), > syslog(2), > localVolatile(3) > } >=20 >=20 >=20 > Would it be needed a note for compatibility ? There does seem to be 2 distinct requests from you here: a) ensure DOCSIS specs are inline with cd mib v2/rfc2669bis: see above, I think we are ok there, even with the text deletion but = Randy who raised the comment or Rich and Kevin should speak up. b) providing some "compatibility" with an old version of the CD mib = Internet-Draft. Is this correct? On the latter, note that all we care about (here in IETF) is backward = compatibility with RFC 2669. I'm not sure what kind of note you are = looking for. Can you propose something? > Same kind of notes for the requirement of local /localVolatile when > configured notifications and/or syslog (back to DOCSIS 1.0) Can we leave this out of the MIB? Based on the table 7-3, I think this = is hard to do and now is not the time to add brand new text unless we = can just fix the current one. > My concern is that normally those values are set through config files > rather than SNMP SETs , which are going to be hard to map > capabilities/behavior for provisioning systems I don't understand the above issue. > Issue #4 >=20 >=20 > As today ( I missed the discussions) >=20 > I do not see in operations (but probably in theory) that CMs currently > persist those values, because prior to registration the CM does not > forward CM traffic (moot point of the tables applicability ), and if > the config file comes with same entries it will fail the registration > process e.g. createAndGo for an existing entries >=20 >=20 >=20 > I would say "SHOULD NOT" , (otherwise specified) , there could be > options in the future to streamline the provisioning process and > reduce CM unavailable time in case of a forced reboot by Management > system, just not to close the door if I understand the suggestion of > using "SHOULD NOT" So you agree with current consensus, thanks. >=20 >=20 > Thanks >=20 >=20 >=20 > Eduardo >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Jean-Francois Mule > Sent: Monday, August 15, 2005 4:20 PM > To: ipcdn@ietf.org > Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on > proposedchanges >=20 >=20 >=20 > Folks, >=20 > As you may have read in meeting notes from last week, we spent the > IETF 63 meeting discussing the closure of open issues on the CD mib = v2. >=20 > The meeting notes proposed some changes to get final (yes, final) > closure on this mib. >=20 > Please review the text below and please speak up if you have some > concerns (it's also welcome that you express your agreement). >=20 > Thanks, >=20 > Jean-Fran=E7ois >=20 > [extract from ipcdn minutes] >=20 > 3.1/ DOCSIS Cable Device MIB version 2 >=20 > draft-ietf-ipcdn-device-mibv2-09.txt >=20 > Editors: Kevin Marez & Rich Woundy >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2- > 09.txt >=20 > We spent most of the meeting reviewing the 4 top remaining issues, see >=20 > summary sent by Rich and Kevin in: >=20 > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html >=20 >=20 >=20 > + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces >=20 > Raised by Randy, the issue is, in the defval we have a 4 octet value >=20 > =3D> How can systems with interfaces in a number not multiple >=20 > of 8 interpret the DEFVAL value. Are bits ignored? >=20 > Randy commented that he would be ok if there was some mention like >=20 > 'octets containing bits corresponding to non-existent interfaces are >=20 > ignored.' That said, if there are implementations that would reject a >=20 > SET, then we need to say something about that. >=20 > Rich commented that the DEFVAL was added due to prior MIB doctor >=20 > comment and that the object is now deprecated. Bert asked whether >=20 > there was any concern deleting the DEFVAL. >=20 > Proposal for wg review: >=20 > a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } >=20 > b) consider the following (NICE TO HAVE kind of fix) >=20 > adding a sentence to say something like: >=20 > bits set corresponding to non-existing interfaces is >=20 > implementation specific (to warn the mgmt admin/apps that no >=20 > assumptions should be made on existing implementations of this >=20 > object. (Randy's suggestion) >=20 >=20 >=20 > + ISSUE #2: docsDevNmAccessStatus >=20 > -- Also, we should change the DESCRIPTION of docsDevCpeStatus >=20 > -- and docsDevCpeInetRowStatus to document how the agent adds rows. >=20 > See issue raised by Randy and the email summary provided by Rich for >=20 > the context around this issue #2. >=20 > We had some discussions around the persistency of those tables, the >=20 > fact that the CM config file drives the row creation at boot-up and >=20 > the fact that they are read-create tables so admins can also create >=20 > entries as Bert pointed out. >=20 > In most cases (except for docsDevEvControlTable), entries do not >=20 > persist across CM reboots. Even in the case of docsDevEvControlTable, >=20 > after some discussion, we believe that the entries are cleared and >=20 > "recreated" after the CM reads the config file. That is the common >=20 > understanding. >=20 > Bert said: add a statement ("this is a deprecated table, this is >=20 > vendor specific as to what vendors do with this table, mgmt app cannot >=20 > expect a certain behavior"). >=20 > + ISSUE #3: docsDevEvReporting and local(0) rows >=20 > Comment close: ID authors agree with Randy's comment re: local(0) rows >=20 > MUST persist. Text will be revised. >=20 > in docsDevFilterLLCTable: >=20 > Any attempt to SET the traps(1) or syslog(2) bits >=20 > without setting the local(0) or localVolatile(8) >=20 > bits MUST result in an error being generated. >=20 > Proposal: >=20 > DELETE above text if nobody complains after reading the meeting >=20 > notes >=20 > + ISSUE #4: docsDevFilterLLCTable >=20 > Issue is around text for the level of requirements on table >=20 > persistence. Agree with Rich's text proposal: >=20 > |"Table entries MUST NOT persist across reboots for cable modems." >=20 > Rich also proposed to apply this requirement to: >=20 > NmAccess, FilterLLC, FilterIp, Policy, Tos, >=20 > Cpe and InetCpe tables. >=20 > It was suggested to use SHOULD NOT rather than MUST NOT but other than >=20 > that, proposal is ok. >=20 >=20 >=20 > + Other items on CD Device MIB: >=20 > Randy added for consideration: >=20 > wherever we have this "must not persist" langage in table definitions, >=20 > it would be a plus to indicate that they may come back as entries may >=20 > reappear when CM reboots and comes up with config file. Or consider >=20 > adding this in the front paper as a consideration for users of the >=20 > MIBs if that is too many little edits in the MIB objects. >=20 > Proposal: >=20 > add a note on persistence model explaining the persistance of some >=20 > mib objects and the CM re-creating them upon config file reloading. >=20 > A comment was made that in general, we should indicate the persistency >=20 > model in each object rather than in the compliance section. >=20 > Bert also commented on the compliance sections: if different >=20 > requirements apply to CM and CMTS, suggestion is to make 2 different >=20 > compliances. Rich added that the new compliance statement is designed >=20 > like that. >=20 > # AI: [authors: Kevin Marez & Rich Woundy] >=20 > # Authors to summarize list of agreed changed and the technical >=20 > # changes in the text per wg consensus and issue new draft after AD >=20 > # review comments are in. >=20 > # Due by early September? >=20 > # AD review by Bert due by August 15 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Mon Aug 29 08:09:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9iSb-0004Dl-F1; Mon, 29 Aug 2005 08:09:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9iSZ-0004DT-Ht for ipcdn@megatron.ietf.org; Mon, 29 Aug 2005 08:09:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04321 for ; Mon, 29 Aug 2005 08:09:54 -0400 (EDT) Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9iTu-0005lc-46 for ipcdn@ietf.org; Mon, 29 Aug 2005 08:11:18 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.13.4/8.13.4) with ESMTP id j7TC9iLD000953; Mon, 29 Aug 2005 06:09:44 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested onproposed changes Date: Mon, 29 Aug 2005 06:09:43 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46FFEE75B@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] cable dev mib draft09 - WG consensus requested onproposed changes Thread-Index: AcWcNEOXOYZ0b+qySouBm0pyfZ29vACXuwPQANTemlACGL+b0ACJ2AHQAAdnAXA= From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Randy Presuhn" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org, "Richard Woundy @ Comcast" , Marez Kevin-MGI1375 X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Hi Jean-Francois,=20 See inline=20 Eduardo -----Original Message----- From: Jean-Francois Mule=20 Sent: Monday, August 29, 2005 2:58 AM To: Eduardo Cardona; Randy Presuhn Cc: ipcdn@ietf.org; Richard Woundy @ Comcast; Marez Kevin-MGI1375 Subject: RE: [ipcdn] cable dev mib draft09 - WG consensus requested = onproposed changes Eduardo, Thanks for your response and input. More inline. Jean-Fran=E7ois Eduardo wrote: > #issue 1 >=20 > a) I probably missed the DEFVAL added >=20 > Normally a configuration will try to allow access to RFI CATV (bit1) > interface only ( as DS interface and US interfaces - bit 2 and 3 are > not set) >=20 > My preferred DEFVAL would be DEFVAL { 'c0000000'h } That is if we were to keep the DEFVAL. Do you have any objection to deleting the DEFVAL clause? Per the wg = meeting minutes, that was the proposal. Can you clarify your preference? = Note that the DEFVAL was not present in the to-be-obsoleted RFC and = given the issues raised by Randy, the preference so far is no defval, = add text per the meeting notes. Yes, no problem not stating the DEFVAL as the object is deprecated=20 But,=20 There is in RFC 2669 a note that says : -- DEFVAL is the bitmask corresponding to all interfaces So I believe is ambiguous to say (depends on which version Randy made = the revision)=20 "the DEFVAL was not present in the to-be-obsoleted RFC" Not present but indicated as a comment.=20 So we can certainly assume implementations way back indicates that = default although is unclear for me why it was a comment and not integral = part of the description. ( that DEFVAL is not tested, because is not a requirement (hyphens) and = MSOs will always set the interface value in the CM configuration to = prevent access from all CPE interfaces)=20 Probably that's the reason the IPCDN group loose track of the stated = default value statement (back in draft 06 as last version had it) =20 > As today '00000001'h is pointing to interface 32 which I do not think > is part of any CM implementation That is yet another reason for getting rid of it. > b) OK with the text, but also recognize that the object is already > deprecated Ok, the clarification text should take the deprecation of the object = into consideration. > Issue #2 >=20 > Agree ok > Issue #3 >=20 >=20 >=20 > in docsDevFilterLLCTable: (you mean docsDevEvReporting ) Yes - sorry for the confusion. Thanks for the input, I think you provide some elements of rationale = behind the added text which based on Rich's email from 7/24 was not = clear we had. >=20 > Any attempt to SET the traps(1) or syslog(2) bits >=20 > without setting the local(0) or localVolatile(8) >=20 > bits MUST result in an error being generated. >=20 > Currently the specs require (for backup ) a message send as a > notification and traps need to be send to local log Is this requirement in section 7.4.2.3 of = http://www.cablemodem.com/downloads/specs/CM-SP-OSSIv2.0-I09-050812.pdf? = =20 Section 7.4.2.3 does establish default reporting modes based on the = event priority. If this is the right text, is the requirement pretty = much the translation of the "error" events row, row #4? In not, just so that everyone can read this DOCSIS requirement, can you = point to the DOCSIS spec, section number or paste the relevant txt in = email? =20 > I see that the recommendation is to not require that, so just to > confirm that our specs need to align with that Ok so the point of the added text was to align the MIB object setting = with the above requirement more formerly. Note that if the text is deleted, you can still mandate the same = behavior (all the text deletion does is move the MUST requirement away = from the CM SNMP agent to the CM config file and sysadmins who must must = make sure the 2 set commands are in the config file). The proposed text deletion does not prohibit the DOCSIS spec and you can = still have the Docsis requirements right? Now Randy, what was your comment about? about the fact that with = local(0) you have persistency? Based on the above explanation, and the = fact that the DOCSIS spec pretty much makes it a MUST for CM to do that, = can you elaborate on (or summarize) the issues and is there a better way = to word this behavior? Or do we still prefer a deletion of the text, = leaving this legacy requirement outside of the MIB? We need to get closure on this mib module soon. Thx for everyone's help = to resolve this. > Draft 09 says: >=20 > SYNTAX BITS { > local(0), > traps(1), > syslog(2), > localVolatile(8), > stdInterface(9) > } >=20 >=20 >=20 > From early 2002 CMs (DOCSIS 1.0 ) support ( see early drafts 03 CD MIB > v2 ) >=20 >=20 > SYNTAX BITS { > localNonvolatile(0), --> local(0) > traps(1), > syslog(2), > localVolatile(3) > } >=20 >=20 >=20 > Would it be needed a note for compatibility ? There does seem to be 2 distinct requests from you here: a) ensure DOCSIS specs are inline with cd mib v2/rfc2669bis: see above, I think we are ok there, even with the text deletion but = Randy who raised the comment or Rich and Kevin should speak up. b) providing some "compatibility" with an old version of the CD mib = Internet-Draft. Is this correct? On the latter, note that all we care about (here in IETF) is backward = compatibility with RFC 2669. I'm not sure what kind of note you are = looking for. Can you propose something? > Same kind of notes for the requirement of local /localVolatile when > configured notifications and/or syslog (back to DOCSIS 1.0) Can we leave this out of the MIB? Based on the table 7-3, I think this = is hard to do and now is not the time to add brand new text unless we = can just fix the current one. > My concern is that normally those values are set through config files > rather than SNMP SETs , which are going to be hard to map > capabilities/behavior for provisioning systems I don't understand the above issue. > Issue #4 >=20 >=20 > As today ( I missed the discussions) >=20 > I do not see in operations (but probably in theory) that CMs currently > persist those values, because prior to registration the CM does not > forward CM traffic (moot point of the tables applicability ), and if > the config file comes with same entries it will fail the registration > process e.g. createAndGo for an existing entries >=20 >=20 >=20 > I would say "SHOULD NOT" , (otherwise specified) , there could be > options in the future to streamline the provisioning process and > reduce CM unavailable time in case of a forced reboot by Management > system, just not to close the door if I understand the suggestion of > using "SHOULD NOT" So you agree with current consensus, thanks. >=20 >=20 > Thanks >=20 >=20 >=20 > Eduardo >=20 >=20 >=20 >=20 >=20 > ________________________________ >=20 > From: Jean-Francois Mule > Sent: Monday, August 15, 2005 4:20 PM > To: ipcdn@ietf.org > Subject: [ipcdn] cable dev mib draft09 - WG consensus requested on > proposedchanges >=20 >=20 >=20 > Folks, >=20 > As you may have read in meeting notes from last week, we spent the > IETF 63 meeting discussing the closure of open issues on the CD mib = v2. >=20 > The meeting notes proposed some changes to get final (yes, final) > closure on this mib. >=20 > Please review the text below and please speak up if you have some > concerns (it's also welcome that you express your agreement). >=20 > Thanks, >=20 > Jean-Fran=E7ois >=20 > [extract from ipcdn minutes] >=20 > 3.1/ DOCSIS Cable Device MIB version 2 >=20 > draft-ietf-ipcdn-device-mibv2-09.txt >=20 > Editors: Kevin Marez & Rich Woundy >=20 > http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2- > 09.txt >=20 > We spent most of the meeting reviewing the 4 top remaining issues, see >=20 > summary sent by Rich and Kevin in: >=20 > http://www1.ietf.org/mail-archive/web/ipcdn/current/msg01664.html >=20 >=20 >=20 > + ISSUE #1: DEFVAL for docsDevNmAccessInterfaces >=20 > Raised by Randy, the issue is, in the defval we have a 4 octet value >=20 > =3D> How can systems with interfaces in a number not multiple >=20 > of 8 interpret the DEFVAL value. Are bits ignored? >=20 > Randy commented that he would be ok if there was some mention like >=20 > 'octets containing bits corresponding to non-existent interfaces are >=20 > ignored.' That said, if there are implementations that would reject a >=20 > SET, then we need to say something about that. >=20 > Rich commented that the DEFVAL was added due to prior MIB doctor >=20 > comment and that the object is now deprecated. Bert asked whether >=20 > there was any concern deleting the DEFVAL. >=20 > Proposal for wg review: >=20 > a) in docsDevNmAccessInterfaces, delete DEFVAL { '00000001'h } >=20 > b) consider the following (NICE TO HAVE kind of fix) >=20 > adding a sentence to say something like: >=20 > bits set corresponding to non-existing interfaces is >=20 > implementation specific (to warn the mgmt admin/apps that no >=20 > assumptions should be made on existing implementations of this >=20 > object. (Randy's suggestion) >=20 >=20 >=20 > + ISSUE #2: docsDevNmAccessStatus >=20 > -- Also, we should change the DESCRIPTION of docsDevCpeStatus >=20 > -- and docsDevCpeInetRowStatus to document how the agent adds rows. >=20 > See issue raised by Randy and the email summary provided by Rich for >=20 > the context around this issue #2. >=20 > We had some discussions around the persistency of those tables, the >=20 > fact that the CM config file drives the row creation at boot-up and >=20 > the fact that they are read-create tables so admins can also create >=20 > entries as Bert pointed out. >=20 > In most cases (except for docsDevEvControlTable), entries do not >=20 > persist across CM reboots. Even in the case of docsDevEvControlTable, >=20 > after some discussion, we believe that the entries are cleared and >=20 > "recreated" after the CM reads the config file. That is the common >=20 > understanding. >=20 > Bert said: add a statement ("this is a deprecated table, this is >=20 > vendor specific as to what vendors do with this table, mgmt app cannot >=20 > expect a certain behavior"). >=20 > + ISSUE #3: docsDevEvReporting and local(0) rows >=20 > Comment close: ID authors agree with Randy's comment re: local(0) rows >=20 > MUST persist. Text will be revised. >=20 > in docsDevFilterLLCTable: >=20 > Any attempt to SET the traps(1) or syslog(2) bits >=20 > without setting the local(0) or localVolatile(8) >=20 > bits MUST result in an error being generated. >=20 > Proposal: >=20 > DELETE above text if nobody complains after reading the meeting >=20 > notes >=20 > + ISSUE #4: docsDevFilterLLCTable >=20 > Issue is around text for the level of requirements on table >=20 > persistence. Agree with Rich's text proposal: >=20 > |"Table entries MUST NOT persist across reboots for cable modems." >=20 > Rich also proposed to apply this requirement to: >=20 > NmAccess, FilterLLC, FilterIp, Policy, Tos, >=20 > Cpe and InetCpe tables. >=20 > It was suggested to use SHOULD NOT rather than MUST NOT but other than >=20 > that, proposal is ok. >=20 >=20 >=20 > + Other items on CD Device MIB: >=20 > Randy added for consideration: >=20 > wherever we have this "must not persist" langage in table definitions, >=20 > it would be a plus to indicate that they may come back as entries may >=20 > reappear when CM reboots and comes up with config file. Or consider >=20 > adding this in the front paper as a consideration for users of the >=20 > MIBs if that is too many little edits in the MIB objects. >=20 > Proposal: >=20 > add a note on persistence model explaining the persistance of some >=20 > mib objects and the CM re-creating them upon config file reloading. >=20 > A comment was made that in general, we should indicate the persistency >=20 > model in each object rather than in the compliance section. >=20 > Bert also commented on the compliance sections: if different >=20 > requirements apply to CM and CMTS, suggestion is to make 2 different >=20 > compliances. Rich added that the new compliance statement is designed >=20 > like that. >=20 > # AI: [authors: Kevin Marez & Rich Woundy] >=20 > # Authors to summarize list of agreed changed and the technical >=20 > # changes in the text per wg consensus and issue new draft after AD >=20 > # review comments are in. >=20 > # Due by early September? >=20 > # AD review by Bert due by August 15 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From ipcdn-bounces@ietf.org Tue Aug 30 21:45:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAHfB-0005d1-8z; Tue, 30 Aug 2005 21:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAHf9-0005Yb-0z for ipcdn@megatron.ietf.org; Tue, 30 Aug 2005 21:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23210 for ; Tue, 30 Aug 2005 21:45:12 -0400 (EDT) Received: from mms3.broadcom.com ([216.31.210.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAHgl-0004Oy-BB for ipcdn@ietf.org; Tue, 30 Aug 2005 21:46:57 -0400 Received: from 10.10.64.121 by MMS3.broadcom.com with SMTP (Broadcom SMTP Relay (Email Firewall v6.1.0)); Tue, 30 Aug 2005 18:45:32 -0700 X-Server-Uuid: 35E76369-CF33-4172-911A-D1698BD5E887 Received: from mail-irva-8.broadcom.com ([10.10.64.221]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-72233U7200L2200S0V35) with ESMTP id com; Tue, 30 Aug 2005 18:44:44 -0700 Received: from mon-irva-10.broadcom.com (mon-irva-10.broadcom.com [10.10.64.171]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id BRO37437; Tue, 30 Aug 2005 18:44:44 -0700 (PDT) Received: from nt-sjca-0740.brcm.ad.broadcom.com ( nt-sjca-0740.sj.broadcom.com [10.16.192.49]) by mon-irva-10.broadcom.com (8.9.1/8.9.1) with ESMTP id SAA28623; Tue, 30 Aug 2005 18:44:44 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-sjca-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 30 Aug 2005 18:44:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call Date: Tue, 30 Aug 2005 18:44:56 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B031230A3@NT-RMNA-0740.brcm.ad.broadcom.com> Thread-Topic: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result of conference call Thread-Index: AcWRJHAQGZNVoZcsQc6QiTx7E7oIbgAe42+AAAPI/VAAAYTkYALbFMcwAAAtm+AAKDJ+AAMfJunwAAKOOXAA4F8SIA== From: "Eugene Nechamkin" To: "Sumanth Channabasappa" X-OriginalArrivalTime: 31 Aug 2005 01:44:42.0154 (UTC) FILETIME=[8E8EA0A0:01C5ADCD] X-WSS-ID: 6F0BD4362ZW2940343-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP over Cable Data Network List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipcdn-bounces@ietf.org Errors-To: ipcdn-bounces@ietf.org Sumanth, Looking further at the Bellcore specs for pulse flash requirements (GR-506-CORE "LSSGR: Signaling for Analog Interfaces"), it turnes out = that the requirements for the pulse range for flash are higher than it is currently allowed by the "pktcNcsEndPntConfigMaxHookFlash" MIB Object. Bellcore specs say that flash MUST be 300-1100, but may be up to 1550: Table 12-2. Flash Response Enabled Timing On-Hook Duration (milliseconds) SPCS Interpretation < 200 Hit 200 to 300 Hit or Flash 300 to 1100 Flash 1100 to 1550 Flash or Disconnect >1550 Disconnect To better meet the Bellcore specs requirements, the following = modification of the MIB Object's range is proposed: pktcNcsEndPntConfigMaxHookFlash OBJECT-TYPE =20 SYNTAX Unsigned32 (20..1550) =20 UNITS "Milliseconds" =20 MAX-ACCESS read-only =20 STATUS current =20 DESCRIPTION =20 " This is the maximum time a line needs to be on hook for a=20 valid hook flash. The value of=20 pktcNcsEndPntConfigMaxHookFlash MUST be greater than=20 pktcNcsEndPntConfigMinHookFlash. This object MUST only be=20 set via the configuration file during the provisioning=20 process."=20 DEFVAL { 800 } =20 ::=3D { pktcNcsEndPntConfigEntry 33 } =20 Eugene. -----Original Message----- From: Sumanth Channabasappa [mailto:sumanth@cablelabs.com]=20 Sent: Friday, August 26, 2005 7:24 AM To: Jean-Francois Mule Cc: ipcdn@ietf.org; Freyman Phillip-FPF300; Eugene Nechamkin; David De = Reu; T, Shivakumar; sercu@tComLabs.com; Satish Kumar at Texas Instruments; = Beacham Gordon-CGB005 Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further = changes;result of conference call Jean-Francois, I concur. Unless there are objections, I will be presenting the final proposal to this group in the next week. Regards Sumanth=20 -----Original Message----- From: Jean-Francois Mule Sent: Friday, August 26, 2005 7:18 AM To: Sumanth Channabasappa Cc: ipcdn@ietf.org; 'Freyman Phillip-FPF300'; 'Eugene Nechamkin'; 'David = De Reu'; 'T, Shivakumar'; 'sercu@tComLabs.com'; Satish Kumar at Texas Instruments; 'Beacham Gordon-CGB005' Subject: RE: [ipcdn] draft-ipcdn-pktc-signaling-08, further = changes;result of conference call Sumanth, Thanks for inviting anyone from IETF ipcdn to attend the discussion = and for the notes. We have not seen one comment on your posting in 15 days so the = proposal should be good enough. Per the IETF#63 meeting, the action item on the signaling MIB was: # AI: authors to close one open issue on tone table by August 20. # Ask Randy to review final proposal. Can you put out the proposed changes in the form of updated object definitions to the list so we can see all the aggregated changes? Based on our discussions, we are getting close to the end on this one = and I would like to set the date of next Friday, September 2nd to have a = consensus on the technical changes to allow a draft09 publication by mid-September = at the latest. Thanks, Jean-Fran=E7ois > -----Original Message----- > From: Sumanth Channabasappa > Sent: Wednesday, August 10, 2005 10:09 AM > To: ipcdn@ietf.org > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;result = > of conference call >=20 > Folks, >=20 > As per the discussion on the conference call today (thanks to the=20 > attendees), the proposal from Phil seems to be reasonable. >=20 > Further, there was a suggestion to include the following examples in=20 > the draft for clarity and ease of implementation. Note: Example B was=20 > also the cause for the latest suggestion. >=20 >=20 > Example A: Call waiting tone defined per ITU-T E.180: > 1) 400 Hz AM modulated by 16 Hz, on for 500ms at -4 dBm > 2) 400 Hz AM modulated by 16 Hz, off for 400ms > 3) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 4) 400 Hz not AM modulated, off for 450 ms > 5) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 6) 400 Hz not AM modulated, off for 3450 ms > 7) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 8) 400 Hz not AM modulated, off for 450 ms > 9) 400 Hz not AM modulated, on for 50 ms at -4 dBm > 10) 400 Hz not AM modulated, off for 3450 ms > 11) not repeated, not continuous >=20 > Assume userDefined1(17) is assigned to this tone: >=20 > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 17 400 16 0 0 1 90 -40 500 > 400 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 > 17 400 0 0 0 2 0 -40 50 > 450 0 > 17 400 0 0 0 2 0 -40 50 > 3450 0 >=20 >=20 > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > 17 0 false(2) >=20 >=20 > ---------------------------------------------------------------------- > -- > --------------- >=20 > Example B - Congestion Tone - congestion(17): >=20 > This example of an embedded cadence is based on an operator variation. > 1) 400Hz on for 400ms -10 dBm > 2) 400Hz off for 350ms > 3) 400Hz on for 225ms -4 dBm > 4) 400Hz off for 525ms > 5) repeat (1) through (4) 5000 times or T0 timeout (which ever is=20 > shortest period) >=20 > ToneType|Freq-1|Freq-2|Freq-3|Freq- > 4|FreqMode|ModePrtg|DbLevel|OnDur|Off > Dur|Rep-Count > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > 17 400 0 0 0 2 0 -100 400 > 350 0 > 17 400 0 0 0 2 0 -40 225 > 525 0 >=20 >=20 > pktcSigDevToneTable: > ToneType|ToneRep-Count|Steady > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > 17 5000 false(0) >=20 >=20 > Please feel free to provide any comments. >=20 > Regards > Sumanth >=20 > -----Original Message----- > From: Sumanth Channabasappa > Sent: Tuesday, August 09, 2005 2:37 PM > To: 'ipcdn@ietf.org' > Subject: [ipcdn] draft-ipcdn-pktc-signaling-08, further changes;=20 > conference call >=20 > Folks, >=20 > There has been a suggestion (from Phillip Freyman, Motorola) to move=20 > the 'dBm level', currently under 'PktcSigDevToneTable' to=20 > 'pktcSigDevMultiFreqToneTable'. This is due to certain examples that=20 > require this structure. >=20 >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn