From exim@www1.ietf.org Wed Jul 2 16:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12736 for ; Wed, 2 Jul 2003 16:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGq-0002XE-US for ipcdn-archive@odin.ietf.org; Wed, 02 Jul 2003 16:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h62KW414009744 for ipcdn-archive@odin.ietf.org; Wed, 2 Jul 2003 16:32:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGn-0002VW-QP; Wed, 02 Jul 2003 16:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19XoGg-0002U0-3g for ipcdn@optimus.ietf.org; Wed, 02 Jul 2003 16:31:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12544; Wed, 2 Jul 2003 16:31:48 -0400 (EDT) Message-Id: <200307022031.QAA12544@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 02 Jul 2003 16:31:48 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-09.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus Author(s) : S. Green, K. Ozawa, K. Katsnelson Filename : draft-ietf-ipcdn-bpiplus-mib-09.txt Pages : 72 Date : 2003-7-2 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of the Baseline Privacy Plus features of DOCSIS1.1- compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-bpiplus-mib-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161436.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161436.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 3 11:31:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16509 for ; Thu, 3 Jul 2003 11:31:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y638-0001SV-0q for ipcdn-archive@odin.ietf.org; Thu, 03 Jul 2003 11:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63FV5xF005602 for ipcdn-archive@odin.ietf.org; Thu, 3 Jul 2003 11:31:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y637-0001Rn-4h; Thu, 03 Jul 2003 11:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y62h-0001Gi-Pk for ipcdn@optimus.ietf.org; Thu, 03 Jul 2003 11:30:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16181; Thu, 3 Jul 2003 11:30:37 -0400 (EDT) Message-Id: <200307031530.LAA16181@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipcdn@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 03 Jul 2003 11:30:37 -0400 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-10.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus Author(s) : S. Green, K. Ozawa, K. Katsnelson Filename : draft-ietf-ipcdn-bpiplus-mib-10.txt Pages : 74 Date : 2003-7-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of the Baseline Privacy Plus features of DOCSIS1.1- compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-bpiplus-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-3111953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-bpiplus-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-3111953.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 3 11:57:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19784 for ; Thu, 3 Jul 2003 11:57:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6SE-0004YY-EN for ipcdn-archive@odin.ietf.org; Thu, 03 Jul 2003 11:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63Fv2XA017506 for ipcdn-archive@odin.ietf.org; Thu, 3 Jul 2003 11:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6SD-0004XV-QU; Thu, 03 Jul 2003 11:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Y6Rl-0004WU-CT for ipcdn@optimus.ietf.org; Thu, 03 Jul 2003 11:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19745 for ; Thu, 3 Jul 2003 11:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Y6Rk-0001Df-00 for ipcdn@ietf.org; Thu, 03 Jul 2003 11:56:32 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19Y6Rh-0001DE-00 for ipcdn@ietf.org; Thu, 03 Jul 2003 11:56:30 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h63Ftswd000131 for ; Thu, 3 Jul 2003 08:55:54 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h63FtqSR032364 for ; Thu, 3 Jul 2003 10:55:52 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Thu, 3 Jul 2003 08:55:51 -0700 Message-ID: From: Nakanishi Greg-MGI8179 To: "'ipcdn@ietf.org'" Date: Thu, 3 Jul 2003 08:55:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Comments on CableHome drafts Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Comments on the CableHome drafts --- General 1) Some of the lines exceed 72 characters. I didn't do an exhaustive search, but for the lines that I saw exceeding 72 characters they have trailing space characters. I don't really know how important the this is to correct. 2) "Status of this Memo" section - The reference "[1]" to RFC2026 should be removed. Per "Ad Review of I-Ds" doc: Do not add a numbered reference in the ID boilerplate to RFC 2026 (makes it harder for the RFC editor to process the document when they strip off the ID boilerplate) 3) Section 1 - Another "not sure how important this is" comment. The form of the references used in the draft doesn't match the "Boilerplate for IETF MIB Documents" doc. E.g. the draft uses [1] where as the boilerplate doc uses [RFC3410]. 4) CONTACT-INFO clause should include reference to IPCDN web page per 'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.5 5) Table objects that support dynamic row creation - Per 'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.6.3: - There either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart. I think a description on what happens to the row on a restart needs to be added for most table objects in the CH MIBs. 6) Inclusion of CableHome 1.1 objects? - Is the intent to standardize on the CableHome 1.1 objects as well? Some time ago, I recall the group felt it was premature to include CableHome 1.1; however, it's been a while and things may have changed. There are a number of CableHome 1.1 objects defined in the MIB. However, none of the descriptive sections of the draft (e.g. overview, glossary, references) address CableHome 1.1. 7) Section 7 - Needs to be updated to comply with "Security Guidelines for IETF MIB Modules". In particular, a discussion of the security sensitivity of specific objects. 8) Section 8 - CableHome 1.0 spec reference should be updated to -I04. CableHome 1.1 refence should be added, if needed. (see comment 6 above). 9) Section 8/9 - The "Boilerplate for IETF MIB Documents" show the reference to RFC3410 as Informative, whereas the draft includes it in the Normative section. Is the reference where it belongs? 10) Conversion errors from source document - Looks there are a few non-ASCII characters. Looks like the main errors occurred in converting bullet items and left/right quotation marks, but there were others as well. I found the following characters in the draft that should be some other character: - Latin small letter u with circumflex (original was a bullet character, I think) - Latin small letter o with circumflex (original was a left quote, I think) - Latin small letter o with diaeresis (original was a right quote, I think) - Latin capital letter o with diaeresis - Latin capital letter AE I've noticed these in the Config MIB and the Device MIB, for sure. I didn't notice it the other MIBs, but didn't do a thorough search. 11) Glossary - Each draft has a different set of terms in the glossary. I guess this is good in that the only the terms applicable to the particular draft is included. However, it seems easier and more consistent if only one all-inclusive glossary was written and included in all drafts. Just a thought to consider. Gateway Addressing MIB 1) Section 2.2, last sentence - "...software code image verification using techniques." Should this be "...software code image verification techniques." ? 2) cabhCapTcpTimeWait DESCRIPTION - reference to [RFC793] not included in section 8 or 9. 3) cabhCapTcpTimeWait DEFVAL - should add comment "-- 5 minutes" to be consistent with UDP and ICMP timeout objects. Gateway Configuration MIB 1) cabhCdpLanAddrEntry DESCRIPTION - The description states: Implementors need to be aware that if the size of cabhCdpLanAddrIp exceeds 115 octets then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3. a) Does the 115 number reflect the re-rooting of the MIB tree? b) While the cabhCdpLanAddrIp could exceed 115 character in theory, in practice I don't ever see this happening. Is this sentence really needed? 2) Use of "CMP" : acronym needs to be expanded on first use and described. 3) Use of InetAddressType - The MIB uses the "old" convention of pairing INetAddressType and InetAddress objects together. Should we adopt the "new" convention of allowing multiple InetAddress objects refer to a single INetAddressType? E.g. cabhCdpPoolStartType and cabhCdpPoolEndType could be combined into a single 'poolType' object as it makes no sense for cabhCdpPoolStartType and cabhCdpPoolEndType to have different values. 4) cabhCdpWanDnsServerTable - What value would the ServerIpType and ServerIp objects in rows 2 and 3 have if there is only one DNS server? Should this be specified in the description? Gateway Device MIB 1) section 3.1, paragraph 1 - I think this paragraph is obsolete. 2) section 3.1, paragraph 2 - "CABH-PS-DEV-MIB" should be "CABH-IETF-PS-DEV-MIB" 3) Use of "CMP" and "CDC" : acronym needs to be expanded on first use and described. 4) cabhPsDevCspTrap NOTIFICATION-TYPE - "CableHome Security Portal" used but not described. cabhPsDevCapTrap NOTIFICATION-TYPE - "CableHome Address Portal" used but not described. cabhPsDevCtpTrap NOTIFICATION-TYPE - "CableHome Test Portal" used but not described. Gateway Security MIB 1) section 2.8 - Seems odd that CDP is defined here but never referred to in the draft. Perhaps it should be deleted. It the glossary should describe the CSP, instead. 2) cabhSecFwPolicyOperStatus - Since this is a "new" MIB, should the deprecated completeFromMgt(3) comment be deleted? Which then raises the question, should failed(4) be renumbered to failed(3)? 3) Section 3 - Needs to be updated to describe additional MIB objects that were added since the last draft. e.g. the Kerberos objects. Also, all the 1.1 objects, if they are going to be included (see General comment #6). Gateway Tools MIB 1) CTP should be in the glossary. 2) I think the Ping Tool and Connection Speed Tool should be described in the glossary. Gateway QoS MIB 1) cabhPriorityQosBpEntry - Does the 113 number reflect the re-rooting of the MIB tree? 2) cabhPriorityQosBpDestEntry - same comment as #1 3) Reference to 1.1 spec should be updated to -I01. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 3 19:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26184 for ; Thu, 3 Jul 2003 19:41:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDRo-0000HF-MO for ipcdn-archive@odin.ietf.org; Thu, 03 Jul 2003 19:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h63NP40V001061 for ipcdn-archive@odin.ietf.org; Thu, 3 Jul 2003 19:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDRl-0000Gl-SZ; Thu, 03 Jul 2003 19:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YDQw-00008G-I5 for ipcdn@optimus.ietf.org; Thu, 03 Jul 2003 19:24:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22518 for ; Thu, 3 Jul 2003 19:24:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YDHL-00034w-00 for ipcdn@ietf.org; Thu, 03 Jul 2003 19:14:15 -0400 Received: from coral.tci.com ([198.178.8.81] helo=saipal.tci.com) by ietf-mx with esmtp (Exim 4.12) id 19YDHK-0002tA-00 for ipcdn@ietf.org; Thu, 03 Jul 2003 19:14:14 -0400 Received: from entexchimc04.broadband.att.com (localhost [127.0.0.1]) by saipal.tci.com (8.12.9/8.12.9) with ESMTP id h63NDVKF028098 for ; Thu, 3 Jul 2003 17:13:31 -0600 (MDT) Received: by entexchimc04.broadband.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Jul 2003 17:13:30 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC05663CB7@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Thu, 3 Jul 2003 17:13:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] FW: I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-10.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Folks, There were two versions of the BPI+ MIB submitted before the internet-draft submission deadline. Version -10 is the most recent and best version, and includes an improved Security Considerations section, Kaz Ozawa's contact information, and other editorial fixes. Note that I also made several recent updates to the IPCDN webpages: (new drafts, and an issues list for the NCS Signaling MIB) (Vienna meeting information) -- Rich -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, July 03, 2003 11:31 AM Cc: ipcdn@ietf.org Subject: I-D ACTION:draft-ietf-ipcdn-bpiplus-mib-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus Author(s) : S. Green, K. Ozawa, K. Katsnelson Filename : draft-ietf-ipcdn-bpiplus-mib-10.txt Pages : 74 Date : 2003-7-3 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of the Baseline Privacy Plus features of DOCSIS1.1- compliant Cable Modems and Cable Modem Termination Systems. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-10.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipcdn-bpiplus-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-bpiplus-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Jul 4 11:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29699 for ; Fri, 4 Jul 2003 11:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSWd-0004e4-0r for ipcdn-archive@odin.ietf.org; Fri, 04 Jul 2003 11:31:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h64FV3nm017852 for ipcdn-archive@odin.ietf.org; Fri, 4 Jul 2003 11:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSWc-0004dk-Kp; Fri, 04 Jul 2003 11:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19YSWE-0004ch-Nh for ipcdn@optimus.ietf.org; Fri, 04 Jul 2003 11:30:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29676 for ; Fri, 4 Jul 2003 11:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19YSWD-0006pe-00 for ipcdn@ietf.org; Fri, 04 Jul 2003 11:30:37 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19YSWC-0006pF-00 for ipcdn@ietf.org; Fri, 04 Jul 2003 11:30:37 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h64FU3wQ004663; Fri, 4 Jul 2003 09:30:03 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] Agenda for the IPCDN July 16'03 meeting in Vienna Date: Fri, 4 Jul 2003 09:30:03 -0600 Message-ID: Thread-Topic: [ipcdn] Agenda for the IPCDN July 16'03 meeting in Vienna Thread-Index: AcKF817qwqx0WLMUQ8ahOf2SFpiPNi0vOgXgAePp8qA= From: "Jean-Francois Mule" To: "IPCDN (E-mail)" Cc: "Richard Woundy" , "Jean-Francois Mule" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Here's the proposed agenda for the IPCDN WG meeting in Vienna. =20 IP over Cable Data Network WG (ipcdn) =20 Wednesday, July 16, 2003, at 0900-1130=20 = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 CHAIRS: Richard Woundy Jean-Francois Mule =20 AGENDA: =20 I. Agenda Bashing =20 II. Administration CableHome MIBs accepted as official wg items Determine new WG milestones WG handling of expired internet-drafts: applying the rule we discussed in the=20 Atlanta meeting, 2 ipcdn wg meetings=20 without any draft update =3D> draft is discontinued and removed from charter? =20 III. DOCSIS Submissions o DOCSIS BPI+ MIB draft 10 draft-ietf-ipcdn-bpiplus-mib-10.txt review closure on MIB doctor review comments o Subscriber Mgmt MIB draft 11 draft-ietf-ipcdn-subscriber-mib-11.txt o RF MIB v2 draft 07 draft-ietf-ipcdn-docs-rfmibv2-06.txt draft to be submitted soon review of comments addressed in 07 ready for WGLC IV. IPCablecom/PacketCable Submissions o MTA MIB draft-ietf-ipcdn-pktc-mtamib-01.txt any comments from the list? ready for WGLC o Signaling MIB draft-ietf-ipcdn-pktc-signaling-01.txt=20 any comments from the list? ready for WGLC=20 o Management Event MIB for PacketCable/IPCablecom=20 draft-ietf-ipcdn-pktc-eventmess-02.txt draft to be submitted soon need volunteer to review against syslog & other event mgmt mechanism V. CableHome Submissions o updated drafts: These drafts were submitted and should appear on ID repository soon draft-ietf-ipcdn-cable-gateway-addressing-mib-00 draft-ietf-ipcdn-cable-gateway-config-mib-00 draft-ietf-ipcdn-cable-gateway-device-mib-00 draft-ietf-ipcdn-cable-gateway-qos-mib-00 draft-ietf-ipcdn-cable-gateway-config-mib-00 -> need reviewers VI. Status of other WG drafts VII. WG next steps -- Richard Woundy and Jean-Francois Mule, IPCDN co-chairs _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 7 10:10:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26281 for ; Mon, 7 Jul 2003 10:10:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWgt-00032h-CM for ipcdn-archive@odin.ietf.org; Mon, 07 Jul 2003 10:10:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67EA3gM011686 for ipcdn-archive@odin.ietf.org; Mon, 7 Jul 2003 10:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWgr-000326-PG; Mon, 07 Jul 2003 10:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWg3-00030f-9w for ipcdn@optimus.ietf.org; Mon, 07 Jul 2003 10:09:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26154 for ; Mon, 7 Jul 2003 10:09:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWg1-0004a9-00 for ipcdn@ietf.org; Mon, 07 Jul 2003 10:09:09 -0400 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 19ZWg0-0004a5-00 for ipcdn@ietf.org; Mon, 07 Jul 2003 10:09:08 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id h67E96lj011634 for ; Mon, 7 Jul 2003 07:09:06 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id h67E94SR018011 for ; Mon, 7 Jul 2003 09:09:04 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 7 Jul 2003 07:09:04 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Date: Mon, 7 Jul 2003 07:08:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Comments on IETF Signaling MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , All, I have consolidated comments received from various vendors on the IETF Signaling MIB. Rich Woundy has kindly posted the document here: . Please use this forum to comment and/or suggest other recommendations you have on the IETF Signaling MIB. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 9 14:47:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13814 for ; Wed, 9 Jul 2003 14:47:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJy4-0002Vj-Px for ipcdn-archive@odin.ietf.org; Wed, 09 Jul 2003 14:47:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Il4iN009642 for ipcdn-archive@odin.ietf.org; Wed, 9 Jul 2003 14:47:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJy0-0002VK-SN; Wed, 09 Jul 2003 14:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aJxa-0002Uo-Pl for ipcdn@optimus.ietf.org; Wed, 09 Jul 2003 14:46:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13787 for ; Wed, 9 Jul 2003 14:46:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aJxY-0001l3-00 for ipcdn@ietf.org; Wed, 09 Jul 2003 14:46:32 -0400 Received: from web41902.mail.yahoo.com ([66.218.93.153]) by ietf-mx with smtp (Exim 4.12) id 19aJxX-0001kd-00 for ipcdn@ietf.org; Wed, 09 Jul 2003 14:46:31 -0400 Message-ID: <20030709184557.15097.qmail@web41902.mail.yahoo.com> Received: from [24.244.193.6] by web41902.mail.yahoo.com via HTTP; Wed, 09 Jul 2003 14:45:57 EDT Date: Wed, 9 Jul 2003 14:45:57 -0400 (EDT) From: sds sds To: ipcdn@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2032356999-1057776357=:13970" Subject: [ipcdn] docsQosServiceFlowStats Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --0-2032356999-1057776357=:13970 Content-Type: text/plain; charset=us-ascii Hi There, I am not sure if I should be submitting this email to this group. But I have a question with regards to the service flow stats. If the CMTS does not have a cli to support clearing the cable modem transfer counters, how can I clear these counters via snmp. I am able to view the stats and match service flows with specific modem macs. However I am interested in being able to clear them without reseting the modem or anything like that. Thanks --------------------------------- Post your free ad now! Yahoo! Canada Personals --0-2032356999-1057776357=:13970 Content-Type: text/html; charset=us-ascii
Hi  There,
 
I am not sure if I should be submitting this email to this group. But I have a question with regards to the service flow stats.  If the CMTS does not have a cli to support clearing the cable modem transfer counters, how can I clear these counters via snmp. 
 
I am able to view the stats and match service flows with specific modem macs.  However I am interested in being able to clear them without reseting the modem or anything like that. 
 
Thanks


Post your free ad now! Yahoo! Canada Personals
--0-2032356999-1057776357=:13970-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 10 17:37:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22937 for ; Thu, 10 Jul 2003 17:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj69-0003BU-Ch for ipcdn-archive@odin.ietf.org; Thu, 10 Jul 2003 17:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ALb5F3012239 for ipcdn-archive@odin.ietf.org; Thu, 10 Jul 2003 17:37:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj65-00039x-VU; Thu, 10 Jul 2003 17:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aj5u-00039R-5X for ipcdn@optimus.ietf.org; Thu, 10 Jul 2003 17:36:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22924 for ; Thu, 10 Jul 2003 17:36:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aj5r-0007dA-00 for ipcdn@ietf.org; Thu, 10 Jul 2003 17:36:47 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19aj5q-0007cw-00 for ipcdn@ietf.org; Thu, 10 Jul 2003 17:36:46 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6ALaDwQ016676 for ; Thu, 10 Jul 2003 15:36:14 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: re: [ipcdn] Comments on CableHome drafts Date: Thu, 10 Jul 2003 15:36:13 -0600 Message-ID: Thread-Topic: re: [ipcdn] Comments on CableHome drafts Thread-Index: AcNBfGWpAaZJqAGZTWy+W2/nIWhmNgDIzDEwAKJNUpA= From: "Kevin Luehrs" To: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable To Greg and other IPCDN WG participants; Please see responses inline. Kevin ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Luehrs Project Director, CableHome Engineering CableLabs 400 Centennial Parkway Louisville, CO 80027 303 661 9100 fax 303 661 9199 k.luehrs@cablelabs.com -----Original Message----- From: Nakanishi Greg-MGI8179 [mailto:gnakanishi@motorola.com]=20 Sent: Thursday, July 03, 2003 9:56 AM To: 'ipcdn@ietf.org' Subject: [ipcdn] Comments on CableHome drafts Comments on the CableHome drafts --- General 1) Some of the lines exceed 72 characters. I didn't do an exhaustive search, but for the lines that I saw exceeding 72 characters they have trailing space characters. I don't really know how important the this is to correct. We agree this should be fixed and authors will correct it in the next draft of each MIB i-d. 2) "Status of this Memo" section - The reference "[1]" to RFC2026 should be removed. Per "Ad Review of I-Ds" doc: Do not add a numbered reference in the ID boilerplate to RFC 2026 (makes it harder for the RFC editor to process the document when they strip off the ID boilerplate) We agree this should be fixed and authors will correct it in the next draft of each MIB i-d. 3) Section 1 - Another "not sure how important this is" comment. The form of the references used in the draft doesn't match the "Boilerplate for IETF MIB Documents" doc. E.g. the draft uses [1] where as the boilerplate doc uses [RFC3410]. Unless there is widespread objection to the existing language I propose that we leave it as-is. 4) CONTACT-INFO clause should include reference to IPCDN web page per 'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.5 Add to the next draft of the i-d. 5) Table objects that support dynamic row creation - Per 'draft-ietf-ops-mib-review-guidelines-01.txt' section 4.6.3: - There either MUST be one columnar object with a SYNTAX value of StorageType [RFC2579] and a MAX-ACCESS value of read-create, or else the row object (table entry) DESCRIPTION clause MUST specify what happens to dynamically-created rows after an agent restart. I think a description on what happens to the row on a restart needs to be added for most table objects in the CH MIBs. 6) Inclusion of CableHome 1.1 objects? - Is the intent to standardize on the CableHome 1.1 objects as well? Some time ago, I recall the group felt it was premature to include CableHome 1.1; however, it's been a while and things may have changed. There are a number of CableHome 1.1 objects defined in the MIB. However, none of the descriptive sections of the draft (e.g. overview, glossary, references) address CableHome 1.1. =20 It was our intention from the beginning to include CableHome 1.1 objects in the i-d/IETF version of the CableHome MIBs. We plan to update at least the CableHome 1.1 specification to replace references to CableLabs reference numbers with RFC numbers for the MIBs, when RFC numbers are assigned to the MIBs.=20 CableHome 1.1 is referenced in the compliances section of each applicable MIB, e.g. (PSDev MIB):, -- conditionally mandatory group GROUP cabhPsDevAttribGroup DESCRIPTION "This group is implemented only in CableHome 1.1 PS=20 elements, not CableHome 1.0 PS elements." =20 -- conditionally mandatory group GROUP cabhPsDevPsStatsGroup DESCRIPTION "This group is implemented only in CableHome 1.1 PS elements, not CableHome 1.0 PS elements." ::=3D { cabhPsCompliances 1} Please submit a proposal for descriptive text for the overview, glossary, and references sections of the i-d. 7) Section 7 - Needs to be updated to comply with "Security Guidelines for IETF MIB Modules". In particular, a discussion of the security sensitivity of specific objects. We agree this needs to be added. Authors will add text for the next draft of each MIB i-d. 8) Section 8 - CableHome 1.0 spec reference should be updated to -I04. CableHome 1.1 refence should be added, if needed. (see comment 6 above). Agree. Authors will edit the document for the next draft. 9) Section 8/9 - The "Boilerplate for IETF MIB Documents" show the reference to RFC3410 as Informative, whereas the draft includes it in the Normative section. Is the reference where it belongs? This reference should be moved to the Informative section. Authors will edit the document for the next draft. 10) Conversion errors from source document - Looks there are a few non-ASCII characters. Looks like the main errors occurred in converting bullet items and left/right quotation marks, but there were others as well. I found the following characters in the draft that should be some other character: - Latin small letter u with circumflex (original was a bullet character, I think) - Latin small letter o with circumflex (original was a left quote, I think) - Latin small letter o with diaeresis (original was a right quote, I think) - Latin capital letter o with diaeresis - Latin capital letter AE I've noticed these in the Config MIB and the Device MIB, for sure. I didn't notice it the other MIBs, but didn't do a thorough search. Agree that these errors should be corrected. Authors will edit the document for the next draft to make these corrections. 11) Glossary - Each draft has a different set of terms in the glossary. I guess this is good in that the only the terms applicable to the particular draft is included. However, it seems easier and more consistent if only one all-inclusive glossary was written and included in all drafts. Just a thought to consider. Our preference is to define in the glossary only those terms used in the document. If general WG consensus is that we use the same glossary for each cable-gateway MIB i-d then we will respect the group's wishes. Gateway Addressing MIB 1) Section 2.2, last sentence - "...software code image verification using techniques." Should this be "...software code image verification techniques." ? Agree that this correction should be made. Authors will edit the document for the next draft to make this correction. 2) cabhCapTcpTimeWait DESCRIPTION - reference to [RFC793] not included in section 8 or 9. Agree that this reference should be added to the Normative References section of the i-d. Authors will edit the document for the next draft. 3) cabhCapTcpTimeWait DEFVAL - should add comment "-- 5 minutes" to be consistent with UDP and ICMP timeout objects. Agree that this comment should be added for consistency. Authors will edit the document for the next draft. Gateway Configuration MIB 1) cabhCdpLanAddrEntry DESCRIPTION - The description states: Implementors need to be aware that if the size=20 of cabhCdpLanAddrIp exceeds 115 octets then OIDs=20 of column instances in this table will have more=20 than 128 sub-identifiers and cannot be accessed=20 using SNMPv1, SNMPv2c, or SNMPv3. a) Does the 115 number reflect the re-rooting of the MIB tree? This number is Rich Woundy's estimate for the maximum length of cabhCdpLanAddrIp without exceeding limits imposed by SNMPv1, v2c, and v3 on OID length, assuming re-rooting under the mib-2 branch (Rich - please clarify as needed). Eduardo contacted IETF OPS groups for clarification on how this should be calculated in a standard manner but he has so far received no response. b) While the cabhCdpLanAddrIp could exceed 115 character in theory, in practice I don't ever see this happening. Is this sentence really needed? This is a common policy to guarantee the extensibility of the mib as IETF recommends. 2) Use of "CMP" : acronym needs to be expanded on first use and described. Agree. Authors will edit the document for the next draft. 3) Use of InetAddressType - The MIB uses the "old" convention of pairing INetAddressType and InetAddress objects together. Should we adopt the "new" convention of allowing multiple InetAddress objects refer to a single INetAddressType? E.g. cabhCdpPoolStartType and cabhCdpPoolEndType could be combined into a single 'poolType' object as it makes no sense for cabhCdpPoolStartType and cabhCdpPoolEndType to have different values. 4) cabhCdpWanDnsServerTable - What value would the ServerIpType and ServerIp objects in rows 2 and 3 have if there is only one DNS server? Should this be specified in the description? Gateway Device MIB 1) section 3.1, paragraph 1 - I think this paragraph is obsolete. Agree. Authors will edit the document to update for the next draft. 2) section 3.1, paragraph 2 - "CABH-PS-DEV-MIB" should be "CABH-IETF-PS-DEV-MIB" Agree. Authors will edit the document to update for the next draft. 3) Use of "CMP" and "CDC" : acronym needs to be expanded on first use and described. Agree. Authors will edit the document to update for the next draft. 4) cabhPsDevCspTrap NOTIFICATION-TYPE - "CableHome Security Portal" used but not described. Agree that the description should be edited to provide a more relevant reference. Authors will edit the document to update for the next draft. cabhPsDevCapTrap NOTIFICATION-TYPE - "CableHome Address Portal" used but not described. Agree that the description should be edited to provide a more complete reference. Authors will edit the document to update for the next draft. cabhPsDevCtpTrap NOTIFICATION-TYPE - "CableHome Test Portal" used but not described. Agree that the description should be edited to provide a more complete reference. Authors will edit the document to update for the next draft. Gateway Security MIB 1) section 2.8 - Seems odd that CDP is defined here but never referred to in the draft. Perhaps it should be deleted. It the glossary should describe the CSP, instead.=20 Agree that 'CDP' should not be defined in the Security MIB if it is not used. Authors will remove this=20 definition from the document for the next draft. 2) cabhSecFwPolicyOperStatus - Since this is a "new" MIB, should the deprecated completeFromMgt(3) comment be deleted? Which then raises the question, should failed(4) be renumbered to failed(3)? We agree with Greg, that the deprecated object be deleted from the i-d version of the Security MIB, and agree that 'failed(4)' should be renumbered to failed(3). This will create some confusion with existing vendor products but can be corrected with a software upgrade, and it is preferable to submitting a "new" i-d MIB to the IETF with a deprecated object. 3) Section 3 - Needs to be updated to describe additional MIB objects that were added since the last draft. e.g. the Kerberos objects. Also, all the 1.1 objects, if they are going to be included (see General comment #6). Agree. There are also other recent changes introduced via the CableHome Engineering Change process. Authors will edit the document for the next draft. Gateway Tools MIB 1) CTP should be in the glossary. Agree. Authors will edit the document for the next draft. 2) I think the Ping Tool and Connection Speed Tool should be described in the glossary. Agree. Authors will edit the document for the next draft. Gateway QoS MIB 1) cabhPriorityQosBpEntry - Does the 113 number reflect the re-rooting of the MIB tree? See the response for the similar question under Gateway Configuration MIB, above. 2) cabhPriorityQosBpDestEntry - same comment as #1 as above 3) Reference to 1.1 spec should be updated to -I01. Agree. Authors will edit the document for the next draft. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 14 10:47:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26068 for ; Mon, 14 Jul 2003 10:47:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4bW-0001J0-RJ for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 10:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EEl2ab005013 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 10:47:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4bU-0001Id-SC; Mon, 14 Jul 2003 10:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c4ar-0001IF-La for ipcdn@optimus.ietf.org; Mon, 14 Jul 2003 10:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25969 for ; Mon, 14 Jul 2003 10:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4ap-0000u8-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 10:46:19 -0400 Received: from jester.ti.com ([192.94.94.1]) by ietf-mx with esmtp (Exim 4.12) id 19c4ao-0000tT-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 10:46:18 -0400 Received: from dlep52.itg.ti.com ([157.170.134.103]) by jester.ti.com (8.12.9/8.12.9) with ESMTP id h6EEjim1020309; Mon, 14 Jul 2003 09:45:44 -0500 (CDT) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep52.itg.ti.com (8.12.9/8.12.9) with ESMTP id h6EEjiTh026426; Mon, 14 Jul 2003 09:45:44 -0500 (CDT) Received: from dbde01.itg.ti.com (dbde01.itg.ti.com [157.87.95.201]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id JAA14746; Mon, 14 Jul 2003 09:45:42 -0500 (CDT) Received: by dbde01.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 20:15:40 +0530 Message-ID: From: "Kumar, Satish" To: "Ipcdn (E-mail)" , "Woundy, Richard " Cc: Jean-Francois Mule Date: Mon, 14 Jul 2003 20:15:38 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] MTA MIB comment Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Rich, I did MTA MIB review and found some issue. Please add this to your review list comments in IETF. pktcMtaDevRealmUnsolicitedKeyMaxTimeout Def Value: 30 seconds pktcMtaDevRealmUnsolicitedKeyNomTimeout Def value: 10000 milli sec pktcMtaDevRealmUnsolicitedKeyMaxRetries Def value: 5 As per the above default values MTA exhaust the def values in 3 retries, But we need to either change the max timeout to 50 seconds or max retries to 3 or reduce the NomTimeout to 5000 milli sec. I am in favour of later change like..changing the NomTimeout to 5000msec, so that MTA will retry if it doesn't get AS reply in 5 seconds. Thanks, Satish Kumar Texas Instruments _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 14 13:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07216 for ; Mon, 14 Jul 2003 13:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7CB-0003Wv-HL for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 13:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHX3Du013551 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 13:33:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7C9-0003WF-6y; Mon, 14 Jul 2003 13:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7Bf-0003Ve-Le for ipcdn@optimus.ietf.org; Mon, 14 Jul 2003 13:32:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07181 for ; Mon, 14 Jul 2003 13:32:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7Bd-0003gH-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 13:32:29 -0400 Received: from coral.tci.com ([198.178.8.81] helo=dapsang.tci.com) by ietf-mx with esmtp (Exim 4.12) id 19c7Bc-0003fq-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 13:32:28 -0400 Received: from entexchimc02.broadband.att.com (localhost [127.0.0.1]) by dapsang.tci.com (8.12.9/8.12.9) with ESMTP id h6EHVp04009934; Mon, 14 Jul 2003 11:31:52 -0600 (MDT) Received: by entexchimc02.broadband.att.com with Internet Mail Service (5.5.2653.19) id <3TGYV2X3>; Mon, 14 Jul 2003 11:31:51 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC05663CF3@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Kumar, Satish'" Cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] MTA MIB comment Date: Mon, 14 Jul 2003 11:31:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Satish, I assume that we want: (MaxTimeout Default) == (NomTimeout Default) * (MaxRetries Default) So shouldn't we reduce the NomTimeout to 6000 milliseconds instead of 5000 milliseconds, since (30 seconds) = (6000 milliseconds) * (5 retries)? I must have also miscalculated this value relationship in our private email earlier. Sorry about that. I added your original comment to the PacketCable MTA MIB considerations at . -- Rich -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:46 AM To: Ipcdn (E-mail); Woundy, Richard Cc: Jean-Francois Mule Subject: [ipcdn] MTA MIB comment Rich, I did MTA MIB review and found some issue. Please add this to your review list comments in IETF. pktcMtaDevRealmUnsolicitedKeyMaxTimeout Def Value: 30 seconds pktcMtaDevRealmUnsolicitedKeyNomTimeout Def value: 10000 milli sec pktcMtaDevRealmUnsolicitedKeyMaxRetries Def value: 5 As per the above default values MTA exhaust the def values in 3 retries, But we need to either change the max timeout to 50 seconds or max retries to 3 or reduce the NomTimeout to 5000 milli sec. I am in favour of later change like..changing the NomTimeout to 5000msec, so that MTA will retry if it doesn't get AS reply in 5 seconds. Thanks, Satish Kumar Texas Instruments _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 14 13:37:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07517 for ; Mon, 14 Jul 2003 13:37:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7G1-0003ha-DE for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 13:37:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHb16H014226 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 13:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7G1-0003hD-3U; Mon, 14 Jul 2003 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7FH-0003gY-91 for ipcdn@optimus.ietf.org; Mon, 14 Jul 2003 13:36:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07425 for ; Mon, 14 Jul 2003 13:36:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7FF-0003kb-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 13:36:13 -0400 Received: from jester.ti.com ([192.94.94.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7FE-0003j2-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 13:36:12 -0400 Received: from dlep51.itg.ti.com ([157.170.141.75]) by jester.ti.com (8.12.9/8.12.9) with ESMTP id h6EHZfm1003647; Mon, 14 Jul 2003 12:35:41 -0500 (CDT) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep51.itg.ti.com (8.12.9/8.12.9) with ESMTP id h6EHZeBO022370; Mon, 14 Jul 2003 12:35:40 -0500 (CDT) Received: from dbde01.itg.ti.com (dbde01.itg.ti.com [157.87.95.201]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id MAA19163; Mon, 14 Jul 2003 12:35:39 -0500 (CDT) Received: by dbde01.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jul 2003 23:05:37 +0530 Message-ID: From: "Kumar, Satish" To: "'Woundy, Richard'" Cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] MTA MIB comment Date: Mon, 14 Jul 2003 23:05:36 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Rich, Your caluclation is correct, and we need to change Nomtimeout default value to 6000msec. -Satish -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, July 14, 2003 5:32 PM To: Kumar, Satish Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Satish, I assume that we want: (MaxTimeout Default) == (NomTimeout Default) * (MaxRetries Default) So shouldn't we reduce the NomTimeout to 6000 milliseconds instead of 5000 milliseconds, since (30 seconds) = (6000 milliseconds) * (5 retries)? I must have also miscalculated this value relationship in our private email earlier. Sorry about that. I added your original comment to the PacketCable MTA MIB considerations at . -- Rich -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:46 AM To: Ipcdn (E-mail); Woundy, Richard Cc: Jean-Francois Mule Subject: [ipcdn] MTA MIB comment Rich, I did MTA MIB review and found some issue. Please add this to your review list comments in IETF. pktcMtaDevRealmUnsolicitedKeyMaxTimeout Def Value: 30 seconds pktcMtaDevRealmUnsolicitedKeyNomTimeout Def value: 10000 milli sec pktcMtaDevRealmUnsolicitedKeyMaxRetries Def value: 5 As per the above default values MTA exhaust the def values in 3 retries, But we need to either change the max timeout to 50 seconds or max retries to 3 or reduce the NomTimeout to 5000 milli sec. I am in favour of later change like..changing the NomTimeout to 5000msec, so that MTA will retry if it doesn't get AS reply in 5 seconds. Thanks, Satish Kumar Texas Instruments _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 14 13:59:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09216 for ; Mon, 14 Jul 2003 13:59:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7bI-0005aJ-Q7 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 13:59:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EHx0dD021454 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 13:59:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7bI-0005Zv-I3; Mon, 14 Jul 2003 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19c7aR-0005U4-Jk for ipcdn@optimus.ietf.org; Mon, 14 Jul 2003 13:58:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09149 for ; Mon, 14 Jul 2003 13:58:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19c7aP-0004Bs-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 13:58:05 -0400 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 19c7aO-0004Bp-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 13:58:04 -0400 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Mon, 14 Jul 2003 10:57:59 -0700 Received: from nt-irva-0740.brcm.ad.broadcom.com ([10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id KAA01334; Mon, 14 Jul 2003 10:57:23 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Mon, 14 Jul 2003 10:58:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] MTA MIB comment Date: Mon, 14 Jul 2003 10:59:32 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B01500E@nt-rmna-0740.ca.broadcom.com> Thread-Topic: [ipcdn] MTA MIB comment Thread-Index: AcNKLtMVLZvPHFO/S3SRVO0uJxIVogAAF1EQ From: "Eugene Nechamkin" To: "Kumar, Satish" , "Woundy, Richard" cc: "IPCDN WG (E-mail)" X-OriginalArrivalTime: 14 Jul 2003 17:58:02.0265 (UTC) FILETIME=[77F12090:01C34A31] X-WSS-ID: 130C30AD2224412-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Satish, I am not sure if we want to have this sort of restrictive relationship = between these three MIB Objects, at least this was not the intention in = Security backoff and Retry and similarly in NCS backoff and Retry = algorithms. With the currently existing Default values, MTA will go through the = following sequence of retries and exponential timeouts (I have used = exponential factor of "2" as an example, but in any case, it should be = greater than 1): Attemp# Timeout (sec) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 1 10 2 2 * 10 =3D 20 (< 30, so TO=3D20) 3 2 * 20 =3D 40 (> 30, so TO=3D30) 4 2 * 30 =3D 60 (> 30, so TO=3D30) 5 2 * 30 =3D 60 (> 30, so TO=3D30) So, all 5 "pktcMtaDevRealmUnsolicitedKeyMaxRetries" will be exhausted, = and MTA will give up after 5 retries without exceedeing the MAX timeout = value of 30 secs as requred by the MIB objects. Currently existing MTA MIB does not imply existence of any sort of = relationship between these three MIB Objects, and I don't think we need = to change anything in default values especially if such a change would = hint to the existance of any form of formular dependencies. Eugene. -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:36 AM To: 'Woundy, Richard' Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Rich, Your caluclation is correct, and we need to change Nomtimeout default value to 6000msec. -Satish -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, July 14, 2003 5:32 PM To: Kumar, Satish Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Satish, I assume that we want: (MaxTimeout Default) =3D=3D (NomTimeout Default) * (MaxRetries Default) So shouldn't we reduce the NomTimeout to 6000 milliseconds instead of = 5000 milliseconds, since=20 (30 seconds) =3D (6000 milliseconds) * (5 retries)? I must have also miscalculated this value relationship in our private = email earlier. Sorry about that. I added your original comment to the PacketCable MTA MIB considerations = at . -- Rich -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:46 AM To: Ipcdn (E-mail); Woundy, Richard Cc: Jean-Francois Mule Subject: [ipcdn] MTA MIB comment Rich,=20 I did MTA MIB review and found some issue. Please add this to your = review list comments in IETF. pktcMtaDevRealmUnsolicitedKeyMaxTimeout Def Value: 30 seconds pktcMtaDevRealmUnsolicitedKeyNomTimeout Def value: 10000 milli sec pktcMtaDevRealmUnsolicitedKeyMaxRetries Def value: 5=20 As per the above default values MTA exhaust the def values in 3 retries, = But we need to either change the max timeout to 50 seconds or max retries to = 3 or reduce the NomTimeout to 5000 milli sec. I am in favour of later = change like..changing the NomTimeout to 5000msec, so that MTA will retry if it doesn't get AS reply in 5 seconds. Thanks,=20 Satish Kumar Texas Instruments _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 14 18:46:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03338 for ; Mon, 14 Jul 2003 18:46:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cC54-0000eL-S2 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 18:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6EMk2aj002493 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 18:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cC53-0000dr-Gc; Mon, 14 Jul 2003 18:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cC50-0000dK-Pm for ipcdn@optimus.ietf.org; Mon, 14 Jul 2003 18:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03269 for ; Mon, 14 Jul 2003 18:45:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cC4x-0001jL-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 18:45:55 -0400 Received: from go4.ext.ti.com ([192.91.75.132]) by ietf-mx with esmtp (Exim 4.12) id 19cC4w-0001iK-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 18:45:54 -0400 Received: from dlep50.itg.ti.com ([157.170.141.74]) by go4.ext.ti.com (8.12.9/8.12.9) with ESMTP id h6EMjNwD017901; Mon, 14 Jul 2003 17:45:23 -0500 (CDT) Received: from dlep98.itg.ti.com (localhost [127.0.0.1]) by dlep50.itg.ti.com (8.12.9/8.12.9) with ESMTP id h6EMjM20022052; Mon, 14 Jul 2003 17:45:23 -0500 (CDT) Received: from dbde01.itg.ti.com (dbde01.itg.ti.com [157.87.95.201]) by dlep98.itg.ti.com (8.9.3/8.9.3) with ESMTP id RAA12760; Mon, 14 Jul 2003 17:45:21 -0500 (CDT) Received: by dbde01.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Jul 2003 04:15:19 +0530 Message-ID: From: "Kumar, Satish" To: "'Eugene Nechamkin'" , "Woundy, Richard" Cc: "IPCDN WG (E-mail)" Subject: RE: [ipcdn] MTA MIB comment Date: Tue, 15 Jul 2003 04:15:18 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Eugene, All the three MIBs(under discussion) are inter related, and was the intention earlier too. The exponential behavior seen with AP req/rep scenario doesn't have this issue. In your example MTA retries thrice at 30, which doesn't sound like exponential. I think we have to change the default value suitably for pktcMtaDevRealmUnsolicitedKeyMaxTimeout and pktcMtaDevRealmUnsolicitedKeyNomTimeout to follow exponential scenario. -Satish -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Monday, July 14, 2003 6:00 PM To: Kumar, Satish; Woundy, Richard Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Satish, I am not sure if we want to have this sort of restrictive relationship between these three MIB Objects, at least this was not the intention in Security backoff and Retry and similarly in NCS backoff and Retry algorithms. With the currently existing Default values, MTA will go through the following sequence of retries and exponential timeouts (I have used exponential factor of "2" as an example, but in any case, it should be greater than 1): Attemp# Timeout (sec) ================================ 1 10 2 2 * 10 = 20 (< 30, so TO=20) 3 2 * 20 = 40 (> 30, so TO=30) 4 2 * 30 = 60 (> 30, so TO=30) 5 2 * 30 = 60 (> 30, so TO=30) So, all 5 "pktcMtaDevRealmUnsolicitedKeyMaxRetries" will be exhausted, and MTA will give up after 5 retries without exceedeing the MAX timeout value of 30 secs as requred by the MIB objects. Currently existing MTA MIB does not imply existence of any sort of relationship between these three MIB Objects, and I don't think we need to change anything in default values especially if such a change would hint to the existance of any form of formular dependencies. Eugene. -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:36 AM To: 'Woundy, Richard' Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Rich, Your caluclation is correct, and we need to change Nomtimeout default value to 6000msec. -Satish -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, July 14, 2003 5:32 PM To: Kumar, Satish Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Satish, I assume that we want: (MaxTimeout Default) == (NomTimeout Default) * (MaxRetries Default) So shouldn't we reduce the NomTimeout to 6000 milliseconds instead of 5000 milliseconds, since (30 seconds) = (6000 milliseconds) * (5 retries)? I must have also miscalculated this value relationship in our private email earlier. Sorry about that. I added your original comment to the PacketCable MTA MIB considerations at . -- Rich -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:46 AM To: Ipcdn (E-mail); Woundy, Richard Cc: Jean-Francois Mule Subject: [ipcdn] MTA MIB comment Rich, I did MTA MIB review and found some issue. Please add this to your review list comments in IETF. pktcMtaDevRealmUnsolicitedKeyMaxTimeout Def Value: 30 seconds pktcMtaDevRealmUnsolicitedKeyNomTimeout Def value: 10000 milli sec pktcMtaDevRealmUnsolicitedKeyMaxRetries Def value: 5 As per the above default values MTA exhaust the def values in 3 retries, But we need to either change the max timeout to 50 seconds or max retries to 3 or reduce the NomTimeout to 5000 milli sec. I am in favour of later change like..changing the NomTimeout to 5000msec, so that MTA will retry if it doesn't get AS reply in 5 seconds. Thanks, Satish Kumar Texas Instruments _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 14 19:48:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07657 for ; Mon, 14 Jul 2003 19:48:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD34-0004we-Gj for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 19:48:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ENm2jd019008 for ipcdn-archive@odin.ietf.org; Mon, 14 Jul 2003 19:48:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD33-0004wF-31; Mon, 14 Jul 2003 19:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cD2D-0004vO-PB for ipcdn@optimus.ietf.org; Mon, 14 Jul 2003 19:47:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07491 for ; Mon, 14 Jul 2003 19:47:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cD2B-0002oB-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 19:47:07 -0400 Received: from mms3.broadcom.com ([63.70.210.38]) by ietf-mx with esmtp (Exim 4.12) id 19cD2B-0002o6-00 for ipcdn@ietf.org; Mon, 14 Jul 2003 19:47:07 -0400 Received: from 63.70.210.1 by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.5.2)); Mon, 14 Jul 2003 16:47:08 -0700 Received: from nt-irva-0740.brcm.ad.broadcom.com ([10.8.194.53]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id QAA24870; Mon, 14 Jul 2003 16:46:32 -0700 (PDT) Received: from nt-rmna-0740.brcm.ad.broadcom.com ([10.136.192.33]) by nt-irva-0740.brcm.ad.broadcom.com with Microsoft SMTPSVC(5.0.2195.5329) ; Mon, 14 Jul 2003 16:47:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ipcdn] MTA MIB comment Date: Mon, 14 Jul 2003 16:48:40 -0700 Message-ID: <24CDBA67F085904999751B3C4F9E8C0B015013@nt-rmna-0740.ca.broadcom.com> Thread-Topic: [ipcdn] MTA MIB comment Thread-Index: AcNKWeK/U6YZNRFwT7eT20CleznuMgAAH2ug From: "Eugene Nechamkin" To: "Kumar, Satish" , "Woundy, Richard" cc: "IPCDN WG (E-mail)" X-OriginalArrivalTime: 14 Jul 2003 23:47:10.0390 (UTC) FILETIME=[3DFF5560:01C34A62] X-WSS-ID: 130D9F762276376-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Satish, > All the three MIBs(under discussion) are inter related,=20 I disagree. Neither Prov Spec, nor Security Spec, nor MTA MIB do not = seem to currently suggest that there is (or there even should be) any = dependences between these three MTA MIB objects. All PC Specs seem to be = in agreement that such dependances should not be neccessary. Besides, if = you take a look at the backoff and retry in NCS, then its exponential = behavior looks very close to what I described in my hypothetical = example.=20 > The exponential behavior seen with AP req/rep > scenario doesn't have this issue. In your example=20 > MTA retries thrice at 30, > which doesn't sound like exponential. The fact that the max value of the timeout is restricted from the top, = does not mean that exponential calcualtion has not been used. The = existence of a combination of the default values such that the result of = the exponential calcualtions will not "sound like exponential", to my = opinion, does not grant the need to introduce the dependencies between = MIB Objects. Without arguing with your point, I'd suggest to have some more = discussions on the PC Prov Reflector and then submit neccesasry changes = to IPCDN WG (if needed). Thanks, Eugene. -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 3:45 PM To: Eugene Nechamkin; Woundy, Richard Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Eugene, All the three MIBs(under discussion) are inter related, and was the intention earlier too. The exponential behavior seen with AP req/rep scenario doesn't have this issue. In your example MTA retries thrice at = 30, which doesn't sound like exponential. =20 I think we have to change the default value suitably for pktcMtaDevRealmUnsolicitedKeyMaxTimeout and pktcMtaDevRealmUnsolicitedKeyNomTimeout to follow exponential scenario.=20 -Satish -----Original Message----- From: Eugene Nechamkin [mailto:enechamkin@broadcom.com] Sent: Monday, July 14, 2003 6:00 PM To: Kumar, Satish; Woundy, Richard Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Satish, I am not sure if we want to have this sort of restrictive relationship between these three MIB Objects, at least this was not the intention in Security backoff and Retry and similarly in NCS backoff and Retry algorithms. With the currently existing Default values, MTA will go through the following sequence of retries and exponential timeouts (I have used exponential factor of "2" as an example, but in any case, it should be greater than 1): Attemp# Timeout (sec) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 1 10 2 2 * 10 =3D 20 (< 30, so TO=3D20) 3 2 * 20 =3D 40 (> 30, so TO=3D30) 4 2 * 30 =3D 60 (> 30, so TO=3D30) 5 2 * 30 =3D 60 (> 30, so TO=3D30) So, all 5 "pktcMtaDevRealmUnsolicitedKeyMaxRetries" will be exhausted, = and MTA will give up after 5 retries without exceedeing the MAX timeout = value of 30 secs as requred by the MIB objects. Currently existing MTA MIB does not imply existence of any sort of relationship between these three MIB Objects, and I don't think we need = to change anything in default values especially if such a change would hint = to the existance of any form of formular dependencies. Eugene. -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:36 AM To: 'Woundy, Richard' Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Rich, Your caluclation is correct, and we need to change Nomtimeout default value to 6000msec. -Satish -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Monday, July 14, 2003 5:32 PM To: Kumar, Satish Cc: IPCDN WG (E-mail) Subject: RE: [ipcdn] MTA MIB comment Satish, I assume that we want: (MaxTimeout Default) =3D=3D (NomTimeout Default) * (MaxRetries Default) So shouldn't we reduce the NomTimeout to 6000 milliseconds instead of = 5000 milliseconds, since=20 (30 seconds) =3D (6000 milliseconds) * (5 retries)? I must have also miscalculated this value relationship in our private = email earlier. Sorry about that. I added your original comment to the PacketCable MTA MIB considerations = at . -- Rich -----Original Message----- From: Kumar, Satish [mailto:satish.kumar@ti.com] Sent: Monday, July 14, 2003 10:46 AM To: Ipcdn (E-mail); Woundy, Richard Cc: Jean-Francois Mule Subject: [ipcdn] MTA MIB comment Rich,=20 I did MTA MIB review and found some issue. Please add this to your = review list comments in IETF. pktcMtaDevRealmUnsolicitedKeyMaxTimeout Def Value: 30 seconds pktcMtaDevRealmUnsolicitedKeyNomTimeout Def value: 10000 milli sec pktcMtaDevRealmUnsolicitedKeyMaxRetries Def value: 5=20 As per the above default values MTA exhaust the def values in 3 retries, = But we need to either change the max timeout to 50 seconds or max retries to = 3 or reduce the NomTimeout to 5000 milli sec. I am in favour of later = change like..changing the NomTimeout to 5000msec, so that MTA will retry if it doesn't get AS reply in 5 seconds. Thanks,=20 Satish Kumar Texas Instruments _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 16 12:21:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07428 for ; Wed, 16 Jul 2003 12:21:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cp1Z-0005HR-Mo for ipcdn-archive@odin.ietf.org; Wed, 16 Jul 2003 12:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6GGL1C1020291 for ipcdn-archive@odin.ietf.org; Wed, 16 Jul 2003 12:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cp1Y-0005HA-Id; Wed, 16 Jul 2003 12:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cp1H-0005Gs-E9 for ipcdn@optimus.ietf.org; Wed, 16 Jul 2003 12:20:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07404 for ; Wed, 16 Jul 2003 12:20:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19cp1G-0000uC-00 for ipcdn@ietf.org; Wed, 16 Jul 2003 12:20:42 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19cp14-0000tb-00 for ipcdn@ietf.org; Wed, 16 Jul 2003 12:20:31 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6GGJKwQ026126; Wed, 16 Jul 2003 10:19:20 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 Date: Wed, 16 Jul 2003 10:19:20 -0600 Message-ID: Thread-Topic: [ipcdn] draft submitted: subscriber management MIB -11 Thread-Index: AcMwOTHGZN8tcXkfSRmcgovAuLoB9Qbc+TXw From: "Jean-Francois Mule" To: Cc: , "Kirk Friedman" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Wilson, I like the work on the RFC3289 integration, nice job. Going through the changes you proposed in draft11 w.r.t. mandating part of RFC 3289, find below a suggestion to address the concerns that what's required from 3289 is kind of loosely defined in the draft. I agree that this can be done via the DOCSIS RFI; below is a complementary proposal. First, the requirements on 3289 in section 2.3 are written in terms of objects, not object groups. Consequently, it is not possible to enforce any level of requirement is on these objects (object groups could allow you to be more precise with SYNTAX and WRITE-SYNTAX clauses for e.g.).=20 Secondly, going through the RFC3289 object groups one by one, you are not that far from actually mandating some object groups: o diffServDataPathTable =3D> this is diffServMIBDataPathGroup object group o diffServClfrTable =3D> based on section 3.2.1 of RFC3289, I think you may also = need to mandate the support of diffServClfrNextFree. diffServClfrNextFree is populated by the agent when creating ids in the table. If you agree to add this one object, requiring diffServClfrNextFree + diffServClfrTable objects =3D> diffServMIBClfrGroup. This comment applies to the next tables as well. o diffServClfrElementTable =3D> how about diffServClfrElementNextFree? If you include diffServClfrElementNextFree + diffServClfrElementTable =3D> diffServMIBClfrElementGroup o diffServMultiFieldClfrTable how about diffServMultiFieldClfrNextFree? If you include diffServMultiFieldClfrNextFree + diffServMultiFieldClfrTable =3D> diffServMIBMultiFieldClfrGroup o diffServActionTable how about diffServActionNextFree? If you include diffServActionNextFree + diffServActionTable = =3D> diffServMIBActionGroup. o diffServAlgDropTable (diffServAlgDropType=3DalwaysDrop) how about diffServAlgDropNextFree ? If you include diffServAlgDropNextFree + diffServAlgDropTable = =3D> diffServMIBAlgDropGroup o diffServCountActTable how about diffServCountActNextFree? If you include diffServCountActNextFree + diffServCountActTable + the following objects from diffServAlgDropTable (diffServAlgDropOctets, diffServAlgDropPkts, diffServAlgRandomDropOctets, diffServAlgRandomDropPkts) =3D> diffServMIBCounterGroup =3D=3D> In short, if you agree that supporting the diff*NextFree objects = is not a bad idea (especially since it's probably going to be implemented by the agent with the various tables), you can easily transform the section 2.3 and write it in terms object groups. =20 To that extent, I am wondering if the docsSubMgtBasicCompliance module compliance statement could be enhanced to actually include the object groups from RFC3289 cited above. Based on your section 2.3, this enhancement could then look something like this: docsSubMgtBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CMTS devices that implement CMTS centric subscriber management." MODULE DIFFSERV-MIB -- RFC3289 MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup,=20 diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup,=20 diffServMIBAlgDropGroup, diffServMIBCounterGroup } ... ...=20 -- and now you may formerly specify that=20 -- diffServAlgDropType=3DalwaysDrop in diffServAlgDropTable, etc.=20 MODULE -- This module i.e. DOCS-IETF-SUBMGT-MIB MANDATORY-GROUPS { docsSubMgtGroup } ... Thoughts? Sorry for not sending this proposal earlier, Jean-Francois. > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com]=20 > Sent: Wednesday, June 11, 2003 10:44 AM > To: Kirk Friedman > Cc: bwijnen@lucent.com; ipcdn@ietf.org > Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 >=20 >=20 >=20 > Kirk - Agreed that the Docsis OSSI Spec needs new language to=20 > spec out CMTS compliance w.r.t. RFC3289. For the most part,=20 > I think that language more properly belongs in the OSSI spec=20 > than in the internet draft. But I'm open to suggestions. >=20 > Keep in mind that there's a necessary lag in the publication=20 > of the OSSI > Spec: It can't mandate compliance with the subscriber=20 > management internet-draft until the MIB is assigned a root -=20 > and that won't happen until publication as an RFC. >=20 > Regards, > Wilson >=20 >=20 >=20 > =20 > =20 > =20 > "Kirk Friedman" =20 > =20 > =20 > =20 > =20 > ant.com> cc: =20 > , =20 > =20 > Subject: RE:=20 > [ipcdn] draft submitted: subscriber management MIB -11 =20 > =20 > 06/11/03 11:59 AM =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 >=20 >=20 >=20 > Hi Wilson, >=20 > Thanks for the prompt reply. Walking through your responses >=20 > 1. I agree its not a major issue. More of a implementation=20 > simplification. >=20 > 2. RFC3289 does not refer to=20 > filter-classifiers-used-for-subscriber-managemment. =20 > Considering 3289 by itself is using classifiers for filters=20 > and for QoS management. There is definitely cause for=20 > confusion between this and the QoS MIB without careful explanation. >=20 > 3. The ifIndex makes sense if only applied to the Docsis MAC=20 > interface. This should be clarified. >=20 > 4. The question is how RFC3289 is interpreted for use in a=20 > CMTS and what constitutes compliance. If this MIB is going=20 > to be used in DOCSIS 1.1 systems then an ECR should=20 > immediately be drafted the OSSI Spec "Detailed MIB=20 > Requirements" so there is no confusion about what is and is=20 > not required to be implemented. Otherwise the confusion will=20 > snowball. >=20 > 5. Agree, see 4. >=20 > 6. Agreed. >=20 > 7. Agreed since the ifIndex is only applicable to the MAC interface. >=20 > To re-iterate comment 4. If I take a look at RFC3289 without=20 > any other documentation, then there are MIB entries other=20 > than the classifiers that could be said to apply to the CMTS.=20 > Section 3 "Management Information Bases (MIBS)" should also=20 > be ECRd to change the requirements for the subscriber mgmt=20 > mib and add a section for RFC 3289. If not, there will be a=20 > large disconnect between 1.1 systems and 2.0 systems that=20 > will make MSO management that much more difficult. >=20 > Thanks again, >=20 > Kirk Friedman >=20 > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: Monday, June 09, 2003 11:17 AM > To: Kirk Friedman > Cc: bwijnen@lucent.com; ipcdn@ietf.org > Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 >=20 >=20 >=20 > Kirk - thanks for your comments. My mailer doesn't do a good=20 > job of inlining responses, so I'll refer to your numbering: >=20 > 1. Agreed on the redundancy on packet matching, although the=20 > two mechanisms and their matching criteria differ. How does=20 > this affect the decision to use RFC3289, though? >=20 > 2. Yes, we have Docsis classifiers, and now we have=20 > RFC3289-filter-classifiers-as-used-for-subscriber-management.=20 > But the 3289 classifiers are doing what the old submgt Filter=20 > table was doing. So is the confusion just in the word=20 > "classifier", or am I missing something else? >=20 > 3. The ifIndex should be the Docsis MAC interface, which is a=20 > bidirectional interface. Does this need to be clarified in the i-d? >=20 > 4. I don't think there's any mandate that we move any=20 > functionality unrelated to subscriber management under the=20 > 3289 umbrella. So yes, we have token buckets (for the QoS=20 > MIB), but they do not appear in the context of RFC3289. >=20 > 5. Thee is no need to support diffServQEntry at all.=20 > zeroDotZero, Count Actions, and Drop Actions are all that is=20 > needed. (see below for your broader comment about the QoS MIB). >=20 > 6. In recent versions of the subscriber management MIB, two=20 > classifiers would have been needed to match the same port=20 > numbers in TCP and UDP, so no savings there. Here's the=20 > relevant text from the -10 draft: >=20 > docsSubMgtPktFilterUlp OBJECT-TYPE > SYNTAX Integer32 (0..256) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Upper level protocol to match. If this value is 256, > matches ALL ULP values. Otherwise, this matches the specific > protocol value. Note that if the packet ULP is either=20 > 6 (tcp) or > 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be > consulted (if its entry exists) to see if this entry matches. > If this value is neither tcp(6) nor udp(17), then that > table is not consulted." >=20 > 7. There are no values for the CM - this is a CMTS-only MIB.=20 > We *do* need a section of the OSSI spec which calls out the=20 > minimal requirements for implementation of RFC3289 on CMTSs.=20 > Do we need anything beyond that? I don't think it lines up=20 > quite as cleanly as, for example, ifTable, because the=20 > expressive power of RFC3289 lies in the flexibility of its structure. >=20 > (re your unnumbered summary): >=20 > On the most literal level, there is no reason why this change=20 > should cause any confusion with the QoS MIB. Subscriber=20 > Management has always been independent of the QoS MIB, and=20 > the choice to adopt RFC3289 representation for=20 > packet-filtering criteria doesn't change that. The QoS MIB=20 > will continue to use its own criteria and will continue to be=20 > applied independently of the representation of subscriber=20 > management filtering. >=20 > On a broader broader MIB-representational level, I'd agree=20 > that there may be work ahead to coordinate with the QoS MIB. =20 > The QoS MIB is also evolving, and may one day also choose to=20 > adopt conventions from RFC3289. If so, the 3289 framework=20 > will need to convey the relationship between the two=20 > processes. I believe that it has the expressive power to do=20 > so. But, for now, I'd be very reluctant to push for that=20 > level of unity with something as necessarily complex as the=20 > QoS MIB. I'd rather make progress independently for now. >=20 > As for implementation, keep in mind that even if QoS does go=20 > this way, there is no requirement that the full arbitrary=20 > expressiveness of 3289 be implemented - classifying the same=20 > packet through 3 meters, two merge ramps, a toll booth and=20 > two truck stops. We can use 3289 as a tool to express the=20 > problems we have - not to impose arbitrarily difficult=20 > queuing regimes. >=20 > Regards, > Wilson Sawyer >=20 >=20 >=20 >=20 > "Kirk Friedman" > , > ant.com> cc: > > Subject: RE:=20 > [ipcdn] draft > submitted: subscriber > 06/09/03 12:50 PM management MIB -11 >=20 >=20 >=20 >=20 >=20 >=20 > Hi Wilson, >=20 > Sorry this took so long to put together. I have real=20 > reservations about this change. While it does indeed remove=20 > some MIB redundancy and allow for some future capabilities,=20 > it also complicates matters quite a bit during implementation=20 > and for understanding how the QoS and Subscriber Management=20 > MIBs work together on CMTS and CMs. >=20 > 1) There is already redundancy between the DOCSIS 1.1 QoS MIB=20 > (currently > draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in=20 > the packet matching criteria. In some sense that simplifies=20 > both implementation and understanding how the two MIBs=20 > operate together. >=20 > 2) It is confusing that classifiers for a DOCSIS system are=20 > no longer uniquely defined. There are DOCSIS packet=20 > classifiers for service flows and now classifiers associated=20 > with RFC3289 and the Subscriber Mgmt MIB. >=20 > 3) The diffServDataPathEntry is indexed by ifIndex (which is=20 > fine) and ifDirection. It is somewhat based on the premise=20 > that an interface is bi-directional. The RFI interfaces are=20 > uni-directional. So there needs to be a description that=20 > indicates which direction applies for which interface type=20 > for which device (CMTS/CM). See last item. >=20 > 4) In order to follow the compliancies of RFC3289, groups=20 > that are not called out in the subscriber MIB are now=20 > mandatory. The diffServMIBTBParamGroup must be implemented=20 > because "This group is mandatory for devices that implement=20 > token-bucket metering functions." The diffServMIBMeterGroup=20 > is "... is mandatory for devices that implement metering=20 > functions." Both the CMTS and CM do this. >=20 > 5) The requirements to include row pointers to diffServQEntry=20 > is also confusing, even if zeroDotZero is applied in most=20 > cases. Again, there is alot of overlap with QoS MIB. >=20 > 6) Two classifiers must be used if it is desired to match=20 > only TCP/UDP packets. This was one of the shortcuts in the=20 > previous version of the Subscriber Mgmt MIB since this is the=20 > majority of the traffic on the Internet. >=20 > 7) One way out of this confusion would be to specify all the=20 > various values for the objects of this MIB for CM and CMTS. =20 > This would be like the relationship between the ifTable and=20 > RFC2670 called Appendix B of the DOCSIS OSSI specification. =20 > However, my understanding is that for DOCSIS 1.1 this=20 > specification is going to be wrapped up soon. >=20 > RFC3289 is used to provide a solution for both filtering=20 > and QoS. But requiring part of its implementation seems to=20 > me to open up a whole new can of worms about implementation=20 > and precedence with the DOCSIS 1.1 QoS MIB. >=20 > Thanks, >=20 > Kirk Friedman > Correlant Communications > 15110 Avenue Of Science > San Diego, CA., 92128 >=20 >=20 >=20 >=20 > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On=20 > Behalf Of Wilson.Sawyer@arrisi.com > Sent: Thursday, May 29, 2003 5:22 AM > To: ipcdn@ietf.org > Cc: bwijnen@lucent.com > Subject: [ipcdn] draft submitted: subscriber management MIB -11 >=20 >=20 > I have submitted a greatly-revised version of the subscriber=20 > management mib (draft-ietf-ipcdn-subscriber-mib-11.txt),=20 > making use of the Diffserv MIB > (RFC3289) as outlined in my April 28 email. The good news is=20 > that the document is now shorter, since much of filtering is=20 > now deferred to existing facilities in RFC3289. This will be=20 > a significant implementation change for CMTS vendors and operators. >=20 > The reason for the change is that the overlap with RFC3289=20 > was so great that I did not believe that the document would=20 > pass the broader review needed for RFC approval. We gain by=20 > re-using the work that has already gone into 3289. It also=20 > gives us the ability, although not mandated, to integrate=20 > with other facilities within 3289. >=20 > I urge CMTS vendors and operators, in particular, to review=20 > this carefully and make suggestions. As always, this document=20 > is the product of the working group and only proceeds with=20 > working group consensus. >=20 > Respectfully submitted, > Wilson Sawyer > ARRIS >=20 >=20 > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=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 From exim@www1.ietf.org Thu Jul 17 16:28:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21384 for ; Thu, 17 Jul 2003 16:28:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFMC-0006iA-KY for ipcdn-archive@odin.ietf.org; Thu, 17 Jul 2003 16:28:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HKS4iu025794 for ipcdn-archive@odin.ietf.org; Thu, 17 Jul 2003 16:28:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFM9-0006hA-BL; Thu, 17 Jul 2003 16:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFLy-0006gu-S4 for ipcdn@optimus.ietf.org; Thu, 17 Jul 2003 16:27:50 -0400 Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21337 for ; Thu, 17 Jul 2003 16:27:45 -0400 (EDT) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6HKMDwQ010882 for ; Thu, 17 Jul 2003 14:22:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C34CA1.1B98AC5D" Subject: [ipcdn] IPCDN meeting minutes from IETF 57 in Vienna Date: Thu, 17 Jul 2003 14:22:13 -0600 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [ipcdn] IPCDN meeting minutes from IETF 57 in Vienna Thread-Index: AcL5bikJ89UOWkr5Tha+akgQ0ZM93xTMqGew From: "Jean-Francois Mule" To: "IPCDN WG (E-mail)" X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34CA1.1B98AC5D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Below are the meeting minutes for review & comment. Please send comments within 1 week, thanks. Jean-Francois. --------------------- IETF IPCDN Meeting Vienna, Austria Wednesday July 16, 2003 Reported by Azlina Ahmad (azlina@cisco.com) and Kevin Luehrs (k.luehrs@cablelabs.com) Edited by Jean-Francois Mule' (jfm@cablelabs.com) --- WG Meeting Summary --- ------------------ Fifteen attendees of the IP over Cable Data Networks WG met at the Vienna IETF on July 16, 2003. The WG discussed the status of its updated work items, that is the 11 Internet-Draft updates released since the last meeting: two drafts for DOCSIS MIBs, three drafts for PacketCable/IPCablecom, and six drafts for CableHome. We also discussed some considerations on the DOCSIS IGMP MIB ID. Total meeting time was about one hour. Meeting materials will be provided as part of the IETF proceedings and are also posted at http://www.ipcdn.org/meetings.html - Summary of decisions made (e.g., document accepted as WG item, documents ready for IETF LC, etc.) o draft-ietf-ipcdn-bpiplus-mib-10.txt pending resolution of 2 open issues (see action items below), the bpi+ ID is ready for WGLC. Expected ID update by end of August/early September'03 and launch of WGLC shortly after. o draft-ietf-ipcdn-subscriber-mib-11.txt draft is ready for a new WGLC (given the latest changes). There was no objections from the WG. o expired draft-ietf-ipcdn-igmp-mib-04.txt Considerations & request for input were brought up by WG chair during the meeting: the proposal is to simply withdraw & stop the ipcdn IGMP mib. This proposal is being considered by the wg chairs and motivated by: a) no activity on the draft & no volunteer to solve MIB doctor comments since August 14, 2002; b) inability to find operators interested in using this MIB mechanism to configure & monitor IGMP using a specific ipcdn IGMP MIB even though there is product support for some vendors; c) ipcdn Atlanta rule: no updates in more than 2 IETF meetings. A decision will be made by the chairs by 8/14/03 based on solicited input. o draft-ietf-ipcdn-pktc-mtamib-01.txt awaiting end of WGLC that is 7/18/03. o draft-ietf-ipcdn-pktc-signaling-01.txt awaiting end of WGLC that is 7/18/03. list of oustanding issues is available on ipcdn and was sent to the list; resolution of those issues is the next step; there was no comments on the list of issues during the IETF 57 meeting; see AI6. o draft-ietf-ipcdn-pktc-eventmess-02.txt draft needs to be reviewed, especially alignment with RFC2669 & Syslog MIB ID. See AI7 below. o draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt o draft-ietf-ipcdn-cable-gateway-config-mib-00.txt o draft-ietf-ipcdn-cable-gateway-device-mib-00.txt o draft-ietf-ipcdn-cable-gateway-qos-mib-00.txt o draft-ietf-ipcdn-cable-gateway-security-mib-00.txt o draft-ietf-ipcdn-cable-gateway-tools-mib-00.txt CableHome IDs need to be reviewed, have been submitted for ipcdn consideration & feedback since October 2002. Call for Volunteers. - Summary of Action Items (AI), [owner] of action item, and target date o draft-ietf-ipcdn-bpiplus-mib-10.txt AI1: send detailed response to ipcdn list detailing how Bert's comments were addressed in draft-10; [jfm] 7/18/03 AI2: co-authors to address 2 remaining open issues and release draft-11; [Alex Katnelson - CableLabs] 8/31/03 a) Explain why for some objects enum values start with 0 (docsBpi2CmtsAuthCmBpiVersion, docsBpi2CmtsTEKSAType) b) Split compliance statement into 2, 1 for CM, 1 for CMTS AI3: wg chairs to launch bpiplus WGLC; [chairs] 9/1/03 o draft-ietf-ipcdn-subscriber-mib-11.txt AI4: wg chairs to launch WGLC after IETF 57 meeting; [chairs] 8/1/03 (=3Dstart date of WGLC) o expired draft-ietf-ipcdn-igmp-mib-04.txt AI5: wg chairs to announce decision on draft withdrawal; [chairs] 8/14/03 o draft-ietf-ipcdn-pktc-signaling-01.txt AI6: resolve list of documented oustanding issues; [Gordon Beacham] 8/31/03 o draft-ietf-ipcdn-pktc-eventmess-02.txt AI7: review draft-ietf-ipcdn-pktc-eventmess-02.txt; [Azlina Ahmad] 8/15/03 o CableHome IDs AI8: co-chairs to call for volunteers to review CH drafts by 8/1/03 with the goal to have 2 assignments for each ID by 8/15/03. [chairs] - Review of the charter milestones to verify they are still correct IPCDN WG charter milestones as available on IETF site are completely out of date. - Review of current charter: Updated charter proposal for IESG approval has been sent to ADs. ------_=_NextPart_001_01C34CA1.1B98AC5D Content-Type: text/html; name="ipcdn-ietf57-minutes-071603.html" Content-Description: ipcdn-ietf57-minutes-071603.html Content-Disposition: attachment; filename="ipcdn-ietf57-minutes-071603.html" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjx0aXRsZT5DOlxEb2N1bWVudHMgYW5kIFNldHRpbmdzXGpmbXVsZVxE ZXNrdG9wXElFVEY1N1xpcGNkblxpcGNkbi1taW51dGVzLTA3MTYwM18wMC50eHQuaHRtbDwvdGl0 bGU+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9IlZpbS82LjIiPg0KPG1ldGEgaHR0 cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNvLTg4 NTktMSI+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSIjZmZmZmZmIiB0ZXh0PSIjMDAwMDAwIj4N CjxwcmU+DQpJRVRGIElQQ0ROIE1lZXRpbmcNClZpZW5uYSwgQXVzdHJpYQ0KV2VkbmVzZGF5IEp1 bHkgMTYsIDIwMDMNCg0KUmVwb3J0ZWQgYnkgQXpsaW5hIEFobWFkIChhemxpbmFAY2lzY28uY29t KQ0KICAgICAgICAgYW5kIEtldmluIEx1ZWhycyAoay5sdWVocnNAY2FibGVsYWJzLmNvbSkNCkVk aXRlZCBieSBKZWFuLUZyYW5jb2lzIE11bGUnIChqZm1AY2FibGVsYWJzLmNvbSkNCg0KDQotLS0g V0cgTWVldGluZyBTdW1tYXJ5DQotLS0gLS0tLS0tLS0tLS0tLS0tLS0tDQpGaWZ0ZWVuIGF0dGVu ZGVlcyBvZiB0aGUgSVAgb3ZlciBDYWJsZSBEYXRhIE5ldHdvcmtzIFdHIG1ldA0KYXQgdGhlIFZp ZW5uYSBJRVRGIG9uIEp1bHkgMTYsIDIwMDMuIFRoZSBXRyBkaXNjdXNzZWQgdGhlIHN0YXR1cw0K b2YgaXRzIHVwZGF0ZWQgd29yayBpdGVtcywgdGhhdCBpcyB0aGUgMTEgSW50ZXJuZXQtRHJhZnQg dXBkYXRlcw0KcmVsZWFzZWQgc2luY2UgdGhlIGxhc3QgbWVldGluZzogdHdvIGRyYWZ0cyBmb3Ig RE9DU0lTIE1JQnMsIHRocmVlDQpkcmFmdHMgZm9yIFBhY2tldENhYmxlL0lQQ2FibGVjb20sIGFu ZCBzaXggZHJhZnRzIGZvciBDYWJsZUhvbWUuIFdlIGFsc28NCmRpc2N1c3NlZCBzb21lIGNvbnNp ZGVyYXRpb25zIG9uIHRoZSBET0NTSVMgSUdNUCBNSUIgSUQuIFRvdGFsIG1lZXRpbmcNCnRpbWUg d2FzIGFib3V0IG9uZSBob3VyLg0KDQpNZWV0aW5nIG1hdGVyaWFscyB3aWxsIGJlIHByb3ZpZGVk IGFzIHBhcnQgb2YgdGhlIElFVEYgcHJvY2VlZGluZ3MgYW5kDQphcmUgYWxzbyBwb3N0ZWQgYXQg PEEgSFJFRj0iaHR0cDovL3d3dy5pcGNkbi5vcmcvbWVldGluZ3MuaHRtbCI+aHR0cDovL3d3dy5p cGNkbi5vcmcvbWVldGluZ3MuaHRtbDwvQT4NCg0KDQotIFN1bW1hcnkgb2YgZGVjaXNpb25zIG1h ZGUNCiAgKGUuZy4sIGRvY3VtZW50IGFjY2VwdGVkIGFzIFdHIGl0ZW0sDQogICAgZG9jdW1lbnRz IHJlYWR5IGZvciBJRVRGIExDLCBldGMuKQ0KDQogIG8gZHJhZnQtaWV0Zi1pcGNkbi1icGlwbHVz LW1pYi0xMC50eHQNCiAgICBwZW5kaW5nIHJlc29sdXRpb24gb2YgMiBvcGVuIGlzc3VlcyAoc2Vl IGFjdGlvbiBpdGVtcyBiZWxvdyksIHRoZQ0KICAgIGJwaSsgSUQgaXMgcmVhZHkgZm9yIFdHTEMu IEV4cGVjdGVkIElEIHVwZGF0ZSBieQ0KICAgIGVuZCBvZiBBdWd1c3QvZWFybHkgU2VwdGVtYmVy JzAzIGFuZCBsYXVuY2ggb2YgV0dMQyBzaG9ydGx5IGFmdGVyLg0KDQogIG8gZHJhZnQtaWV0Zi1p cGNkbi1zdWJzY3JpYmVyLW1pYi0xMS50eHQNCiAgICBkcmFmdCBpcyByZWFkeSBmb3IgYSBuZXcg V0dMQyAoZ2l2ZW4gdGhlIGxhdGVzdCBjaGFuZ2VzKS4gVGhlcmUgd2FzDQogICAgbm8gb2JqZWN0 aW9ucyBmcm9tIHRoZSBXRy4NCg0KICBvIGV4cGlyZWQgZHJhZnQtaWV0Zi1pcGNkbi1pZ21wLW1p Yi0wNC50eHQNCiAgICBDb25zaWRlcmF0aW9ucyAmYW1wOyByZXF1ZXN0IGZvciBpbnB1dCB3ZXJl IGJyb3VnaHQgdXAgYnkgV0cgY2hhaXINCiAgICBkdXJpbmcgdGhlIG1lZXRpbmc6IHRoZSBwcm9w b3NhbCBpcyB0byBzaW1wbHkgd2l0aGRyYXcgJmFtcDsgc3RvcCB0aGUNCiAgICBpcGNkbiBJR01Q IG1pYi4gVGhpcyBwcm9wb3NhbCBpcyBiZWluZyBjb25zaWRlcmVkIGJ5IHRoZSB3ZyBjaGFpcnMN CiAgICBhbmQgbW90aXZhdGVkIGJ5Og0KICAgICAgYSkgbm8gYWN0aXZpdHkgb24gdGhlIGRyYWZ0 ICZhbXA7IG5vIHZvbHVudGVlciB0byBzb2x2ZSBNSUIgZG9jdG9yDQogICAgICAgICBjb21tZW50 cyBzaW5jZSBBdWd1c3QgMTQsIDIwMDI7DQogICAgICBiKSBpbmFiaWxpdHkgdG8gZmluZCBvcGVy YXRvcnMgaW50ZXJlc3RlZCBpbiB1c2luZyB0aGlzIE1JQg0KICAgICAgICAgbWVjaGFuaXNtIHRv IGNvbmZpZ3VyZSAmYW1wOyBtb25pdG9yIElHTVAgdXNpbmcgYSBzcGVjaWZpYyBpcGNkbg0KICAg ICAgICAgSUdNUCBNSUIgZXZlbiB0aG91Z2ggdGhlcmUgaXMgcHJvZHVjdCBzdXBwb3J0IGZvciBz b21lIHZlbmRvcnM7DQogICAgICBjKSBpcGNkbiBBdGxhbnRhIHJ1bGU6IG5vIHVwZGF0ZXMgaW4g bW9yZSB0aGFuIDIgSUVURiBtZWV0aW5ncy4NCiAgICBBIGRlY2lzaW9uIHdpbGwgYmUgbWFkZSBi eSB0aGUgY2hhaXJzIGJ5IDgvMTQvMDMgYmFzZWQgb24gc29saWNpdGVkDQogICAgaW5wdXQuDQoN CiAgbyBkcmFmdC1pZXRmLWlwY2RuLXBrdGMtbXRhbWliLTAxLnR4dA0KICAgIGF3YWl0aW5nIGVu ZCBvZiBXR0xDIHRoYXQgaXMgNy8xOC8wMy4NCg0KICBvIGRyYWZ0LWlldGYtaXBjZG4tcGt0Yy1z aWduYWxpbmctMDEudHh0DQogICAgYXdhaXRpbmcgZW5kIG9mIFdHTEMgdGhhdCBpcyA3LzE4LzAz Lg0KICAgIGxpc3Qgb2Ygb3VzdGFuZGluZyBpc3N1ZXMgaXMgYXZhaWxhYmxlIG9uIGlwY2RuIGFu ZCB3YXMgc2VudCB0byB0aGUNCiAgICBsaXN0OyByZXNvbHV0aW9uIG9mIHRob3NlIGlzc3VlcyBp cyB0aGUgbmV4dCBzdGVwOyB0aGVyZSB3YXMgbm8NCiAgICBjb21tZW50cyBvbiB0aGUgbGlzdCBv ZiBpc3N1ZXMgZHVyaW5nIHRoZSBJRVRGIDU3IG1lZXRpbmc7IHNlZSBBSTYuDQoNCiAgbyBkcmFm dC1pZXRmLWlwY2RuLXBrdGMtZXZlbnRtZXNzLTAyLnR4dA0KICAgIGRyYWZ0IG5lZWRzIHRvIGJl IHJldmlld2VkLCBlc3BlY2lhbGx5IGFsaWdubWVudCB3aXRoIFJGQzI2NjkgJmFtcDsNCiAgICBT eXNsb2cgTUlCIElELiBTZWUgQUk3IGJlbG93Lg0KDQogIG8gZHJhZnQtaWV0Zi1pcGNkbi1jYWJs ZS1nYXRld2F5LWFkZHJlc3NpbmctbWliLTAwLnR4dA0KICBvIGRyYWZ0LWlldGYtaXBjZG4tY2Fi bGUtZ2F0ZXdheS1jb25maWctbWliLTAwLnR4dA0KICBvIGRyYWZ0LWlldGYtaXBjZG4tY2FibGUt Z2F0ZXdheS1kZXZpY2UtbWliLTAwLnR4dA0KICBvIGRyYWZ0LWlldGYtaXBjZG4tY2FibGUtZ2F0 ZXdheS1xb3MtbWliLTAwLnR4dA0KICBvIGRyYWZ0LWlldGYtaXBjZG4tY2FibGUtZ2F0ZXdheS1z ZWN1cml0eS1taWItMDAudHh0DQogIG8gZHJhZnQtaWV0Zi1pcGNkbi1jYWJsZS1nYXRld2F5LXRv b2xzLW1pYi0wMC50eHQNCiAgICBDYWJsZUhvbWUgSURzIG5lZWQgdG8gYmUgcmV2aWV3ZWQsIGhh dmUgYmVlbiBzdWJtaXR0ZWQgZm9yIGlwY2RuDQogICAgY29uc2lkZXJhdGlvbiAmYW1wOyBmZWVk YmFjayBzaW5jZSBPY3RvYmVyIDIwMDIuIENhbGwgZm9yIFZvbHVudGVlcnMuDQoNCg0KLSBTdW1t YXJ5IG9mIEFjdGlvbiBJdGVtcyAoQUkpLCBbb3duZXJdIG9mIGFjdGlvbiBpdGVtLCBhbmQgdGFy Z2V0IGRhdGUNCiAgbyBkcmFmdC1pZXRmLWlwY2RuLWJwaXBsdXMtbWliLTEwLnR4dA0KICAgICBB STE6IHNlbmQgZGV0YWlsZWQgcmVzcG9uc2UgdG8gaXBjZG4gbGlzdCBkZXRhaWxpbmcgaG93IEJl cnQncw0KICAgICAgICAgIGNvbW1lbnRzIHdlcmUgYWRkcmVzc2VkIGluIGRyYWZ0LTEwOyBbamZt XSA3LzE4LzAzDQogICAgIEFJMjogY28tYXV0aG9ycyB0byBhZGRyZXNzIDIgcmVtYWluaW5nIG9w ZW4gaXNzdWVzIGFuZCByZWxlYXNlDQogICAgICAgICAgZHJhZnQtMTE7IFtBbGV4IEthdG5lbHNv biAtIENhYmxlTGFic10gOC8zMS8wMw0KICAgICAgICAgIGEpIEV4cGxhaW4gd2h5IGZvciBzb21l IG9iamVjdHMgZW51bSB2YWx1ZXMgc3RhcnQgd2l0aCAwDQogICAgICAgICAgICAgKGRvY3NCcGky Q210c0F1dGhDbUJwaVZlcnNpb24sIGRvY3NCcGkyQ210c1RFS1NBVHlwZSkNCiAgICAgICAgICBi KSBTcGxpdCBjb21wbGlhbmNlIHN0YXRlbWVudCBpbnRvIDIsIDEgZm9yIENNLCAxIGZvciBDTVRT DQogICAgIEFJMzogd2cgY2hhaXJzIHRvIGxhdW5jaCBicGlwbHVzIFdHTEM7IFtjaGFpcnNdIDkv MS8wMw0KDQogIG8gZHJhZnQtaWV0Zi1pcGNkbi1zdWJzY3JpYmVyLW1pYi0xMS50eHQNCiAgICAg QUk0OiB3ZyBjaGFpcnMgdG8gbGF1bmNoIFdHTEMgYWZ0ZXIgSUVURiA1NyBtZWV0aW5nOw0KICAg ICAgICAgIFtjaGFpcnNdIDgvMS8wMyAoPXN0YXJ0IGRhdGUgb2YgV0dMQykNCg0KICBvIGV4cGly ZWQgZHJhZnQtaWV0Zi1pcGNkbi1pZ21wLW1pYi0wNC50eHQNCiAgICAgQUk1OiB3ZyBjaGFpcnMg dG8gYW5ub3VuY2UgZGVjaXNpb24gb24gZHJhZnQgd2l0aGRyYXdhbDsgW2NoYWlyc10NCiAgICAg ICAgICA4LzE0LzAzDQoNCiAgbyBkcmFmdC1pZXRmLWlwY2RuLXBrdGMtc2lnbmFsaW5nLTAxLnR4 dA0KICAgICBBSTY6IHJlc29sdmUgbGlzdCBvZiBkb2N1bWVudGVkIG91c3RhbmRpbmcgaXNzdWVz OyBbR29yZG9uIEJlYWNoYW1dDQogICAgICAgICAgOC8zMS8wMw0KDQogIG8gZHJhZnQtaWV0Zi1p cGNkbi1wa3RjLWV2ZW50bWVzcy0wMi50eHQNCiAgICAgQUk3OiByZXZpZXcgZHJhZnQtaWV0Zi1p cGNkbi1wa3RjLWV2ZW50bWVzcy0wMi50eHQ7IFtBemxpbmEgQWhtYWRdDQogICAgICAgICAgOC8x NS8wMw0KDQogIG8gQ2FibGVIb21lIElEcw0KICAgICBBSTg6IGNvLWNoYWlycyB0byBjYWxsIGZv ciB2b2x1bnRlZXJzIHRvIHJldmlldyBDSCBkcmFmdHMgYnkgOC8xLzAzDQogICAgICAgICAgd2l0 aCB0aGUgZ29hbCB0byBoYXZlIDIgYXNzaWdubWVudHMgZm9yIGVhY2ggSUQgYnkgOC8xNS8wMy4N CiAgICAgICAgICBbY2hhaXJzXQ0KDQoNCg0KLSBSZXZpZXcgb2YgdGhlIGNoYXJ0ZXIgbWlsZXN0 b25lcyB0byB2ZXJpZnkgdGhleSBhcmUgc3RpbGwgY29ycmVjdA0KICAgIElQQ0ROIFdHIGNoYXJ0 ZXIgbWlsZXN0b25lcyBhcyBhdmFpbGFibGUgb24gSUVURiBzaXRlIGFyZSBjb21wbGV0ZWx5DQog ICAgb3V0IG9mIGRhdGUuDQoNCi0gUmV2aWV3IG9mIGN1cnJlbnQgY2hhcnRlcjoNCiAgICBVcGRh dGVkIGNoYXJ0ZXIgcHJvcG9zYWwgZm9yIElFU0cgYXBwcm92YWwgaGFzIGJlZW4gc2VudCB0byBB RHMuDQoNCkNvLWNoYWlyczoNCiAgUmljaCBXb3VuZHkgLSBDb21jYXN0IC0gUmljaGFyZF9Xb3Vu ZHlAY2FibGUuY29tY2FzdC5jb20NCiAgSmVhbi1GcmFuY29pcyBNdWxlIC0gQ2FibGVMYWJzIC0g amZtQGNhYmxlbGFicy5jb20NCg0KPC9wcmU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= ------_=_NextPart_001_01C34CA1.1B98AC5D-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 17 16:39:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21885 for ; Thu, 17 Jul 2003 16:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFWn-0007Mb-1I for ipcdn-archive@odin.ietf.org; Thu, 17 Jul 2003 16:39:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6HKd1v8028300 for ipcdn-archive@odin.ietf.org; Thu, 17 Jul 2003 16:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFWm-0007ML-LP; Thu, 17 Jul 2003 16:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19dFWF-0007LD-Ry for ipcdn@optimus.ietf.org; Thu, 17 Jul 2003 16:38:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21878 for ; Thu, 17 Jul 2003 16:38:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19dFWD-0001FB-00 for ipcdn@ietf.org; Thu, 17 Jul 2003 16:38:25 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19dFW2-0001F8-00 for ipcdn@ietf.org; Thu, 17 Jul 2003 16:38:14 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6HKbPwQ011760; Thu, 17 Jul 2003 14:37: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: multipart/alternative; boundary="----_=_NextPart_001_01C34CA3.3B498FEB" Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Thu, 17 Jul 2003 14:37:25 -0600 Message-ID: Thread-Topic: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Thread-Index: AcLTcy1oUzrP+TZJSta0Z6wy3lxNNR5L6VIw From: "Jean-Francois Mule" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C34CA3.3B498FEB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bert & all, Below are the details on what comments got addresed in draft-ietf-ipcdn-bpiplus-mib-10 based on your review. Jean-Francois. > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, February 13, 2003 8:13 AM > To: Ipcdn (E-mail) > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com > Subject: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt >=20 >=20 > Here are my comments: >=20 > - references/citations in abstract are not allowed per > RFC-Editor policy -> deleted refs. > - 2nd para in abstract seems not needed. but I can live > with it -> deleted. > - Tiltle of sect 1 is not inline with MIB boilerplate -> fixed. > - 3rd para in section 1 is not needed, in fact I'd rather > see it removed. The RFC3410 explains all that. -> fixed. > - DESCRIPTION clause of MODULE-IDENTITY is missing the > MIB copyright statement -> added the following text: Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC xxx; see the RFC itself for full legal notices." > - I had asked in in earlier email: > Mmm.. did I review rev 07. I can't quickly find that I > did send a review report. > I am assuming that you will take care of all the comments > that are (in my view) to be expected based on the review > of the subscriber mib I did, right? -> yes. will review and double check draft10. > - Is this MIB obsoleteing an earlier (RFC) version? -> no. BPI mib and BPI plus coexist together. > If this is the first time this MIB gets publsihed as an > RFC, then we want to see only one simple revisions clause > with a DESCRIPTION aka: > "Initial version, published as RFC xxxx." > -- RFC-editor assigns xxxx -> fixed. > We do not want to see long lists of changes that happened > during initial revisions of Internet Drafts -> ok. Left all the revisions in there for now with comments to be deleted when doing final rfc editing. Did not get removed in draft10 yet, will be done later. > - And how did you decide to assign the=20 > docsBpi2MIB MODULE-IDENTITY > ... > ::=3D { docsIfMib 6 } > I worry a lot about this practice, cause it is very difficult > to keep track and to ensure that no conflicts arise. -> fixed by replacing this by ::=3D { mib-2 xx } -- xx to be assigned by IANA > - I worry about: > X509Certificate ::=3D TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An X509 digital certificate encoded as an ASN.1 DER > object." > SYNTAX OCTET STRING (SIZE (0..1400)) > The reason is that this is not some X509 generic Certificate > but a special one for your IPCDN use. > How about renaming it to DocsX509ASN1DEREncodedCertificate ?? -> good point. Changed to the suggested TC name everywhere. > - docsBpi2CmAuthReset OBJECT-TYPE > Would it be wise to add a docsBpi2CmAuthLastReset object > similar as what was done in the subscriber MIB module? -> per our interim meeting in Feb'03, the new last reset object will not be added because this reset is really only for testing purposes. Changed docsBpi2CmAuthReset description has been updated to add This object is for testing purposes only and therefore it does not require to be associated with a last reset object." > - objects like: > docsBpi2CmAuthRejects OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the count of times the CM > has received an Authorization Reject message,=20 > since reboot." > require that a Counter starts at zero. But those are NOT the > semanticws of a Counter32. If this is what you want, I think you > need to use the ZeroBasedCounter32 as per RFC2021. > Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6 > specifically 4.6.1.2 > You have quite a few of those objetcs -> ok. For each Counter32 object that require a start at zero, we will change syntax from Counter32 to ZeroBasedCounter32. Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB. > - docsBpi2CmAuthRejectErrorString OBJECT-TYPE > SYNTAX SnmpAdminString (SIZE (0..128)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the Display-String in > S/Display-String/text string/ ?? > Same for docsBpi2CmAuthInvalidErrorString > And for docsBpi2CmTEKKeyRejectErrorString > docsBpi2CmTEKInvalidErrorString > docsBpi2CmIpMulticastSAMapRejectErrorString > docsBpi2CmtsAuthInvalidErrorString -> done - replaced all 'Display-String' in description clauses by 'text string' > - docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE > SYNTAX INTEGER { > none(0), > des56CbcMode(1), > des40CbcMode(2) > } > We recommend to start Enumerations from 1. > Possibly the 1 and 2 for the desXxxx enumerations are so numbered > to align with some other place. If so, then starting with zero > seems acceptable. But pls add some explanantion in that case -> ok. fixed. Table 4-22 of bpiplus spec defines the Data Encryption Algorithm Identifiers and values are: 0 Reserved 1 CBC-Mode, 56-bit DES 2 CBC-Mode, 40-bit DES 3-255 Reserved so it is proposed to leave object def as-is and add the following justification text: "Values 'des56CbcMode' and 'des40CbcMode' are defined in the interface specification as integer values (1) and (2)." > Same question for simial xxxCrypto object -> ok. fixed. > - docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE > SYNTAX INTEGER { > none(0) > } > An object that can only have one value that is ALWAYS zero? > What is the use of that? Maybe future extensibility, but if so, > then please say so in DESCRIPTION clause, otherwise this > seems nonsense and bloat. -> ok. fixed. Added "This object is defined for future extensibility." > Same question for simial xxxCrypto object -> ok. fixed. same as above. > - docsBpi2CmIpMulticastIndex OBJECT-TYPE > SYNTAX Integer32 (1..1000) > It is valid. But for INDEX objects we prefer Unsigned32 with > a range. see again the mib review guidelines doc > I think this occurs a few more time in this MIB module. > As I say, it is valid, but since your still working on this > MIB module, might as well use the recommended method. -> certainly. fixed all integer32 INDEX objects syntax to Unsigned32. This includes the following objects: docsBpi2CmTEKSAId docsBpi2CmIpMulticastIndex docsBpi2CmCryptoSuiteIndex docsBpi2CmtsTEKSAId docsBpi2CmtsIpMulticastIndex docsBpi2CmtsMulticastAuthSAId docsBpi2CmtsCACertIndex > - docsBpi2CmIpMulticastAddress OBJECT-TYPE > SYNTAX InetAddress > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This object represents the IP multicast address > to be mapped." > you MUST specify with InetAddressType object defines the context > or type of this object. You did it correct in subscriber mib. -> fixed. > - docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE > SYNTAX INTEGER { > trusted (1), > untrusted (2) > } > Seems to me that docsBpi2CmtsDefaultSelfSignedManufCertTrusted > descriptor with a syntax of TruthValue is more appropriate > - docsBpi2CmtsCheckCertValidityPeriods OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-write > STATUS current > DESCRIPTION > "Setting this object to TRUE causes all chained and > The better wording is: > "Setting this object to 'true' causes all chained and -> ^^^^^ fixed. > This occurs a few more times in this MIB module -> fixed all of them. > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE > SYNTAX INTEGER { > bpi (0), > bpiPlus (1) > } > Any special reason why enumeration cannot start at 1? to be discussed in docsis team. > - docsBpi2CmtsAuthCmReset OBJECT-TYPE > Yet another way in which you guys do resets. > - docsBpi2CmtsAuthCmInfos OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the count of times the > CMTS has received an Authentication Information=20 > message from > this CM, since entry creatiion." > ZeroBasedCounter32 ?? -> yes, fixed. > You have several of those -> yes fixed. > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > SYNTAX INTEGER { > unknown (0), > validCmChained (1), > validCmTrusted (2), > invalidCmUntrusted (3), > invalidCAUntrusted (4), > invalidCmOther (5), > invalidCAOther (6) > } > Any special reason to start ENUMERATION with zero ?? > - docsBpi2CmtsTEKSAType OBJECT-TYPE > SYNTAX INTEGER { > none(0), > primary(1), > static(2), > dynamic(3) > } > Any special reason to start ENUMERATION with zero ?? -> to be addressed in docsis team > There are more of those... I won;t list them anymore, > I guess you get the gist. > - I wonder if it would not be better to have 2 compliance > statements, one for CM and one for CMTS. > It is unclear to me if any GROUPS are mandatory. I think > some are, but it depends if your are CM or CMTS -> to be addressed in docsis team > - -- relaxation on IP addressing > OBJECT docsBpi2CmIpMulticastAddressType > -- SYNTAX InetAddressType { ipv4(1) } > Pls make it a real SYNTAX clause and not a comment. > That SMICng barks at it is something we know and SMICng > should be fixed. -> fixed. > - You have citations in DESCRIPTION clauses. We normally do not > do that, cause they will be lost when people extract the > MIB module from the RFC. -> ok. fixed. > - Mmm.. you start off with some OBSOLETED object group right=20 > away he? You might want to say something about when/why that > happened. > - References need to be split in normative and informative -> ok. fixed. > - You have picked up the new MIB boilerplate, but you still=20 > have a lot of old MIB boilerplate references included, which > make no sense anymore -> ok. cleaned as much as possible. > - The new MIB boilerplate has [RFC2578], [RFC2579] and [RFC2580] > as citations, but they do not show as such in the references > section -> ok. fixed. > - The security considerations section is not compliant with the > new MIB security guidelines. The subscriber MIB has > done a much better job. You should too. -> ok, beefed up the security consideration section. > - I see 3 names in CONTACT-INFO while only two are listed > on front page and only two are listed in Author's addresses? -> The 2 co-authors of draft 08 agree to add Kaz Ozawa as part of the author list. Contact info for Kaz corrected. Minor additional nits: - Enforced (mostly) the 72 character column limit in Word, and fixing the wrapped text (many many changes). - Removed some non-ASCII text, especially "special" quotation marks - Removed IMPORT of Gauge32, since it is not used - Removed the REFERENCE clauses from the OBJECT compliance statements, since they are not permitted per the following syntax from page 6 of RFC 2580. ------_=_NextPart_001_01C34CA3.3B498FEB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

Bert & = all,

Below are = the details on what comments got addresed in = draft-ietf-ipcdn-bpiplus-mib-10 based on your review.

Jean-Francois.
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Thursday, February 13, 2003 8:13 = AM
> To: Ipcdn (E-mail)
> Cc: stu.green@arrisi.com; Alexander = Katsnelson; k.ozawa@cablelabs.com
> Subject: [ipcdn] Review of: = draft-ietf-ipcdn-bpiplus-mib-08.txt
>
>
> Here are my comments:
>
> - references/citations in abstract are not = allowed per
>   RFC-Editor policy
  = -> deleted refs.

> - 2nd para in abstract seems not needed. but I can = live
>   with it
  = ->   deleted.

> - Tiltle of sect 1 is not inline with MIB = boilerplate
  = ->   fixed.

> - 3rd para in section 1 is not needed, in fact I'd = rather
>   see it removed. The RFC3410 = explains all that.
  = ->   fixed.

> - DESCRIPTION clause of MODULE-IDENTITY is missing = the
>   MIB copyright = statement
  = ->   added the following text:
           &n= bsp;  Copyright (C) The Internet Society (2003). This = version
           &n= bsp;  of this MIB module is part of RFC xxx; see the = RFC
           &n= bsp;  itself for full legal notices."

> - I had asked in in earlier email:
>   Mmm.. did I review rev 07. I can't = quickly find that I
>   did send a review = report.
>   I am assuming that you will take = care of all the comments
>   that are (in my view) to be = expected based on the review
>   of the subscriber mib I did, = right?
  = -> yes. will review and double check draft10.

> - Is this MIB obsoleteing an earlier (RFC) = version?
  = ->   no. BPI mib and BPI plus coexist = together.

>   If this is the first time this MIB gets publsihed = as an
>   RFC, then we want to see only one = simple revisions clause
>   with a DESCRIPTION = aka:
>      "Initial = version, published as RFC xxxx."
>      -- RFC-editor = assigns xxxx
  = ->   fixed.

>   We do not want to see long lists of changes that = happened
>   during initial revisions of = Internet Drafts
  = ->   ok. Left all the revisions in there for now with = comments to be
  = deleted when doing final rfc editing. Did not get removed in = draft10
  yet, = will be done later.

> - And how did you decide to assign the
>   docsBpi2MIB = MODULE-IDENTITY
>      = ...
>      ::=3D { = docsIfMib 6 }
>   I worry a lot about this practice, = cause it is very difficult
>   to keep track and to ensure that = no conflicts arise.
  = ->   fixed by replacing this by
            = ::=3D { mib-2 xx }   -- xx to be assigned by = IANA

> - I worry about:
>       = X509Certificate ::=3D TEXTUAL-CONVENTION
>          &nbs= p; STATUS    current
>          &nbs= p; DESCRIPTION
>          &nbs= p;     "An X509 digital certificate encoded as = an ASN.1 DER
>          &nbs= p; object."
>          &nbs= p; SYNTAX    OCTET STRING (SIZE (0..1400))
>    The reason is that this is = not some X509 generic Certificate
>    but a special one for your = IPCDN use.
>    How about renaming it to = DocsX509ASN1DEREncodedCertificate ??
  = ->   good point. Changed to the suggested TC name = everywhere.


> -       docsBpi2CmAuthReset = OBJECT-TYPE
>    Would it be wise to add a = docsBpi2CmAuthLastReset object
>    similar as what was done in = the subscriber MIB module?
  = -> per our interim meeting in Feb'03, the new last reset = object
  = will  not
  be = added because this reset is really only for testing = purposes.
  = Changed docsBpi2CmAuthReset description has been updated to = add
        This object is for = testing purposes only and therefore it
        does not require to be = associated with a last reset object."


> - objects like:
>       = docsBpi2CmAuthRejects    OBJECT-TYPE
>          &nbs= p; SYNTAX         = Counter32
>          &nbs= p; MAX-ACCESS     read-only
>          &nbs= p; STATUS         = current
>          &nbs= p; DESCRIPTION
>          &nbs= p;      "The value of this object is the = count of times the CM
>          &nbs= p; has received an Authorization Reject message,
> since reboot."
>   require that a Counter starts at = zero. But those are NOT the
>   semanticws of a Counter32. If this = is what you want, I think you
>   need to use the ZeroBasedCounter32 = as per RFC2021.
>   Pls read = draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6
>   specifically 4.6.1.2
>   You have quite a few of those = objetcs
   -> ok.
   For each Counter32 object that require a start at = zero, we
   will change syntax from Counter32 to = ZeroBasedCounter32.
   Added IMPORT ZeroBasedCounter32 FROM = RMON2-MIB.

> -       = docsBpi2CmAuthRejectErrorString    = OBJECT-TYPE
>          &nbs= p; SYNTAX         = SnmpAdminString (SIZE (0..128))
>          &nbs= p; MAX-ACCESS     read-only
>          &nbs= p; STATUS         = current
>          &nbs= p; DESCRIPTION
>          &nbs= p;      "The value of this object is the = Display-String in
>    S/Display-String/text = string/ ??
>    Same for = docsBpi2CmAuthInvalidErrorString
>    And for = docsBpi2CmTEKKeyRejectErrorString
>          &nbs= p; docsBpi2CmTEKInvalidErrorString
>       = docsBpi2CmIpMulticastSAMapRejectErrorString
>     = docsBpi2CmtsAuthInvalidErrorString
  = -> done - replaced all 'Display-String' in description clauses by = 'text
  = string'

> -      = docsBpi2CmTEKDataEncryptAlg   OBJECT-TYPE
>           = SYNTAX         INTEGER = {
>          &nbs= p;            = ;           = none(0),
>          &nbs= p;            = ;           = des56CbcMode(1),
>          &nbs= p;            = ;           = des40CbcMode(2)
>          &nbs= p;            = ;           = }
>    We recommend to start = Enumerations from 1.
>    Possibly the 1 and 2 for the = desXxxx enumerations are so numbered
>    to align with some other = place. If so, then starting with zero
>    seems acceptable. But pls = add some explanantion in that case
  = -> ok. fixed.
  = Table 4-22 of bpiplus spec defines the Data Encryption
  = Algorithm Identifiers and values are:
  0 = Reserved
  1 = CBC-Mode, 56-bit DES
  2 = CBC-Mode, 40-bit DES
  = 3-255 Reserved
  so = it is proposed to leave object def as-is and add the = following
  = justification text:
  = "Values 'des56CbcMode' and 'des40CbcMode' are defined in = the
  = interface specification as integer values (1) and = (2)."


>    Same question for simial xxxCrypto = object
  = -> ok. fixed.

> -       = docsBpi2CmTEKDataAuthentAlg   OBJECT-TYPE
>          &nbs= p; SYNTAX         INTEGER = {
>          &nbs= p;            = ;            = none(0)
>          &nbs= p;            = ;            = }
>    An object that can only have = one value that is ALWAYS zero?
>    What is the use of that? = Maybe future extensibility, but if so,
>    then please say so in = DESCRIPTION clause, otherwise this
>    seems nonsense and = bloat.
  = -> ok. fixed. Added "This object is defined for = future
  = extensibility."

>    Same question for simial xxxCrypto = object
  = -> ok. fixed. same as above.

> -       = docsBpi2CmIpMulticastIndex        = ; OBJECT-TYPE
>          &nbs= p; SYNTAX         Integer32 = (1..1000)
>    It is valid. But for INDEX = objects we prefer Unsigned32 with
>    a range. see again the mib = review guidelines doc
>    I think this occurs a few = more time in this MIB module.
>    As I say, it is valid, but = since your still working on this
>    MIB module, might as well = use the recommended method.
 -> = certainly. fixed all integer32 INDEX objects syntax to = Unsigned32.
  This = includes the following objects:
  = docsBpi2CmTEKSAId
  = docsBpi2CmIpMulticastIndex
  = docsBpi2CmCryptoSuiteIndex
  = docsBpi2CmtsTEKSAId
  = docsBpi2CmtsIpMulticastIndex
  = docsBpi2CmtsMulticastAuthSAId
  = docsBpi2CmtsCACertIndex

> -       = docsBpi2CmIpMulticastAddress  OBJECT-TYPE
>          &nbs= p; SYNTAX         = InetAddress
>          &nbs= p; MAX-ACCESS     read-only
>          &nbs= p; STATUS         = current
>          &nbs= p; DESCRIPTION
>          &nbs= p;      "This object represents the IP = multicast address
>          &nbs= p; to be mapped."
>    you MUST specify with = InetAddressType object defines the context
>    or type of this object. You = did it correct in subscriber mib.
  = -> fixed.

> -       = docsBpi2CmtsDefaultSelfSignedManufCertTrust  = OBJECT-TYPE
>          &nbs= p; SYNTAX    INTEGER {
>          &nbs= p;           trusted = (1),
>          &nbs= p;           untrusted = (2)
>          &nbs= p;           = }
>    Seems to me that = docsBpi2CmtsDefaultSelfSignedManufCertTrusted
>    descriptor with a syntax of = TruthValue is more appropriate
> -       = docsBpi2CmtsCheckCertValidityPeriods    = OBJECT-TYPE
>          &nbs= p; SYNTAX         = TruthValue
>          &nbs= p; MAX-ACCESS     read-write
>          &nbs= p; STATUS         = current
>          &nbs= p; DESCRIPTION
>          = "Setting this object to TRUE causes all chained and
>    The better wording = is:
>          = "Setting this object to 'true' causes all chained and
           &n= bsp;           &nb= sp;   ->       ^^^^^ = fixed.

>    This occurs a few more times in this MIB = module
     -> fixed all of them.


> -     docsBpi2CmtsAuthCmBpiVersion  = OBJECT-TYPE
>          &nbs= p; SYNTAX         INTEGER = {
>          &nbs= p;            = ;  bpi (0),
>          &nbs= p;            = ;  bpiPlus (1)
>          &nbs= p;            = ;        }
>    Any special reason why = enumeration cannot start at 1?
      to be discussed in docsis = team.

> -       = docsBpi2CmtsAuthCmReset  OBJECT-TYPE
>    Yet another way in which you = guys do resets.
> -       = docsBpi2CmtsAuthCmInfos       = OBJECT-TYPE
>          &nbs= p; SYNTAX         = Counter32
>          &nbs= p; MAX-ACCESS     read-only
>          &nbs= p; STATUS         = current
>          &nbs= p; DESCRIPTION
>          &nbs= p;      "The value of this object is the = count of times the
>          &nbs= p; CMTS has received an Authentication Information
> message from
>          &nbs= p; this CM, since entry creatiion."
>    ZeroBasedCounter32 = ??
  = -> yes, fixed.

>    You have several of those
  = -> yes fixed.

> -       = docsBpi2CmtsAuthBpkmCmCertValid       =   OBJECT-TYPE
>          &nbs= p; SYNTAX    INTEGER {
>          &nbs= p;            = ;       unknown (0),
>          &nbs= p;            = ;       validCmChained (1),
>          &nbs= p;            = ;       validCmTrusted (2),
>          &nbs= p;            = ;       invalidCmUntrusted = (3),
>          &nbs= p;            = ;       invalidCAUntrusted = (4),
>          &nbs= p;            = ;       invalidCmOther (5),
>          &nbs= p;            = ;       invalidCAOther (6)
>          &nbs= p;            = ;       }
>      Any special = reason to start ENUMERATION with zero ??
> -       = docsBpi2CmtsTEKSAType    OBJECT-TYPE
>          &nbs= p; SYNTAX         INTEGER = {
>          &nbs= p;            = ;            = none(0),
>          &nbs= p;            = ;            = primary(1),
>          &nbs= p;            = ;            = static(2),
>          &nbs= p;            = ;            = dynamic(3)
>          &nbs= p;            = ;            = }
>      Any special = reason to start ENUMERATION with zero ??
  = -> to be addressed in docsis team

>      There are more of those... I = won;t list them anymore,
>      I guess you get = the gist.

> - I wonder if it would not be better to have 2 = compliance
>   statements, one for CM and one for = CMTS.
>   It is unclear to me if any GROUPS = are mandatory. I think
>   some are, but it depends if your = are CM or CMTS
  = -> to be addressed in docsis team

> -       -- relaxation on IP = addressing
>       = OBJECT    docsBpi2CmIpMulticastAddressType
>          &nbs= p;   -- SYNTAX InetAddressType { ipv4(1) }
>    Pls make it a real SYNTAX = clause and not a comment.
>    That SMICng barks at it is = something we know and SMICng
>    should be = fixed.
  = -> fixed.


> - You have citations in DESCRIPTION clauses. We normally do = not
>   do that, cause they will be lost = when people extract the
>   MIB module from the = RFC.
 -> = ok. fixed.

> - Mmm.. you start off with some OBSOLETED object group = right
>   away he? You might want to say = something about when/why that
>   happened.
> - References need to be split in normative and = informative
 -> = ok. fixed.

> - You have picked up the new MIB boilerplate, but you = still
>   have a lot of old MIB boilerplate = references included, which
>   make no sense = anymore
 -> = ok. cleaned as much as possible.

> - The new MIB boilerplate has [RFC2578], [RFC2579] and = [RFC2580]
>   as citations, but they do not show = as such in the references
>   section
 -> = ok. fixed.

> - The security considerations section is not compliant with = the
>   new MIB security guidelines. The = subscriber MIB has
>   done a much better job. You should = too.
 -> = ok, beefed up the security consideration section.


> - I see 3 names in CONTACT-INFO while only two are = listed
>   on front page and only two are = listed in Author's addresses?
 -> = The 2 co-authors of draft 08 agree to add Kaz Ozawa as
    part of the author list.
    Contact info for Kaz corrected.

Minor = additional nits:
 - = Enforced (mostly) the 72 character column limit in Word, and = fixing
   the wrapped text (many many changes).
 - = Removed some non-ASCII text, especially "special" quotation = marks
 - = Removed IMPORT of Gauge32, since it is not used
 - = Removed the REFERENCE clauses from the OBJECT compliance
   statements, since they are not permitted per the = following syntax
   from page 6 of RFC 2580.


------_=_NextPart_001_01C34CA3.3B498FEB-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Jul 18 15:43:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11198 for ; Fri, 18 Jul 2003 15:43:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19db89-0002cM-Jo for ipcdn-archive@odin.ietf.org; Fri, 18 Jul 2003 15:43:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6IJh1IG010055 for ipcdn-archive@odin.ietf.org; Fri, 18 Jul 2003 15:43:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19db89-0002bu-1h; Fri, 18 Jul 2003 15:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19db7T-0002Yw-7V for ipcdn@optimus.ietf.org; Fri, 18 Jul 2003 15:42:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11138 for ; Fri, 18 Jul 2003 15:42:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19db7M-00032F-00 for ipcdn@ietf.org; Fri, 18 Jul 2003 15:42:12 -0400 Received: from coral.tci.com ([198.178.8.81] helo=dapsang.tci.com) by ietf-mx with esmtp (Exim 4.12) id 19db7B-00031X-00 for ipcdn@ietf.org; Fri, 18 Jul 2003 15:42:02 -0400 Received: from entexchimc04.broadband.att.com (localhost [127.0.0.1]) by dapsang.tci.com (8.12.9/8.12.9) with ESMTP id h6IJd104018420; Fri, 18 Jul 2003 13:39:02 -0600 (MDT) Received: by entexchimc04.broadband.att.com with Internet Mail Service (5.5.2653.19) id <304TZ7TX>; Fri, 18 Jul 2003 13:39:02 -0600 Message-ID: <6732623D2548D61193C90002A5C88DCC05663D30@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Cc: "'Jean-Francois Mule'" , "Woundy, Richard" Subject: RE: [ipcdn] IPCDN meeting minutes from IETF 57 in Vienna Date: Fri, 18 Jul 2003 13:38:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , >Below are the meeting minutes for review & comment. >Please send comments within 1 week, thanks. I have also posted the minutes on the website at . -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 21 18:58:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14392 for ; Mon, 21 Jul 2003 18:58:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ejbW-00028E-TM for ipcdn-archive@odin.ietf.org; Mon, 21 Jul 2003 18:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6LMw20H008190 for ipcdn-archive@odin.ietf.org; Mon, 21 Jul 2003 18:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ejbV-00027s-6M; Mon, 21 Jul 2003 18:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ejat-00027R-Iw for ipcdn@optimus.ietf.org; Mon, 21 Jul 2003 18:57:23 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14361 for ; Mon, 21 Jul 2003 18:57:16 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6LMtwP05584 for ; Mon, 21 Jul 2003 17:55:58 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jul 2003 00:55:45 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15502017ED9@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Jean-Francois Mule , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: stu.green@arrisi.com, Alexander Katsnelson , k.ozawa@cablelabs.com Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Tue, 22 Jul 2003 00:55:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Inline, deleted those things that we now agree on. > -----Original Message----- > From: Jean-Francois Mule [mailto:jf.mule@cablelabs.com] > Sent: donderdag 17 juli 2003 22:37 > To: Wijnen, Bert (Bert); Ipcdn (E-mail) > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com > Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 > > > Bert & all, > Below are the details on what comments got addresed in > draft-ietf-ipcdn-bpiplus-mib-10 based on your review. > Jean-Francois. > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Thursday, February 13, 2003 8:13 AM > > To: Ipcdn (E-mail) > > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com > > Subject: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt > > > > > > Here are my comments: > > > > - I had asked in in earlier email: > > Mmm.. did I review rev 07. I can't quickly find that I > > did send a review report. > > I am assuming that you will take care of all the comments > > that are (in my view) to be expected based on the review > > of the subscriber mib I did, right? > -> yes. will review and double check draft10. Did you do so now? > > - Is this MIB obsoleteing an earlier (RFC) version? > -> no. BPI mib and BPI plus coexist together. OK > > If this is the first time this MIB gets publsihed as an > > RFC, then we want to see only one simple revisions clause > > with a DESCRIPTION aka: > > "Initial version, published as RFC xxxx." > > -- RFC-editor assigns xxxx > -> fixed. > > We do not want to see long lists of changes that happened > > during initial revisions of Internet Drafts > -> ok. Left all the revisions in there for now with > comments to be deleted when doing final rfc editing. > Did not get removed in draft10 > yet, will be done later. OK, that will work > > - And how did you decide to assign the > > docsBpi2MIB MODULE-IDENTITY > > ... > > ::= { docsIfMib 6 } > > I worry a lot about this practice, cause it is very difficult > > to keep track and to ensure that no conflicts arise. > -> fixed by replacing this by > ::= { mib-2 xx } -- xx to be assigned by IANA First, if you want to do mib-2 xx, then you must import mib-2 from SNMPv2-SMI. But... I see that RFc3083 is docsIfMib 6. And so if this is an extension to that MIB module, then it makes sense (probably) to put this new one under docsIfMib too. So my question was not that you cannot do so if it makes sense. My question was more: how do you make sure that no one else assigns the same number. If IPCDN WG keeps an eye on it, then that may be acceptable. It might be best to ask IANA to at least keep a registry. I currently see docsIfMib 1 - RFC2670 docsIfMib 2 - RFC2670 docsIfMib 3 - RFC2670 docsIfMib 5 - RFC3083 docsIfMib 6 - bpiplus and a few other ::= { docsIfMib XXX } -- to be assigned bu IANA C:\bwijnen\smicng\rfcs>grep docsIfMib *.mi2 rfc2670.mi2:docsIfMib MODULE-IDENTITY rfc2670.mi2:docsIfMibObjects OBJECT IDENTIFIER ::= { docsIfMib 1 } rfc2670.mi2:docsIfBaseObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 1 } rfc2670.mi2:docsIfCmObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 2 } rfc2670.mi2:docsIfCmtsObjects OBJECT IDENTIFIER ::= { docsIfMibObjects 3 } rfc2670.mi2:docsIfNotification OBJECT IDENTIFIER ::= { docsIfMib 2 } rfc2670.mi2:docsIfConformance OBJECT IDENTIFIER ::= { docsIfMib 3 } rfc2670.mi2:MODULE -- docsIfMib rfc3083.mi2: docsIfMib, docsIfCmServiceId, docsIfCmtsServiceId rfc3083.mi2: ::= { docsIfMib 5 } In fact, looking at this, it seems a weird structure of the OID tree. So you better decide what you want or how to clean it up if that is what you want. Maybe we discussed this 5 months ago and I forgot. Maybe it is indeed best to put this one under mib-2 > > > - docsBpi2CmAuthReset OBJECT-TYPE > > Would it be wise to add a docsBpi2CmAuthLastReset object > > similar as what was done in the subscriber MIB module? > -> per our interim meeting in Feb'03, the new last reset object > will not > be added because this reset is really only for testing purposes. > Changed docsBpi2CmAuthReset description has been updated to add > This object is for testing purposes only and therefore it > does not require to be associated with a last reset object." > OK > > > - objects like: > > docsBpi2CmAuthRejects OBJECT-TYPE > > SYNTAX Counter32 > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "The value of this object is the count of > times the CM > > has received an Authorization Reject message, > > since reboot." > > require that a Counter starts at zero. But those are NOT the > > semanticws of a Counter32. If this is what you want, I think you > > need to use the ZeroBasedCounter32 as per RFC2021. > > Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6 > > specifically 4.6.1.2 > > You have quite a few of those objetcs > -> ok. > For each Counter32 object that require a start at zero, we > will change syntax from Counter32 to ZeroBasedCounter32. > Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB. OK. This also means that you must make RFC2021 a normative reference > > - docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE > > SYNTAX INTEGER { > > none(0), > > des56CbcMode(1), > > des40CbcMode(2) > > } > > We recommend to start Enumerations from 1. > > Possibly the 1 and 2 for the desXxxx enumerations are so > > numbered > > to align with some other place. If so, then starting with zero > > seems acceptable. But pls add some explanantion in that case > -> ok. fixed. > Table 4-22 of bpiplus spec defines the Data Encryption > Algorithm Identifiers and values are: > 0 Reserved > 1 CBC-Mode, 56-bit DES > 2 CBC-Mode, 40-bit DES > 3-255 Reserved > so it is proposed to leave object def as-is and add the following > justification text: > "Values 'des56CbcMode' and 'des40CbcMode' are defined in the > interface specification as integer values (1) and (2)." > OK. > > > Same question for simial xxxCrypto object > -> ok. fixed. > > - docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE > > SYNTAX INTEGER { > > none(0) > > } > > An object that can only have one value that is ALWAYS zero? > > What is the use of that? Maybe future extensibility, but if so, > > then please say so in DESCRIPTION clause, otherwise this > > seems nonsense and bloat. > -> ok. fixed. Added "This object is defined for future > extensibility." I still find it weird.. but ?? > > - docsBpi2CmIpMulticastAddress OBJECT-TYPE > > SYNTAX InetAddress > > MAX-ACCESS read-only > > STATUS current > > DESCRIPTION > > "This object represents the IP multicast address > > to be mapped." > > you MUST specify with InetAddressType object defines the context > > or type of this object. You did it correct in subscriber mib. > -> fixed. I still do not see that this is reflected in the InetAddress objects, do I? Fo example: docsBpi2CmIpMulticastAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the IP multicast address to be mapped." Should say something aka: docsBpi2CmIpMulticastAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-only STATUS current DESCRIPTION "This object represents the IP multicast address to be mapped. The type of this address is determined by the value of the docsBpi2CmIpMulticastAddressType object." In your compliance section I see: -- relaxation on IP addressing OBJECT docsBpi2CmIpMulticastAddressType -- SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." First, I do not think it is a "relaxation", but rather a "restriction"? But that is nit picking. More important, the SYNTAX should not be a comment! I know that SMICng complains about it, but that is a bug in SMICng. You have multiple of those > > > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE > > SYNTAX INTEGER { > > bpi (0), > > bpiPlus (1) > > } > > Any special reason why enumeration cannot start at 1? > to be discussed in docsis team. Still discission needed? You better decide soon > > - docsBpi2CmtsAuthCmReset OBJECT-TYPE > > Yet another way in which you guys do resets. ?? no answer? > > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > > SYNTAX INTEGER { > > unknown (0), > > validCmChained (1), > > validCmTrusted (2), > > invalidCmUntrusted (3), > > invalidCAUntrusted (4), > > invalidCmOther (5), > > invalidCAOther (6) > > } > > Any special reason to start ENUMERATION with zero ?? > > - docsBpi2CmtsTEKSAType OBJECT-TYPE > > SYNTAX INTEGER { > > none(0), > > primary(1), > > static(2), > > dynamic(3) > > } > > Any special reason to start ENUMERATION with zero ?? > -> to be addressed in docsis team When?? > > There are more of those... I won;t list them anymore, > > I guess you get the gist. > > - I wonder if it would not be better to have 2 compliance > > statements, one for CM and one for CMTS. > > It is unclear to me if any GROUPS are mandatory. I think > > some are, but it depends if your are CM or CMTS > -> to be addressed in docsis team When ? > > - -- relaxation on IP addressing > > OBJECT docsBpi2CmIpMulticastAddressType > > -- SYNTAX InetAddressType { ipv4(1) } > > Pls make it a real SYNTAX clause and not a comment. > > That SMICng barks at it is something we know and SMICng > > should be fixed. > -> fixed. > Mmm... I still see them !! > > - The security considerations section is not compliant with the > > new MIB security guidelines. The subscriber MIB has > > done a much better job. You should too. > -> ok, beefed up the security consideration section. > I wonder if Security ADs want to see something about all that key information that you have in the MIB. You may want to check with them early on... so that they can give you early advise. Like Keylengths and such? > Minor additional nits: > - Enforced (mostly) the 72 character column limit in Word, > and fixing the wrapped text (many many changes). > - Removed some non-ASCII text, especially "special" quotation marks I still get: $ /bin/checkpage.awk < draft-ietf-ipcdn-bpiplus-mib-10.txt Bad chars at 77 Bad chars at 3758 Bad chars at 3950 -: 3 lines containing non-US-ASCII characters -: 73 formfeeds not on a line by themselves > - Removed IMPORT of Gauge32, since it is not used > - Removed the REFERENCE clauses from the OBJECT compliance > statements, since they are not permitted per the following syntax > from page 6 of RFC 2580. > I also still see refernce to RFC2571/4/5/ which have been obsoleted by RFC3411/4/5 You have norm ref to RFC2819.. you probably mean RFC2021 (RMON2-MIB). Further, SMICng tells me: W: f(ipcdnbpiplus.mi2), (3242,8) OBJECT-GROUP "docsBpi2ObsoleteObjectsGroup" is not used in a MODULE-COMPLIANCE in current module It is best to list it as optional in the MODULE-COMPLIANCE. See bottom of page 23 of draft-ietf-ops-mib-review-guidelines-01.txt Further I see in your meeting mnutes: o draft-ietf-ipcdn-bpiplus-mib-10.txt pending resolution of 2 open issues (see action items below), the bpi+ ID is ready for WGLC. Expected ID update by end of August/early September'03 and launch of WGLC shortly after. If you do WG LC in first half of Sept, then there is no way that this doc will make it to RFC by end-october! _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 22 13:32:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20345 for ; Tue, 22 Jul 2003 13:32:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0za-0008G8-L4 for ipcdn-archive@odin.ietf.org; Tue, 22 Jul 2003 13:32:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MHW2d5031744 for ipcdn-archive@odin.ietf.org; Tue, 22 Jul 2003 13:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0zZ-0008Fp-Nw; Tue, 22 Jul 2003 13:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0zR-0008Fb-CZ for ipcdn@optimus.ietf.org; Tue, 22 Jul 2003 13:31:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20318 for ; Tue, 22 Jul 2003 13:31:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0zP-000685-00 for ipcdn@ietf.org; Tue, 22 Jul 2003 13:31:51 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19f0zC-00067p-00 for ipcdn@ietf.org; Tue, 22 Jul 2003 13:31:38 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6MHUNdS006444; Tue, 22 Jul 2003 11:30:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35076.EDA9D606" Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Tue, 22 Jul 2003 11:30:22 -0600 Message-ID: Thread-Topic: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Thread-Index: AcLTcy1oUzrP+TZJSta0Z6wy3lxNNR5L6VIwAMpNuBA= From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35076.EDA9D606 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jean Francois,=20 =20 Thanks for the sumarized details of actions,=20 =20 Here are comments and proposals for the open questions. for the MIB authors and ipcdn group consideration. =20 feel free to make comments and suggestions. =20 Eduardo > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > bpi (0),=20 > bpiPlus (1)=20 > }=20 > Any special reason why enumeration cannot start at 1?=20 to be discussed in docsis team.=20 docsBpi2CmtsAuthTable is a CMTS table that list the CM Authorization Association with respect to BPI+ - RFC 3083 have a similar table docsBpiCmtsAuthTable docsBpi2CmtsAuthCmBpiVersion was added in Bpi2 mib and is not present in Bpi mib, It reflects a new BPI+ parameters in the BPKM ( code 22) BPI-Version: BPI (RFC 3083) covers {0, 17-126} reserved, {127,128-255} vendor, {1-16} BPI defined BPI+ (bpiplus draft) covers {0, 28-126} reserved, {127,128-255} vendor, {1-27} BPI defined the new bpi defined parameters by bpiplus 17-27) includes : Code 22 BPI-Version in 4.2.2.22 BPI-Version of SP-BPI+-I09-020830 defined values are : 0, Reserved 1 BPI+=20 2-255 Reserved The mib assigns 0 to bpi , 1 to bpiplus and reserved numbers 2-255 for future protocols denominations =20 ---Suggested Text =20 docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 SYNTAX INTEGER {=20 bpi (0),=20 bpiPlus (1)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the version of Baseline=20 Privacy for which this CM has registered. The Value=20 'bpiplus' represents the value of BPI-Version Attribute of=20 the Baseline Privacy Key Management BPKM attribute=20 BPI-Version (1). Value 'bpi' is used to represent the CM=20 registerered using DOCSIS 1.0 Baseline Privacy." REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.22"=20 =20 ::=3D { docsBpi2CmtsAuthEntry 2 }=20 -------------------------------------- > Any special reason to start ENUMERATION with zero ??=20 > - docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > primary(1),=20 > static(2),=20 > dynamic(3)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 -> to be addressed in docsis team=20 > There are more of those... I won;t list them anymore,=20 > I guess you get the gist.=20 docsBpi2CmTEKDataEncryptAlg docsBpi2CmTEKDataAuthentAlg=20 Already fixed since draft 9 I believe the mib author decided to align the structure of enumerations for the objects in the table docsBpi2CmTEKTable=20 docsBpi2CmTEKSAType=20 docsBpi2CmTEKDataEncryptAlg docsBpi2CmTEKDataAuthentAlg=20 the BPKM Attribute 24 SA-Type does start in zero, but the defined enumeration in the mib does not follow exactly those values. =20 docsBpi2CmTEKSAType : none(0) primary(1) static(2) dynamic(3) BPKM attribute 24 SA-Type: 0 primary, 1 static, 2 Dynamic. 3-127 Reserved, 128-255 Vendor-Specific (***) -- Ideal MIB enumeration primary(0), static(1), Dynamic(2)=20 docsBpi2CmTEKDataEncryptAlg: none(0) des56CbcMode(1) des40CbcMode(2) BPKM Attribute 20 Cryptographic-suite:=20 Data Authentication Algorithm Identifiers 0 Reserved, 1 CBC-Mode, 2 CBC-Mode, 3-255 Reserved docsBpi2CmTEKDataAuthentAlg: none(0) BPKM Attribute 20 Cryptographic-suite:=20 Data Authentic ation Algorithm Identifiers 0 No Data Authentication, 1-255 Reserved A truly consistent enumeration for docsBpi2CmTEKSAType against the protocol would be primary(0), static(1), Dynamic(2), none(3) At the level protocol no 'none' attribute is send on the wire,=20 it means BPKM messages are have not yet sent to determine the SA type docsBpi2CmTEKSAType OBJECT-TYPE=20 .............. DESCRIPTION=20 "The value of this object is the type of security=20 association. The none(0) encoding must only be used=20 if the SA type has yet to be determined."=20 In conclusion the enumeration 0 would be valid to match the protocol requirements (see ***) ( known value from the BPKM protocol) , but the change in the enumeration is desirable to happen to have the same enumeration structure in docsBpi2CmTEKTable as well as keeping the definition compatible with the broad number of devices in the field. Proposed text (updated reference) docsBpi2CmTEKSAType OBJECT-TYPE=20 SYNTAX INTEGER {=20 none(0),=20 primary(1),=20 static(2),=20 dynamic(3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. The none(0) encoding must only be used=20 if the SA type has yet to be determined. Values=20 'primary', 'static' and 'dynamic are defined in the=20 SA-Type Attribute of the Baseline Privacy Key=20 Management BPKM as (0), (1), (2) respectively."=20 REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.24"=20 ::=3D { docsBpi2CmTEKEntry 2 }=20 -------------------------------------------- > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > unknown (0),=20 > validCmChained (1),=20 > validCmTrusted (2),=20 > invalidCmUntrusted (3),=20 > invalidCAUntrusted (4),=20 > invalidCmOther (5),=20 > invalidCAOther (6)=20 > }=20 The docsBpi2CmtsAuthBpkmCmCertValid value is assigned by the CMTS to indicate validity of the CM certificates path or chain provisioned or aquired via BPKM. =20 The same rationale as in some BPI mibs like docsBpi2CmtsAuthCmBpiVersion enumeration 0, 'unknown' value is used to represent the case when the CM is running in bpi not bpiplus NOt a straigth match but the BPKM attibutes in bpiplus intentionaly reserves the value zero and in bpi mode no bpiplus attibutes are not sent in the wire. so believe the mib is using the enmeration 0 to reflect the bpi mode of operation without conflicting with the bpiplis attributes values (almost all time SA-Type still has to me dark areas) =20 =20 =20 The DESCRIPTION also mention the reason of 'unknown' value for (bpi) where certificates are not used,=20 That allows to use in the future other enumerations above 6 for detailed CM Certificates validity status.=20 =20 =20 docsBpi2CmtsAuthBpkmCmCertValid=20 .... I do not see any Protocol codes association (in BPI+ 9.4.1 CMTS Certificate Management Model) replied to the CM that matches any Certificate validation. BPI experts may provide a more clean explanation. =20 Therefore I do not think a mib change is needed if for IETF Mib Doctors using enumeration 0 is valid for bpiplus mibs reporting devices in bpi mode.=20 Any suggestions to make that more clear?=20 =20 > - I wonder if it would not be better to have 2 compliance=20 > statements, one for CM and one for CMTS.=20 > It is unclear to me if any GROUPS are mandatory. I think=20 > some are, but it depends if your are CM or CMTS=20 -> to be addressed in docsis team=20 =20 There is not unconditionally groups (e.e base group applying both CM and CMTSes) The tree groups are =20 =20 docsBpi2CmtsGroup CMTS only docsBpi2CmGroup CM only docsBpi2CodeDownloadGroup CM and optional CMTS =20 Maybe a way to indicates the MANDATORY requirements would be: =20 Proposed changes: replace 'implemented' with required =20 -- conditionally mandatory group=20 GROUP docsBpi2CmGroup=20 DESCRIPTION=20 "This group is required only in CMs, not in CMTSs."=20 =20 -- conditionally mandatory group=20 GROUP docsBpi2CmtsGroup=20 DESCRIPTION=20 "This group is required only in CMTSs, not in CMs."=20 =20 -- conditionally mandatory group=20 GROUP docsBpi2CodeDownloadGroup=20 DESCRIPTION=20 "This group is required in CMs and is optional in CMTSs."=20 =20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Thursday, July 17, 2003 2:37 PM To: Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 =09 =09 Bert & all,=20 Below are the details on what comments got addresed in draft-ietf-ipcdn-bpiplus-mib-10 based on your review.=20 Jean-Francois.=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com ]=20 > Sent: Thursday, February 13, 2003 8:13 AM=20 > To: Ipcdn (E-mail)=20 > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com=20 > Subject: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt=20 >=20 >=20 > Here are my comments:=20 >=20 > - references/citations in abstract are not allowed per=20 > RFC-Editor policy=20 -> deleted refs.=20 > - 2nd para in abstract seems not needed. but I can live=20 > with it=20 -> deleted.=20 > - Tiltle of sect 1 is not inline with MIB boilerplate=20 -> fixed.=20 > - 3rd para in section 1 is not needed, in fact I'd rather=20 > see it removed. The RFC3410 explains all that.=20 -> fixed.=20 > - DESCRIPTION clause of MODULE-IDENTITY is missing the=20 > MIB copyright statement=20 -> added the following text:=20 Copyright (C) The Internet Society (2003). This version=20 of this MIB module is part of RFC xxx; see the RFC itself for full legal notices."=20 > - I had asked in in earlier email:=20 > Mmm.. did I review rev 07. I can't quickly find that I=20 > did send a review report.=20 > I am assuming that you will take care of all the comments=20 > that are (in my view) to be expected based on the review=20 > of the subscriber mib I did, right?=20 -> yes. will review and double check draft10.=20 > - Is this MIB obsoleteing an earlier (RFC) version?=20 -> no. BPI mib and BPI plus coexist together.=20 > If this is the first time this MIB gets publsihed as an=20 > RFC, then we want to see only one simple revisions clause=20 > with a DESCRIPTION aka:=20 > "Initial version, published as RFC xxxx."=20 > -- RFC-editor assigns xxxx=20 -> fixed.=20 > We do not want to see long lists of changes that happened=20 > during initial revisions of Internet Drafts=20 -> ok. Left all the revisions in there for now with comments to be=20 deleted when doing final rfc editing. Did not get removed in draft10=20 yet, will be done later.=20 > - And how did you decide to assign the=20 > docsBpi2MIB MODULE-IDENTITY=20 > ...=20 > ::=3D { docsIfMib 6 }=20 > I worry a lot about this practice, cause it is very difficult=20 > to keep track and to ensure that no conflicts arise.=20 -> fixed by replacing this by=20 ::=3D { mib-2 xx } -- xx to be assigned by IANA=20 > - I worry about:=20 > X509Certificate ::=3D TEXTUAL-CONVENTION=20 > STATUS current=20 > DESCRIPTION=20 > "An X509 digital certificate encoded as an ASN.1 DER=20 > object."=20 > SYNTAX OCTET STRING (SIZE (0..1400))=20 > The reason is that this is not some X509 generic Certificate=20 > but a special one for your IPCDN use.=20 > How about renaming it to DocsX509ASN1DEREncodedCertificate ??=20 -> good point. Changed to the suggested TC name everywhere.=20 > - docsBpi2CmAuthReset OBJECT-TYPE=20 > Would it be wise to add a docsBpi2CmAuthLastReset object=20 > similar as what was done in the subscriber MIB module?=20 -> per our interim meeting in Feb'03, the new last reset object=20 will not=20 be added because this reset is really only for testing purposes.=20 Changed docsBpi2CmAuthReset description has been updated to add=20 This object is for testing purposes only and therefore it=20 does not require to be associated with a last reset object."=20 > - objects like:=20 > docsBpi2CmAuthRejects OBJECT-TYPE=20 > SYNTAX Counter32=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the count of times the CM=20 > has received an Authorization Reject message,=20 > since reboot."=20 > require that a Counter starts at zero. But those are NOT the > semanticws of a Counter32. If this is what you want, I think you=20 > need to use the ZeroBasedCounter32 as per RFC2021.=20 > Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6=20 > specifically 4.6.1.2=20 > You have quite a few of those objetcs=20 -> ok.=20 For each Counter32 object that require a start at zero, we=20 will change syntax from Counter32 to ZeroBasedCounter32.=20 Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB.=20 > - docsBpi2CmAuthRejectErrorString OBJECT-TYPE=20 > SYNTAX SnmpAdminString (SIZE (0..128))=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the Display-String in=20 > S/Display-String/text string/ ??=20 > Same for docsBpi2CmAuthInvalidErrorString=20 > And for docsBpi2CmTEKKeyRejectErrorString=20 > docsBpi2CmTEKInvalidErrorString=20 > docsBpi2CmIpMulticastSAMapRejectErrorString=20 > docsBpi2CmtsAuthInvalidErrorString=20 -> done - replaced all 'Display-String' in description clauses by 'text=20 string'=20 > - docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > des56CbcMode(1),=20 > des40CbcMode(2)=20 > }=20 > We recommend to start Enumerations from 1.=20 > Possibly the 1 and 2 for the desXxxx enumerations are so numbered=20 > to align with some other place. If so, then starting with zero=20 > seems acceptable. But pls add some explanantion in that case=20 -> ok. fixed.=20 Table 4-22 of bpiplus spec defines the Data Encryption=20 Algorithm Identifiers and values are:=20 0 Reserved=20 1 CBC-Mode, 56-bit DES=20 2 CBC-Mode, 40-bit DES=20 3-255 Reserved=20 so it is proposed to leave object def as-is and add the following=20 justification text:=20 "Values 'des56CbcMode' and 'des40CbcMode' are defined in the=20 interface specification as integer values (1) and (2)."=20 > Same question for simial xxxCrypto object=20 -> ok. fixed.=20 > - docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0)=20 > }=20 > An object that can only have one value that is ALWAYS zero? > What is the use of that? Maybe future extensibility, but if so,=20 > then please say so in DESCRIPTION clause, otherwise this=20 > seems nonsense and bloat.=20 -> ok. fixed. Added "This object is defined for future=20 extensibility."=20 > Same question for simial xxxCrypto object=20 -> ok. fixed. same as above.=20 > - docsBpi2CmIpMulticastIndex OBJECT-TYPE=20 > SYNTAX Integer32 (1..1000)=20 > It is valid. But for INDEX objects we prefer Unsigned32 with=20 > a range. see again the mib review guidelines doc=20 > I think this occurs a few more time in this MIB module.=20 > As I say, it is valid, but since your still working on this > MIB module, might as well use the recommended method.=20 -> certainly. fixed all integer32 INDEX objects syntax to Unsigned32.=20 This includes the following objects:=20 docsBpi2CmTEKSAId=20 docsBpi2CmIpMulticastIndex=20 docsBpi2CmCryptoSuiteIndex=20 docsBpi2CmtsTEKSAId=20 docsBpi2CmtsIpMulticastIndex=20 docsBpi2CmtsMulticastAuthSAId=20 docsBpi2CmtsCACertIndex=20 > - docsBpi2CmIpMulticastAddress OBJECT-TYPE=20 > SYNTAX InetAddress=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "This object represents the IP multicast address=20 > to be mapped."=20 > you MUST specify with InetAddressType object defines the context=20 > or type of this object. You did it correct in subscriber mib.=20 -> fixed.=20 > - docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > trusted (1),=20 > untrusted (2)=20 > }=20 > Seems to me that docsBpi2CmtsDefaultSelfSignedManufCertTrusted=20 > descriptor with a syntax of TruthValue is more appropriate=20 > - docsBpi2CmtsCheckCertValidityPeriods OBJECT-TYPE=20 > SYNTAX TruthValue=20 > MAX-ACCESS read-write=20 > STATUS current=20 > DESCRIPTION=20 > "Setting this object to TRUE causes all chained and=20 > The better wording is:=20 > "Setting this object to 'true' causes all chained and -> ^^^^^ fixed.=20 > This occurs a few more times in this MIB module=20 -> fixed all of them.=20 > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > bpi (0),=20 > bpiPlus (1)=20 > }=20 > Any special reason why enumeration cannot start at 1?=20 to be discussed in docsis team.=20 > - docsBpi2CmtsAuthCmReset OBJECT-TYPE=20 > Yet another way in which you guys do resets.=20 > - docsBpi2CmtsAuthCmInfos OBJECT-TYPE=20 > SYNTAX Counter32=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the count of times the=20 > CMTS has received an Authentication Information=20 > message from=20 > this CM, since entry creatiion."=20 > ZeroBasedCounter32 ??=20 -> yes, fixed.=20 > You have several of those=20 -> yes fixed.=20 > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > unknown (0),=20 > validCmChained (1),=20 > validCmTrusted (2),=20 > invalidCmUntrusted (3),=20 > invalidCAUntrusted (4),=20 > invalidCmOther (5),=20 > invalidCAOther (6)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 > - docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > primary(1),=20 > static(2),=20 > dynamic(3)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 -> to be addressed in docsis team=20 > There are more of those... I won;t list them anymore,=20 > I guess you get the gist.=20 > - I wonder if it would not be better to have 2 compliance=20 > statements, one for CM and one for CMTS.=20 > It is unclear to me if any GROUPS are mandatory. I think=20 > some are, but it depends if your are CM or CMTS=20 -> to be addressed in docsis team=20 > - -- relaxation on IP addressing=20 > OBJECT docsBpi2CmIpMulticastAddressType=20 > -- SYNTAX InetAddressType { ipv4(1) }=20 > Pls make it a real SYNTAX clause and not a comment.=20 > That SMICng barks at it is something we know and SMICng=20 > should be fixed.=20 -> fixed.=20 > - You have citations in DESCRIPTION clauses. We normally do not=20 > do that, cause they will be lost when people extract the=20 > MIB module from the RFC.=20 -> ok. fixed.=20 > - Mmm.. you start off with some OBSOLETED object group right=20 > away he? You might want to say something about when/why that > happened.=20 > - References need to be split in normative and informative=20 -> ok. fixed.=20 > - You have picked up the new MIB boilerplate, but you still=20 > have a lot of old MIB boilerplate references included, which > make no sense anymore=20 -> ok. cleaned as much as possible.=20 > - The new MIB boilerplate has [RFC2578], [RFC2579] and [RFC2580]=20 > as citations, but they do not show as such in the references > section=20 -> ok. fixed.=20 > - The security considerations section is not compliant with the=20 > new MIB security guidelines. The subscriber MIB has=20 > done a much better job. You should too.=20 -> ok, beefed up the security consideration section.=20 > - I see 3 names in CONTACT-INFO while only two are listed=20 > on front page and only two are listed in Author's addresses? -> The 2 co-authors of draft 08 agree to add Kaz Ozawa as=20 part of the author list.=20 Contact info for Kaz corrected.=20 Minor additional nits:=20 - Enforced (mostly) the 72 character column limit in Word, and fixing=20 the wrapped text (many many changes).=20 - Removed some non-ASCII text, especially "special" quotation marks=20 - Removed IMPORT of Gauge32, since it is not used=20 - Removed the REFERENCE clauses from the OBJECT compliance=20 statements, since they are not permitted per the following syntax=20 from page 6 of RFC 2580.=20 ------_=_NextPart_001_01C35076.EDA9D606 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Jean=20 Francois,
 
Thanks=20 for the sumarized details of actions,
 
Here=20 are comments and proposals for the open questions. for the MIB authors = and ipcdn=20 group consideration.
 
feel=20 free to make comments and suggestions.
 
Eduardo

>=20 -     docsBpi2CmtsAuthCmBpiVersion =20 OBJECT-TYPE
>         = ;  =20 SYNTAX         INTEGER = {=20
>         = ;            =    =20 bpi (0),
>         = ;            =    =20 bpiPlus (1)
>         = ;            =          =20 }
>    Any special reason why = enumeration cannot=20 start at 1?
      to be discussed in = docsis=20 team.

docsBpi2CmtsAuthTable is a CMTS table that list the CM = Authorization=20 Association with respect to BPI+

- RFC 3083=20 have a similar table docsBpiCmtsAuthTable

docsBpi2CmtsAuthCmBpiVersion was added in Bpi2 mib and is not = present in=20 Bpi mib, It reflects a new BPI+ parameters in the BPKM ( code=20 22) BPI-Version:

BPI (RFC 3083)=20 covers {0, 17-126} reserved, {127,128-255} vendor, {1-16} BPI=20 defined

BPI+ (bpiplus draft) covers {0, 28-126} = reserved,=20 {127,128-255} vendor, {1-27} BPI defined

the new bpi=20 defined parameters by bpiplus 17-27) includes :

Code 22=20 BPI-Version in 4.2.2.22 BPI-Version of SP-BPI+-I09-020830 defined = values=20 are :

0, Reserved

1 BPI+=20

2-255=20 Reserved

The mib=20 assigns 0 to bpi , 1 to bpiplus and reserved numbers 2-255 for future = protocols=20 denominations

 

---Suggested=20 Text

 

        = docsBpi2CmtsAuthCmBpiVersion =20 OBJECT-TYPE=20
           =20 SYNTAX         INTEGER {=20
           &nb= sp;           &nbs= p;=20 bpi (0),=20
           &nb= sp;           &nbs= p;=20 bpiPlus (1)=20
           &nb= sp;           &nbs= p;    =20 }
            = MAX-ACCESS     read-only=20
           =20 STATUS        =20 current 
          &nbs= p;=20 DESCRIPTION=20
           &nb= sp;    =20 "The value of this object is the version of Baseline=20
           &nb= sp;    =20 Privacy for which this CM has registered. The Value=20
           &nb= sp;    =20 'bpiplus' represents the value of BPI-Version Attribute of=20
           &nb= sp;    =20 the Baseline Privacy Key Management BPKM attribute=20
           &nb= sp;    =20 BPI-Version (1). Value 'bpi' is used to represent the CM=20
           &nb= sp;    =20 registerered using DOCSIS 1.0 Baseline=20 Privacy."
          =   =20 REFERENCE=20
           &nb= sp;    =20 "DOCSIS Baseline Privacy Plus Interface Specification,=20
           &nb= sp;    =20 Section 4.2.2.22"=20
 
          = ; =20 ::=3D { docsBpi2CmtsAuthEntry 2 }

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

>      = Any special=20 reason to start ENUMERATION with zero ??
> = -      =20 docsBpi2CmtsTEKSAType    OBJECT-TYPE =
>         = ;  =20 SYNTAX         INTEGER = {=20
>         = ;            =             &= nbsp;=20 none(0),
>         = ;            =             &= nbsp;=20 primary(1),
>         = ;            =             &= nbsp;=20 static(2),
>         = ;            =             &= nbsp;=20 dynamic(3)
>         = ;            =             &= nbsp;=20 }
>      Any special reason to = start=20 ENUMERATION with zero ??
  = -> to be=20 addressed in docsis team

>      There are more of = those... I=20 won;t list them anymore,
>      I guess you get the=20 gist.

docsBpi2CmTEKDataEncryptAlg
docsBpi2CmTEKDataAuthentAlg

Already fixed=20 since draft 9

I = believe the mib=20 author decided to align the structure of enumerations for the objects in = the=20 table docsBpi2CmTEKTable=20

docsBpi2CmTEKSAType=20
docsBpi2CmTEKDataEncryptAlg
docsBpi2CmTEKDataAuthentAlg=20
the BPKM=20 Attribute 24 SA-Type does start in zero, but the defined enumeration in = the mib=20 does not follow exactly those=20 values.

 

docsBpi2CmTEKSAType :=20 none(0) primary(1) static(2) dynamic(3)
    BPKM = attribute=20 24
           &= nbsp;=20 SA-Type: 0 primary, 1 static, 2 Dynamic. 3-127 Reserved, 128-255=20 Vendor-Specific  (***)

          &nbs= p; =20 -- Ideal MIB enumeration primary(0), static(1), Dynamic(2)=20

docsBpi2CmTEKDataEncryptAlg: none(0) des56CbcMode(1)=20 des40CbcMode(2)
   BPKM Attribute = 20
Cryptographic-suite:=20
Data Authentication Algorithm=20 Identifiers
         &nbs= p;            = ;    =20 0 Reserved, 1 CBC-Mode, 2 CBC-Mode, 3-255 Reserved

docsBpi2CmTEKDataAuthentAlg: none(0)
   BPKM = Attribute=20 20
Cryptographic-suite:
Data Authentic ation Algorithm=20 Identifiers
         &nbs= p;            = ;     =20 0 No Data Authentication, 1-255 Reserved

A=20 truly consistent enumeration for docsBpi2CmTEKSAType against the protocol would=20 be primary(0), static(1), Dynamic(2),=20 none(3)

At the level protocol no 'none' attribute is = send on=20 the wire,

it means BPKM messages are have not = yet sent to=20 determine the SA type   

docsBpi2CmTEKSAType OBJECT-TYPE=20

   =20 ..............

      DESCRIPTION=20
           &nb= sp;    =20 "The value of this object is the type of security=20
           =20 association.  The none(0) encoding must only be used=20
            = if the SA=20 type has yet to be determined."

In conclusion the enumeration 0 would be = valid to match=20 the protocol requirements (see ***) ( known value from the BPKM = protocol) , but=20 the change in the enumeration is desirable to happen to have the same=20 enumeration structure in docsBpi2CmTEKTable as well as keeping the=20 definition compatible with the broad number of devices in the=20 field.

Proposed = text (updated=20 reference)

docsBpi2CmTEKSAType = OBJECT-TYPE=20
           =20 SYNTAX         INTEGER {=20
           &nb= sp;           &nbs= p;          =20 none(0),=20
           &nb= sp;           &nbs= p;          =20 primary(1),=20
           &nb= sp;           &nbs= p;          =20 static(2),=20
           &nb= sp;           &nbs= p;          =20 dynamic(3)=20
           &nb= sp;           &nbs= p;          =20 }
            = MAX-ACCESS     read-only=20
           =20 STATUS         current=20
           =20 DESCRIPTION=20
           &nb= sp;    =20 "The value of this object is the type of security=20
           &nb= sp;    =20 association.  The none(0) encoding must only be used=20
           &nb= sp;    =20 if the SA type has yet to be determined. Values=20
           &nb= sp;    =20 'primary', 'static' and 'dynamic are defined in the=20
           &nb= sp;    =20 SA-Type Attribute of the Baseline Privacy Key=20
           &nb= sp;    =20 Management BPKM as (0), (1), (2) respectively."=20
            = REFERENCE=20
           &nb= sp;    =20 "DOCSIS Baseline Privacy Plus Interface Specification,=20
           &nb= sp;    =20 Section 4.2.2.24"=20
            = ::=3D {=20 docsBpi2CmTEKEntry 2 }

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

>=20 -      =20 docsBpi2CmtsAuthBpkmCmCertValid       =  =20 OBJECT-TYPE
>         = ;  =20 SYNTAX    INTEGER {
>         = ;            =         =20 unknown (0),
>         = ;            =         =20 validCmChained (1),
>         = ;            =         =20 validCmTrusted (2),
>         = ;            =         =20 invalidCmUntrusted (3),
>         = ;            =         =20 invalidCAUntrusted (4),
>         = ;            =         =20 invalidCmOther (5),
>         = ;            =         =20 invalidCAOther (6)
>    <= FONT=20 face=3D"Courier New">         &nb= sp;      =20 }

The docsBpi2CmtsAuthBpkmCmCertValid = value is=20 assigned by the CMTS to indicate validity of the CM certificates = path or=20 chain provisioned or aquired via = BPKM.
 
The same rationale as in some BPI mibs like docsBpi2CmtsAuthCmBpiVersion =20 enumeration 0, 'unknown' value is used to represent the case when the CM = is=20 running in  bpi not bpiplus
NOt a straigth = match but=20 the BPKM attibutes in bpiplus intentionaly reserves the = value=20 zero and in bpi mode no bpiplus attibutes are not sent in the=20 wire. so believe  the mib is using the enmeration 0 to = reflect=20 the bpi mode of operation without conflicting with the bpiplis = attributes values=20 (almost all time SA-Type still has to me dark=20 areas)
 
 
 
The DESCRIPTION = also mention the reason of  'unknown' value for (bpi) where=20 certificates are not used, 
That allows to use in the = future other enumerations above 6 for detailed CM Certificates = validity=20 status. 
 
 
docsBpi2CmtsAuthBpkmCmCertValid=20
....
I do not see any Protocol = codes=20 association (in BPI+ 9.4.1 CMTS Certificate Management Model) replied to = the CM=20 that matches any Certificate validation. BPI experts may provide a more = clean=20 explanation.
 
Therefore I do not think = a mib change=20 is needed if for IETF Mib Doctors using enumeration 0 is valid for = bpiplus=20 mibs reporting devices in bpi mode.
Any suggestions to make that = more clear?=20
 

> - I=20 wonder if it would not be better to have 2 compliance =
>   statements, one for = CM and one=20 for CMTS.
>   It is unclear to me if any GROUPS are = mandatory.=20 I think
>  =20 some are, but it depends if your are CM or CMTS
  -> to be addressed in docsis team
 
There is not unconditionally groups (e.e base = group=20 applying both CM and CMTSes)
The tree groups are =20
 
docsBpi2CmtsGroup  CMTS=20 only
docsBpi2CmGroup    CM = only
docsBpi2CodeDownloadGroup=20 CM and optional CMTS
 
Maybe a way to indicates the MANDATORY = requirements=20 would be:
 
Proposed changes: replace 'implemented' with=20 required
 
   -- conditionally mandatory group =
       GROUP    =20 docsBpi2CmGroup=20
           =20 DESCRIPTION=20
            = "This=20 group is required only in CMs, not in CMTSs." =
    =20
       -- conditionally mandatory = group=20
       GROUP    =20 docsBpi2CmtsGroup=20
           =20 DESCRIPTION=20
            = "This=20 group is required only in CMTSs, not in CMs." =
    =20
       -- conditionally mandatory = group=20
       GROUP    =20 docsBpi2CodeDownloadGroup=20
           =20 DESCRIPTION=20
            = "This=20 group is required in CMs and is optional in=20 CMTSs." 

 

-----Original Message-----
From: = Jean-Francois=20 Mule
Sent: Thursday, July 17, 2003 2:37 PM
To: = Wijnen,=20 Bert (Bert); Ipcdn (E-mail)
Cc: stu.green@arrisi.com; = Alexander=20 Katsnelson; k.ozawa@cablelabs.com
Subject: [ipcdn] Changes = made in=20 draft-ietf-ipcdn-bpiplus-mib-10

Bert &=20 all,

Below are = the details on=20 what comments got addresed in draft-ietf-ipcdn-bpiplus-mib-10 based on = your=20 review.

Jean-Francois.
> -----Original=20 Message-----
> From: Wijnen, Bert (Bert) = [mailto:bwijnen@lucent.com] =
> = Sent: Thursday,=20 February 13, 2003 8:13 AM
> To: Ipcdn = (E-mail)=20
> Cc:=20 stu.green@arrisi.com; Alexander Katsnelson;=20 k.ozawa@cablelabs.com
> Subject: [ipcdn] = Review of:=20 draft-ietf-ipcdn-bpiplus-mib-08.txt
> =
>=20
>=20 Here are my comments:
> =
> = -=20 references/citations in abstract are not allowed per =
>  =20 RFC-Editor policy
  -> deleted refs.

> - 2nd=20 para in abstract seems not needed. but I can live =
>   with=20 it
 =20 ->   deleted.

> -=20 Tiltle of sect 1 is not inline with MIB boilerplate =
  = ->  =20 fixed.

> - 3rd=20 para in section 1 is not needed, in fact I'd rather =
>   see=20 it removed. The RFC3410 explains all that.
  = ->  =20 fixed.

> -=20 DESCRIPTION clause of MODULE-IDENTITY is missing the =
>   MIB=20 copyright statement
  ->   added the = following=20 text:
          &nbs= p;  =20 Copyright (C) The Internet Society (2003). This version=20
          &nbs= p;  =20 of this MIB module is part of RFC xxx; see the RFC =
          &nbs= p;  =20 itself for full legal notices."

> - I had=20 asked in in earlier email:
>   Mmm.. = did I review=20 rev 07. I can't quickly find that I
>   did = send a review=20 report.
>   I am assuming that you will = take care of=20 all the comments
>   that are (in my view) to be = expected=20 based on the review
>   of the = subscriber mib=20 I did, right?
  -> yes. will review and double check = draft10.=20

> - Is=20 this MIB obsoleteing an earlier (RFC) version?
  = ->   no. BPI=20 mib and BPI plus coexist together.

>   If this is the first time this MIB gets = publsihed as=20 an
>   RFC, then we want to see only one simple = revisions=20 clause
>   with a DESCRIPTION = aka:=20
>      "Initial version, = published as RFC=20 xxxx."
>      -- = RFC-editor assigns=20 xxxx
 =20 ->   fixed.

>   We do not want to see long lists of changes = that=20 happened
>   during initial revisions of = Internet=20 Drafts
  ->   ok. Left all the revisions in there = for now=20 with comments to be
  deleted when doing final rfc = editing. Did not=20 get removed in draft10
  yet, will be done = later.

> - And=20 how did you decide to assign the
>   = docsBpi2MIB=20 MODULE-IDENTITY
>      = ...=20
>      ::=3D { docsIfMib 6 = }=20
>   I worry a lot about this practice, cause it = is very=20 difficult
>   to keep track and to ensure = that no=20 conflicts arise.
  ->   fixed by replacing this = by=20
          &nbs= p; ::=3D=20 { mib-2 xx }   -- xx to be assigned by IANA =

> - I=20 worry about:
>       = X509Certificate=20 ::=3D TEXTUAL-CONVENTION
>          =  =20 STATUS    current
>          =  =20 DESCRIPTION
>          =      =20 "An X509 digital certificate encoded as an ASN.1 DER =
>          =  =20 object."
>          =  =20 SYNTAX    OCTET STRING (SIZE (0..1400)) =
>    The reason is that this is not some = X509 generic=20 Certificate
>    but a special one for = your IPCDN=20 use.
>    How about renaming it to=20 DocsX509ASN1DEREncodedCertificate ??
  ->   good point. = Changed to the=20 suggested TC name everywhere.


>=20 -       docsBpi2CmAuthReset=20 OBJECT-TYPE
>    Would it be wise to = add a=20 docsBpi2CmAuthLastReset object
>    = similar as what=20 was done in the subscriber MIB module?
  -> per our = interim=20 meeting in Feb'03, the new last reset object
  will  = not=20
  be = added because=20 this reset is really only for testing purposes. =
  Changed = docsBpi2CmAuthReset=20 description has been updated to add
        This=20 object is for testing purposes only and therefore it =
        does not require = to be=20 associated with a last reset object."


> -=20 objects like:
>      =20 docsBpi2CmAuthRejects    OBJECT-TYPE =
>          =  =20 SYNTAX         = Counter32=20
>          =  =20 MAX-ACCESS     read-only
>          =  =20 STATUS         = current=20
>          =  =20 DESCRIPTION
>          =       =20 "The value of this object is the count of times the CM =
>          =  =20 has received an Authorization Reject message,
> = since=20 reboot."
>   require that a Counter = starts at zero.=20 But those are NOT the
>   = semanticws of a=20 Counter32. If this is what you want, I think you =
>   need=20 to use the ZeroBasedCounter32 as per RFC2021.
>   Pls=20 read draft-ietf-ops-mib-review-guidelines-00.txt sect = 4.6=20
>   specifically 4.6.1.2
>   You=20 have quite a few of those objetcs
   -> ok. =
   For each = Counter32=20 object that require a start at zero, we
   will = change syntax=20 from Counter32 to ZeroBasedCounter32.
   Added IMPORT = ZeroBasedCounter32 FROM=20 RMON2-MIB.

>=20 -      =20 docsBpi2CmAuthRejectErrorString    = OBJECT-TYPE=20
>          =  =20 SYNTAX         SnmpAdminString = (SIZE=20 (0..128))
>          =  =20 MAX-ACCESS     read-only
>          =  =20 STATUS         = current=20
>          =  =20 DESCRIPTION
>          =       =20 "The value of this object is the Display-String in =
>    S/Display-String/text string/ = ??=20
>    Same for=20 docsBpi2CmAuthInvalidErrorString
>    = And for=20 docsBpi2CmTEKKeyRejectErrorString
>          =  =20 docsBpi2CmTEKInvalidErrorString
>      =20 docsBpi2CmIpMulticastSAMapRejectErrorString
>    =20 docsBpi2CmtsAuthInvalidErrorString
  -> done - replaced all = 'Display-String' in=20 description clauses by 'text
  string'

>=20 -      = docsBpi2CmTEKDataEncryptAlg  =20 OBJECT-TYPE
>          = =20 SYNTAX         INTEGER = {=20
>          =             &= nbsp;          =20 none(0),
>          =             &= nbsp;          =20 des56CbcMode(1),
>          =             &= nbsp;          =20 des40CbcMode(2)
>          =             &= nbsp;          =20 }
>    We recommend to start Enumerations = from=20 1.
>    Possibly the 1 and 2 for the desXxxx=20 enumerations are so numbered
>    = to align with=20 some other place. If so, then starting with zero =
>    seems acceptable. But pls add some = explanantion=20 in that case
  -> ok. fixed.
  Table 4-22 of bpiplus spec = defines the Data=20 Encryption
  Algorithm Identifiers and values are: =
  0 = Reserved=20
  1 = CBC-Mode, 56-bit=20 DES
 =20 2 CBC-Mode, 40-bit DES
  3-255 Reserved =
  so it is = proposed to leave=20 object def as-is and add the following
  justification=20 text:
  "Values 'des56CbcMode' and 'des40CbcMode' are defined = in=20 the
 =20 interface specification as integer values (1) and (2)." =


>    Same question for simial xxxCrypto=20 object
  -> ok. fixed.

>=20 -       = docsBpi2CmTEKDataAuthentAlg  =20 OBJECT-TYPE
>          =  =20 SYNTAX         INTEGER = {=20
>          =             &= nbsp;           =20 none(0)
>          =             &= nbsp;           =20 }
>    An object that can only have one value = that is=20 ALWAYS zero?
>    What is the use of = that? Maybe=20 future extensibility, but if so,
>    = then please say=20 so in DESCRIPTION clause, otherwise this
>    seems nonsense and = bloat.=20
  = -> ok. fixed.=20 Added "This object is defined for future
 =20 extensibility."

>    Same question for simial xxxCrypto=20 object
  -> ok. fixed. same as above.

>=20 -      =20 = docsBpi2CmIpMulticastIndex        = ;=20 OBJECT-TYPE
>          =  =20 SYNTAX         Integer32=20 (1..1000)
>    It is valid. But for = INDEX objects=20 we prefer Unsigned32 with
>    a = range. see=20 again the mib review guidelines doc
>    I = think this=20 occurs a few more time in this MIB module.
>    As I say, it is valid, but since your = still=20 working on this
>    MIB module, might as = well use the=20 recommended method.
 -> certainly. fixed all = integer32 INDEX=20 objects syntax to Unsigned32.
  This includes the following=20 objects:
  docsBpi2CmTEKSAId
  = docsBpi2CmIpMulticastIndex=20
 =20 docsBpi2CmCryptoSuiteIndex
  docsBpi2CmtsTEKSAId =
 =20 docsBpi2CmtsIpMulticastIndex
  = docsBpi2CmtsMulticastAuthSAId=20
 =20 docsBpi2CmtsCACertIndex

>=20 -       = docsBpi2CmIpMulticastAddress =20 OBJECT-TYPE
>          =  =20 SYNTAX        =20 InetAddress
>          =  =20 MAX-ACCESS     read-only
>          =  =20 STATUS         = current=20
>          =  =20 DESCRIPTION
>          =       =20 "This object represents the IP multicast address =
>          =  =20 to be mapped."
>    you MUST specify with=20 InetAddressType object defines the context
>    or type of this object. You did it = correct in=20 subscriber mib.
  -> fixed.

>=20 -      =20 docsBpi2CmtsDefaultSelfSignedManufCertTrust  = OBJECT-TYPE=20
>          =  =20 SYNTAX    INTEGER {
>          =            =20 trusted (1),
>          =            =20 untrusted (2)
>          =            =20 }
>    Seems to me that=20 docsBpi2CmtsDefaultSelfSignedManufCertTrusted
>    descriptor with a syntax of TruthValue = is more=20 appropriate
> -      =20 docsBpi2CmtsCheckCertValidityPeriods   =20 OBJECT-TYPE
>          =  =20 SYNTAX        =20 TruthValue
>          =  =20 MAX-ACCESS     read-write
>          =  =20 STATUS         = current=20
>          =  =20 DESCRIPTION
>          = "Setting=20 this object to TRUE causes all chained and
>    The better wording is: =
>          = "Setting=20 this object to 'true' causes all chained and
          &nbs= p;            = ;   =20 ->       ^^^^^ fixed. =

>    This occurs a few more times in this = MIB=20 module
     -> fixed all of = them.=20


>=20 -     docsBpi2CmtsAuthCmBpiVersion =20 OBJECT-TYPE
>          =  =20 SYNTAX         INTEGER = {=20
>          =             &= nbsp; =20 bpi (0),
>          =             &= nbsp; =20 bpiPlus (1)
>          =             &= nbsp;       =20 }
>    Any special reason why enumeration = cannot start=20 at 1?
      to be discussed in docsis=20 team.

>=20 -       docsBpi2CmtsAuthCmReset =20 OBJECT-TYPE
>    Yet another way in = which you guys=20 do resets.
> -      =20 docsBpi2CmtsAuthCmInfos      =20 OBJECT-TYPE
>          =  =20 SYNTAX         = Counter32=20
>          =  =20 MAX-ACCESS     read-only
>          =  =20 STATUS         = current=20
>          =  =20 DESCRIPTION
>          =       =20 "The value of this object is the count of times the =
>          =  =20 CMTS has received an Authentication Information =
> = message=20 from
>          =  =20 this CM, since entry creatiion."
>   =20 ZeroBasedCounter32 ??
  -> yes, fixed. =

>    You have several of = those=20
  = -> yes=20 fixed.

>=20 -      =20 = docsBpi2CmtsAuthBpkmCmCertValid       =  =20 OBJECT-TYPE
>          =  =20 SYNTAX    INTEGER {
>          =             &= nbsp;      =20 unknown (0),
>          =             &= nbsp;      =20 validCmChained (1),
>          =             &= nbsp;      =20 validCmTrusted (2),
>          =             &= nbsp;      =20 invalidCmUntrusted (3),
>          =             &= nbsp;      =20 invalidCAUntrusted (4),
>          =             &= nbsp;      =20 invalidCmOther (5),
>          =             &= nbsp;      =20 invalidCAOther (6)
>          =             &= nbsp;      =20 }
>      Any special reason to = start=20 ENUMERATION with zero ??
>=20 -       = docsBpi2CmtsTEKSAType   =20 OBJECT-TYPE
>          =  =20 SYNTAX         INTEGER = {=20
>          =             &= nbsp;           =20 none(0),
>          =             &= nbsp;           =20 primary(1),
>          =             &= nbsp;           =20 static(2),
>          =             &= nbsp;           =20 dynamic(3)
>          =             &= nbsp;           =20 }
>      Any special reason to = start=20 ENUMERATION with zero ??
  -> to be addressed in docsis=20 team

>      There are more of those... = I won;t=20 list them anymore,
>      I guess = you get the=20 gist.

> - I=20 wonder if it would not be better to have 2 compliance =
>  =20 statements, one for CM and one for CMTS.
>   It=20 is unclear to me if any GROUPS are mandatory. I think =
>   some=20 are, but it depends if your are CM or CMTS
  -> to be = addressed in=20 docsis team

>=20 -       -- relaxation on IP=20 addressing
>      =20 OBJECT    = docsBpi2CmIpMulticastAddressType=20
>          =    =20 -- SYNTAX InetAddressType { ipv4(1) }
>    = Pls make it a=20 real SYNTAX clause and not a comment.
>    = That SMICng=20 barks at it is something we know and SMICng
>    should be fixed. =
  -> = fixed.=20


> - You=20 have citations in DESCRIPTION clauses. We normally do = not=20
>   do that, cause they will be lost when people = extract=20 the
>   MIB module from the RFC. =
 -> ok.=20 fixed.

> - Mmm..=20 you start off with some OBSOLETED object group right =
>   away=20 he? You might want to say something about when/why that=20
>   happened.
> - References need = to be split in=20 normative and informative
 -> ok. fixed. =

> - You=20 have picked up the new MIB boilerplate, but you still =
>   have=20 a lot of old MIB boilerplate references included, which=20
>   make no sense anymore =
 -> ok. = cleaned as much as=20 possible.

> - The=20 new MIB boilerplate has [RFC2578], [RFC2579] and = [RFC2580]=20
>   as citations, but they do not show as such = in the=20 references
>   section =
 -> ok.=20 fixed.

> - The=20 security considerations section is not compliant with = the=20
>   new MIB security guidelines. The subscriber = MIB=20 has
>   done a much better job. You should = too.=20
 -> = ok, beefed up=20 the security consideration section.


> - I see=20 3 names in CONTACT-INFO while only two are listed =
>   on=20 front page and only two are listed in Author's = addresses?=20
 -> = The 2=20 co-authors of draft 08 agree to add Kaz Ozawa as =
    = part of the=20 author list.
    Contact info for Kaz = corrected.

Minor = additional=20 nits:
 - Enforced (mostly) the 72 character column limit in = Word, and=20 fixing
   the wrapped text (many many = changes).=20
 - = Removed some=20 non-ASCII text, especially "special" quotation marks =
 - Removed = IMPORT of Gauge32,=20 since it is not used
 - Removed the REFERENCE clauses = from the=20 OBJECT compliance
   statements, since they are not permitted per the = following=20 syntax
   from page 6 of RFC 2580.=20


------_=_NextPart_001_01C35076.EDA9D606-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 23 12:07:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18193 for ; Wed, 23 Jul 2003 12:07:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fM8u-0000aL-RU for ipcdn-archive@odin.ietf.org; Wed, 23 Jul 2003 12:07:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NG74Ar002233 for ipcdn-archive@odin.ietf.org; Wed, 23 Jul 2003 12:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fM8r-0000Yx-Ow; Wed, 23 Jul 2003 12:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fM8a-0000Y6-EL for ipcdn@optimus.ietf.org; Wed, 23 Jul 2003 12:06:44 -0400 Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18156 for ; Wed, 23 Jul 2003 12:06:40 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6NG59s22776 for ; Wed, 23 Jul 2003 11:05:10 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jul 2003 18:05:04 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B643@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , Jean-Francois Mule , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: stu.green@arrisi.com, Alexander Katsnelson , k.ozawa@CableLabs.com Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Wed, 23 Jul 2003 18:05:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , W.r.t. > > - I wonder if it would not be better to have 2 compliance > > statements, one for CM and one for CMTS. > > It is unclear to me if any GROUPS are mandatory. I think > > some are, but it depends if your are CM or CMTS > -> to be addressed in docsis team > > There is not unconditionally groups (e.e base group applying > both CM and CMTSes) > The tree groups are > > docsBpi2CmtsGroup CMTS only > docsBpi2CmGroup CM only > docsBpi2CodeDownloadGroup CM and optional CMTS > > Maybe a way to indicates the MANDATORY requirements would be: > > Proposed changes: replace 'implemented' with required > > -- conditionally mandatory group > GROUP docsBpi2CmGroup > DESCRIPTION > "This group is required only in CMs, not in CMTSs." > > -- conditionally mandatory group > GROUP docsBpi2CmtsGroup > DESCRIPTION > "This group is required only in CMTSs, not in CMs." > > -- conditionally mandatory group > GROUP docsBpi2CodeDownloadGroup > DESCRIPTION > "This group is required in CMs and is optional in CMTSs." > Or, have TWO MODULE-COMPLIANCE statements, one for CM, which would have MANDFATORY groups docsBpi2CmGroup and docsBpi2CodeDownloadGroup and one for CMTS, which would have mandatory groups docsBpi2CmtsGroup and docsBpi2CodeDownloadGroup Does that not make sense? Are there situations where one SNMP agent would be acting in both roles? Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 23 14:17:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22171 for ; Wed, 23 Jul 2003 14:17:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOAh-00079x-Em for ipcdn-archive@odin.ietf.org; Wed, 23 Jul 2003 14:17:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NIH334027515 for ipcdn-archive@odin.ietf.org; Wed, 23 Jul 2003 14:17:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOAe-00079c-Vk; Wed, 23 Jul 2003 14:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fOAR-00078O-0n for ipcdn@optimus.ietf.org; Wed, 23 Jul 2003 14:16:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22153 for ; Wed, 23 Jul 2003 14:16:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fOAO-0006fd-00 for ipcdn@ietf.org; Wed, 23 Jul 2003 14:16:44 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fOAD-0006ey-00 for ipcdn@ietf.org; Wed, 23 Jul 2003 14:16:33 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6NIF9dS013049; Wed, 23 Jul 2003 12:15:10 -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-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion Date: Wed, 23 Jul 2003 12:15:09 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion Thread-Index: AcLTcy1oUzrP+TZJSta0Z6wy3lxNNR5L6VIwAMpNuBAAXiEM8A== From: "Jean-Francois Mule" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Eduardo, The proposed resolution on docsBpi2CmtsAuthCmBpiVersion looks good to me. Any other comments on this one? In short, you propose to not change the enum list and start with 0 and to add some explanatory text to justify it. To get closure on docsBpi2CmtsAuthCmBpiVersion, minor nits (mostly add reference to BPI spec in ref clause since value 0 is not defined in bpi+. docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 SYNTAX INTEGER {=20 bpi (0),=20 bpiPlus (1)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the version of Baseline=20 Privacy for which this CM has registered. The value=20 'bpiplus' represents the value of BPI-Version Attribute of=20 the Baseline Privacy Key Management BPKM attribute=20 BPI-Version (1). The value 'bpi' is used to represent the=20 CM registerered using DOCSIS 1.0 Baseline Privacy." REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.22; DOCSIS Baseline Privacy Interface Specification"=20 ::=3D { docsBpi2CmtsAuthEntry 2 }=20 Jean-Francois. Ps: note the email address change for Kaz (Kazuyoshi.Ozawa --AT-- toshiba.co.jp) -----Original Message----- From: Eduardo Cardona=20 Sent: Tuesday, July 22, 2003 11:30 AM To: Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Jean Francois,=20 Thanks for the sumarized details of actions,=20 Here are comments and proposals for the open questions. for the MIB authors and ipcdn group consideration. feel free to make comments and suggestions. Eduardo > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > bpi (0),=20 > bpiPlus (1)=20 > }=20 > Any special reason why enumeration cannot start at 1?=20 to be discussed in docsis team.=20 docsBpi2CmtsAuthTable is a CMTS table that list the CM Authorization Association with respect to BPI+ - RFC 3083 have a similar table docsBpiCmtsAuthTable docsBpi2CmtsAuthCmBpiVersion was added in Bpi2 mib and is not present in Bpi mib, It reflects a new BPI+ parameters in the BPKM ( code 22) BPI-Version: BPI (RFC 3083) covers {0, 17-126} reserved, {127,128-255} vendor, {1-16} BPI defined BPI+ (bpiplus draft) covers {0, 28-126} reserved, {127,128-255} vendor, {1-27} BPI defined the new bpi defined parameters by bpiplus 17-27) includes : Code 22 BPI-Version in 4.2.2.22 BPI-Version of SP-BPI+-I09-020830 defined values are : 0, Reserved 1 BPI+=20 2-255 Reserved The mib assigns 0 to bpi , 1 to bpiplus and reserved numbers 2-255 for future protocols denominations ---Suggested Text docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 SYNTAX INTEGER {=20 bpi (0),=20 bpiPlus (1)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the version of Baseline=20 Privacy for which this CM has registered. The Value=20 'bpiplus' represents the value of BPI-Version Attribute of=20 the Baseline Privacy Key Management BPKM attribute=20 BPI-Version (1). Value 'bpi' is used to represent the CM=20 registerered using DOCSIS 1.0 Baseline Privacy." REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.22"=20 =20 ::=3D { docsBpi2CmtsAuthEntry 2 }=20 -------------------------------------- > Any special reason to start ENUMERATION with zero ??=20 > - docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > primary(1),=20 > static(2),=20 > dynamic(3)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 -> to be addressed in docsis team=20 > There are more of those... I won;t list them anymore,=20 > I guess you get the gist.=20 docsBpi2CmTEKDataEncryptAlg docsBpi2CmTEKDataAuthentAlg=20 Already fixed since draft 9 I believe the mib author decided to align the structure of enumerations for the objects in the table docsBpi2CmTEKTable=20 docsBpi2CmTEKSAType=20 docsBpi2CmTEKDataEncryptAlg docsBpi2CmTEKDataAuthentAlg=20 the BPKM Attribute 24 SA-Type does start in zero, but the defined enumeration in the mib does not follow exactly those values. docsBpi2CmTEKSAType : none(0) primary(1) static(2) dynamic(3) BPKM attribute 24 SA-Type: 0 primary, 1 static, 2 Dynamic. 3-127 Reserved, 128-255 Vendor-Specific (***) -- Ideal MIB enumeration primary(0), static(1), Dynamic(2)=20 docsBpi2CmTEKDataEncryptAlg: none(0) des56CbcMode(1) des40CbcMode(2) BPKM Attribute 20 Cryptographic-suite:=20 Data Authentication Algorithm Identifiers 0 Reserved, 1 CBC-Mode, 2 CBC-Mode, 3-255 Reserved docsBpi2CmTEKDataAuthentAlg: none(0) BPKM Attribute 20 Cryptographic-suite:=20 Data Authentic ation Algorithm Identifiers 0 No Data Authentication, 1-255 Reserved A truly consistent enumeration for docsBpi2CmTEKSAType against the protocol would be primary(0), static(1), Dynamic(2), none(3) At the level protocol no 'none' attribute is send on the wire,=20 it means BPKM messages are have not yet sent to determine the SA type docsBpi2CmTEKSAType OBJECT-TYPE=20 .............. DESCRIPTION=20 "The value of this object is the type of security=20 association. The none(0) encoding must only be used=20 if the SA type has yet to be determined."=20 In conclusion the enumeration 0 would be valid to match the protocol requirements (see ***) ( known value from the BPKM protocol) , but the change in the enumeration is desirable to happen to have the same enumeration structure in docsBpi2CmTEKTable as well as keeping the definition compatible with the broad number of devices in the field. Proposed text (updated reference) docsBpi2CmTEKSAType OBJECT-TYPE=20 SYNTAX INTEGER {=20 none(0),=20 primary(1),=20 static(2),=20 dynamic(3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. The none(0) encoding must only be used=20 if the SA type has yet to be determined. Values=20 'primary', 'static' and 'dynamic are defined in the=20 SA-Type Attribute of the Baseline Privacy Key=20 Management BPKM as (0), (1), (2) respectively."=20 REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.24"=20 ::=3D { docsBpi2CmTEKEntry 2 }=20 -------------------------------------------- > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > unknown (0),=20 > validCmChained (1),=20 > validCmTrusted (2),=20 > invalidCmUntrusted (3),=20 > invalidCAUntrusted (4),=20 > invalidCmOther (5),=20 > invalidCAOther (6)=20 > }=20 The docsBpi2CmtsAuthBpkmCmCertValid value is assigned by the CMTS to indicate validity of the CM certificates path or chain provisioned or aquired via BPKM. The same rationale as in some BPI mibs like docsBpi2CmtsAuthCmBpiVersion enumeration 0, 'unknown' value is used to represent the case when the CM is running in bpi not bpiplus NOt a straigth match but the BPKM attibutes in bpiplus intentionaly reserves the value zero and in bpi mode no bpiplus attibutes are not sent in the wire. so believe the mib is using the enmeration 0 to reflect the bpi mode of operation without conflicting with the bpiplis attributes values (almost all time SA-Type still has to me dark areas) The DESCRIPTION also mention the reason of 'unknown' value for (bpi) where certificates are not used,=20 That allows to use in the future other enumerations above 6 for detailed CM Certificates validity status.=20 docsBpi2CmtsAuthBpkmCmCertValid=20 .... I do not see any Protocol codes association (in BPI+ 9.4.1 CMTS Certificate Management Model) replied to the CM that matches any Certificate validation. BPI experts may provide a more clean explanation. Therefore I do not think a mib change is needed if for IETF Mib Doctors using enumeration 0 is valid for bpiplus mibs reporting devices in bpi mode.=20 Any suggestions to make that more clear?=20 > - I wonder if it would not be better to have 2 compliance=20 > statements, one for CM and one for CMTS.=20 > It is unclear to me if any GROUPS are mandatory. I think=20 > some are, but it depends if your are CM or CMTS=20 -> to be addressed in docsis team=20 There is not unconditionally groups (e.e base group applying both CM and CMTSes) The tree groups are =20 docsBpi2CmtsGroup CMTS only docsBpi2CmGroup CM only docsBpi2CodeDownloadGroup CM and optional CMTS Maybe a way to indicates the MANDATORY requirements would be: Proposed changes: replace 'implemented' with required -- conditionally mandatory group=20 GROUP docsBpi2CmGroup=20 DESCRIPTION=20 "This group is required only in CMs, not in CMTSs."=20 =20 -- conditionally mandatory group=20 GROUP docsBpi2CmtsGroup=20 DESCRIPTION=20 "This group is required only in CMTSs, not in CMs."=20 =20 -- conditionally mandatory group=20 GROUP docsBpi2CodeDownloadGroup=20 DESCRIPTION=20 "This group is required in CMs and is optional in CMTSs."=20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Thursday, July 17, 2003 2:37 PM To: Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Bert & all,=20 Below are the details on what comments got addresed in draft-ietf-ipcdn-bpiplus-mib-10 based on your review.=20 Jean-Francois.=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, February 13, 2003 8:13 AM=20 > To: Ipcdn (E-mail)=20 > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com=20 > Subject: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt=20 >=20 >=20 > Here are my comments:=20 >=20 > - references/citations in abstract are not allowed per=20 > RFC-Editor policy=20 -> deleted refs.=20 > - 2nd para in abstract seems not needed. but I can live=20 > with it=20 -> deleted.=20 > - Tiltle of sect 1 is not inline with MIB boilerplate=20 -> fixed.=20 > - 3rd para in section 1 is not needed, in fact I'd rather=20 > see it removed. The RFC3410 explains all that.=20 -> fixed.=20 > - DESCRIPTION clause of MODULE-IDENTITY is missing the=20 > MIB copyright statement=20 -> added the following text:=20 Copyright (C) The Internet Society (2003). This version=20 of this MIB module is part of RFC xxx; see the RFC=20 itself for full legal notices."=20 > - I had asked in in earlier email:=20 > Mmm.. did I review rev 07. I can't quickly find that I=20 > did send a review report.=20 > I am assuming that you will take care of all the comments=20 > that are (in my view) to be expected based on the review=20 > of the subscriber mib I did, right?=20 -> yes. will review and double check draft10.=20 > - Is this MIB obsoleteing an earlier (RFC) version?=20 -> no. BPI mib and BPI plus coexist together.=20 > If this is the first time this MIB gets publsihed as an=20 > RFC, then we want to see only one simple revisions clause=20 > with a DESCRIPTION aka:=20 > "Initial version, published as RFC xxxx."=20 > -- RFC-editor assigns xxxx=20 -> fixed.=20 > We do not want to see long lists of changes that happened=20 > during initial revisions of Internet Drafts=20 -> ok. Left all the revisions in there for now with comments to be=20 deleted when doing final rfc editing. Did not get removed in draft10=20 yet, will be done later.=20 > - And how did you decide to assign the=20 > docsBpi2MIB MODULE-IDENTITY=20 > ...=20 > ::=3D { docsIfMib 6 }=20 > I worry a lot about this practice, cause it is very difficult=20 > to keep track and to ensure that no conflicts arise.=20 -> fixed by replacing this by=20 ::=3D { mib-2 xx } -- xx to be assigned by IANA=20 > - I worry about:=20 > X509Certificate ::=3D TEXTUAL-CONVENTION=20 > STATUS current=20 > DESCRIPTION=20 > "An X509 digital certificate encoded as an ASN.1 DER=20 > object."=20 > SYNTAX OCTET STRING (SIZE (0..1400))=20 > The reason is that this is not some X509 generic Certificate=20 > but a special one for your IPCDN use.=20 > How about renaming it to DocsX509ASN1DEREncodedCertificate ??=20 -> good point. Changed to the suggested TC name everywhere.=20 > - docsBpi2CmAuthReset OBJECT-TYPE=20 > Would it be wise to add a docsBpi2CmAuthLastReset object=20 > similar as what was done in the subscriber MIB module?=20 -> per our interim meeting in Feb'03, the new last reset object=20 will not=20 be added because this reset is really only for testing purposes.=20 Changed docsBpi2CmAuthReset description has been updated to add=20 This object is for testing purposes only and therefore it=20 does not require to be associated with a last reset object."=20 > - objects like:=20 > docsBpi2CmAuthRejects OBJECT-TYPE=20 > SYNTAX Counter32=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the count of times the CM > has received an Authorization Reject message,=20 > since reboot."=20 > require that a Counter starts at zero. But those are NOT the=20 > semanticws of a Counter32. If this is what you want, I think you=20 > need to use the ZeroBasedCounter32 as per RFC2021.=20 > Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6=20 > specifically 4.6.1.2=20 > You have quite a few of those objetcs=20 -> ok.=20 For each Counter32 object that require a start at zero, we=20 will change syntax from Counter32 to ZeroBasedCounter32.=20 Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB.=20 > - docsBpi2CmAuthRejectErrorString OBJECT-TYPE=20 > SYNTAX SnmpAdminString (SIZE (0..128))=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the Display-String in=20 > S/Display-String/text string/ ??=20 > Same for docsBpi2CmAuthInvalidErrorString=20 > And for docsBpi2CmTEKKeyRejectErrorString=20 > docsBpi2CmTEKInvalidErrorString=20 > docsBpi2CmIpMulticastSAMapRejectErrorString=20 > docsBpi2CmtsAuthInvalidErrorString=20 -> done - replaced all 'Display-String' in description clauses by 'text=20 string'=20 > - docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > des56CbcMode(1),=20 > des40CbcMode(2)=20 > }=20 > We recommend to start Enumerations from 1.=20 > Possibly the 1 and 2 for the desXxxx enumerations are so numbered=20 > to align with some other place. If so, then starting with zero=20 > seems acceptable. But pls add some explanantion in that case=20 -> ok. fixed.=20 Table 4-22 of bpiplus spec defines the Data Encryption=20 Algorithm Identifiers and values are:=20 0 Reserved=20 1 CBC-Mode, 56-bit DES=20 2 CBC-Mode, 40-bit DES=20 3-255 Reserved=20 so it is proposed to leave object def as-is and add the following=20 justification text:=20 "Values 'des56CbcMode' and 'des40CbcMode' are defined in the=20 interface specification as integer values (1) and (2)."=20 > Same question for simial xxxCrypto object=20 -> ok. fixed.=20 > - docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0)=20 > }=20 > An object that can only have one value that is ALWAYS zero?=20 > What is the use of that? Maybe future extensibility, but if so,=20 > then please say so in DESCRIPTION clause, otherwise this=20 > seems nonsense and bloat.=20 -> ok. fixed. Added "This object is defined for future=20 extensibility."=20 > Same question for simial xxxCrypto object=20 -> ok. fixed. same as above.=20 > - docsBpi2CmIpMulticastIndex OBJECT-TYPE=20 > SYNTAX Integer32 (1..1000)=20 > It is valid. But for INDEX objects we prefer Unsigned32 with=20 > a range. see again the mib review guidelines doc=20 > I think this occurs a few more time in this MIB module.=20 > As I say, it is valid, but since your still working on this=20 > MIB module, might as well use the recommended method.=20 -> certainly. fixed all integer32 INDEX objects syntax to Unsigned32.=20 This includes the following objects:=20 docsBpi2CmTEKSAId=20 docsBpi2CmIpMulticastIndex=20 docsBpi2CmCryptoSuiteIndex=20 docsBpi2CmtsTEKSAId=20 docsBpi2CmtsIpMulticastIndex=20 docsBpi2CmtsMulticastAuthSAId=20 docsBpi2CmtsCACertIndex=20 > - docsBpi2CmIpMulticastAddress OBJECT-TYPE=20 > SYNTAX InetAddress=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "This object represents the IP multicast address=20 > to be mapped."=20 > you MUST specify with InetAddressType object defines the context=20 > or type of this object. You did it correct in subscriber mib.=20 -> fixed.=20 > - docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > trusted (1),=20 > untrusted (2)=20 > }=20 > Seems to me that docsBpi2CmtsDefaultSelfSignedManufCertTrusted=20 > descriptor with a syntax of TruthValue is more appropriate=20 > - docsBpi2CmtsCheckCertValidityPeriods OBJECT-TYPE=20 > SYNTAX TruthValue=20 > MAX-ACCESS read-write=20 > STATUS current=20 > DESCRIPTION=20 > "Setting this object to TRUE causes all chained and=20 > The better wording is:=20 > "Setting this object to 'true' causes all chained and=20 -> ^^^^^ fixed.=20 > This occurs a few more times in this MIB module=20 -> fixed all of them.=20 > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > bpi (0),=20 > bpiPlus (1)=20 > }=20 > Any special reason why enumeration cannot start at 1?=20 to be discussed in docsis team.=20 > - docsBpi2CmtsAuthCmReset OBJECT-TYPE=20 > Yet another way in which you guys do resets.=20 > - docsBpi2CmtsAuthCmInfos OBJECT-TYPE=20 > SYNTAX Counter32=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the count of times the=20 > CMTS has received an Authentication Information=20 > message from=20 > this CM, since entry creatiion."=20 > ZeroBasedCounter32 ??=20 -> yes, fixed.=20 > You have several of those=20 -> yes fixed.=20 > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > unknown (0),=20 > validCmChained (1),=20 > validCmTrusted (2),=20 > invalidCmUntrusted (3),=20 > invalidCAUntrusted (4),=20 > invalidCmOther (5),=20 > invalidCAOther (6)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 > - docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > primary(1),=20 > static(2),=20 > dynamic(3)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 -> to be addressed in docsis team=20 > There are more of those... I won;t list them anymore,=20 > I guess you get the gist.=20 > - I wonder if it would not be better to have 2 compliance=20 > statements, one for CM and one for CMTS.=20 > It is unclear to me if any GROUPS are mandatory. I think=20 > some are, but it depends if your are CM or CMTS=20 -> to be addressed in docsis team=20 > - -- relaxation on IP addressing=20 > OBJECT docsBpi2CmIpMulticastAddressType=20 > -- SYNTAX InetAddressType { ipv4(1) }=20 > Pls make it a real SYNTAX clause and not a comment.=20 > That SMICng barks at it is something we know and SMICng=20 > should be fixed.=20 -> fixed.=20 > - You have citations in DESCRIPTION clauses. We normally do not=20 > do that, cause they will be lost when people extract the=20 > MIB module from the RFC.=20 -> ok. fixed.=20 > - Mmm.. you start off with some OBSOLETED object group right=20 > away he? You might want to say something about when/why that=20 > happened.=20 > - References need to be split in normative and informative=20 -> ok. fixed.=20 > - You have picked up the new MIB boilerplate, but you still=20 > have a lot of old MIB boilerplate references included, which=20 > make no sense anymore=20 -> ok. cleaned as much as possible.=20 > - The new MIB boilerplate has [RFC2578], [RFC2579] and [RFC2580]=20 > as citations, but they do not show as such in the references=20 > section=20 -> ok. fixed.=20 > - The security considerations section is not compliant with the=20 > new MIB security guidelines. The subscriber MIB has=20 > done a much better job. You should too.=20 -> ok, beefed up the security consideration section.=20 > - I see 3 names in CONTACT-INFO while only two are listed=20 > on front page and only two are listed in Author's addresses?=20 -> The 2 co-authors of draft 08 agree to add Kaz Ozawa as=20 part of the author list.=20 Contact info for Kaz corrected.=20 Minor additional nits:=20 - Enforced (mostly) the 72 character column limit in Word, and fixing=20 the wrapped text (many many changes).=20 - Removed some non-ASCII text, especially "special" quotation marks=20 - Removed IMPORT of Gauge32, since it is not used=20 - Removed the REFERENCE clauses from the OBJECT compliance=20 statements, since they are not permitted per the following syntax=20 from page 6 of RFC 2580.=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 23 19:30:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07849 for ; Wed, 23 Jul 2003 19:30:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fT3a-0005uD-Q1 for ipcdn-archive@odin.ietf.org; Wed, 23 Jul 2003 19:30:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NNU2eF022697 for ipcdn-archive@odin.ietf.org; Wed, 23 Jul 2003 19:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fT3Z-0005ts-DD; Wed, 23 Jul 2003 19:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fT2a-0005i3-04 for ipcdn@optimus.ietf.org; Wed, 23 Jul 2003 19:29:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07824 for ; Wed, 23 Jul 2003 19:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fT2Y-0001hn-00 for ipcdn@ietf.org; Wed, 23 Jul 2003 19:28:58 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fT2M-0001hk-00 for ipcdn@ietf.org; Wed, 23 Jul 2003 19:28:47 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6NNRrdS000344; Wed, 23 Jul 2003 17:27:54 -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-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion Date: Wed, 23 Jul 2003 17:27:53 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion Thread-Index: AcLTcy1oUzrP+TZJSta0Z6wy3lxNNR5L6VIwAMpNuBAAXiEM8AACKAwg From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jean-Francois,=20 That will be: docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 SYNTAX INTEGER {=20 bpi (0),=20 bpiPlus (1)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the version of Baseline=20 Privacy for which this CM has registered. The value=20 'bpiplus' represents the value of BPI-Version Attribute of=20 the Baseline Privacy Key Management BPKM attribute=20 BPI-Version (1). The value 'bpi' is used to represent the=20 CM registerered using DOCSIS 1.0 Baseline Privacy." REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.22; ANSI/SCTE 22-2 2002(formerly DSS 02-03)=20 Data-Over-Cable Service Interface Specification DOCSIS 1.0 Baseline Privacy Interface (BPI)" ::=3D { docsBpi2CmtsAuthEntry 2 }=20 About Bert Comments:=20 Please make the required comments. Below is a proposed two compliance modules=20 I changed relaxation for constrains Removed commenst in SYNTAX clauses=20 Compliances modules Basic keyword removed, expanded to Cm or CMTS docsBpi2CmCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "This is the compliance statement for CMs which=20 implement the DOCSIS Baseline Privacy Interface Plus."=20 =20 MODULE -- docsBpi2MIB=20 =20 -- unconditionally mandatory group MANDATORY-GROUPS { docsBpi2CmGroup, docsBpi2CodeDownloadGroup } =20 GROUP docsBpi2CmGroup=20 DESCRIPTION=20 "This group implementation is required for CMs only."=20 =20 GROUP docsBpi2CodeDownloadGroup=20 DESCRIPTION=20 "This group implementation is required for CMs."=20 =20 -- constrains on IP addressing=20 OBJECT docsBpi2CmIpMulticastAddressType=20 -- SYNTAX InetAddressType { ipv4(1) }=20 DESCRIPTION=20 "An implementation is only required to support IPv4=20 addresses."=20 =20 -- constrains on IP addressing=20 OBJECT docsBpi2CmIpMulticastAddress=20 SYNTAX InetAddress (SIZE(4))=20 DESCRIPTION=20 "An implementation is only required to support IPv4=20 addresses."=20 =20 ::=3D { docsBpi2Compliances 1 }=20 docsBpi2CmtsCompliance MODULE-COMPLIANCE=20 STATUS current=20 DESCRIPTION=20 "This is the compliance statement for CMTSs which=20 implement the DOCSIS Baseline Privacy Interface Plus."=20 =20 MODULE -- docsBpi2MIB=20 -- unconditionally mandatory group MANDATORY-GROUPS { docsBpi2CmtsGroup } =20 GROUP docsBpi2CmtsGroup=20 DESCRIPTION=20 "This group implementation is required for CMTSs only."=20 =20 -- Optional group=20 GROUP docsBpi2CodeDownloadGroup=20 DESCRIPTION=20 "This group is optional for CMTSs."=20 =20 =20 -- constrains on Object range=20 OBJECT docsBpi2CmtsDefaultAuthLifetime=20 SYNTAX Integer32 (86400..6048000)=20 DESCRIPTION=20 "The refined range corresponds to the minimum and maximum=20 values in operational networks."=20 =20 -- constrains on mandatory range=20 OBJECT docsBpi2CmtsDefaultTEKLifetime=20 SYNTAX Integer32 (1800..604800)=20 DESCRIPTION=20 "The refined range corresponds to the minimum and maximum=20 values in operational networks."=20 =20 -- constrains on mandatory range=20 OBJECT docsBpi2CmtsAuthCmLifetime=20 SYNTAX Integer32 (86400..6048000)=20 DESCRIPTION=20 "The refined range corresponds to the minimum and maximum=20 values in operational networks."=20 =20 -- constrains on mandatory range=20 OBJECT docsBpi2CmtsTEKLifetime=20 SYNTAX Integer32 (1800..604800)=20 DESCRIPTION=20 "The refined range corresponds to the minimum and maximum=20 values in operational networks."=20 =20 -- constrains on IP addressing=20 OBJECT docsBpi2CmtsIpMulticastAddressType=20 -- SYNTAX InetAddressType { ipv4(1) }=20 DESCRIPTION=20 "An implementation is only required to support IPv4=20 addresses."=20 =20 -- constrains on IP addressing=20 OBJECT docsBpi2CmtsIpMulticastAddress=20 SYNTAX InetAddress (SIZE(4))=20 DESCRIPTION=20 "An implementation is only required to support IPv4=20 addresses."=20 =20 -- constrains on IP addressing=20 OBJECT docsBpi2CmtsIpMulticastMaskType=20 -- SYNTAX InetAddressType { ipv4(1) }=20 DESCRIPTION=20 "An implementation is only required to support IPv4=20 addresses."=20 =20 -- constrains on IP addressing=20 OBJECT docsBpi2CmtsIpMulticastMask=20 SYNTAX InetAddress (SIZE(4))=20 DESCRIPTION=20 "An implementation is only required to support IPv4=20 addresses."=20 =20 ::=3D { docsBpi2Compliances 2 }=20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Wednesday, July 23, 2003 12:15 PM To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; Kazuyoshi.Ozawa@toshiba.co.jp Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion=20 Eduardo, The proposed resolution on docsBpi2CmtsAuthCmBpiVersion looks good to me. Any other comments on this one? In short, you propose to not change the enum list and start with 0 and to add some explanatory text to justify it. To get closure on docsBpi2CmtsAuthCmBpiVersion, minor nits (mostly add reference to BPI spec in ref clause since value 0 is not defined in bpi+. docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 SYNTAX INTEGER {=20 bpi (0),=20 bpiPlus (1)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the version of Baseline=20 Privacy for which this CM has registered. The value=20 'bpiplus' represents the value of BPI-Version Attribute of=20 the Baseline Privacy Key Management BPKM attribute=20 BPI-Version (1). The value 'bpi' is used to represent the=20 CM registerered using DOCSIS 1.0 Baseline Privacy." REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.22; DOCSIS Baseline Privacy Interface Specification"=20 ::=3D { docsBpi2CmtsAuthEntry 2 }=20 Jean-Francois. Ps: note the email address change for Kaz (Kazuyoshi.Ozawa --AT-- toshiba.co.jp) -----Original Message----- From: Eduardo Cardona=20 Sent: Tuesday, July 22, 2003 11:30 AM To: Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Jean Francois,=20 Thanks for the sumarized details of actions,=20 Here are comments and proposals for the open questions. for the MIB authors and ipcdn group consideration. feel free to make comments and suggestions. Eduardo > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > bpi (0),=20 > bpiPlus (1)=20 > }=20 > Any special reason why enumeration cannot start at 1? to be discussed in docsis team.=20 docsBpi2CmtsAuthTable is a CMTS table that list the CM Authorization Association with respect to BPI+ - RFC 3083 have a similar table docsBpiCmtsAuthTable docsBpi2CmtsAuthCmBpiVersion was added in Bpi2 mib and is not present in Bpi mib, It reflects a new BPI+ parameters in the BPKM ( code 22) BPI-Version: BPI (RFC 3083) covers {0, 17-126} reserved, {127,128-255} vendor, {1-16} BPI defined BPI+ (bpiplus draft) covers {0, 28-126} reserved, {127,128-255} vendor, {1-27} BPI defined the new bpi defined parameters by bpiplus 17-27) includes : Code 22 BPI-Version in 4.2.2.22 BPI-Version of SP-BPI+-I09-020830 defined values are : 0, Reserved 1 BPI+=20 2-255 Reserved The mib assigns 0 to bpi , 1 to bpiplus and reserved numbers 2-255 for future protocols denominations ---Suggested Text docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 SYNTAX INTEGER {=20 bpi (0),=20 bpiPlus (1)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the version of Baseline=20 Privacy for which this CM has registered. The Value=20 'bpiplus' represents the value of BPI-Version Attribute of=20 the Baseline Privacy Key Management BPKM attribute=20 BPI-Version (1). Value 'bpi' is used to represent the CM=20 registerered using DOCSIS 1.0 Baseline Privacy." REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.22"=20 =20 ::=3D { docsBpi2CmtsAuthEntry 2 }=20 -------------------------------------- > Any special reason to start ENUMERATION with zero ??=20 > - docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > primary(1),=20 > static(2),=20 > dynamic(3)=20 > }=20 > Any special reason to start ENUMERATION with zero ?? -> to be addressed in docsis team=20 > There are more of those... I won;t list them anymore,=20 > I guess you get the gist. docsBpi2CmTEKDataEncryptAlg docsBpi2CmTEKDataAuthentAlg=20 Already fixed since draft 9 I believe the mib author decided to align the structure of enumerations for the objects in the table docsBpi2CmTEKTable=20 docsBpi2CmTEKSAType=20 docsBpi2CmTEKDataEncryptAlg docsBpi2CmTEKDataAuthentAlg=20 the BPKM Attribute 24 SA-Type does start in zero, but the defined enumeration in the mib does not follow exactly those values. docsBpi2CmTEKSAType : none(0) primary(1) static(2) dynamic(3) BPKM attribute 24 SA-Type: 0 primary, 1 static, 2 Dynamic. 3-127 Reserved, 128-255 Vendor-Specific (***) -- Ideal MIB enumeration primary(0), static(1), Dynamic(2)=20 docsBpi2CmTEKDataEncryptAlg: none(0) des56CbcMode(1) des40CbcMode(2) BPKM Attribute 20 Cryptographic-suite:=20 Data Authentication Algorithm Identifiers 0 Reserved, 1 CBC-Mode, 2 CBC-Mode, 3-255 Reserved docsBpi2CmTEKDataAuthentAlg: none(0) BPKM Attribute 20 Cryptographic-suite:=20 Data Authentic ation Algorithm Identifiers 0 No Data Authentication, 1-255 Reserved A truly consistent enumeration for docsBpi2CmTEKSAType against the protocol would be primary(0), static(1), Dynamic(2), none(3) At the level protocol no 'none' attribute is send on the wire,=20 it means BPKM messages are have not yet sent to determine the SA type docsBpi2CmTEKSAType OBJECT-TYPE=20 .............. DESCRIPTION=20 "The value of this object is the type of security=20 association. The none(0) encoding must only be used=20 if the SA type has yet to be determined."=20 In conclusion the enumeration 0 would be valid to match the protocol requirements (see ***) ( known value from the BPKM protocol) , but the change in the enumeration is desirable to happen to have the same enumeration structure in docsBpi2CmTEKTable as well as keeping the definition compatible with the broad number of devices in the field. Proposed text (updated reference) docsBpi2CmTEKSAType OBJECT-TYPE=20 SYNTAX INTEGER {=20 none(0),=20 primary(1),=20 static(2),=20 dynamic(3)=20 }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. The none(0) encoding must only be used=20 if the SA type has yet to be determined. Values=20 'primary', 'static' and 'dynamic are defined in the=20 SA-Type Attribute of the Baseline Privacy Key=20 Management BPKM as (0), (1), (2) respectively."=20 REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.24"=20 ::=3D { docsBpi2CmTEKEntry 2 }=20 -------------------------------------------- > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > unknown (0),=20 > validCmChained (1),=20 > validCmTrusted (2),=20 > invalidCmUntrusted (3),=20 > invalidCAUntrusted (4),=20 > invalidCmOther (5),=20 > invalidCAOther (6)=20 > } The docsBpi2CmtsAuthBpkmCmCertValid value is assigned by the CMTS to indicate validity of the CM certificates path or chain provisioned or aquired via BPKM. The same rationale as in some BPI mibs like docsBpi2CmtsAuthCmBpiVersion enumeration 0, 'unknown' value is used to represent the case when the CM is running in bpi not bpiplus NOt a straigth match but the BPKM attibutes in bpiplus intentionaly reserves the value zero and in bpi mode no bpiplus attibutes are not sent in the wire. so believe the mib is using the enmeration 0 to reflect the bpi mode of operation without conflicting with the bpiplis attributes values (almost all time SA-Type still has to me dark areas) The DESCRIPTION also mention the reason of 'unknown' value for (bpi) where certificates are not used,=20 That allows to use in the future other enumerations above 6 for detailed CM Certificates validity status.=20 docsBpi2CmtsAuthBpkmCmCertValid=20 .... I do not see any Protocol codes association (in BPI+ 9.4.1 CMTS Certificate Management Model) replied to the CM that matches any Certificate validation. BPI experts may provide a more clean explanation. Therefore I do not think a mib change is needed if for IETF Mib Doctors using enumeration 0 is valid for bpiplus mibs reporting devices in bpi mode.=20 Any suggestions to make that more clear?=20 > - I wonder if it would not be better to have 2 compliance=20 > statements, one for CM and one for CMTS.=20 > It is unclear to me if any GROUPS are mandatory. I think=20 > some are, but it depends if your are CM or CMTS -> to be addressed in docsis team=20 There is not unconditionally groups (e.e base group applying both CM and CMTSes) The tree groups are =20 docsBpi2CmtsGroup CMTS only docsBpi2CmGroup CM only docsBpi2CodeDownloadGroup CM and optional CMTS Maybe a way to indicates the MANDATORY requirements would be: Proposed changes: replace 'implemented' with required -- conditionally mandatory group=20 GROUP docsBpi2CmGroup=20 DESCRIPTION=20 "This group is required only in CMs, not in CMTSs."=20 =20 -- conditionally mandatory group=20 GROUP docsBpi2CmtsGroup=20 DESCRIPTION=20 "This group is required only in CMTSs, not in CMs."=20 =20 -- conditionally mandatory group=20 GROUP docsBpi2CodeDownloadGroup=20 DESCRIPTION=20 "This group is required in CMs and is optional in CMTSs."=20 -----Original Message----- From: Jean-Francois Mule=20 Sent: Thursday, July 17, 2003 2:37 PM To: Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com Subject: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Bert & all,=20 Below are the details on what comments got addresed in draft-ietf-ipcdn-bpiplus-mib-10 based on your review.=20 Jean-Francois.=20 > -----Original Message-----=20 > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 > Sent: Thursday, February 13, 2003 8:13 AM=20 > To: Ipcdn (E-mail)=20 > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@cablelabs.com=20 > Subject: [ipcdn] Review of: draft-ietf-ipcdn-bpiplus-mib-08.txt=20 >=20 >=20 > Here are my comments:=20 >=20 > - references/citations in abstract are not allowed per=20 > RFC-Editor policy=20 -> deleted refs.=20 > - 2nd para in abstract seems not needed. but I can live=20 > with it=20 -> deleted.=20 > - Tiltle of sect 1 is not inline with MIB boilerplate=20 -> fixed.=20 > - 3rd para in section 1 is not needed, in fact I'd rather=20 > see it removed. The RFC3410 explains all that.=20 -> fixed.=20 > - DESCRIPTION clause of MODULE-IDENTITY is missing the=20 > MIB copyright statement=20 -> added the following text:=20 Copyright (C) The Internet Society (2003). This version=20 of this MIB module is part of RFC xxx; see the RFC=20 itself for full legal notices."=20 > - I had asked in in earlier email:=20 > Mmm.. did I review rev 07. I can't quickly find that I=20 > did send a review report.=20 > I am assuming that you will take care of all the comments=20 > that are (in my view) to be expected based on the review=20 > of the subscriber mib I did, right?=20 -> yes. will review and double check draft10.=20 > - Is this MIB obsoleteing an earlier (RFC) version?=20 -> no. BPI mib and BPI plus coexist together.=20 > If this is the first time this MIB gets publsihed as an=20 > RFC, then we want to see only one simple revisions clause=20 > with a DESCRIPTION aka:=20 > "Initial version, published as RFC xxxx."=20 > -- RFC-editor assigns xxxx=20 -> fixed.=20 > We do not want to see long lists of changes that happened=20 > during initial revisions of Internet Drafts=20 -> ok. Left all the revisions in there for now with comments to be=20 deleted when doing final rfc editing. Did not get removed in draft10=20 yet, will be done later.=20 > - And how did you decide to assign the=20 > docsBpi2MIB MODULE-IDENTITY=20 > ...=20 > ::=3D { docsIfMib 6 }=20 > I worry a lot about this practice, cause it is very difficult=20 > to keep track and to ensure that no conflicts arise.=20 -> fixed by replacing this by=20 ::=3D { mib-2 xx } -- xx to be assigned by IANA=20 > - I worry about:=20 > X509Certificate ::=3D TEXTUAL-CONVENTION=20 > STATUS current=20 > DESCRIPTION=20 > "An X509 digital certificate encoded as an ASN.1 DER=20 > object."=20 > SYNTAX OCTET STRING (SIZE (0..1400))=20 > The reason is that this is not some X509 generic Certificate=20 > but a special one for your IPCDN use.=20 > How about renaming it to DocsX509ASN1DEREncodedCertificate ??=20 -> good point. Changed to the suggested TC name everywhere.=20 > - docsBpi2CmAuthReset OBJECT-TYPE=20 > Would it be wise to add a docsBpi2CmAuthLastReset object=20 > similar as what was done in the subscriber MIB module?=20 -> per our interim meeting in Feb'03, the new last reset object=20 will not=20 be added because this reset is really only for testing purposes.=20 Changed docsBpi2CmAuthReset description has been updated to add=20 This object is for testing purposes only and therefore it=20 does not require to be associated with a last reset object."=20 > - objects like:=20 > docsBpi2CmAuthRejects OBJECT-TYPE=20 > SYNTAX Counter32=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the count of times the CM > has received an Authorization Reject message,=20 > since reboot."=20 > require that a Counter starts at zero. But those are NOT the=20 > semanticws of a Counter32. If this is what you want, I think you=20 > need to use the ZeroBasedCounter32 as per RFC2021.=20 > Pls read draft-ietf-ops-mib-review-guidelines-00.txt sect 4.6=20 > specifically 4.6.1.2=20 > You have quite a few of those objetcs=20 -> ok.=20 For each Counter32 object that require a start at zero, we=20 will change syntax from Counter32 to ZeroBasedCounter32.=20 Added IMPORT ZeroBasedCounter32 FROM RMON2-MIB.=20 > - docsBpi2CmAuthRejectErrorString OBJECT-TYPE=20 > SYNTAX SnmpAdminString (SIZE (0..128))=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the Display-String in=20 > S/Display-String/text string/ ??=20 > Same for docsBpi2CmAuthInvalidErrorString=20 > And for docsBpi2CmTEKKeyRejectErrorString=20 > docsBpi2CmTEKInvalidErrorString=20 > docsBpi2CmIpMulticastSAMapRejectErrorString=20 > docsBpi2CmtsAuthInvalidErrorString=20 -> done - replaced all 'Display-String' in description clauses by 'text=20 string'=20 > - docsBpi2CmTEKDataEncryptAlg OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > des56CbcMode(1),=20 > des40CbcMode(2)=20 > }=20 > We recommend to start Enumerations from 1.=20 > Possibly the 1 and 2 for the desXxxx enumerations are so numbered=20 > to align with some other place. If so, then starting with zero=20 > seems acceptable. But pls add some explanantion in that case=20 -> ok. fixed.=20 Table 4-22 of bpiplus spec defines the Data Encryption=20 Algorithm Identifiers and values are:=20 0 Reserved=20 1 CBC-Mode, 56-bit DES=20 2 CBC-Mode, 40-bit DES=20 3-255 Reserved=20 so it is proposed to leave object def as-is and add the following=20 justification text:=20 "Values 'des56CbcMode' and 'des40CbcMode' are defined in the=20 interface specification as integer values (1) and (2)."=20 > Same question for simial xxxCrypto object=20 -> ok. fixed.=20 > - docsBpi2CmTEKDataAuthentAlg OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0)=20 > }=20 > An object that can only have one value that is ALWAYS zero?=20 > What is the use of that? Maybe future extensibility, but if so,=20 > then please say so in DESCRIPTION clause, otherwise this=20 > seems nonsense and bloat.=20 -> ok. fixed. Added "This object is defined for future=20 extensibility."=20 > Same question for simial xxxCrypto object=20 -> ok. fixed. same as above.=20 > - docsBpi2CmIpMulticastIndex OBJECT-TYPE=20 > SYNTAX Integer32 (1..1000)=20 > It is valid. But for INDEX objects we prefer Unsigned32 with=20 > a range. see again the mib review guidelines doc=20 > I think this occurs a few more time in this MIB module.=20 > As I say, it is valid, but since your still working on this=20 > MIB module, might as well use the recommended method.=20 -> certainly. fixed all integer32 INDEX objects syntax to Unsigned32.=20 This includes the following objects:=20 docsBpi2CmTEKSAId=20 docsBpi2CmIpMulticastIndex=20 docsBpi2CmCryptoSuiteIndex=20 docsBpi2CmtsTEKSAId=20 docsBpi2CmtsIpMulticastIndex=20 docsBpi2CmtsMulticastAuthSAId=20 docsBpi2CmtsCACertIndex=20 > - docsBpi2CmIpMulticastAddress OBJECT-TYPE=20 > SYNTAX InetAddress=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "This object represents the IP multicast address=20 > to be mapped."=20 > you MUST specify with InetAddressType object defines the context=20 > or type of this object. You did it correct in subscriber mib.=20 -> fixed.=20 > - docsBpi2CmtsDefaultSelfSignedManufCertTrust OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > trusted (1),=20 > untrusted (2)=20 > }=20 > Seems to me that docsBpi2CmtsDefaultSelfSignedManufCertTrusted=20 > descriptor with a syntax of TruthValue is more appropriate=20 > - docsBpi2CmtsCheckCertValidityPeriods OBJECT-TYPE=20 > SYNTAX TruthValue=20 > MAX-ACCESS read-write=20 > STATUS current=20 > DESCRIPTION=20 > "Setting this object to TRUE causes all chained and=20 > The better wording is:=20 > "Setting this object to 'true' causes all chained and=20 -> ^^^^^ fixed.=20 > This occurs a few more times in this MIB module=20 -> fixed all of them.=20 > - docsBpi2CmtsAuthCmBpiVersion OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > bpi (0),=20 > bpiPlus (1)=20 > }=20 > Any special reason why enumeration cannot start at 1?=20 to be discussed in docsis team.=20 > - docsBpi2CmtsAuthCmReset OBJECT-TYPE=20 > Yet another way in which you guys do resets.=20 > - docsBpi2CmtsAuthCmInfos OBJECT-TYPE=20 > SYNTAX Counter32=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the count of times the=20 > CMTS has received an Authentication Information=20 > message from=20 > this CM, since entry creatiion."=20 > ZeroBasedCounter32 ??=20 -> yes, fixed.=20 > You have several of those=20 -> yes fixed.=20 > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > unknown (0),=20 > validCmChained (1),=20 > validCmTrusted (2),=20 > invalidCmUntrusted (3),=20 > invalidCAUntrusted (4),=20 > invalidCmOther (5),=20 > invalidCAOther (6)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 > - docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX INTEGER {=20 > none(0),=20 > primary(1),=20 > static(2),=20 > dynamic(3)=20 > }=20 > Any special reason to start ENUMERATION with zero ??=20 -> to be addressed in docsis team=20 > There are more of those... I won;t list them anymore,=20 > I guess you get the gist.=20 > - I wonder if it would not be better to have 2 compliance=20 > statements, one for CM and one for CMTS.=20 > It is unclear to me if any GROUPS are mandatory. I think=20 > some are, but it depends if your are CM or CMTS=20 -> to be addressed in docsis team=20 > - -- relaxation on IP addressing=20 > OBJECT docsBpi2CmIpMulticastAddressType=20 > -- SYNTAX InetAddressType { ipv4(1) }=20 > Pls make it a real SYNTAX clause and not a comment.=20 > That SMICng barks at it is something we know and SMICng=20 > should be fixed.=20 -> fixed.=20 > - You have citations in DESCRIPTION clauses. We normally do not=20 > do that, cause they will be lost when people extract the=20 > MIB module from the RFC.=20 -> ok. fixed.=20 > - Mmm.. you start off with some OBSOLETED object group right=20 > away he? You might want to say something about when/why that=20 > happened.=20 > - References need to be split in normative and informative=20 -> ok. fixed.=20 > - You have picked up the new MIB boilerplate, but you still=20 > have a lot of old MIB boilerplate references included, which=20 > make no sense anymore=20 -> ok. cleaned as much as possible.=20 > - The new MIB boilerplate has [RFC2578], [RFC2579] and [RFC2580]=20 > as citations, but they do not show as such in the references=20 > section=20 -> ok. fixed.=20 > - The security considerations section is not compliant with the=20 > new MIB security guidelines. The subscriber MIB has=20 > done a much better job. You should too.=20 -> ok, beefed up the security consideration section.=20 > - I see 3 names in CONTACT-INFO while only two are listed=20 > on front page and only two are listed in Author's addresses?=20 -> The 2 co-authors of draft 08 agree to add Kaz Ozawa as=20 part of the author list.=20 Contact info for Kaz corrected.=20 Minor additional nits:=20 - Enforced (mostly) the 72 character column limit in Word, and fixing=20 the wrapped text (many many changes).=20 - Removed some non-ASCII text, especially "special" quotation marks=20 - Removed IMPORT of Gauge32, since it is not used=20 - Removed the REFERENCE clauses from the OBJECT compliance=20 statements, since they are not permitted per the following syntax=20 from page 6 of RFC 2580.=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 04:05:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28168 for ; Thu, 24 Jul 2003 04:05:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fb63-00033x-C9 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 04:05:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O857qW011763 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 04:05:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fb62-00033c-SE; Thu, 24 Jul 2003 04:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fb58-0002tD-T4 for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 04:04:11 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com [192.11.223.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28116 for ; Thu, 24 Jul 2003 04:04:06 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6O82jP11922 for ; Thu, 24 Jul 2003 03:02:46 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 10:02:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B69A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , Jean-Francois Mule , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" Cc: stu.green@arrisi.com, Alexander Katsnelson , Kazuyoshi.Ozawa@toshiba.co.jp Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2C mtsAuthCmBpiVersion Date: Thu, 24 Jul 2003 10:02:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 24 juli 2003 1:28 > To: Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail) > Cc: stu.green@arrisi.com; Alexander Katsnelson; > Kazuyoshi.Ozawa@toshiba.co.jp > Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on > docsBpi2CmtsAuthCmBpiVersion > .. snip .. > > About Bert Comments: > > Please make the required comments. > > Below is a proposed two compliance modules > I changed relaxation for constrains > Removed commenst in SYNTAX clauses > Compliances modules Basic keyword removed, expanded to Cm or CMTS > > > docsBpi2CmCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "This is the compliance statement for CMs which > implement the DOCSIS Baseline Privacy Interface Plus." > > MODULE -- docsBpi2MIB > > -- unconditionally mandatory group > MANDATORY-GROUPS { > docsBpi2CmGroup, > docsBpi2CodeDownloadGroup > } > > > GROUP docsBpi2CmGroup > DESCRIPTION > "This group implementation is required for CMs only." > > GROUP docsBpi2CodeDownloadGroup > DESCRIPTION > "This group implementation is required for CMs." > The above two GROUP statements are not needed (may even cause errors). They are already included in the MANDATORY-GROUPS clause ! > -- constrains on IP addressing > OBJECT docsBpi2CmIpMulticastAddressType > -- SYNTAX InetAddressType { ipv4(1) } This comment line should be changed in a real statement: SYNTAX InetAddressType { ipv4(1) } > DESCRIPTION > "An implementation is only required to support IPv4 > addresses." > > -- constrains on IP addressing > OBJECT docsBpi2CmIpMulticastAddress > SYNTAX InetAddress (SIZE(4)) > DESCRIPTION > "An implementation is only required to support IPv4 > addresses." > > ::= { docsBpi2Compliances 1 } > > > docsBpi2CmtsCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "This is the compliance statement for CMTSs which > implement the DOCSIS Baseline Privacy Interface Plus." > > MODULE -- docsBpi2MIB > -- unconditionally mandatory group > MANDATORY-GROUPS { > docsBpi2CmtsGroup > } > > > GROUP docsBpi2CmtsGroup > DESCRIPTION > "This group implementation is required for CMTSs only." > The above GROUP can be removed, it is already included in the MANDATORY-GROUPS clause !! > -- Optional group > GROUP docsBpi2CodeDownloadGroup > DESCRIPTION > "This group is optional for CMTSs." > It would be better to describe under what circumstances this group would/should be used. Or is it completely at the discretion of the implementer? > > -- constrains on Object range > OBJECT docsBpi2CmtsDefaultAuthLifetime > SYNTAX Integer32 (86400..6048000) > DESCRIPTION > "The refined range corresponds to the minimum and maximum > values in operational networks." > > -- constrains on mandatory range > OBJECT docsBpi2CmtsDefaultTEKLifetime > SYNTAX Integer32 (1800..604800) > DESCRIPTION > "The refined range corresponds to the minimum and maximum > values in operational networks." > > -- constrains on mandatory range > OBJECT docsBpi2CmtsAuthCmLifetime > SYNTAX Integer32 (86400..6048000) > DESCRIPTION > "The refined range corresponds to the minimum and maximum > values in operational networks." > > -- constrains on mandatory range > OBJECT docsBpi2CmtsTEKLifetime > SYNTAX Integer32 (1800..604800) > DESCRIPTION > "The refined range corresponds to the minimum and maximum > values in operational networks." > > -- constrains on IP addressing > OBJECT docsBpi2CmtsIpMulticastAddressType > -- SYNTAX InetAddressType { ipv4(1) } This comment line should be changed in a real statement: SYNTAX InetAddressType { ipv4(1) } > DESCRIPTION > "An implementation is only required to support IPv4 > addresses." > > -- constrains on IP addressing > OBJECT docsBpi2CmtsIpMulticastAddress > SYNTAX InetAddress (SIZE(4)) > DESCRIPTION > "An implementation is only required to support IPv4 > addresses." > > -- constrains on IP addressing > OBJECT docsBpi2CmtsIpMulticastMaskType > -- SYNTAX InetAddressType { ipv4(1) } This comment line should be changed in a real statement: SYNTAX InetAddressType { ipv4(1) } > DESCRIPTION > "An implementation is only required to support IPv4 > addresses." > > -- constrains on IP addressing > OBJECT docsBpi2CmtsIpMulticastMask > SYNTAX InetAddress (SIZE(4)) > DESCRIPTION > "An implementation is only required to support IPv4 > addresses." > > ::= { docsBpi2Compliances 2 } > > Hope this helps/explains, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 10:18:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08628 for ; Thu, 24 Jul 2003 10:18:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fguw-0007wX-Le for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 10:18:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OEI2bo030532 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 10:18:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fguv-0007wD-Lo; Thu, 24 Jul 2003 10:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fguN-0007nN-77 for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 10:17:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08608 for ; Thu, 24 Jul 2003 10:17:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fguJ-0006MQ-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 10:17:23 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fgu8-0006M9-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 10:17:12 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6OEFTdS002733; Thu, 24 Jul 2003 08:15: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 Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion Date: Thu, 24 Jul 2003 08:15:29 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion Thread-Index: AcNRufUHZEdrWgIYSbORJvDZBd/V6AAKQhew From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Jean-Francois Mule" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Bert,=20 Thanks for the promply comments,=20 Sorry forgot to remove the comments in the SYNTAX clauses,=20 Will remove the repeated groups in CM and CMTS in both MODULE-COMPLIANCE Will add a note explaining why this is optional=20 Thanks eduardo=20 -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, July 24, 2003 2:02 AM To: Eduardo Cardona; Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; Kazuyoshi.Ozawa@toshiba.co.jp Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on docsBpi2CmtsAuthCmBpiVersion=20 Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 24 juli 2003 1:28 > To: Jean-Francois Mule; Wijnen, Bert (Bert); Ipcdn (E-mail) > Cc: stu.green@arrisi.com; Alexander Katsnelson;=20 > Kazuyoshi.Ozawa@toshiba.co.jp > Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on=20 > docsBpi2CmtsAuthCmBpiVersion >=20 .. snip .. >=20 > About Bert Comments: >=20 > Please make the required comments. >=20 > Below is a proposed two compliance modules > I changed relaxation for constrains > Removed commenst in SYNTAX clauses=20 > Compliances modules Basic keyword removed, expanded to Cm or CMTS >=20 >=20 > docsBpi2CmCompliance MODULE-COMPLIANCE=20 > STATUS current=20 > DESCRIPTION=20 > "This is the compliance statement for CMs which=20 > implement the DOCSIS Baseline Privacy Interface=20 > Plus." > =20 > MODULE -- docsBpi2MIB > =20 > -- unconditionally mandatory group > MANDATORY-GROUPS { > docsBpi2CmGroup, > docsBpi2CodeDownloadGroup > } >=20 > =20 > GROUP docsBpi2CmGroup=20 > DESCRIPTION=20 > "This group implementation is required for CMs only." > =20 > GROUP docsBpi2CodeDownloadGroup=20 > DESCRIPTION=20 > "This group implementation is required for CMs." > =20 The above two GROUP statements are not needed (may even cause errors). They are already included in the MANDATORY-GROUPS clause ! > -- constrains on IP addressing=20 > OBJECT docsBpi2CmIpMulticastAddressType=20 > -- SYNTAX InetAddressType { ipv4(1) } This comment line should be changed in a real statement: SYNTAX InetAddressType { ipv4(1) }=20 > DESCRIPTION=20 > "An implementation is only required to support IPv4=20 > addresses." > =20 > -- constrains on IP addressing=20 > OBJECT docsBpi2CmIpMulticastAddress=20 > SYNTAX InetAddress (SIZE(4))=20 > DESCRIPTION=20 > "An implementation is only required to support IPv4=20 > addresses." > =20 > ::=3D { docsBpi2Compliances 1 } >=20 >=20 > docsBpi2CmtsCompliance MODULE-COMPLIANCE=20 > STATUS current=20 > DESCRIPTION=20 > "This is the compliance statement for CMTSs which=20 > implement the DOCSIS Baseline Privacy Interface=20 > Plus." > =20 > MODULE -- docsBpi2MIB=20 > -- unconditionally mandatory group > MANDATORY-GROUPS { > docsBpi2CmtsGroup > } > =20 >=20 > GROUP docsBpi2CmtsGroup=20 > DESCRIPTION=20 > "This group implementation is required for CMTSs only." > =20 The above GROUP can be removed, it is already included in the MANDATORY-GROUPS clause !! > -- Optional group=20 > GROUP docsBpi2CodeDownloadGroup=20 > DESCRIPTION=20 > "This group is optional for CMTSs." > =20 It would be better to describe under what circumstances this group would/should be used. Or is it completely at the discretion of the implementer? > =20 > -- constrains on Object range=20 > OBJECT docsBpi2CmtsDefaultAuthLifetime=20 > SYNTAX Integer32 (86400..6048000)=20 > DESCRIPTION=20 > "The refined range corresponds to the minimum and maximum=20 > values in operational networks." > =20 > -- constrains on mandatory range=20 > OBJECT docsBpi2CmtsDefaultTEKLifetime=20 > SYNTAX Integer32 (1800..604800)=20 > DESCRIPTION=20 > "The refined range corresponds to the minimum and maximum=20 > values in operational networks." > =20 > -- constrains on mandatory range=20 > OBJECT docsBpi2CmtsAuthCmLifetime=20 > SYNTAX Integer32 (86400..6048000)=20 > DESCRIPTION=20 > "The refined range corresponds to the minimum and maximum=20 > values in operational networks." > =20 > -- constrains on mandatory range=20 > OBJECT docsBpi2CmtsTEKLifetime=20 > SYNTAX Integer32 (1800..604800)=20 > DESCRIPTION=20 > "The refined range corresponds to the minimum and maximum=20 > values in operational networks." > =20 > -- constrains on IP addressing=20 > OBJECT docsBpi2CmtsIpMulticastAddressType=20 > -- SYNTAX InetAddressType { ipv4(1) } This comment line should be changed in a real statement: SYNTAX InetAddressType { ipv4(1) }=20 > DESCRIPTION=20 > "An implementation is only required to support IPv4=20 > addresses." > =20 > -- constrains on IP addressing=20 > OBJECT docsBpi2CmtsIpMulticastAddress=20 > SYNTAX InetAddress (SIZE(4))=20 > DESCRIPTION=20 > "An implementation is only required to support IPv4=20 > addresses." > =20 > -- constrains on IP addressing=20 > OBJECT docsBpi2CmtsIpMulticastMaskType=20 > -- SYNTAX InetAddressType { ipv4(1) } This comment line should be changed in a real statement: SYNTAX InetAddressType { ipv4(1) }=20 > DESCRIPTION=20 > "An implementation is only required to support IPv4=20 > addresses." > =20 > -- constrains on IP addressing=20 > OBJECT docsBpi2CmtsIpMulticastMask=20 > SYNTAX InetAddress (SIZE(4))=20 > DESCRIPTION=20 > "An implementation is only required to support IPv4=20 > addresses." > =20 > ::=3D { docsBpi2Compliances 2 } >=20 >=20 Hope this helps/explains, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 13:42:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17573 for ; Thu, 24 Jul 2003 13:42:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk6O-0002Kl-LZ for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 13:42:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OHg4DY008965 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 13:42:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk6L-0002KQ-TN; Thu, 24 Jul 2003 13:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fk68-0002K8-3O for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 13:41:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17471 for ; Thu, 24 Jul 2003 13:41:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fk65-0000II-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 13:41:45 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fk5u-0000Hw-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 13:41:34 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6OHeLdS014001; Thu, 24 Jul 2003 11:40:22 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Thu, 24 Jul 2003 11:40:21 -0600 Message-ID: Thread-Topic: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Thread-Index: AcNP25d5jllppQWtS3idhdd7HuqawwCKIXGA From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Jean-Francois Mule" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable >In fact, looking at this, it seems a weird structure of the OID tree. >So you better decide what you want or how to clean it up if that is >what you want. Maybe we discussed this 5 months ago and I forgot. >Maybe it is indeed best to put this one under mib-2 Bert,=20 We Would like to get your advise in this topic and I am extending some generalization: The DOCSIS Interface suite of mibs were initialy visualized as : Mib-2 branch Device mibs RFC 2669 ( eventually SubMgmt also)=20 Mib-2.transmission.docsIfMib(127) branch: Extension of CATV Interface (ifType=3D127) for Phy/MAC layer requirements like bpi, bpiplus, = docsQos,=20 Is that still a valid approach for the submitted drafs or mib-2 branch will be the structure wise required tree? Is there any other OID holder based on functionality schema? ( security/ Qos ) ?=20 The intention of that was corroborated ( I presume that ) with the assignemt of bpi mib RFC 3083 under docsIfMib 5=20 We definitely will do what IETF and IANA wanted to keep organized the OID trees, but a better understanding of IETF desire will be really valuable. And the drafts could be the places to keep those trends requirements among IETF, IPCDN and IANA. A look of your oid mapping:=20 docsIfMib 1 - RFC2670 mib objects docsIfMib 2 - RFC2670 notifications docsIfMib 3 - RFC2670 conformance=20 docsIfMib 5 - RFC3083 bpi objects/notifications/conformance The current drafts (implemented in the field showed in parantesis): -> prior to InetAddress RFC 2851/3291 docsIfMib 6 - bpiplus (draft 05) objects/notifications/conformance docsIfMib 7 - docsQos (draft 04) objects/notifications/conformance Keeping the legacy structure: (legacy "weird structure") new proposed drafts for RFC docsIfMib 8 - IETF bpiplus RFC objects/notifications/conformance docsIfMib 9 - IETF docsQos RFC objects/notifications/conformance=20 Thinking in IETF-MODULE styles What would be the organized structure? Mib-2 or transmission Hierachy related ifmib, bpiplus docsqos? How IETF really wants to organize the trees? If Mib-2 for bpiplus and qos, any particular subtrees of mib-2 Or transmission sub-tree: How does IETF docsIfMib play as an umbrella for bpiplus and docsQos or any DOCSIS related interface mib Will that define a path requiring IETF docsIfMib to be IESG approved before bpiplus/docsQos ? Supposed in transmission branch transmission... (128 is also a docsis ifType not as good option as 127 but that one is already covered by rfc2670 One option: Transmission 128 - docsIfIETF ? ( to say any number? ) docsIfIETF 1 docsIfMib new RFC (objects/notifications/conformance) docsIfIETF 2 bpiplus new RFC (objects/notifications/conformance) docsIfIETF 3 docsQos new RFC (objects/notifications/conformance) Thanks Eduardo =20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 13:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18654 for ; Thu, 24 Jul 2003 13:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkJu-0002zY-0w for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 13:56:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OHu1DP011491 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 13:56:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkJt-0002zC-NS; Thu, 24 Jul 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fkIu-0002yM-Os for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 13:55:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18525 for ; Thu, 24 Jul 2003 13:54:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fkIs-0000UI-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 13:54:58 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fkIh-0000Tr-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 13:54:47 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6OHsAdS014845; Thu, 24 Jul 2003 11:54:10 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Jul 2003 11:54:10 -0600 Message-ID: Thread-Topic: draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Thread-Index: AcNRufUHZEdrWgIYSbORJvDZBd/V6AAPbRsQ From: "Eduardo Cardona" To: "Ipcdn (E-mail)" , "Eduardo Cardona" , "DOCSIS Sec Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi all, A very similar email was circulated this morning in the ipcdn group. I am posting the SEC reflector to hear opinions. Thanks Eduardo The ipcdn group is doing the last updates in BPI plus mib to get the draft to the Last Call status and then request and RFc number. One of the remaining issues is related to enumerations starting in zero. It is not recommended (nor invalid) to have named-values as '0' but the intention is to have the mib very clean in that respect. The objects with SA-Type attribute related are docsBpi2CmTEKSAType, docsBpi2CmtsTEKSAType and docsBpi2CmtsIpMulticastSAType. Issues:=20 enumeration '0' value conflict=20 Vendor-specific representation The SA-Type allocates for Vendor-Reserved SA-Type the range 128-255 is not posible to represent any vendor-reserved SA-Type under the current mib syntax As I am aware, other than primary, static, dynamic, I do not believe a vendor ever will define a new type=20 Will that be a correct assumption?=20 Even though in such case a generic type vendorSpecific(255) would be enough to represent that. The final enumeration will be (*):=20 none(0), primary(1) static(2) dynamic(3)=20 vendorSpecific(255) Still it does not match the BPKM SA-Type Attibute list indexes which is=20 primary - 0 static - 1 dynamic - 2 reserved - 3-128 vendor-specific - 128-255 The truly matching BPKM-mib enumeration would be : (**) primary(0) static(1) dynamic(2)=20 vendorSpecific(255) none(256) An intermedia solution (***) primary(1) static(2) dynamic(3)=20 vendorSpecific(255) none(256) Current BPI implementations under draft 05 uses (*) + vendorSpecific(255) (**) make a shift in all the values - backward compatible problems in mibs (***) Would be the least intrusive one, keep the values of primary, static and dynamic and moves none to 256, Eiher case (*) (**) or (***) 'none' is a temprarly value while the SA is Authorized/configured.=20 If (***) is considered the best, I am suggesting a Textual convention to explain the values rationale due the conflict of values with the BPKM protocol as explained above. ( other options may need only to change quickly the TEXTUAL-CONVENTION=20 Again It will apply to=20 docsBpi2CmtsIpMulticastSAType docsBpi2CmTEKSAType docsBpi2CmtsTEKSAType Note: moved to TEXTUAL-CONVENTION "The none(0) encoding must only be used if the SA=20 type has yet to be determined." =20 =20 DocsBpkmSAType ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. The values of the named-numbers are=20 associated with the BPKM SA-Type attributes: =20 'primary' corresponds to code '0', 'static' to code '1' 'dynamic' to code '2'. 'vendorSpecific' value represents any value in the=20 SA-Type attribute range 128 to 255. if used, it is=20 recomended the vendor extends the information about the security association enterprise branch. 'none' value must only be used if the SA type has=20 yet to be determined. =20 "=20 REFERENCE "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 4.2.2.24" SYNTAX INTEGER { primary(1), static(2), dynamic(3), vendorSpecific(255), none(256) }=20 Objects updates: DocsBpi2CmTEKEntry ::=3D SEQUENCE {=20 docsBpi2CmTEKSAId Unsigned32,=20 docsBpi2CmTEKSAType DocsBpkmSAType, =20 =20 docsBpi2CmTEKSAType OBJECT-TYPE=20 SYNTAX DocsBpkmSAType MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association."=20 REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 2.1.3."=20 ::=3D { docsBpi2CmTEKEntry 2 }=20 =20 DocsBpi2CmtsTEKEntry ::=3D SEQUENCE {=20 docsBpi2CmtsTEKSAId Unsigned32,=20 docsBpi2CmtsTEKSAType DocsBpkmSAType,=20 =20 docsBpi2CmtsTEKSAType OBJECT-TYPE=20 SYNTAX DocsBpkmSAType=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. 'dynamic' does not apply to CMs running in=20 BPI mode. Unicast BPI TEKs must utilize the 'primary' =20 encoding and multicast BPI TEKs must utilize the 'static' =20 encoding."=20 REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 2.1.3."=20 ::=3D { docsBpi2CmtsTEKEntry 2 }=20 DocsBpi2CmtsIpMulticastMapEntry ::=3D SEQUENCE {=20 docsBpi2CmtsIpMulticastIndex Unsigned32,=20 docsBpi2CmtsIpMulticastAddressType InetAddressType,=20 docsBpi2CmtsIpMulticastAddress InetAddress,=20 docsBpi2CmtsIpMulticastMaskType InetAddressType,=20 docsBpi2CmtsIpMulticastMask InetAddress,=20 docsBpi2CmtsIpMulticastSAId Integer32,=20 docsBpi2CmtsIpMulticastSAType DocsBpkmSAType,=20 docsBpi2CmtsIpMulticastSAType OBJECT-TYPE=20 SYNTAX DocsBpkmSAType MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. 'dynamic' doess not apply to CMs running in=20 BPI mode. Unicast BPI TEKs must utilize the 'primary' =20 encoding and multicast BPI TEKs must utilize the 'static'=20 encoding."=20 REFERENCE=20 "DOCSIS Baseline Privacy Plus Interface Specification,=20 Section 2.1.3."=20 ::=3D { docsBpi2CmtsIpMulticastMapEntry 7 }=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 16:49:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29925 for ; Thu, 24 Jul 2003 16:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fn1L-0004iO-EL for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 16:49:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OKn3Ma018121 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 16:49:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fn1J-0004i6-Ey; Thu, 24 Jul 2003 16:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fn0y-0004hc-Ny for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 16:48:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29919 for ; Thu, 24 Jul 2003 16:48:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fn0w-00028j-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 16:48:38 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19fn0l-00027d-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 16:48:27 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6OKlnA11689 for ; Thu, 24 Jul 2003 15:47:49 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 22:47:47 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B813@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Ipcdn (E-mail)" , DOCSIS Sec Majordomo List Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Ob jects Date: Thu, 24 Jul 2003 22:47:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 24 juli 2003 19:54 > To: Ipcdn (E-mail); Eduardo Cardona; DOCSIS Sec Majordomo List > Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType > Objects > > > Hi all, > A very similar email was circulated this morning in the ipcdn group. I > am posting the SEC reflector to hear opinions. > Thanks > Eduardo > > The ipcdn group is doing the last updates in BPI plus mib to get the > draft to the Last Call status and then request and RFc number. > > One of the remaining issues is related to enumerations starting in zero. > It is not recommended (nor invalid) to have named-values as '0' but the > intention is to have the mib very clean in that respect. > Let me explain (again) why we (MIB-doctors) prefer (so we do not mandate) that enumerations start at 1 instead of zero. The reason is that many programs are written such that memory allocation for variables results in an initial value of zero in such a field. So we have seen errors in implementations where someone just used a non-initized field that conatined zeroes and so the resulting response to a GET request was/is the zero value. That said, if there are good reasons to start at zero... as I think you explain below, then that is OK. See more below > The objects with SA-Type attribute related are docsBpi2CmTEKSAType, > docsBpi2CmtsTEKSAType and docsBpi2CmtsIpMulticastSAType. > Issues: > enumeration '0' value conflict > Vendor-specific representation > > The SA-Type allocates for Vendor-Reserved SA-Type the range 128-255 > is not posible to represent any vendor-reserved SA-Type under the > current mib syntax > > As I am aware, other than primary, static, dynamic, I do not believe a > vendor ever will define a new type > Will that be a correct assumption? > > Even though in such case a generic type vendorSpecific(255) would be > enough to represent that. The final enumeration will be (*): > none(0), > primary(1) > static(2) > dynamic(3) > vendorSpecific(255) > > Still it does not match the BPKM SA-Type Attibute list > indexes which is > primary - 0 > static - 1 > dynamic - 2 > reserved - 3-128 > vendor-specific - 128-255 > Seems that value 128 can mean two things ?? Is it maybe the following? > reserved - 3-127 > vendor-specific - 128-255 The range for "vendor-specific" kind of makes me thing that you should NOT use an enumeration. However, if you do not believe that such are ever used then using a single value might be defendable. > The truly matching BPKM-mib enumeration would be : > (**) > primary(0) > static(1) > dynamic(2) > vendorSpecific(255) > none(256) > And so, if that indeed matches up with the SPEC, then that seems the best assignment to make. In the DESCRIPTION clause explain that this matches up with the other spec. Potentially add a REFERENCE clause that points to that spec with which we want to be in sync. Maybe, one could/should add another column, docsBpi2CmTEKSAVendorSpecificType .. SYNTAX Integer32 (128..255) And then indicate that if docsBpi2CmTEKSAType has a value of 255, that that means that this docsBpi2CmTEKSAVendorSpecificType column contains the vendor specific value, and that the meaning of the values of that ..VendorSpecificType are depending on the specific vendor. > An intermedia solution (***) > primary(1) > static(2) > dynamic(3) > vendorSpecific(255) > none(256) > > Current BPI implementations under draft 05 uses (*) + > vendorSpecific(255) > (**) make a shift in all the values - backward compatible problems in > mibs > (***) Would be the least intrusive one, keep the values of primary, > static and dynamic and moves none to 256, > > Eiher case (*) (**) or (***) 'none' is a temprarly value > while the SA is > Authorized/configured. > So I'd suggest to use my modified (**) above. Bert > > If (***) is considered the best, I am suggesting a Textual > convention to > explain the values rationale due the conflict of values with the BPKM > protocol as explained above. ( other options may need only to change > quickly the TEXTUAL-CONVENTION > Again It will apply to > docsBpi2CmtsIpMulticastSAType > docsBpi2CmTEKSAType > docsBpi2CmtsTEKSAType > > Note: moved to TEXTUAL-CONVENTION > "The none(0) encoding must only be used if the SA > type has yet to be determined." > > > DocsBpkmSAType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "The value of this object is the type of security > association. The values of the named-numbers are > associated with the BPKM SA-Type attributes: > 'primary' corresponds to code '0', 'static' > to code '1' > 'dynamic' to code '2'. > 'vendorSpecific' value represents any value in the > SA-Type attribute range 128 to 255. if used, it is > recomended the vendor extends the > information about the > > security association enterprise branch. > 'none' value must only be used if the SA type has > yet to be determined. > " > REFERENCE > "DOCSIS Baseline Privacy Plus Interface > Specification, > Section 4.2.2.24" > SYNTAX INTEGER { > primary(1), > static(2), > dynamic(3), > vendorSpecific(255), > none(256) > } > > Objects updates: > DocsBpi2CmTEKEntry ::= SEQUENCE { > docsBpi2CmTEKSAId Unsigned32, > docsBpi2CmTEKSAType DocsBpkmSAType, > > > docsBpi2CmTEKSAType OBJECT-TYPE > SYNTAX DocsBpkmSAType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the type of security > association." > REFERENCE > "DOCSIS Baseline Privacy Plus Interface > Specification, > Section 2.1.3." > ::= { docsBpi2CmTEKEntry 2 } > > DocsBpi2CmtsTEKEntry ::= SEQUENCE { > docsBpi2CmtsTEKSAId Unsigned32, > docsBpi2CmtsTEKSAType DocsBpkmSAType, > > docsBpi2CmtsTEKSAType OBJECT-TYPE > SYNTAX DocsBpkmSAType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of this object is the type of security > association. 'dynamic' does not apply to CMs running in > BPI mode. Unicast BPI TEKs must utilize the 'primary' > encoding and multicast BPI TEKs must utilize the > 'static' > encoding." > REFERENCE > "DOCSIS Baseline Privacy Plus Interface > Specification, > Section 2.1.3." > ::= { docsBpi2CmtsTEKEntry 2 } > > DocsBpi2CmtsIpMulticastMapEntry ::= SEQUENCE { > docsBpi2CmtsIpMulticastIndex Unsigned32, > docsBpi2CmtsIpMulticastAddressType InetAddressType, > docsBpi2CmtsIpMulticastAddress InetAddress, > docsBpi2CmtsIpMulticastMaskType InetAddressType, > docsBpi2CmtsIpMulticastMask InetAddress, > docsBpi2CmtsIpMulticastSAId Integer32, > docsBpi2CmtsIpMulticastSAType DocsBpkmSAType, > > docsBpi2CmtsIpMulticastSAType OBJECT-TYPE > SYNTAX DocsBpkmSAType > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The value of this object is the type of security > association. 'dynamic' doess not apply to CMs running in > BPI mode. Unicast BPI TEKs must utilize the 'primary' > encoding and multicast BPI TEKs must utilize the 'static' > encoding." > REFERENCE > "DOCSIS Baseline Privacy Plus Interface > Specification, > Section 2.1.3." > ::= { docsBpi2CmtsIpMulticastMapEntry 7 } > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 17:29:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01859 for ; Thu, 24 Jul 2003 17:29:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fne1-0007Ol-NI for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 17:29:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OLT1dr028431 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 17:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fne0-0007OI-Ry; Thu, 24 Jul 2003 17:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fnd9-0007Kc-3K for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 17:28:07 -0400 Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01744 for ; Thu, 24 Jul 2003 17:28:01 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h6OLQVA00515 for ; Thu, 24 Jul 2003 16:26:32 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jul 2003 23:26:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550213B815@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eduardo Cardona , "Wijnen, Bert (Bert)" , Jean-Francois Mule , "Ipcdn (E-mail)" Cc: stu.green@arrisi.com, Alexander Katsnelson , k.ozawa@CableLabs.com Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Thu, 24 Jul 2003 23:26:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 24 juli 2003 19:40 > To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail) > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@CableLabs.com > Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 > > > >In fact, looking at this, it seems a weird structure of the OID tree. > >So you better decide what you want or how to clean it up if that is > >what you want. Maybe we discussed this 5 months ago and I forgot. > >Maybe it is indeed best to put this one under mib-2 > > Bert, > We Would like to get your advise in this topic and I am extending some > generalization: > > The DOCSIS Interface suite of mibs were initialy visualized as : > > Mib-2 branch Device mibs RFC 2669 ( eventually SubMgmt also) > That seemed (and still seems) to make sense. > Mib-2.transmission.docsIfMib(127) branch: Extension of CATV Interface > (ifType=127) for Phy/MAC layer requirements like bpi, > bpiplus, docsQos, > So I can see that transmission.127 makes sense for the RFC2670 MIB. Seems that BPI, BPIPLUS are also strongly related to a MAC interface, so probably assigning them underneath docsIfMib is OK. For the QOS MIB module I am not so sure. Seems to me that that should go under mib-2, similar to how DIFFSERV-MIB went under mib-2. > Is that still a valid approach for the submitted drafs or mib-2 branch > will be the structure wise required tree? See above... they need to go where we think they make sense logically. What I possibly would have done is something aka: Mib-2.transmission.docsis(127) -- generic OID branch for DOCSIS interface -- objects docsis.docsIfMib(1) -- docsIfMib docsIfMib.docsIfMibObjects(1) -- OID branches within docsIfMib docsis.docsBpiMib(2) -- docsBpiMib docsis.docsBpiPlusMib(3) -- docsBpiPlusMib In other words, I would have used one branch under which I would put the MIB modules, and then within each MIB module I would have made anotehr level for Objects, Notifications, Compliances etc. You have now intermixed all that and that has made it a bit of a mess (at least in my eyes). But we cannot fix that anymore. Or if we do, then it comes with a lot of pain I suppose. > Is there any other OID holder based on functionality schema? > ( security/Qos ) ? > The intention of that was corroborated ( I presume that ) with the > assignemt of bpi mib RFC 3083 under docsIfMib 5 > > We definitely will do what IETF and IANA wanted to keep organized the > OID trees, but a better understanding of IETF desire will be really > valuable. And the drafts could be the places to keep those trends > requirements among IETF, IPCDN and IANA. > Within One MIB module, people can assign in the DRAFT docs itself. You normally have something aka: someModuleMib MODULE-IDENTITY ... ::= { root-oid xx } -- xx to be assigned by IANA Within root-oid.xx you can then assign your own structure This will help in the sense that you only get xx assigned once the ID gets published as an RFC. And that is the time that people can actually use the OID that gets assigned, not anytime earlier while you are still developing the draft. > A look of your oid mapping: > > docsIfMib 1 - RFC2670 mib objects > docsIfMib 2 - RFC2670 notifications > docsIfMib 3 - RFC2670 conformance > docsIfMib 5 - RFC3083 bpi objects/notifications/conformance > > The current drafts (implemented in the field showed in parantesis): -> > prior to InetAddress RFC 2851/3291 > docsIfMib 6 - bpiplus (draft 05) objects/notifications/conformance > docsIfMib 7 - docsQos (draft 04) objects/notifications/conformance > This is REALLY BAD. Peopl should NOT and NEVER implement I-Ds and then use OIDs from the IANA maintained/controlled OID space) for the MIB modules that are not yet published as RFC. Vendors could have put them under their enterprise OID tree, or maybe under some experimental OID tree if you had asked for one. > Keeping the legacy structure: (legacy "weird structure") new proposed > drafts for RFC > docsIfMib 8 - IETF bpiplus RFC objects/notifications/conformance > docsIfMib 9 - IETF docsQos RFC objects/notifications/conformance > So if we do this, then the customers may end up with the same objects but under two different OID trees? That sounds like BAD for the customers, does it not? What a mess! > > Thinking in IETF-MODULE styles > > > What would be the organized structure? > Mib-2 or transmission Hierachy related ifmib, bpiplus docsqos? > How IETF really wants to organize the trees? > If Mib-2 for bpiplus and qos, any particular subtrees of mib-2 > > Or transmission sub-tree: > > How does IETF docsIfMib play as an umbrella for bpiplus and > docsQos or > any DOCSIS related interface mib > > Will that define a path requiring IETF docsIfMib to be IESG approved > before bpiplus/docsQos ? > Supposed in transmission branch transmission... (128 is also a docsis > ifType not as good option as 127 but that one is already covered by > rfc2670 > > One option: > > Transmission 128 - docsIfIETF ? ( to say any number? ) > docsIfIETF 1 docsIfMib new RFC (objects/notifications/conformance) > docsIfIETF 2 bpiplus new RFC (objects/notifications/conformance) > docsIfIETF 3 docsQos new RFC (objects/notifications/conformance) > Will you also rename your object descriptors? How are people going to know the difference between current docsIfDownstreamChannelTable and the docsIfDownstreamChannelTable once it gets re-rooted under docsIfIETF ?? See... what is biting you here is the rules of how you can change and update non-published (I-Ds) and existing published (as RFCs) MIB modules. You may want to read about that in the RFC2578/79/80 RFCs. Hope this helps. I need to think about a solution. Maybe we need to chat about that some more. Bert > > Thanks > > Eduardo > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 24 20:20:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06675 for ; Thu, 24 Jul 2003 20:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqJW-0006M8-2X for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 20:20:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P0K2dM024433 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 20:20:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqJV-0006Ls-3d; Thu, 24 Jul 2003 20:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqJD-0006LK-25 for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 20:19:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06672 for ; Thu, 24 Jul 2003 20:18:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fqIO-0003Mh-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 20:18:52 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fqID-0003MQ-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 20:18:41 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6P0HQdS004836; Thu, 24 Jul 2003 18:17:27 -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-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Date: Thu, 24 Jul 2003 18:17:26 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Thread-Index: AcNSJNv/Mn4tMtNUR2Skvz/yudvxlgAEkBpg From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , "DOCSIS Sec Majordomo List" , "DOCSIS Sec Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Bert Thanks for the comments See more inline notes -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, July 24, 2003 2:48 PM To: Eduardo Cardona; Ipcdn (E-mail); DOCSIS Sec Majordomo List Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 24 juli 2003 19:54 > To: Ipcdn (E-mail); Eduardo Cardona; DOCSIS Sec Majordomo List > Subject: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType=20 > Objects >=20 >=20 > Hi all, > A very similar email was circulated this morning in the ipcdn group. I > am posting the SEC reflector to hear opinions. Thanks > Eduardo >=20 > The ipcdn group is doing the last updates in BPI plus mib to get the=20 > draft to the Last Call status and then request and RFc number. >=20 > One of the remaining issues is related to enumerations starting in=20 > zero. It is not recommended (nor invalid) to have named-values as '0' > but the intention is to have the mib very clean in that respect. >=20 Let me explain (again) why we (MIB-doctors) prefer (so we do not mandate) that enumerations start at 1 instead of zero. The reason is that many programs are written such that memory allocation for variables results in an initial value of zero in such a field. So we have seen errors in implementations where someone just used a non-initized field that conatined zeroes and so the resulting response to a GET request was/is the zero value.=20 That said, if there are good reasons to start at zero... as I think you explain below, then that is OK. See more below > The objects with SA-Type attribute related are docsBpi2CmTEKSAType,=20 > docsBpi2CmtsTEKSAType and docsBpi2CmtsIpMulticastSAType. > Issues: > enumeration '0' value conflict=20 > Vendor-specific representation >=20 > The SA-Type allocates for Vendor-Reserved SA-Type the range 128-255 is > not posible to represent any vendor-reserved SA-Type under the current > mib syntax >=20 > As I am aware, other than primary, static, dynamic, I do not believe a > vendor ever will define a new type Will that be a correct assumption? >=20 > Even though in such case a generic type vendorSpecific(255) would be=20 > enough to represent that. The final enumeration will be (*): none(0), > primary(1) > static(2) > dynamic(3)=20 > vendorSpecific(255) >=20 > Still it does not match the BPKM SA-Type Attibute list > indexes which is=20 > primary - 0 > static - 1 > dynamic - 2 > reserved - 3-128 > vendor-specific - 128-255 >=20 Seems that value 128 can mean two things ?? Is it maybe the following? > reserved - 3-127 > vendor-specific - 128-255 The range for "vendor-specific" kind of makes me thing that you should NOT use an enumeration. However, if you do not believe that such are ever used then using a single value might be=20 defendable. =20 It is very unlikely that with the current BPI protocol implementation a vendor decide to define another SA Type The protocol is extensible but I (we) believe is unrealistic that it will happen, someone in the OSS/SEC can point if I am wrong and such SA-Types does/will exist. > The truly matching BPKM-mib enumeration would be : > (**) > primary(0) > static(1) > dynamic(2) > vendorSpecific(255) > none(256) >=20 And so, if that indeed matches up with the SPEC, then that seems the best assignment to make. In the DESCRIPTION clause explain that this matches up with the other spec. Potentially add a REFERENCE clause that points to that spec with which we=20 want to be in sync. Maybe, one could/should add another column,=20 docsBpi2CmTEKSAVendorSpecificType .. SYNTAX Integer32 (128..255) =20 And then indicate that if docsBpi2CmTEKSAType has a value of 255, that that means that this docsBpi2CmTEKSAVendorSpecificType column contains the vendor specific value, and that the meaning of the values of that ..VendorSpecificType are depending on the specific vendor. =20 That's true, ( that's why (**) is presented as an option with a '0' justified) unfortunately there are many many boxes in the field with the current enumeration (I know, and unfortunately does not match the protocol) "primary(1), static(2), dynamic(3)" instead of the ideal "primary(0), static(1), dynamic(2)" In my proposed TEXTUAL-CONVENTION we cab switch (***) to (**), etc ... That's means changes in the logic of the current DOCSIS managements applications and not being backward compatible with the current implementations,=20 For the broad audience, Do we want/need the Patched mib or should we go for the clean one (**), MSO input would be appreciated.=20 Option (***) and the description in the TEXTUAL-CONVENTION is trying to : (due a legacy crossed values), That's a PATCH no discussion...=20 To indicate primary(1) -> SA-TYPE =3D0 static(2) -> SA-TYPE =3D1 dynamic(3) -> SA-TYPE =3D2 vendorSpecific(255) -> SA-TYPE 128-255 none(256) -> SA-Type Not known yet Thinking more I won't complain the Mib authors for the initial none(0) selection in (*) because it matches exactly your description of value '0' as an implementation problem. The process is as follow: An entry is created for an SA and after authorization/configuration, the SAType is known and the SAType object si assigned to 1/2/3. =20 > An intermedia solution (***) > primary(1) > static(2) > dynamic(3) > vendorSpecific(255) > none(256) >=20 > Current BPI implementations under draft 05 uses (*) + > vendorSpecific(255) > (**) make a shift in all the values - backward compatible problems in=20 > mibs > (***) Would be the least intrusive one, keep the values of primary,=20 > static and dynamic and moves none to 256, >=20 > Eiher case (*) (**) or (***) 'none' is a temprarly value > while the SA is > Authorized/configured.=20 >=20 So I'd suggest to use my modified (**) above. Not a problem, docsBpi2CmTEKSAVendorSpecificType may not provide enough information since two different implementer may assign value 128 to their vendor-SA-Type with different meaning. And as explained above the likehood of this case is very remote, I am not sure if will make sense, and leave that as extensions/augments in the vendor enterprise subtree =20 =20 Bert >=20 > If (***) is considered the best, I am suggesting a Textual > convention to > explain the values rationale due the conflict of values with the BPKM > protocol as explained above. ( other options may need only to change > quickly the TEXTUAL-CONVENTION=20 > Again It will apply to=20 > docsBpi2CmtsIpMulticastSAType > docsBpi2CmTEKSAType > docsBpi2CmtsTEKSAType >=20 > Note: moved to TEXTUAL-CONVENTION > "The none(0) encoding must only be used if the SA=20 > type has yet to be determined." > =20 > =20 > DocsBpkmSAType ::=3D TEXTUAL-CONVENTION=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the type of security=20 > association. The values of the named-numbers are=20 > associated with the BPKM SA-Type attributes: =20 > 'primary' corresponds to code '0', 'static' > to code '1' > 'dynamic' to code '2'. > 'vendorSpecific' value represents any value in the=20 > SA-Type attribute range 128 to 255. if used, it is=20 > recomended the vendor extends the=20 > information about the >=20 > security association enterprise branch. > 'none' value must only be used if the SA type has=20 > yet to be determined. =20 > "=20 > REFERENCE > "DOCSIS Baseline Privacy Plus Interface > Specification,=20 > Section 4.2.2.24" > SYNTAX INTEGER { > primary(1), > static(2), > dynamic(3), > vendorSpecific(255), > none(256) > }=20 >=20 > Objects updates: > DocsBpi2CmTEKEntry ::=3D SEQUENCE {=20 > docsBpi2CmTEKSAId Unsigned32,=20 > docsBpi2CmTEKSAType DocsBpkmSAType, > =20 > =20 > docsBpi2CmTEKSAType OBJECT-TYPE=20 > SYNTAX DocsBpkmSAType > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the type of security=20 > association."=20 > REFERENCE=20 > "DOCSIS Baseline Privacy Plus Interface > Specification,=20 > Section 2.1.3."=20 > ::=3D { docsBpi2CmTEKEntry 2 }=20 > =20 > DocsBpi2CmtsTEKEntry ::=3D SEQUENCE {=20 > docsBpi2CmtsTEKSAId Unsigned32,=20 > docsBpi2CmtsTEKSAType DocsBpkmSAType,=20 > =20 > docsBpi2CmtsTEKSAType OBJECT-TYPE=20 > SYNTAX DocsBpkmSAType=20 > MAX-ACCESS read-only=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the type of security=20 > association. 'dynamic' does not apply to CMs running in=20 > BPI mode. Unicast BPI TEKs must utilize the 'primary' =20 > encoding and multicast BPI TEKs must utilize the > 'static' =20 > encoding."=20 > REFERENCE=20 > "DOCSIS Baseline Privacy Plus Interface=20 > Specification,=20 > Section 2.1.3."=20 > ::=3D { docsBpi2CmtsTEKEntry 2 }=20 >=20 > DocsBpi2CmtsIpMulticastMapEntry ::=3D SEQUENCE {=20 > docsBpi2CmtsIpMulticastIndex Unsigned32,=20 > docsBpi2CmtsIpMulticastAddressType InetAddressType,=20 > docsBpi2CmtsIpMulticastAddress InetAddress,=20 > docsBpi2CmtsIpMulticastMaskType InetAddressType,=20 > docsBpi2CmtsIpMulticastMask InetAddress,=20 > docsBpi2CmtsIpMulticastSAId Integer32,=20 > docsBpi2CmtsIpMulticastSAType DocsBpkmSAType,=20 >=20 > docsBpi2CmtsIpMulticastSAType OBJECT-TYPE=20 > SYNTAX DocsBpkmSAType > MAX-ACCESS read-create=20 > STATUS current=20 > DESCRIPTION=20 > "The value of this object is the type of security=20 > association. 'dynamic' doess not apply to CMs running in=20 > BPI mode. Unicast BPI TEKs must utilize the 'primary' =20 > encoding and multicast BPI TEKs must utilize the 'static'=20 > encoding."=20 > REFERENCE=20 > "DOCSIS Baseline Privacy Plus Interface > Specification,=20 > Section 2.1.3."=20 > ::=3D { docsBpi2CmtsIpMulticastMapEntry 7 }=20 >=20 >=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 From exim@www1.ietf.org Thu Jul 24 21:01:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07374 for ; Thu, 24 Jul 2003 21:01:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqxB-0007ij-T7 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 21:01:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1112Z029671 for ipcdn-archive@odin.ietf.org; Thu, 24 Jul 2003 21:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqxB-0007i3-7g; Thu, 24 Jul 2003 21:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fqwd-0007gv-Ok for ipcdn@optimus.ietf.org; Thu, 24 Jul 2003 21:00:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07336 for ; Thu, 24 Jul 2003 21:00:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fqwb-0003ZC-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 21:00:25 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19fqwQ-0003Yc-00 for ipcdn@ietf.org; Thu, 24 Jul 2003 21:00:14 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6P0xbdS006466; Thu, 24 Jul 2003 18:59:37 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Date: Thu, 24 Jul 2003 18:59:36 -0600 Message-ID: Thread-Topic: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Thread-Index: AcNSKkQXPB165PWRQMWL9dF5jm4RewAF/oqw From: "Eduardo Cardona" To: "Wijnen, Bert (Bert)" , "Jean-Francois Mule" , "Ipcdn (E-mail)" Cc: , "Alexander Katsnelson" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable See comments inline -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]=20 Sent: Thursday, July 24, 2003 3:26 PM To: Eduardo Cardona; Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail) Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@CableLabs.com Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 Inline > -----Original Message----- > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > Sent: donderdag 24 juli 2003 19:40 > To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail) > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@CableLabs.com > Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 >=20 >=20 > >In fact, looking at this, it seems a weird structure of the OID tree. > >So you better decide what you want or how to clean it up if that is=20 > >what you want. Maybe we discussed this 5 months ago and I forgot.=20 > >Maybe it is indeed best to put this one under mib-2 >=20 > Bert, > We Would like to get your advise in this topic and I am extending some > generalization: >=20 > The DOCSIS Interface suite of mibs were initialy visualized as : >=20 > Mib-2 branch Device mibs RFC 2669 ( eventually SubMgmt also) >=20 That seemed (and still seems) to make sense. > Mib-2.transmission.docsIfMib(127) branch: Extension of CATV Interface > (ifType=3D127) for Phy/MAC layer requirements like bpi, > bpiplus, docsQos,=20 >=20 So I can see that transmission.127 makes sense for the RFC2670 MIB. Seems that BPI, BPIPLUS are also strongly related to a MAC interface, so probably assigning them underneath docsIfMib is OK. For the QOS MIB module I am not so sure. Seems to me that that should go under mib-2, similar to how DIFFSERV-MIB went under mib-2. I have no strong position in that. Only will point that Qos in DOCSIS is only in the RF transmission path between CM and CMTS,=20 At the higher level are the packet classifiers ( where Diff-serv is analogous and complimentary -Filtering/classifying - and will provide at some point the bridge for end-to-end QOS) My only concern is that DOCSIS QOS also handle service Flows information which contains mac parameters: polling rates/types, burst size, etc. kind of interface specific information. Not sure if that qualifies to reside in the transmission branch. Eventually in the future, Classifiers could be strip out to the mib-2 ( DIFF-Serv integration ) and the Service Flow information reside in the transmission docsIfMib area, just thoughs. =20 =20 > Is that still a valid approach for the submitted drafs or mib-2 branch > will be the structure wise required tree? See above... they need to go where we think they make sense logically. What I possibly would have done is something aka: =20 Mib-2.transmission.docsis(127) -- generic OID branch for DOCSIS interface -- objects docsis.docsIfMib(1) -- docsIfMib docsIfMib.docsIfMibObjects(1) -- OID branches within docsIfMib docsis.docsBpiMib(2) -- docsBpiMib docsis.docsBpiPlusMib(3) -- docsBpiPlusMib In other words, I would have used one branch under which I would put the MIB modules, and then within each MIB module I would have made anotehr level for Objects, Notifications, Compliances etc. You have now intermixed all that and that has made it a bit of a mess (at least in my eyes). But we cannot fix that anymore. Or if we do, then it comes with a lot of pain I suppose. Yes, very painfull, Docsis 1.0 started with RFC 2670 and only after a while bpi was added and now bpiplus but not higher root was defined or visualized at that time.=20 =20 > Is there any other OID holder based on functionality schema? > ( security/Qos ) ?=20 > The intention of that was corroborated ( I presume that ) with the > assignemt of bpi mib RFC 3083 under docsIfMib 5=20 >=20 > We definitely will do what IETF and IANA wanted to keep organized the=20 > OID trees, but a better understanding of IETF desire will be really=20 > valuable. And the drafts could be the places to keep those trends=20 > requirements among IETF, IPCDN and IANA. >=20 Within One MIB module, people can assign in the DRAFT docs itself. You normally have something aka: someModuleMib MODULE-IDENTITY ... ::=3D { root-oid xx } -- xx to be assigned by IANA Within root-oid.xx you can then assign your own structure This will help in the sense that you only get xx assigned once the ID gets published as an RFC. And that is the time that people can actually use the OID that gets assigned, not anytime earlier while you are still developing the draft. > A look of your oid mapping: >=20 > docsIfMib 1 - RFC2670 mib objects > docsIfMib 2 - RFC2670 notifications > docsIfMib 3 - RFC2670 conformance=20 > docsIfMib 5 - RFC3083 bpi objects/notifications/conformance >=20 > The current drafts (implemented in the field showed in parantesis): -> > prior to InetAddress RFC 2851/3291 > docsIfMib 6 - bpiplus (draft 05) objects/notifications/conformance > docsIfMib 7 - docsQos (draft 04) objects/notifications/conformance >=20 This is REALLY BAD. Peopl should NOT and NEVER implement I-Ds and then use OIDs from the IANA maintained/controlled OID space) for the MIB=20 modules that are not yet published as RFC. Vendors could have put them under their enterprise OID tree, or maybe under some experimental OID tree if you had asked for one. That's our fault is good that IETF is doing a tremendous effort in manteining the IANA trees integrity. Still we have all this legacy problems. > Keeping the legacy structure: (legacy "weird structure") new proposed=20 > drafts for RFC > docsIfMib 8 - IETF bpiplus RFC objects/notifications/conformance > docsIfMib 9 - IETF docsQos RFC objects/notifications/conformance=20 >=20 So if we do this, then the customers may end up with the same objects but under two different OID trees? That sounds like BAD for the customers, does it not? What a mess! :-| better say this rigth here than having the IESG in a bottleneck situation >=20 > Thinking in IETF-MODULE styles >=20 >=20 > What would be the organized structure? > Mib-2 or transmission Hierachy related ifmib, bpiplus docsqos? How=20 > IETF really wants to organize the trees? If Mib-2 for bpiplus and qos, > any particular subtrees of mib-2 >=20 > Or transmission sub-tree: >=20 > How does IETF docsIfMib play as an umbrella for bpiplus and > docsQos or > any DOCSIS related interface mib >=20 > Will that define a path requiring IETF docsIfMib to be IESG approved=20 > before bpiplus/docsQos ? Supposed in transmission branch=20 > transmission... (128 is also a docsis ifType not as good option as 127 > but that one is already covered by rfc2670 >=20 > One option: >=20 > Transmission 128 - docsIfIETF ? ( to say any number? ) docsIfIETF 1=20 > docsIfMib new RFC (objects/notifications/conformance) > docsIfIETF 2 bpiplus new RFC (objects/notifications/conformance) > docsIfIETF 3 docsQos new RFC (objects/notifications/conformance) >=20 Will you also rename your object descriptors? How are people going to know the difference between current docsIfDownstreamChannelTable and the docsIfDownstreamChannelTable once it gets re-rooted under docsIfIETF ?? See... what is biting you here is the rules of how you can change and update non-published (I-Ds) and existing published (as RFCs) =20 MIB modules. You may want to read about that in the RFC2578/79/80 RFCs. Hope this helps. I need to think about a solution. Maybe we need to chat about that some more. Bert I have the same question and probably something I did not understood completely and I named the MODULE-IDENTITY scope. Or at least As I understood your proposal of DOCS-IETF-IF-MIB vs DOCS-IF-MIB Which in the application side translate into : DOCS-IETF-IF-MIB-docsIfDownstreamChannelTable vs DOCS-IF-MIB-docsIfDownstreamChannelTable that I believe are different. >=20 > Thanks >=20 > Eduardo >=20 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Jul 25 12:03:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10354 for ; Fri, 25 Jul 2003 12:03:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g527-0003T8-Ai for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 12:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PG33Ct013334 for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 12:03:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g524-0003Si-Qt; Fri, 25 Jul 2003 12:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g51G-0003PZ-Oy for ipcdn@optimus.ietf.org; Fri, 25 Jul 2003 12:02:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10323 for ; Fri, 25 Jul 2003 12:02:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g51F-0001SV-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 12:02:09 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19g51D-0001Rx-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 12:02:08 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6PG1GdS010182; Fri, 25 Jul 2003 10:01:17 -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-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Date: Fri, 25 Jul 2003 10:01:16 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Thread-Index: AcNSJNv/Mn4tMtNUR2Skvz/yudvxlgAEkBpgACL/bPA= From: "Jean-Francois Mule" To: "Eduardo Cardona" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , "DOCSIS Sec Majordomo List" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable A couple of thoughts on docsBpi2CmTEKSAType based on the options we discussed so far. First, I like option (*) with Bert's proposal to add docsBpi2CmTEKSAVendorSpecificType > (*): none(0), > > primary(1) > > static(2) > > dynamic(3)=20 > > vendorSpecific(255) This option has the merit to: + address the mib-doctor concerns on enum value 0 and I agree with Eduardo on the justification. > The process is as follow: An entry is created for an SA and=20 > after authorization/configuration, the SAType is known and=20 > the SAType object si assigned to 1/2/3. may be we could add some text in the object description to state the above.=20 + keep compatibility with the current field implementations of the ID (even though this is valid concern from an IETF prospective, it is a plus if we can accommodate it) + adding vendorSpecific value allows to match the docsis protocol spec Additional Comments: + commnent on value 255 in docsBpi2CmTEKSAType=20 > (*): none(0), > > primary(1) > > static(2) > > dynamic(3)=20 > > vendorSpecific(255) ^^^ since value 255 does not necessarily mean docsBpi2CmTEKSAVendorSpecificType =3D 255, I would prefer to use a distinct value for vendor specific types to indicate "go look in docsBpi2CmTEKSAVendorSpecificType" for the actual value - just so that we don't have an overlap that could be misinterpreted. So new proposal is: > (*): none(0), > > primary(1) > > static(2) > > dynamic(3)=20 > > vendorSpecific(256) + comment on docsBpi2CmTEKSAVendorSpecificType > docsBpi2CmTEKSAVendorSpecificType .. > SYNTAX Integer32 (128..255) one concern is what would be the value returned by an object instance when docsBpi2CmTEKSAType=3D0|1|2|3 ? Basically a GET on this when the value is 0|1|2|3 should not return a value in the range of 128..255. so again, I'd propose to add a special value outside the valid range for VendorSpecificType, something like: > docsBpi2CmTEKSAVendorSpecificType .. > SYNTAX Integer32 (128..256) and indicate in the description clause that when docsBpi2CmTEKSAType !=3D 256, docsBpi2CmTEKSAVendorSpecificType MUST be equal to 256. I = picked 256 but anything outside 128..255 would work. Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Jul 25 12:10:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10700 for ; Fri, 25 Jul 2003 12:10:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g58t-0004CV-T4 for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 12:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PGA3em016129 for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 12:10:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g58r-0004Bn-EV; Fri, 25 Jul 2003 12:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g57y-0004AJ-6b for ipcdn@optimus.ietf.org; Fri, 25 Jul 2003 12:09:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10666 for ; Fri, 25 Jul 2003 12:09:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g57w-0001YF-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 12:09:04 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19g57w-0001Xx-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 12:09:04 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6PG8VdS010535; Fri, 25 Jul 2003 10:08:32 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Date: Fri, 25 Jul 2003 10:08:31 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Thread-Index: AcNSJNv/Mn4tMtNUR2Skvz/yudvxlgAEkBpgACL/bPAAAO5gYA== From: "Jean-Francois Mule" To: "Jean-Francois Mule" , "Eduardo Cardona" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , "DOCSIS Sec Majordomo List" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I meant: ... snip > This option has the merit to: ...snip > + keep compatibility with the current field implementations=20 > of the ID (even though this is *not* a valid concern from an IETF=20 ^^^^ > prospective, it is a plus if we can accommodate it) + adding=20 > vendorSpecific value allows to match the docsis protocol spec Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Jul 25 12:40:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11599 for ; Fri, 25 Jul 2003 12:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5bt-00062q-QH for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 12:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PGe1wF023218 for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 12:40:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5bt-00062G-Cs; Fri, 25 Jul 2003 12:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g5bT-00061a-5D for ipcdn@optimus.ietf.org; Fri, 25 Jul 2003 12:39:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11514 for ; Fri, 25 Jul 2003 12:39:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g5b7-0001nW-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 12:39:13 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19g5b6-0001nK-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 12:39:12 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6PGcedS011799; Fri, 25 Jul 2003 10:38:40 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Date: Fri, 25 Jul 2003 10:38:40 -0600 Message-ID: Thread-Topic: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects Thread-Index: AcNSJNv/Mn4tMtNUR2Skvz/yudvxlgAEkBpgACL/bPAAAPeysA== From: "Eduardo Cardona" To: "Jean-Francois Mule" , "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , "DOCSIS Sec Majordomo List" , "DOCSIS OSS Majordomo List" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Jean-Francois,=20 I feel confortable with your suggestion,=20 I twick The proposed TC ( added some extra tunning ),=20 Also for the proposed object docsBpi2CmTEKSAVendorSpecificType. Although I do not desagree with that and find it not harmful, I do not see any special added value just indicating a value in 128-255 range that is meaning less if not associated with a context (CM-CMTS Vendor/product, etc.)=20 Two counter proposals: See the TC description for recommendations in how to handle that case : recommended case Or=20 Define the docsBpi2CmTEKSAVendorSpecificType as docsBpi2CmTEKSAVendorSpecificTypePtr with RowPointer syntax With default zerodotZero to point to more detailed and specific information. Eduardo DocsBpkmSAType ::=3D TEXTUAL-CONVENTION=20 STATUS current=20 DESCRIPTION=20 "The value of this object is the type of security=20 association. The values of the named-numbers are associated with the BPKM SA-Type attributes and operational=20 considerations:=20 'none' value must only be used if the SA type has yet to be=20 determined, this case may occur due the fact that the=20 security association can be created by several mechanisms=20 and the SA-Type is confirmed until the SA authentication and=20 configuration of the SA is completed .=20 'primary' corresponds to SA-Type attribute code '0', 'static'=20 to code '1', 'dynamic' to code '2'. 'vendorSpecific' value represents any value in the SA-Type attribute range 128 to 255. if used, it is recomended the vendor extends the information about the security=20 association in the enterprise sub-tree via the AUGMENTS clause when this TEXTUAL-CONVENTION is used in the syntax of a columnar object, or an indirect reference if this TEXTUAL-CONVENTION is=20 in the syntax of a scalar object" REFERENCE "DOCSIS Baseline Privacy Plus Interface specification, Section 4.2.2.24" SYNTAX INTEGER { none(0), primary(1), static(2), dynamic(3), vendorSpecific(256) } -----Original Message----- From: Jean-Francois Mule=20 Sent: Friday, July 25, 2003 10:01 AM To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail); DOCSIS Sec Majordomo List; DOCSIS OSS Majordomo List Subject: RE: [ipcdn] draft-ietf-ipcdn-bpiplus-mib-10, closure on SAType Objects A couple of thoughts on docsBpi2CmTEKSAType based on the options we discussed so far. First, I like option (*) with Bert's proposal to add docsBpi2CmTEKSAVendorSpecificType > (*): none(0), > > primary(1) > > static(2) > > dynamic(3) > > vendorSpecific(255) This option has the merit to: + address the mib-doctor concerns on enum value 0 and I agree with Eduardo on the justification. > The process is as follow: An entry is created for an SA and > after authorization/configuration, the SAType is known and=20 > the SAType object si assigned to 1/2/3. may be we could add some text in the object description to state the above.=20 + keep compatibility with the current field implementations of the ID (even though this is valid concern from an IETF prospective, it is a plus if we can accommodate it) + adding vendorSpecific value allows to match the docsis protocol spec Additional Comments: + commnent on value 255 in docsBpi2CmTEKSAType=20 > (*): none(0), > > primary(1) > > static(2) > > dynamic(3) > > vendorSpecific(255) ^^^ since value 255 does not necessarily mean docsBpi2CmTEKSAVendorSpecificType =3D 255, I would prefer to use a distinct value for vendor specific types to indicate "go look in docsBpi2CmTEKSAVendorSpecificType" for the actual value - just so that we don't have an overlap that could be misinterpreted. So new proposal is: > (*): none(0), > > primary(1) > > static(2) > > dynamic(3) > > vendorSpecific(256) + comment on docsBpi2CmTEKSAVendorSpecificType > docsBpi2CmTEKSAVendorSpecificType .. > SYNTAX Integer32 (128..255) one concern is what would be the value returned by an object instance when docsBpi2CmTEKSAType=3D0|1|2|3 ? Basically a GET on this when the value is 0|1|2|3 should not return a value in the range of 128..255. so again, I'd propose to add a special value outside the valid range for VendorSpecificType, something like: > docsBpi2CmTEKSAVendorSpecificType .. > SYNTAX Integer32 (128..256) and indicate in the description clause that when docsBpi2CmTEKSAType !=3D 256, docsBpi2CmTEKSAVendorSpecificType MUST be equal to 256. I = picked 256 but anything outside 128..255 would work. Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Fri Jul 25 15:33:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18200 for ; Fri, 25 Jul 2003 15:33:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8JK-0005z7-LJ for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 15:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PJX2cB022999 for ipcdn-archive@odin.ietf.org; Fri, 25 Jul 2003 15:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8JI-0005yj-Gz; Fri, 25 Jul 2003 15:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g8IK-0005wa-S0 for ipcdn@optimus.ietf.org; Fri, 25 Jul 2003 15:32:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18194 for ; Fri, 25 Jul 2003 15:31:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g8II-0002uI-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 15:31:58 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 19g8IH-0002uF-00 for ipcdn@ietf.org; Fri, 25 Jul 2003 15:31:57 -0400 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h6PJVok26110; Fri, 25 Jul 2003 12:31:50 -0700 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 25 Jul 2003 12:31:49 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: "Ipcdn (E-mail)" Subject: Re: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , IPCDN folks, Bert Wijnen brought this thread to my attention and invited me to comment on it from a MIB doctor perspective. I do have a few questions and suggestions that I hope will simplify things. It's possible that some of this will go over old ground, and if it does I apologize in advance. > > From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] > > Sent: donderdag 24 juli 2003 19:40 > > To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail) > > Cc: stu.green@arrisi.com; Alexander Katsnelson; k.ozawa@CableLabs.com > > Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10 ... > > Bert, > > We Would like to get your advise in this topic and I am > > extending some generalization: > > > > The DOCSIS Interface suite of mibs were initialy visualized as: > > > > Mib-2 branch Device mibs RFC 2669 ( eventually SubMgmt also) > > > That seemed (and still seems) to make sense. One general comment: most of the IETF MIB modules I have seen (either as a WG participant, or as a MIB reviewer) seem to be registered directly under mib-2 (or, for media-specific extensions to the IF-MIB, transmission), and either follow the preferred structure that is going to be RECOMMENDED in the next version of the MIB review guidelines document, i.e., xyzMIB (typically mib-2.x or transmission.x) | +-- xyzNotifications(0) +-- xyzObjects(1) +-- xyzConformance(2) | +-- xyzCompliances(1) +-- xyzGoups(2) or else the older (and somewhat less efficient and no longer recommended) variant xyzMIB (typically mib-2.x or transmission.x) | +-- xyzObjects(1) +-- xyzConformance(2) | | | +-- xyzCompliances(1) | +-- xyzGoups(2) | +-- xyzNotifications(3) | +-- xyzNotificationsPrefix(0) With certain exceptions -- the RMON WG is one -- most WGs just get a new node from the IANA each time they create a new MIB module. The RMON WG has historically assigned stuff under the rmon node, and it looks like IPCDN has started down this path, too. I think that was a BIG MISTAKE and want to suggest that IPCDN consider doing what most of the rest of the IETF WGs do for all new MIB modules that it creates. I'm not saying this in an attempt to be critical of anyone ... I just think we ought to recognize when we make mistakes and learn from them rather than repeat them. A little bit of history: in the -00 version of the MIB review guidelines document the following language appeared in Section 4.5: It is also acceptable for a working group to make its own assignments from a subtree delegated to it by IANA, provided that adequate controls are in place to ensure that such assignments are unique. This was put in to -00 largely on the basis of the fact that the RMON WG had been doing it. Bert challenged this, and so we asked Andy Bierman to comment on the RMON WG experience. I've attached his reply. Based on what he said, the consensus of the MIB doctors was to take this language out ... you will not see it in . I believe that you will see in Andy's messane an echo of some of the problems that have arisen here. Please, let's learn from these experiences. Let's consider the advantages of the standard procedure of getting a new node under mib-2 (or some other existing IANA-managed subtree) when a new MIB module is developed: - The procedure is well-known. IANA and the RFC Editor know exactly what to do, and they don't even require that an IANA Considerations section appear in the RFC-to-be to request the assignment (see http://www.ietf.org/ID-nits.html). - It does not require that a WG attempt to manage an OID subtree (a bad idea, since WGs haven't done a good job of it historically), nor does it require that the WG ask the IANA to manage a subtree for it (which would require writing a complete IANA considerations section and publishing it in an RFC, and would add to the IANA's already heavy workload). - Since provisional assignments appear in Internet-Drafts in the form { mib-2 xxx } or the like, it requires that vendors who want to do early implementations use their own enterprise trees or get an experimental number. Traditionally, when a WG assigns the number out of a delegated subtree, it assigns the number right away, but since the document is still a draft, it is subject to arbtrary changes. This has been known to cause problems when vendors implement the spec prior to its approval as an RFC. Witness bpiplus and docsQos. There are some disadvantages, too: - The OID tree does not necessarily reflect the hierarchical relationships between objects in different MIB modules. - There is often a long delay between the time the IESG approves a spec and the publication of the RFC with the IANA-assigned number. In my opinion (and, I think, in the opinion of most of the MIB doctors) the advantages far outweigh the disadvantages. So, I recommend that all future MIB modules that are produces in this WG be assigned nodes directly under mib-2 (or transmission, if that is appropriate) and follow the RECOMMENDED OID assignment plan illustrated above. For existing MIB modules there are two cases: (a) if it's already been published as an RFC then it MUST be left alone. Under no circumstances may the existing OID assignments be changed. Attempting to "tidy up" messy assignments in deployed MIBs is a "cure" that is much worse than the "disease". (b) for stuff that has appeared only in an I-D, but has already appeared in fielded implementations: if the stuff works and is publishable as is, leave it alone. If there are objects that are flawed but have been fielded, the WG may wish to consider having them appear with a status of deprecated (or obsolete) in the initial version of the MIB module. That would require some explaining, but it is probably defensible if it comes with a promise that "this won't happen again". At least, that's the position I'd advise the IESG to take. Now to comment on certain specifics ... > > Mib-2.transmission.docsIfMib(127) branch: Extension of CATV Interface > > (ifType=127) for Phy/MAC layer requirements like bpi, > > bpiplus, docsQos, > > > So I can see that transmission.127 makes sense for the RFC2670 MIB. > Seems that BPI, BPIPLUS are also strongly related to a MAC interface, so > probably assigning them underneath docsIfMib is OK. Unless they are already implemented (which SHOULD NOT be the case if they are only I-Ds), I'd advise a direct assignment under transmission, per the advice in the long diatribe above. > For the QOS MIB module I am not so sure. Seems to me that that should go > under mib-2, similar to how DIFFSERV-MIB went under mib-2. > > > I have no strong position in that. > Only will point that Qos in DOCSIS is only in the RF transmission path > between CM and CMTS, > At the higher level are the packet classifiers ( where Diff-serv is > analogous and complimentary -Filtering/classifying - and will provide > at some point the bridge for end-to-end QOS) > > My only concern is that DOCSIS QOS also handle service Flows information > which contains mac parameters: polling rates/types, burst size, etc. > kind of interface specific information. Not sure if that qualifies to > reside in the transmission branch. > > Eventually in the future, Classifiers could be strip out to the mib-2 ( > DIFF-Serv integration ) and the Service Flow information reside in the > transmission docsIfMib area, just thoughs. > > My VERY STRONG RECOMMENDATION is NOT to use the OID tree to try to express relationships between objects in diferent MIB modules. I would strongly suggest assignments under mib-2. > > Is that still a valid approach for the submitted drafs or mib-2 branch > > > will be the structure wise required tree? > > See above... they need to go where we think they make sense logically. > > What I possibly would have done is something aka: > > Mib-2.transmission.docsis(127) -- generic OID branch for DOCSIS > interface > -- objects > docsis.docsIfMib(1) -- docsIfMib > docsIfMib.docsIfMibObjects(1) -- OID branches within docsIfMib > > docsis.docsBpiMib(2) -- docsBpiMib > docsis.docsBpiPlusMib(3) -- docsBpiPlusMib > > In other words, I would have used one branch under which I would put the > MIB modules, and then within each MIB module I would have made anotehr > level for Objects, Notifications, Compliances etc. You have now > intermixed all that and that has made it a bit of a mess (at least in my > eyes). But we cannot fix that anymore. Or if we do, then it comes with a > lot of pain I suppose. I would not even go that far, as it means that there is a tree that needs to be managed. WGs have historically not done a good job of this, and so it would need to be delegated to the IANA. But that creates a lot of work for no real advantage, IMHO. > > Yes, very painfull, Docsis 1.0 started with RFC 2670 and only after a > while bpi was added and now bpiplus but not higher root was defined or > visualized at that time. > > > > > Is there any other OID holder based on functionality schema? > > ( security/Qos ) ? > > The intention of that was corroborated ( I presume that ) with the > > assignemt of bpi mib RFC 3083 under docsIfMib 5 > > > > We definitely will do what IETF and IANA wanted to keep organized the > > OID trees, but a better understanding of IETF desire will be really > > valuable. And the drafts could be the places to keep those trends > > requirements among IETF, IPCDN and IANA. > > > Within One MIB module, people can assign in the DRAFT docs itself. You > normally have something aka: > > someModuleMib MODULE-IDENTITY > ... > ::= { root-oid xx } -- xx to be assigned by IANA > > Within root-oid.xx you can then assign your own structure > > This will help in the sense that you only get xx assigned once the ID > gets published as an RFC. And that is the time that people can actually > use the OID that gets assigned, not anytime earlier while you are still > developing the draft. Exactly. Once again, I strongly advise the WG to do this, and I further advise that root-oid should be an existing IANA-maintained branch (like mib-2 or transmission). > > A look of your oid mapping: > > > > docsIfMib 1 - RFC2670 mib objects > > docsIfMib 2 - RFC2670 notifications > > docsIfMib 3 - RFC2670 conformance > > docsIfMib 5 - RFC3083 bpi objects/notifications/conformance > > > > The current drafts (implemented in the field showed in parantesis): -> > > > prior to InetAddress RFC 2851/3291 > > docsIfMib 6 - bpiplus (draft 05) objects/notifications/conformance > > docsIfMib 7 - docsQos (draft 04) objects/notifications/conformance > > > This is REALLY BAD. Peopl should NOT and NEVER implement I-Ds and then > use OIDs from the IANA maintained/controlled OID space) for the MIB > modules that are not yet published as RFC. > Vendors could have put them under their enterprise OID tree, or maybe > under some experimental OID tree if you had asked for one. > > > That's our fault is good that IETF is doing a tremendous effort in > manteining the IANA trees integrity. Still we have all this legacy > problems. > This is where my suggestion above might prove to be a good idea: if there are fielded implementations of objects that need to be changed (e.g., pre-InetAddress objects) then consider keeping those objects in the drafts, with the same descriptors and OIDs, but giving them deprecated or even obsolete status. It's unusual to do that for an object that has not appeared in a published RFC, but there is no SMIv2 rule that forbids it. Then, define replacement objects (e.g., that use the InetAddress TC) with new descriptors and OIDs. The same thing should happen with conformance groups. This would make the MIB module look like one that was initially published with the flawed objects, and then was revised via ordinary maintenance. It wouldn't be the best looking MIB module known to man, but it would work, I think. > > Keeping the legacy structure: (legacy "weird structure") new proposed > > drafts for RFC > > docsIfMib 8 - IETF bpiplus RFC objects/notifications/conformance > > docsIfMib 9 - IETF docsQos RFC objects/notifications/conformance > > > So if we do this, then the customers may end up with the same objects > but under two different OID trees? That sounds like BAD for the > customers, does it not? Yes. I say this is a very bad idea, and urge the WG not to do it. [ ... snipped downto: ... ] > See... what is biting you here is the rules of how you can change and > update non-published (I-Ds) and existing published (as RFCs) > MIB modules. You may want to read about that in the RFC2578/79/80 RFCs. Do that, and also look at Section 4.9 of the review guidelines draft . > Hope this helps. I need to think about a solution. Maybe we need to chat > about that some more. Bert I hope my suggestion of having objects that are "born" with a status of deprecated or obsolete can help clean up the immediate problem with bpiplus and docsQos. Mike _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 28 12:08:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10519 for ; Mon, 28 Jul 2003 12:08:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hAXi-0004gV-E2 for ipcdn-archive@odin.ietf.org; Mon, 28 Jul 2003 12:08:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SG8AQr018004 for ipcdn-archive@odin.ietf.org; Mon, 28 Jul 2003 12:08:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hAXZ-0004g4-9B; Mon, 28 Jul 2003 12:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hAWq-0004WB-TR for ipcdn@optimus.ietf.org; Mon, 28 Jul 2003 12:07:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10428; Mon, 28 Jul 2003 12:07:11 -0400 (EDT) From: Wilson.Sawyer@arrisi.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hAWo-0005C2-00; Mon, 28 Jul 2003 12:07:14 -0400 Received: from [63.86.75.192] (helo=mercury.arrisi.com) by ietf-mx with esmtp (Exim 4.12) id 19hAWn-0005Bt-00; Mon, 28 Jul 2003 12:07:13 -0400 Received: from titan.arrisi.com ([10.24.249.1]) by mercury.arrisi.com (Lotus Domino Release 5.0.12) with ESMTP id 2003072812070901:59 ; Mon, 28 Jul 2003 12:07:09 -0400 Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 To: "Jean-Francois Mule" Cc: bwijnen@lucent.com, ipcdn@ietf.org, ipcdn-admin@ietf.org, "Kirk Friedman" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Mon, 28 Jul 2003 12:07:06 -0400 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.12 |February 13, 2003) at 07/28/2003 12:07:09 PM, Itemize by SMTP Server on Mercury/Antec(Release 5.0.12 |February 13, 2003) at 07/28/2003 12:07:09 PM, Serialize by Router on Mercury/Antec(Release 5.0.12 |February 13, 2003) at 07/28/2003 12:07:14 PM, Serialize complete at 07/28/2003 12:07:14 PM Content-type: text/plain; charset=us-ascii Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , (Apologies for the delay in responding) Jean-Francois's suggestions make sense to me - I'll proceed with a draft -12 to incorporate them. Any other comments on J-F's suggestion? Any other comments on the subscriber management MIB i-d that I should fix in this draft? - Wilson "Jean-Francois Mule" To: , "Kirk Friedman" s.com> , Sent by: Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 ipcdn-admin@ietf. org 07/16/03 12:19 PM Wilson, I like the work on the RFC3289 integration, nice job. Going through the changes you proposed in draft11 w.r.t. mandating part of RFC 3289, find below a suggestion to address the concerns that what's required from 3289 is kind of loosely defined in the draft. I agree that this can be done via the DOCSIS RFI; below is a complementary proposal. First, the requirements on 3289 in section 2.3 are written in terms of objects, not object groups. Consequently, it is not possible to enforce any level of requirement is on these objects (object groups could allow you to be more precise with SYNTAX and WRITE-SYNTAX clauses for e.g.). Secondly, going through the RFC3289 object groups one by one, you are not that far from actually mandating some object groups: o diffServDataPathTable => this is diffServMIBDataPathGroup object group o diffServClfrTable => based on section 3.2.1 of RFC3289, I think you may also need to mandate the support of diffServClfrNextFree. diffServClfrNextFree is populated by the agent when creating ids in the table. If you agree to add this one object, requiring diffServClfrNextFree + diffServClfrTable objects => diffServMIBClfrGroup. This comment applies to the next tables as well. o diffServClfrElementTable => how about diffServClfrElementNextFree? If you include diffServClfrElementNextFree + diffServClfrElementTable => diffServMIBClfrElementGroup o diffServMultiFieldClfrTable how about diffServMultiFieldClfrNextFree? If you include diffServMultiFieldClfrNextFree + diffServMultiFieldClfrTable => diffServMIBMultiFieldClfrGroup o diffServActionTable how about diffServActionNextFree? If you include diffServActionNextFree + diffServActionTable => diffServMIBActionGroup. o diffServAlgDropTable (diffServAlgDropType=alwaysDrop) how about diffServAlgDropNextFree ? If you include diffServAlgDropNextFree + diffServAlgDropTable => diffServMIBAlgDropGroup o diffServCountActTable how about diffServCountActNextFree? If you include diffServCountActNextFree + diffServCountActTable + the following objects from diffServAlgDropTable (diffServAlgDropOctets, diffServAlgDropPkts, diffServAlgRandomDropOctets, diffServAlgRandomDropPkts) => diffServMIBCounterGroup ==> In short, if you agree that supporting the diff*NextFree objects is not a bad idea (especially since it's probably going to be implemented by the agent with the various tables), you can easily transform the section 2.3 and write it in terms object groups. To that extent, I am wondering if the docsSubMgtBasicCompliance module compliance statement could be enhanced to actually include the object groups from RFC3289 cited above. Based on your section 2.3, this enhancement could then look something like this: docsSubMgtBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CMTS devices that implement CMTS centric subscriber management." MODULE DIFFSERV-MIB -- RFC3289 MANDATORY-GROUPS { diffServMIBDataPathGroup, diffServMIBClfrGroup, diffServMIBClfrElementGroup, diffServMIBMultiFieldClfrGroup, diffServMIBActionGroup, diffServMIBAlgDropGroup, diffServMIBCounterGroup } ... ... -- and now you may formerly specify that -- diffServAlgDropType=alwaysDrop in diffServAlgDropTable, etc. MODULE -- This module i.e. DOCS-IETF-SUBMGT-MIB MANDATORY-GROUPS { docsSubMgtGroup } ... Thoughts? Sorry for not sending this proposal earlier, Jean-Francois. > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: Wednesday, June 11, 2003 10:44 AM > To: Kirk Friedman > Cc: bwijnen@lucent.com; ipcdn@ietf.org > Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 > > > > Kirk - Agreed that the Docsis OSSI Spec needs new language to > spec out CMTS compliance w.r.t. RFC3289. For the most part, > I think that language more properly belongs in the OSSI spec > than in the internet draft. But I'm open to suggestions. > > Keep in mind that there's a necessary lag in the publication > of the OSSI > Spec: It can't mandate compliance with the subscriber > management internet-draft until the MIB is assigned a root - > and that won't happen until publication as an RFC. > > Regards, > Wilson > > > > > > > "Kirk Friedman" > > > > > ant.com> cc: > , > > Subject: RE: > [ipcdn] draft submitted: subscriber management MIB -11 > > 06/11/03 11:59 AM > > > > > > > > > > > > > Hi Wilson, > > Thanks for the prompt reply. Walking through your responses > > 1. I agree its not a major issue. More of a implementation > simplification. > > 2. RFC3289 does not refer to > filter-classifiers-used-for-subscriber-managemment. > Considering 3289 by itself is using classifiers for filters > and for QoS management. There is definitely cause for > confusion between this and the QoS MIB without careful explanation. > > 3. The ifIndex makes sense if only applied to the Docsis MAC > interface. This should be clarified. > > 4. The question is how RFC3289 is interpreted for use in a > CMTS and what constitutes compliance. If this MIB is going > to be used in DOCSIS 1.1 systems then an ECR should > immediately be drafted the OSSI Spec "Detailed MIB > Requirements" so there is no confusion about what is and is > not required to be implemented. Otherwise the confusion will > snowball. > > 5. Agree, see 4. > > 6. Agreed. > > 7. Agreed since the ifIndex is only applicable to the MAC interface. > > To re-iterate comment 4. If I take a look at RFC3289 without > any other documentation, then there are MIB entries other > than the classifiers that could be said to apply to the CMTS. > Section 3 "Management Information Bases (MIBS)" should also > be ECRd to change the requirements for the subscriber mgmt > mib and add a section for RFC 3289. If not, there will be a > large disconnect between 1.1 systems and 2.0 systems that > will make MSO management that much more difficult. > > Thanks again, > > Kirk Friedman > > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: Monday, June 09, 2003 11:17 AM > To: Kirk Friedman > Cc: bwijnen@lucent.com; ipcdn@ietf.org > Subject: RE: [ipcdn] draft submitted: subscriber management MIB -11 > > > > Kirk - thanks for your comments. My mailer doesn't do a good > job of inlining responses, so I'll refer to your numbering: > > 1. Agreed on the redundancy on packet matching, although the > two mechanisms and their matching criteria differ. How does > this affect the decision to use RFC3289, though? > > 2. Yes, we have Docsis classifiers, and now we have > RFC3289-filter-classifiers-as-used-for-subscriber-management. > But the 3289 classifiers are doing what the old submgt Filter > table was doing. So is the confusion just in the word > "classifier", or am I missing something else? > > 3. The ifIndex should be the Docsis MAC interface, which is a > bidirectional interface. Does this need to be clarified in the i-d? > > 4. I don't think there's any mandate that we move any > functionality unrelated to subscriber management under the > 3289 umbrella. So yes, we have token buckets (for the QoS > MIB), but they do not appear in the context of RFC3289. > > 5. Thee is no need to support diffServQEntry at all. > zeroDotZero, Count Actions, and Drop Actions are all that is > needed. (see below for your broader comment about the QoS MIB). > > 6. In recent versions of the subscriber management MIB, two > classifiers would have been needed to match the same port > numbers in TCP and UDP, so no savings there. Here's the > relevant text from the -10 draft: > > docsSubMgtPktFilterUlp OBJECT-TYPE > SYNTAX Integer32 (0..256) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Upper level protocol to match. If this value is 256, > matches ALL ULP values. Otherwise, this matches the specific > protocol value. Note that if the packet ULP is either > 6 (tcp) or > 17 (udp), then docsSubMgtPktTcpUdpFilterTable must also be > consulted (if its entry exists) to see if this entry matches. > If this value is neither tcp(6) nor udp(17), then that > table is not consulted." > > 7. There are no values for the CM - this is a CMTS-only MIB. > We *do* need a section of the OSSI spec which calls out the > minimal requirements for implementation of RFC3289 on CMTSs. > Do we need anything beyond that? I don't think it lines up > quite as cleanly as, for example, ifTable, because the > expressive power of RFC3289 lies in the flexibility of its structure. > > (re your unnumbered summary): > > On the most literal level, there is no reason why this change > should cause any confusion with the QoS MIB. Subscriber > Management has always been independent of the QoS MIB, and > the choice to adopt RFC3289 representation for > packet-filtering criteria doesn't change that. The QoS MIB > will continue to use its own criteria and will continue to be > applied independently of the representation of subscriber > management filtering. > > On a broader broader MIB-representational level, I'd agree > that there may be work ahead to coordinate with the QoS MIB. > The QoS MIB is also evolving, and may one day also choose to > adopt conventions from RFC3289. If so, the 3289 framework > will need to convey the relationship between the two > processes. I believe that it has the expressive power to do > so. But, for now, I'd be very reluctant to push for that > level of unity with something as necessarily complex as the > QoS MIB. I'd rather make progress independently for now. > > As for implementation, keep in mind that even if QoS does go > this way, there is no requirement that the full arbitrary > expressiveness of 3289 be implemented - classifying the same > packet through 3 meters, two merge ramps, a toll booth and > two truck stops. We can use 3289 as a tool to express the > problems we have - not to impose arbitrarily difficult > queuing regimes. > > Regards, > Wilson Sawyer > > > > > "Kirk Friedman" > , > ant.com> cc: > > Subject: RE: > [ipcdn] draft > submitted: subscriber > 06/09/03 12:50 PM management MIB -11 > > > > > > > Hi Wilson, > > Sorry this took so long to put together. I have real > reservations about this change. While it does indeed remove > some MIB redundancy and allow for some future capabilities, > it also complicates matters quite a bit during implementation > and for understanding how the QoS and Subscriber Management > MIBs work together on CMTS and CMs. > > 1) There is already redundancy between the DOCSIS 1.1 QoS MIB > (currently > draft-ietf-ipcdn-qos-mib-08.txt) and the subscriber MIB in > the packet matching criteria. In some sense that simplifies > both implementation and understanding how the two MIBs > operate together. > > 2) It is confusing that classifiers for a DOCSIS system are > no longer uniquely defined. There are DOCSIS packet > classifiers for service flows and now classifiers associated > with RFC3289 and the Subscriber Mgmt MIB. > > 3) The diffServDataPathEntry is indexed by ifIndex (which is > fine) and ifDirection. It is somewhat based on the premise > that an interface is bi-directional. The RFI interfaces are > uni-directional. So there needs to be a description that > indicates which direction applies for which interface type > for which device (CMTS/CM). See last item. > > 4) In order to follow the compliancies of RFC3289, groups > that are not called out in the subscriber MIB are now > mandatory. The diffServMIBTBParamGroup must be implemented > because "This group is mandatory for devices that implement > token-bucket metering functions." The diffServMIBMeterGroup > is "... is mandatory for devices that implement metering > functions." Both the CMTS and CM do this. > > 5) The requirements to include row pointers to diffServQEntry > is also confusing, even if zeroDotZero is applied in most > cases. Again, there is alot of overlap with QoS MIB. > > 6) Two classifiers must be used if it is desired to match > only TCP/UDP packets. This was one of the shortcuts in the > previous version of the Subscriber Mgmt MIB since this is the > majority of the traffic on the Internet. > > 7) One way out of this confusion would be to specify all the > various values for the objects of this MIB for CM and CMTS. > This would be like the relationship between the ifTable and > RFC2670 called Appendix B of the DOCSIS OSSI specification. > However, my understanding is that for DOCSIS 1.1 this > specification is going to be wrapped up soon. > > RFC3289 is used to provide a solution for both filtering > and QoS. But requiring part of its implementation seems to > me to open up a whole new can of worms about implementation > and precedence with the DOCSIS 1.1 QoS MIB. > > Thanks, > > Kirk Friedman > Correlant Communications > 15110 Avenue Of Science > San Diego, CA., 92128 > > > > > -----Original Message----- > From: ipcdn-admin@ietf.org [mailto:ipcdn-admin@ietf.org]On > Behalf Of Wilson.Sawyer@arrisi.com > Sent: Thursday, May 29, 2003 5:22 AM > To: ipcdn@ietf.org > Cc: bwijnen@lucent.com > Subject: [ipcdn] draft submitted: subscriber management MIB -11 > > > I have submitted a greatly-revised version of the subscriber > management mib (draft-ietf-ipcdn-subscriber-mib-11.txt), > making use of the Diffserv MIB > (RFC3289) as outlined in my April 28 email. The good news is > that the document is now shorter, since much of filtering is > now deferred to existing facilities in RFC3289. This will be > a significant implementation change for CMTS vendors and operators. > > The reason for the change is that the overlap with RFC3289 > was so great that I did not believe that the document would > pass the broader review needed for RFC approval. We gain by > re-using the work that has already gone into 3289. It also > gives us the ability, although not mandated, to integrate > with other facilities within 3289. > > I urge CMTS vendors and operators, in particular, to review > this carefully and make suggestions. As always, this document > is the product of the working group and only proceeds with > working group consensus. > > Respectfully submitted, > Wilson Sawyer > ARRIS > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > > > > > > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Mon Jul 28 13:52:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14020 for ; Mon, 28 Jul 2003 13:52:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCAD-0000GR-Tx for ipcdn-archive@odin.ietf.org; Mon, 28 Jul 2003 13:52:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SHq1IF001009 for ipcdn-archive@odin.ietf.org; Mon, 28 Jul 2003 13:52:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hCAD-0000G4-D7; Mon, 28 Jul 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hC9y-0000Fs-2u for ipcdn@optimus.ietf.org; Mon, 28 Jul 2003 13:51:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14002 for ; Mon, 28 Jul 2003 13:51:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hC9v-0006Bd-00 for ipcdn@ietf.org; Mon, 28 Jul 2003 13:51:43 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx with esmtp (Exim 4.12) id 19hC9t-0006BZ-00 for ipcdn@ietf.org; Mon, 28 Jul 2003 13:51:42 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h6SHpfUE010818 for ; Mon, 28 Jul 2003 10:51:41 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h6SHpdrx002898 for ; Mon, 28 Jul 2003 12:51:39 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Mon, 28 Jul 2003 10:51:38 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Date: Mon, 28 Jul 2003 10:51:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C35530.E3817850" Subject: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C35530.E3817850 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35530.E3817850" ------_=_NextPart_001_01C35530.E3817850 Content-Type: text/plain Rick, Thanks for your review of the signaling MIB recommendations and for providing additional suggestions. For items 1-5 and 7,8, and 10 there is substantial agreement, and I have made the changes as indicated in the open issues list (as posted on the IPCDN web site and included in your document), however, there is one minor exception on item 8. It turns out that sixteenthousand is more commonly used than twelvethousand. Consequently, the description and default are recommended to be sixteenthousand not twelvethousand. For item 9, Motorola agrees with the default change recommended. For item 11, Motorola agrees with the recommendation to obsolete these objects. These objects are product hardware design issues. For item 6, Motorola, after further review determined that there is already an object for setting the level for dtmf or any other tone (pktcSigDevToneDbLevel), which can vary by geographic location. Consequently, the only change recommended for item 6 then is the addition of 3 user defined tones. For item 12, Motorola does not agree with obsoleting these objects. The dial pulse objects vary by geographic location (e.g., NA, Europe, Japan, etc), and need to be retained in order to be adjusted as necessary by the operator. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com -----Original Message----- From: Rick.Morris@arrisi.com [mailto:Rick.Morris@arrisi.com] Sent: Friday, July 25, 2003 2:08 PM To: Wim De Ketelaere Cc: Gordon Beacham; billy.hare@arrisi.com; walter.daniel@arrisi.com Subject: Re: Fw: Publication of PacketCable IETF MIBs - SIB draft 01 Wim and Gorden, I apologize for the length of time it has taken me to get this response back to you. However, we wanted to make sure that we had thoroughly reviewed and considered each of Gorden's suggestions. Please distribute our comments to your list as appropriate. I would like to say that Gorden has done an excellent job of scoping out several suggested changes. The attached document from ARRIS contains any agreements with his recommendations, along with a couple of additional comments. ARRIS would be very interested with discussing our comments with you, and others on your distribution list at your convenience. Thank you both for your efforts in working to clean up this MIB's contents. With the joint cooperation of tComLabs and the MTA vendors, I feel confident we can all move towards a successful certification wave in ECW13. Regards, Rick Morris ARRIS, SrMgr - Engineering, Certification and Standards +001 770 622 8619 "Wim De Ketelaere" 07/03/2003 01:53 PM To: cc: Subject: Fw: Publication of PacketCable IETF MIBs - SIB draft 01 Hi Rick, Here's the document ! Thanks, Best regards, Wim ------_=_NextPart_001_01C35530.E3817850 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTE0MSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PEZPTlQgY29sb3I9IzAwMDBm ZiBzaXplPTI+DQo8UD5SaWNrLDwvRk9OVD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxG T05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiANCjwvRk9OVD48L1A+PC9GT05UPg0KPFA+VGhhbmtz IGZvciB5b3VyIHJldmlldyBvZiB0aGUgc2lnbmFsaW5nIE1JQiByZWNvbW1lbmRhdGlvbnMgYW5k IGZvciBwcm92aWRpbmcgDQphZGRpdGlvbmFsIHN1Z2dlc3Rpb25zLjwvUD4NCjxQPkZvciBpdGVt cyAxLTUgYW5kIDcsOCwgYW5kIDEwJm5ic3A7PFNQQU4gY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAz PnRoZXJlIGlzIA0Kc3Vic3RhbnRpYWwgYWdyZWVtZW50LCBhbmQgPC9TUEFOPkkgaGF2ZSBtYWRl IHRoZSBjaGFuZ2VzIGFzJm5ic3A7PFNQQU4gDQpjbGFzcz00MjkyNzI0MTctMjgwNzIwMDM+aW5k aWNhdGVkIDwvU1BBTj5pbiB0aGUgb3BlbiBpc3N1ZXMgbGlzdDxTUEFOIA0KY2xhc3M9NDI5Mjcy NDE3LTI4MDcyMDAzPiAoYXMgcG9zdGVkIG9uIHRoZSBJUENETiB3ZWIgc2l0ZSBhbmQgaW5jbHVk ZWQgaW4geW91ciANCmRvY3VtZW50KTwvU1BBTj4sIGhvd2V2ZXIsIHRoZXJlIGlzIG9uZSZuYnNw OzxTUEFOIA0KY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPm1pbm9yIDwvU1BBTj5leGNlcHRpb24g b24gaXRlbSA4LiBJdCB0dXJucyANCm91dCZuYnNwOzxTUEFOIGNsYXNzPTQyOTI3MjQxNy0yODA3 MjAwMz50aGF0IDwvU1BBTj5zaXh0ZWVudGhvdXNhbmQgaXMgbW9yZSANCmNvbW1vbmx5IHVzZWQg dGhhbiB0d2VsdmV0aG91c2FuZC4gQ29uc2VxdWVudGx5LCB0aGUgZGVzY3JpcHRpb24gYW5kIGRl ZmF1bHQgYXJlIA0KcmVjb21tZW5kZWQgdG8gYmUgc2l4dGVlbnRob3VzYW5kIG5vdCB0d2VsdmV0 aG91c2FuZC48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvUD48L0ZPTlQ+DQo8UD5G b3IgaXRlbSA5LCBNb3Rvcm9sYSBhZ3JlZXMgd2l0aCB0aGUgZGVmYXVsdCBjaGFuZ2UgcmVjb21t ZW5kZWQuPEZPTlQgDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L1A+PC9GT05UPg0KPFA+Rm9y IGl0ZW0gMTEsIE1vdG9yb2xhIGFncmVlcyB3aXRoIHRoZSByZWNvbW1lbmRhdGlvbiB0byBvYnNv bGV0ZSB0aGVzZSANCm9iamVjdHMuIFRoZXNlIG9iamVjdHMgYXJlIHByb2R1Y3QgaGFyZHdhcmUg ZGVzaWduIGlzc3Vlcy48Rk9OVCANCmZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvUD48L0ZPTlQ+ DQo8UD5Gb3IgaXRlbSA2LCZuYnNwOzxTUEFOIGNsYXNzPTQyOTI3MjQxNy0yODA3MjAwMz5Nb3Rv cm9sYSwgPC9TUEFOPjxTUEFOIA0KY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPmE8L1NQQU4+PFNQ QU4gY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPmZ0ZXIgZnVydGhlciANCnJldmlldyZuYnNwOzwv U1BBTj48U1BBTiBjbGFzcz00MjkyNzI0MTctMjgwNzIwMDM+ZGV0ZXJtaW5lZCB0aGF0IHRoZXJl IGlzIA0KYWxyZWFkeSBhbiBvYmplY3QgZm9yIHNldHRpbmcgdGhlIGxldmVsIGZvciBkdG1mIG9y IGFueSBvdGhlciB0b25lICg8U1BBTiANCnN0eWxlPSJGT05ULVNJWkU6IDEycHQ7IEZPTlQtRkFN SUxZOiAnVGltZXMgTmV3IFJvbWFuJzsgbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IEJhdGFuZzsg bXNvLWFuc2ktbGFuZ3VhZ2U6IEVOLVVTOyBtc28tZmFyZWFzdC1sYW5ndWFnZTogRU4tVVM7IG1z by1iaWRpLWxhbmd1YWdlOiBBUi1TQSI+PEZPTlQgDQpjb2xvcj0jMDAwMDAwPnBrdGNTaWdEZXZU b25lRGJMZXZlbCk8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48U1BBTiANCmNsYXNzPTQyOTI3MjQxNy0y ODA3MjAwMz4sIHdoaWNoIGNhbiB2YXJ5IGJ5IGdlb2dyYXBoaWMgbG9jYXRpb248L1NQQU4+LjxT UEFOIA0KY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPiBDb25zZXF1ZW50bHksIHRoZSBvbmx5IGNo YW5nZSByZWNvbW1lbmRlZCBmb3IgaXRlbSA2IA0KdGhlbiBpcyB0aGUgYWRkaXRpb24gb2YgMyB1 c2VyIGRlZmluZWQgdG9uZXMuPC9TUEFOPjwvUD4NCjxQPjxTUEFOIGNsYXNzPTQyOTI3MjQxNy0y ODA3MjAwMz5Gb3IgaXRlbSAxMiwgTW90b3JvbGEgZG9lcyBub3QgYWdyZWUgd2l0aCANCm9ic29s ZXRpbmcgdGhlc2Ugb2JqZWN0czxTUEFOIGNsYXNzPTQyOTI3MjQxNy0yODA3MjAwMz4uIFRoZSBk aWFsIHB1bHNlIG9iamVjdHMgDQp2YXJ5IGJ5IGdlb2dyYXBoaWMgbG9jYXRpb24gKGUuZy4sIE5B LCBFdXJvcGUsIEphcGFuLCBldGMpLCBhbmQgbmVlZCB0byBiZSANCnJldGFpbmVkIGluIG9yZGVy IHRvIGJlIGFkanVzdGVkIGFzIG5lY2Vzc2FyeSBieSB0aGUgDQpvcGVyYXRvcjwvU1BBTj4uPC9T UEFOPjwvUD48Rk9OVCBmYWNlPSJCb29rIEFudGlxdWEiPg0KPFA+R29yZG9uIEJlYWNoYW08L1A+ DQo8UD5EaWdpdGFsIENvcmUgR2F0ZXdheXMsIEJDUzwvUD4NCjxQPk1vdG9yb2xhLCBJbmMuPC9Q Pg0KPFA+ODU4LTQwNC0yMzM1PC9QPg0KPFA+Z29yZG9uLmJlYWNoYW1AbW90b3JvbGEuY29tPC9Q PjwvRk9OVD48L0ZPTlQ+PC9ESVY+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGRp cj1sdHIgYWxpZ249bGVmdD48Rk9OVCBmYWNlPVRhaG9tYSANCnNpemU9Mj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gUmljay5Nb3JyaXNAYXJyaXNpLmNvbSANCltt YWlsdG86Umljay5Nb3JyaXNAYXJyaXNpLmNvbV08QlI+PEI+U2VudDo8L0I+IEZyaWRheSwgSnVs eSAyNSwgMjAwMyAyOjA4IA0KUE08QlI+PEI+VG86PC9CPiBXaW0gRGUgS2V0ZWxhZXJlPEJSPjxC PkNjOjwvQj4gR29yZG9uIEJlYWNoYW07IA0KYmlsbHkuaGFyZUBhcnJpc2kuY29tOyB3YWx0ZXIu ZGFuaWVsQGFycmlzaS5jb208QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBGdzogDQpQdWJsaWNhdGlv biBvZiBQYWNrZXRDYWJsZSBJRVRGIE1JQnMgLSBTSUIgZHJhZnQgDQowMTxCUj48QlI+PC9GT05U PjwvRElWPjxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT5XaW0gYW5kIEdvcmRlbiw8L0ZPTlQ+ IA0KPEJSPjxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT5JIGFwb2xvZ2l6ZSBmb3IgdGhlIGxl bmd0aCBvZiB0aW1lIGl0IGhhcyB0YWtlbiANCm1lIHRvIGdldCB0aGlzIHJlc3BvbnNlIGJhY2sg dG8geW91LiAmbmJzcDsgJm5ic3A7IEhvd2V2ZXIsIHdlIHdhbnRlZCB0byBtYWtlIA0Kc3VyZSB0 aGF0IHdlIGhhZCB0aG9yb3VnaGx5IHJldmlld2VkIGFuZCBjb25zaWRlcmVkIGVhY2ggb2YgR29y ZGVuJ3MgDQpzdWdnZXN0aW9ucy4gJm5ic3A7UGxlYXNlIGRpc3RyaWJ1dGUgb3VyIGNvbW1lbnRz IHRvIHlvdXIgbGlzdCBhcyANCmFwcHJvcHJpYXRlLjwvRk9OVD4gPEJSPjxCUj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9MT5JIHdvdWxkIGxpa2UgdG8gc2F5IHRoYXQgDQpHb3JkZW4gaGFzIGRvbmUg YW4gZXhjZWxsZW50IGpvYiBvZiBzY29waW5nIG91dCBzZXZlcmFsIHN1Z2dlc3RlZCBjaGFuZ2Vz LiANCiZuYnNwO1RoZSBhdHRhY2hlZCBkb2N1bWVudCBmcm9tIEFSUklTIGNvbnRhaW5zIGFueSBh Z3JlZW1lbnRzIHdpdGggaGlzIA0KcmVjb21tZW5kYXRpb25zLCBhbG9uZyB3aXRoIGEgY291cGxl IG9mIGFkZGl0aW9uYWwgY29tbWVudHMuICZuYnNwO0FSUklTIHdvdWxkIA0KYmUgdmVyeSBpbnRl cmVzdGVkIHdpdGggZGlzY3Vzc2luZyBvdXIgY29tbWVudHMgd2l0aCB5b3UsIGFuZCBvdGhlcnMg b24geW91ciANCmRpc3RyaWJ1dGlvbiBsaXN0IGF0IHlvdXIgY29udmVuaWVuY2UuPC9GT05UPiA8 QlI+PEJSPjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTE+VGhhbmsgeW91IGJvdGggZm9yIHlvdXIg ZWZmb3J0cyBpbiB3b3JraW5nIHRvIGNsZWFuIHVwIHRoaXMgTUlCJ3MgDQpjb250ZW50cy4gJm5i c3A7V2l0aCB0aGUgam9pbnQgY29vcGVyYXRpb24gb2YgdENvbUxhYnMgYW5kIHRoZSBNVEEgdmVu ZG9ycywgSSANCmZlZWwgY29uZmlkZW50IHdlIGNhbiBhbGwgbW92ZSB0b3dhcmRzIGEgc3VjY2Vz c2Z1bCBjZXJ0aWZpY2F0aW9uIHdhdmUgaW4gDQpFQ1cxMy48L0ZPTlQ+IDxCUj48QlI+PEZPTlQg ZmFjZT1BcmlhbCBzaXplPTE+UmVnYXJkcyw8L0ZPTlQ+IDxCUj48Rk9OVCANCmZhY2U9QXJpYWwg c2l6ZT0xPlJpY2sgTW9ycmlzPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTE+QVJS SVMsIFNyTWdyIC0gDQpFbmdpbmVlcmluZywgQ2VydGlmaWNhdGlvbiBhbmQgU3RhbmRhcmRzPC9G T05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTE+KzAwMSANCjc3MCA2MjIgODYxOTwvRk9O VD4gPEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+DQo8VEFCTEUgd2lkdGg9IjEw MCUiPg0KICA8VEJPRFk+DQogIDxUUiB2QWxpZ249dG9wPg0KICAgIDxURD4NCiAgICA8VEQ+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT48Qj4iV2ltIERlIEtldGVsYWVyZSIgDQogICAgICAm bHQ7ZGVrZXRlbGFlcmVAdGNvbWxhYnMuY29tJmd0OzwvQj48L0ZPTlQ+IA0KICAgICAgPFA+PEZP TlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4wNy8wMy8yMDAzIDAxOjUzIFBNPC9GT05UPiA8QlI+ PC9QPg0KICAgIDxURD48Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgPC9GT05UPjxCUj48Rk9OVCANCiAgICAgIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRvOiAmbmJzcDsgJm5ic3A7IA0KICAgICAgJm5i c3A7ICZuYnNwOyZsdDtyaWNrLm1vcnJpc0BhcnJpc2kuY29tJmd0OzwvRk9OVD4gPEJSPjxGT05U IA0KICAgICAgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgY2M6ICZuYnNwOyAmbmJzcDsgDQogICAgICAmbmJzcDsgJm5ic3A7Jmx0O0dvcmRvbi5CZWFj aGFtQG1vdG9yb2xhLmNvbSZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgIGZhY2U9c2Fucy1z ZXJpZiBzaXplPTE+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1YmplY3Q6ICZuYnNwOyAm bmJzcDsgDQogICAgICAmbmJzcDsgJm5ic3A7Rnc6IFB1YmxpY2F0aW9uIG9mIFBhY2tldENhYmxl IElFVEYgTUlCcyAtIFNJQiBkcmFmdCANCiAgMDE8L0ZPTlQ+PC9UUj48L1RCT0RZPjwvVEFCTEU+ PEJSPjxCUj48QlI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj5IaSANClJpY2ssPEJS PjxCUj5IZXJlJ3MgdGhlIGRvY3VtZW50ICE8QlI+PEJSPlRoYW5rcyw8QlI+Jm5ic3A7QmVzdCAN CnJlZ2FyZHMsPEJSPiZuYnNwOyAmbmJzcDtXaW08QlI+PEJSPjxCUj48QlI+PC9GT05UPjxCUj48 QlI+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C35530.E3817850-- ------_=_NextPart_000_01C35530.E3817850 Content-Type: application/octet-stream; name="arris-reply-sigmib-01-outstanding-issues_v4.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="arris-reply-sigmib-01-outstanding-issues_v4.doc" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAcAAAAAAAAAAA EAAAcgAAAAEAAAD+////AAAAAG8AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA8BK/AAAAAAAAEAAAAAAABAAAsyYAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIkoAADd8AAA3fAAAsyIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAHABAAAAAAAAcAEAAHAB AAAAAAAAcAEAAAAAAABwAQAAAAAAAHABAAAAAAAAcAEAABQAAAAAAAAAAAAAAIQBAAAAAAAAmA4A AAAAAACYDgAAAAAAAJgOAAAAAAAAmA4AAAwAAACkDgAAfAAAAIQBAAAAAAAACW0AADIBAAAsDwAA AAAAACwPAAAAAAAALA8AAAAAAAAsDwAAAAAAACwPAAAAAAAALA8AAAAAAAAsDwAAAAAAACwPAAAA AAAAiGwAAAIAAACKbAAAAAAAAIpsAAAAAAAAimwAAAAAAACKbAAAAAAAAIpsAAAAAAAAimwAACQA AAA7bgAAIAIAAFtwAACmAAAArmwAABUAAAAAAAAAAAAAAAAAAAAAAAAAcAEAAAAAAAAsDwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAsDwAAAAAAACwPAAAAAAAALA8AAAAAAAAsDwAAAAAAAK5sAAAAAAAA fhQAAAAAAABwAQAAAAAAAHABAAAAAAAALA8AAAAAAAAAAAAAAAAAACwPAAAAAAAAw2wAABYAAAB+ FAAAAAAAAH4UAAAAAAAAfhQAAAAAAAAsDwAAFgMAAHABAAAAAAAALA8AAAAAAABwAQAAAAAAACwP AAAAAAAAiGwAAAAAAAAAAAAAAAAAAH4UAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALA8AAAAAAACIbAAAAAAAAH4UAABICQAAfhQAAAAAAADGHQAA ZgMAAGBjAABwAgAAcAEAAAAAAABwAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbGoAAAAAAAAsDwAAAAAAACAPAAAMAAAAEH3il+9S wwGEAQAAFA0AAJgOAAAAAAAAQhIAAPoAAADQZQAARAAAAAAAAAAAAAAAbGoAABwCAADZbAAAMAAA AAltAAAAAAAAFGYAAFgEAAABcQAAAAAAADwTAABCAQAAAXEAAAAAAABsagAAAAAAAH4UAAAAAAAA hAEAAAAAAACEAQAAAAAAAHABAAAAAAAAcAEAAAAAAABwAQAAAAAAAHABAAAAAAAAAgDZAAAAQVJS SVMgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzIHRvIE1vdG9yb2xhknMgcHJvcG9zZWQgY2hhbmdl cyB0byBkcmFmdC1pZXRmLWlwY2RuLXBrdGMtc2lnbmFsaW5nLTAxLnR4dA0NRGF0ZTogMjUgSnVs eSAyMDAzDVBvaW50cyBvZiBDb250YWN0OiBSaWNrIE1vcnJpcywgQmlsbHkgSGFyZQ0NIEludHJv ZHVjdGlvbg1UaGUgY29tbWVudHMgcHJlc2VudGVkIGhlcmUgcmVwcmVzZW50IEFSUklTknMgcmV2 aWV3IGFuZCBjb21tZW50cyByZWxhdGVkIHRvIHN1Z2dlc3Rpb25zIG1hZGUgYnkgR29yZGVuIEJl YWNoYW0gKE1vdG9yb2xhKSB0byBtb2RpZnkgdGhlIGRyYWZ0LWlldGYtaXBjZG4tcGt0Yy1zaWdu YWxpbmctMDEudHh0IE1JQiByZXF1aXJlZCBmb3IgRXVyby1QYWNrZXRDYWJsZSBjZXJ0aWZpY2F0 aW9uLg0NQVJSSVMgd291bGQgd2VsY29tZSB0aGUgb3Bwb3J0dW5pdHkgdG8gZnVydGhlciBkaXNj dXNzIHRoZXNlIHJlY29tbWVuZCBjaGFuZ2VzIHdpdGggR29yZGVuLCB0Q29tTGFicyBhbmQgb3Ro ZXIgdmVuZG9ycyBwYXJ0aWNpcGF0aW5nIGluIHRoZSBFdXJvLVBhY2tldENhYmxlIGNlcnRpZmlj YXRpb24gcHJvY2Vzcy4NDUFSUklTIENvbW1lbnRzDU5vdGU6IFRoZSBzdWdnZXN0aW9uIG51bWJl ciBiZWxvdyBjb3JyZXNwb25kcyB0byB0aGUgTW90b3JvbGEgc3VnZ2VzdGlvbiBudW1iZXIgbGlz dGVkIGluIFNlY3Rpb24gMy4wLg0NU3VnZ2VzdGlvbiAxOiBBUlJJUyBhZ3JlZXMgdGhhdCB3ZSBz aG91bGQgb2Jzb2xldGUgdGhpcyBvYmplY3QuIFRoZSBFdXJvLVBhY2tldENhYmxlIHJlcXVpcmVk IGNvZGVjIHNwZWMgKHBrdC1zcC1jb2RlYy1JTzQtMDIxMDE4KSBkZWZpbmVzIGhvdyBNVEFzIG11 c3QgcHJvY2VzcyBzaW11bHRhbmVvdXMgY29kZWNzLg0NU3VnZ2VzdGlvbiAyOiBBUlJJUyBhZ3Jl ZXMgdGhhdCB0aGlzIG9iamVjdCBzaG91bGQgYmUgb2Jzb2xldGVkLiANDVN1Z2dlc3Rpb24gMzog QVJSSVMgYWdyZWVzIHRoYXQgUmluZ2luZyBGcmVxdWVuY3kgc2hvdWxkIGJlIHNwZWNpZmllZCBh dCBwcm92aXNpb25pbmcgdGltZS4gIFRoZSBuZWVkZWQgdmFsdWVzIGluY2x1ZGU6IA1Ob3J0aCBB bWVyaWNhICwgMjBoeiArLy0gMSBoeiwgKHBrdC1zcC1lbXRhLXByaW1hcnktSTAxKQ1FdXJvcGUs IDI1aHogKy8tIDMgaHosIGFuZCA1MCBoeiwgKy8tIDUgaHosIChFVFNJIEVOIDMwMCAwMDEpDUlu dGVybmF0aW9uYWwsIEphcGFuIDE2IGh6LCAtMSB0byArNCBoei4sIChOVFQgZWRpdGlvbiA1LCBN UFQpDUludGVybmF0aW9uYWwsIE90aGVyIA0gICAgIA1TdWdnZXN0aW9uIDQ6IEFSUklTIGFncmVl cyB0aGF0IHdlIHNob3VsZCBvYnNvbGV0ZSB0aGlzIG9iamVjdC4NDVN1Z2dlc3Rpb24gNTogQVJS SVMgYWdyZWVzIHRoYXQgd2Ugc2hvdWxkIG9ic29sZXRlIHRoaXMgb2JqZWN0LiANDVN1Z2dlc3Rp b24gNjogQVJSSVMgYWdyZWVzIHRoYXQgd2Ugc2hvdWxkIG9ic29sZXRlIHRoZXNlIG9iamVjdHMu DQ1TdWdnZXN0aW9uIDc6IEFSUklTIGhhcyBubyBpc3N1ZSB3aXRoIHRoaXMgc3VnZ2VzdGlvbi4N DVN1Z2dlc3Rpb24gODogQVJSSVMgYWdyZWVzIHdpdGggdGhlIHN1Z2dlc3RlZCBjaGFuZ2VzLg0N U3VnZ2VzdGlvbiA5OiBBUlJJUyBhZ3JlZXMgd2l0aCB0aGUgcmVjb21tZW5kZWQgbWluaW11bSBv ZiCWMjAgZEJtLCBidXQgZnVydGhlciByZWNvbW1lbmRzIHRoYXQgdGhlIGRlZmF1bHQgdmFsdWUg YmUgc2V0IHRvIGEgbGV2ZWwgd2hpY2ggd2lsbCBleGNlZWQgdGhlIHdvcnN0IGNhc2UgbWV0ZXIg cHVsc2UgcmVjZWl2ZXIgc2Vuc2l0aXZpdHkgaW4gdGhlIHBob25lLCBhcyBsaXN0ZWQgaW4gRU4g MzAwIDAwMSBWMS41LjEoMTk5OCkgVGFibGUgMS43LjguIEEgbGV2ZWwgb2YgljYgZGJtIChyZWwg OTAwIG9obXMpIGF0IHRoZSBsaW5lIGludGVyZmFjZSB3b3VsZCBnZW5lcmFsbHkgZW5zdXJlIHBy b3BlciBpbnRlcndvcmtpbmcgYmV0d2VlbiB0aGUgTVRBIGFuZCBDUEUgd2l0aG91dCB0aGUgbmVl ZCBmb3IgZnVydGhlciBhZGp1c3RtZW50Lg0NU3VnZ2VzdGlvbiAxMDogQVJSSVMgYWdyZWVzIHRo YXQgd2Ugc2hvdWxkIG9ic29sZXRlIHRoZSBUeC9SeCBnYWluIG9iamVjdHMuIA0NU3VnZ2VzdGlv biAxMTogQVJSSVMgYWdyZWVzIHRoYXQgdGhlc2Ugb2JqZWN0cyBhcmUgbWlzbGVhZGluZy4gSWYg dGhlIHB1cnBvc2UgaXMgdG8gcHJvdmlkZSBvbi9vZmYgaG9vayBzd2l0Y2ggZGVib3VuY2UgaW4g dGhlIHNob3J0IGludGVydmFsIG9mIDAgdG8gMjAgbXMsIGZvciBleGFtcGxlLCB0aGVuIEFSUklT IHN1Z2dlc3RzIHRoYXQgdGhlc2Ugb2JqZWN0cyBiZSByZW1vdmVkIGNvbXBsZXRlbHkuICBQcm92 aXNpb25pbmcgb2YgdGhlc2UgcmVxdWlyZW1lbnRzIHNob3VsZCBub3QgYmUgYWxsb3dlZCBzaW5j ZSB0aGV5IHdvdWxkIGludGVyYWN0IHdpdGggdGhlIGRpYWwgcHVsc2UgYWxnb3JpdGhtIGFuZCBz aG91bGQgYmUgZml4ZWQgaW4gdGhlIEVNVEEgZmlybXdhcmUuDQ1TdWdnZXN0aW9uIDEyOiAgQVJS SVMgcmVjb21tZW5kcyB0aGF0IHRoZSBvYmplY3RzIGxpc3RlZCBpbiBpdGVtIDEyIGJlbG93IGJl IG9ic29sZXRlZC4gIFRoZSBFTVRBIGludGVyZmFjZSBwYXJhbWV0ZXJzIHdpdGggQ1BFIGVuZC1k ZXZpY2UgKGhhbmRzZXQpIGFyZSBkZWZpbmVkIGluIEVUU0kgRU4gMzAwIDAwMSwgVGFibGUgNS4z LjEuMi4NDQ0zLjAgTW90b3JvbGEgU3VnZ2VzdGlvbnMgKGZvciByZWZlcmVuY2UpDVNvdXJjZTog U2lnbmFsaW5nIE1JQiBWZXJzaW9uIDEgT3BlbiBJc3N1ZXMgLSA2LzMwLzIwMDMsIEdvcmRlbiBC ZWFjaGFtLCBNb3Rvcm9sYQ0NIwdPYmplY3QHSXNzdWUHQWx0ZXJuYXRpdmVzBwcxB3BrdGNTaWdE ZXZDb2RlY1RhYmxlIHBrdGNTaWdEZXZDb2RlY0VudHJ5IHBrdGNTaWdEZXZDb2RlY0luZGV4IHBr dGNTaWdEZXZDb2RlY1R5cGUgcGt0Y1NpZ0RldkNvZGVjTWF4DQ1Ob3RlOiBhbHNvIGltcGFjdGVk IHBrdGNTaWdHcm91cAdUaGUgaW50ZW50IG9mIHRoaXMgdGFibGUgd2FzIHRvIGlkZW50aWZ5IHdo aWNoIENPREVDUyB0aGUgTVRBIGxvYWQgc3VwcG9ydHMgc2ltdWx0YW5lb3VzbHksIGZvciB1c2Ug Ynkgb3BlcmF0aW9ucyBzdGFmZi4NDVRoZSB0YWJsZSBhcyBkZWZpbmVkIGlzIGNvbmZ1c2luZyBh bmQgZG9lcyBub3QgYWRlcXVhdGVseSBhY2hpZXZlIGl0cyBpbnRlbnQuDQ1UaGlzIGluZm8gaXMg bm90IHVzZWZ1bCBjb25zaWRlcmluZyB0aGUgQ09ERUMgc3BlYyBUYWJsZS0yIGxpc3RzIGFsbCBQ QyBtYW5kYXRvcnkgQ09ERUMgY29tYmluYXRpb25zLgdPYnNvbGV0ZSB0aGVzZSBvYmplY3RzIChw cmVmZXJyZWQpLg1SZWRlZmluZSB0YWJsZSAoZS5nLiwgbGlzdCBhbGwgcG9zc2libGUgQ09ERUMg Y29tYmluYXRpb25zIGZvciBhbGwgcG9zc2libGUgZW5kLXBvaW50cykuBwcyB1BrdGNTaWdEZXZD b25uZWN0aW9uTW9kZQ0NTm90ZTogYWxzbyBpbXBhY3RlZCBwa3RjU2lnR3JvdXAHVGhpcyBvYmpl Y3QgZGVmaW5lcyB0aGUgY29ubmVjdGlvbiBtb2RlcyB0aGUgTVRBIGRldmljZSBjYW4gc3VwcG9y dC4NDVBDIHNwZWNzIHJlcXVpcmUgYWxsIHRocmVlIG1vZGVzIHRvIGJlIHN1cHBvcnRlZCBieSBh biBNVEEuIENvbnNlcXVlbnRseSwgdGhpcyBvYmplY3QgcHJvdmlkZXMgbm8gYWRkaXRpb25hbCBp bmZvcm1hdGlvbiBvZiB2YWx1ZS4HT2Jzb2xldGUgdGhpcyBvYmplY3QuBwczB3BrdGNTaWdQb3dl clJpbmdGcmVxdWVuY3kHU3VwcG9ydGluZyBhbGwgZnJlcXVlbmNpZXMgbGlzdGVkIGluIHRoaXMg b2JqZWN0IGhhcyBoYXJkd2FyZSBpbXBsaWNhdGlvbnMgKGUuZy4sIFNMSUNzIHN1cHBvcnQgZGlm ZmVyZW50IHJpbmdpbmcgZnJlcXVlbmNpZXMpLg0NRm9yIFBDLCBwZXIgdGhlIFBDIDEuMSBQUkkt TElORSBzcGVjICg4LjMuMykgYSByaW5naW5nIGZyZXF1ZW5jeSBvZiAyMCBIeiBpcyByZXF1aXJl ZC4gTm8gcmluZ2luZyBmcmVxdWVuY2llcyBhcmUgZGVmaW5lZCBhcyBtYW5kYXRvcnkgZm9yIEUt UEMuDQ1UaGlzIG9iamVjdCBpcyBpbnRlbmRlZCB0byBiZSBzZXQgdG8gdGhlIHZhbHVlIHVzZWQg aW4gYSBzcGVjaWZpYyBjb3VudHJ5LiBUaGUgTVRBIGFsc28gdXNlcyB0aGlzIG9iamVjdCB0byBj b25maWd1cmUgaXRzIHJpbmdpbmcgZnJlcXVlbmN5LiBUaGlzIG9iamVjdCBzaG91bGQgYmUgc2V0 IG9ubHkgdmlhIHRoZSBjb25maWd1cmF0aW9uIGZpbGUgc2ltaWxhciB0byBwa3RjTXRhRGV2Q21z SXBzZWNDdHJsIGluIHRoZSBNVEEgTUlCLgdNYWtlIG9iamVjdCByZWFkLW9ubHkgYW5kIGlzc3Vl IEVDUiB0byBQUk9WIChvciBDT0RFQykgc3BlYyB0byBpbmRpY2F0ZSB0aGlzIG9iamVjdCBtdXN0 IGJlIHNldCB2aWEgdGhlIGNvbmZpZyBmaWxlIChwcmVmZXJyZWQpDUFueSBwbGFucyB0byBkZWZp bmUgbWFuZGF0b3J5IHJpbmdpbmcgZnJlcXVlbmNpZXMgaW4gRS1QQz8gVGhlIGZyZXF1ZW5jaWVz IG5lZWRlZCBzaG91bGQgYmUgdGVzdGVkLiBUZXN0aW5nIHNob3VsZCBub3QgaW5jbHVkZSBhbGwg cG9zc2libGUgVVMgYW5kIEludGVybmF0aW9uYWwgZnJlcXVlbmNpZXMuBwc0B1BrdGNTaWdQQ01D b2RpbmcNDU5vdGU6IGFsc28gaW1wYWN0ZWQgcGt0Y0ludGVybmF0aW9uYWxHcm91cAdUaGlzIG9i amVjdCBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYyBhbmQgdGhlcmUgaXMgbm8gbmVlZCB0byBo YXZlIG9wZXJhdGlvbnMgc3RhZmYgY29udHJvbC4HT2Jzb2xldGUgdGhpcyBvYmplY3QHBzUHcGt0 Y05jc0VuZFBudENvbmZpZ05vbUppdHRlckJ1ZmZlclNpemUgcGt0Y05jc0VuZFBudENvbmZpZ01h eEppdHRlckJ1ZmZlclNpemUgDQ1Ob3RlOiBhbHNvIGltcGFjdGVkOg1Qa3RjTmNzRW5kUG50Q29u ZmlnRW50cnkHVGhlc2Ugb2JqZWN0cyBhcmUgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMgZm9yIGEg TVRBIERTUCBzb2Z0d2FyZSBhcmNoaXRlY3R1cmUgYW5kIG5vdCBleHBlY3RlZCB0byBiZSBvZiB1 c2UgdG8gb3BlcmF0aW9ucyBzdGFmZi4HT2Jzb2xldGUgdGhlc2Ugb2JqZWN0cwcHNgdQa3RjU2ln RGV2VG9uZVR5cGUHVGhpcyB0YWJsZSB3YXMgb3JpZ2luYWxseSBkZXNpZ25lZCB0byBlYXNlIE1U QSBpbXBsZW1lbnRhdGlvbiBhbmQga2VlcCB0aGUgdG9uZSBkZWZpbml0aW9uIHBhcmFtZXRlcnMg YWxsIGluIHRoZSBzYW1lIHBsYWNlLiBTaW5jZSB0aGUgRFRNRiB0b25lcyBhcmUgZGVmaW5lZCB0 aGUgc2FtZSB3b3JsZHdpZGUsIGl0IGRvZXMgbm90IG1ha2Ugc2Vuc2UgdG8gY2hhbmdlIHRoZW0g YW5kIGl0IGlzIHByb2JhYmx5IG5vdCBtdWNoIHZhbHVlIHRvIGJlIGFibGUgdG8gcmVhZCB0aGVt IGZyb20gdGhlIE1JQi4NDUFsc28gdGhlIGluZGV4IHZhbHVlIGluIHRoZSBkZXNjcmlwdGlvbiBm b3IgdGhlIHRhYmxlIGlzIGluYWNjdXJhdGUgYXMgdGhlIHRhYmxlIGRvZXMgbm90IGNvbnRhaW4g NDkgZW50cmllcy4NDVRoZXJlIGlzIG9ubHkgb25lIHVzZXIgZGVmaW5hYmxlIHRvbmUgaW4gdGhl IHRhYmxlLiBPdXIgVm9JUCB0cmlhbCBleHBlcmllbmNlIHN1Z2dlc3RzIGluY3JlYXNpbmcgdGhp cyB0byBhIHRvdGFsIG9mIGZvdXIgdXNlciBkZWZpbmFibGUgdG9uZXMgd291bGQgYmUgYmV0dGVy LgdPYnNvbGV0ZSBEVE1GIDAtMTUgZW50cmllcyBmcm9tIHRoaXMgdGFibGUgKEUtUEMgc3BlY3Mg YWxyZWFkeSBpbmRpY2F0ZSB0aGVzZSBvYmplY3RzIE1VU1QgTk9UIGJlIHVzZWQpIChwcmVmZXJy ZWQpDUxlYXZlIHRhYmxlIGFzIGlzIGFuZCBub3RlIHRoYXQgdGhlIERUTUYgdG9uZXMgc2hvdWxk IG5vdCBiZSByZWRlZmluZWQuIEEgdmlldyBjYW4gYmUgZGVmaW5lZCBvbiB0aGUgT1NTIHRoYXQg YWxsb3dzIHJlYWQtb25seSBhY2Nlc3MgdG8gdGhlc2UgZW50cmllcw0NT3RoZXIgQ2hhbmdlOg0N QWRkIDMgYWRkaXRpb25hbCB1c2VyIGRlZmluZWQgdG9uZXMgKHVzZXJEZWZpbmVkMigzNSksIHVz ZXJEZWZpbmVkMygzNSksIHVzZXJEZWZpbmVkNCgzNSkpBwc3B3BrdGNTaWdQdWxzZVNpZ25hbER1 cmF0aW9uLCBwa3RjU2lnUHVsc2VTaWduYWxQYXVzZUR1cmF0aW9uB1RoZSBtaW5pbXVtIHNwZWNp ZmllZCBpbiBUYWJsZSAxLjcuOCBvZiBFTiAzMDAgMDAxIFYxLjUuMSBpcyA1MG1zLgdDaGFuZ2Ug U1lOVEFYIHRvIDUwLi41MDAwIGZvciBib3RoIG9iamVjdHMuBwc4B3BrdGNTaWdQdWxzZVNpZ25h bEZyZXF1ZW5jeQdUaGUgc2lnbmlmaWNhbmNlIG9mIHplcm8gaXMgdW5jbGVhci4NDUZyb20gUGhp bDogIkVOIDMwMCAwMDEgb2ZmZXJzIGd1aWRhbmNlIHRoYXQgdGhlIDUwIEh6IHRvbmUgaXMgdXNl ZCBpbiBsb25nIGxpbmUgYXBwbGljYXRpb25zIChjb21wZW5zYXRpb24gZm9yIGxvc3Mgb2YgdGhl IGhpZ2hlciBmcmVxdWVuY2llcyBvZiAxMi8xNiBrSHopLiAgU2luY2UgUGFja2V0Q2FibGUgYW5k IElQQ2FibGVjb20gYXJlIHNwZWNpZmllZCBhdCBvbmx5IDE1MCBtZXRlcnMsIHRoZSBuZWVkIGZv ciA1MCBIeiBjYW4gYmUgd2F2ZWQgYW5kIG9ubHkgdGhlIDEyIGtIeiBhbmQgMTYga0h6IHNlcnZp Y2VzIG5lZWQgdG8gYmUgc3VwcG9ydGVkLiIHQ2xhcmlmeSBNSUIgb2JqZWN0IGRlc2NyaXB0aW9u IHRvIGluZGljYXRlIHRoYXQgInplcm8iIGlzIHVzZWQgdG8gdHVybiBvZmYgbWV0ZXIgcHVsc2Uu DU9ic29sZXRlICJmaWZ0eSAoMikiLg1DaGFuZ2UgZGVzY3JpcHRpb24gdG8gdXNlICJ0d2VsdmV0 aG91c2FuZCIgbm90ICJmaWZ0eSIuDUNoYW5nZSBERUZWQUwgdG8gYmUgInR3ZWx2ZXRob3VzYW5k IiBub3QgImZpZnR5Ii4HBzkHcGt0Y1NpZ1B1bHNlU2lnbmFsRGJMZXZlbAdUaGUgcmFuZ2UgbGlt aXRzIGFyZSBicm9hZCBhbmQgdGhlIHVwcGVyIGxpbWl0IGlzIHRvbyBoaWdoIHNpbmNlIGl0IHdh cyBiYXNlZCBvbiBQU1ROIGxvbmcgbG9vcCByZXF1aXJlbWVudHMuIEZvciBQQy9FLVBDLCB0aGUg YXBwbGljYXRpb24gaXMgc2hvcnQgbG9vcCAoPCAxMDAwIGZlZXQpLCBhbmQgdGhlIHJhbmdlIGNh biBiZSBhZGp1c3RlZCB0byAtMjAgdG8gKzMgZEJtLg0NRnJvbSBQaGlsOiAiIFBlciBFTiAzMDAg MDAxIHRoZSBsYXJnZXN0IHNpZ25hbCBsZXZlbCBmb3Igdm9pY2UgYmFuZCB0b25lcyBpcyAwIGRC bS4gIENvbnNpZGVyaW5nIEcuNzExIFBDTSBjb2RpbmcgYWxsb3dzIGFtcGxpdHVkZXMgc2xpZ2h0 bHkgYWJvdmUgICsgMyBkQm0sIGl0IHdvdWxkIGFwcGVhciB0aGF0IHRoZSB2b2ljZSBiYW5kIHRv bmUgbWF4aW11bSBzcGVjaWZpY2F0aW9uIGNvdWxkIGJlIHNldCB0byArMyBkQm0gYW5kIG1lZXQg dGhlIGludGVudCBvZiB0aGUgRVRTSSBzcGVjaWZpY2F0aW9uLg0NRU4gMzAwIDAwMSBhbHNvIHBy b3ZpZGVzIHRoZSBtaW5pbXVtIGxldmVscyBmb3Igdm9pY2UgYmFuZCB0b25lcy4gIFdoaWxlIHRo ZXJlIGlzIGEgbGFyZ2UgcmFuZ2Ugb2YgYW1wbGl0dWRlcyBpbiB0aGUgTmF0aW9uYWwgZGlzdHJp YnV0aW9uLCBhIG1pbmltdW0gdmFsdWUgb2YgliAyMCBkQm0gd291bGQgbWVldCBtb3N0IG5hdGlv bmFsIHJlcXVpcmVtZW50cyBmb3IgdXNlciBURS4iB0NoYW5nZSBTWU5UQVggdG8gLTIwMC4uMzAu BwcxMAdwa3RjTmNzRW5kUG50Q29uZmlnVHhHYWluLCBwa3RjTmNzRW5kUG50Q29uZmlnUnhHYWlu B1RoZXNlIG9iamVjdHMgYXJlIERTUCBpbXBsZW1lbnRhdGlvbiBkZXBlbmRlbnQuIFRoZXNlIG9i amVjdHMgd291bGQgYWxzbyBhbGxvdyBvcGVyYXRpb25zIHBlcnNvbm5lbCB0byBhZGp1c3QgdGhl IERTUCBhbmQgcG90ZW50aWFsbHkgaW5qZWN0IG5vaXNlIG9yIG11dGluZyBpbnRvIHRoZSBhdWRp byBzdHJlYW0uB09ic29sZXRlIHRoZXNlIG9iamVjdHMuBwcxMQdwa3RjTmNzRW5kUG50Q29uZmln T2ZmSG9va0RlYm91bmNlLCBwa3RjTmNzRW5kUG50Q29uZmlnT25Ib29rRGVib3VuY2UHSXQgaXMg dW5jbGVhciB3aGF0IHRoZXNlIG9iamVjdHMgYXJlIGRlZmluaW5nIGFuZCB0aGUgb2JqZWN0IGRl c2NyaXB0aW9ucyBhcmUgbWlzbGVhZGluZy4HQ2hhbmdlIHRoZSBtaW5pbXVtIHJhbmdlIHRvIDUw IG1zLg1PYnNvbGV0ZSBvYmplY3RzIGFuZCBkZWZpbmUgbmV3IG9iamVjdHMgd2hpY2ggYXJlIHRo ZSBtaW4vbWF4IHJlcG9ydGluZyB0aW1lcyBmb3Igb24vb2ZmIGhvb2sgZGV0ZWN0aW9uIChlLmcu LCBwa3RjTmNzRW5kUG50Q29uZmlnT2ZmSG9va0RlYm91bmNlTWluL01heCAtICJUaGUgbWluL21h eCB0aW1lIHRvIHdhaXQgYmVmb3JlIHJlcG9ydGluZyBvZmYgaG9vayBkZXRlY3Rpb24iLCBwa3Rj TmNzRW5kUG50Q29uZmlnT25Ib29rRGVib3VuY2VNYXggLSAiIFRoZSBtaW4vbWF4IHRpbWUgdG8g d2FpdCBiZWZvcmUgcmVwb3J0aW5nIG9uIGhvb2tkZXRlY3Rpb24gIi4HBzEyB3BrdGNOY3NFbmRQ bnRDb25maWdQdWxzZURpYWxJbnRlcmRpZ2l0VGltZSwgcGt0Y05jc0VuZFBudENvbmZpZ1B1bHNl RGlhbE1pbk1ha2VUaW1lLCBwa3RjTmNzRW5kUG50Q29uZmlnUHVsc2VEaWFsTWF4TWFrZVRpbWUs IHBrdGNOY3NFbmRQbnRDb25maWdQdWxzZURpYWxNaW5CcmVha1RpbWUsIHBrdGNOY3NFbmRQbnRD b25maWdQdWxzZURpYWxNYXhCcmVha1RpbWUsIHBrdGNOY3NFbmRQbnRDb25maWdNaW5Ib29rRmxh c2gsIHBrdGNOY3NFbmRQbnRDb25maWdNYXhIb29rRmxhc2gHVGhlIG1pbmltdW0gcmFuZ2UgZm9y IHRoZWUgb2JqZWN0cyBzaG91bGQgYmUgYmFzZWQgb24gYSByZWFsLXdvcmxkIG1pbmltdW0gKGUu Zy4sIDIwbXMpIHNpbmNlIHRoZSBsb3dlc3QgbWFrZSB0aW1lIGlzIDI3IG1zIHBlciBFTiAzMDAg MDAxIHRhYmxlIDUuMy4xLjIuB0NoYW5nZSBTWU5UQVggbWluaW11bSB0byAyMCBtcyBmb3IgYWxs IG9iamVjdHMgZXhjZXB0IHBrdGNOY3NFbmRQbnRDb25maWdQdWxzZURpYWxJbnRlcmRpZ2l0VGlt ZSwgd2hpY2ggYWxyZWFkeSBoYXMgYSBtaW5pbXVtIG9mIDEwMCBtcy4HBw0NAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGkEAACmBAAAqAQAALYEAABN BgAAYgYAAMMGAADEBgAAAgkAAEkJAABKCQAAiQkAAEUMAABGDAAAfw4AAKsOAAD+DgAAGw8AADEP AAAyDwAARg8AAEcPAABbDwAAXA8AAG8PAABwDwAApQ8AAB8QAACLEgAARRQAAEoUAACWFAAApxcA AMUZAADGGQAA1hkAAIwbAADPGwAATBwAAH8dAADXHQAA2B0AAO0dAADuHQAAJR4AACYeAABXHgAA TCEAAE0hAAAmJgAAJyYAALMmAAAA+gD3APMA8wDuAO4A6QDzAOEA1gDWANYA1gDTANPP0wDTANMA 0wDM0wDTANMA0wDTAMoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADDCoHBGFKEgAABz4qAWFK FAAEYUoUAAAUQ0oUAE9KAwBRSgMAXkoDAGFKFAAADzUIgUIqCFwIgXBo////AAlCKgZwaP8AAAAI Q0oWAGFKFgAABjUIgVwIgQAEQ0oYAAAKNQiBQ0oYAFwIgTQABAAAaAQAAGkEAAB8BAAApwQAAKgE AAC2BAAAlwUAAJgFAABMBgAATQYAAFwGAADDBgAAxAYAAHoHAAB7BwAAvQcAAL4HAAA3CAAAcAgA AK4IAADtCAAAAwkAAAkJAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAA AAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAA AAD2AAAAAAAAAAAAAAAA5gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA9gAA AAAAAAAAAAAAAOYAAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAANgAAAAAAAAA AAAAAADYAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BQAAD4SEA16EhAMOAAAKJgILRgkADcYHASQJAewEBg+E7ARehOwEAAUQAA+EAABehAAABQAACiYA C0YfAAUBAAomAAtGHwAAAQAAAAQPAAMkAGEkAAABDwAAFwAEAACzJgAA/QAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAQAAQEBCQkAAEkJAABKCQAAiwkAAIwJAADOCQAA zwkAAAYKAAAHCgAAPgoAAD8KAADoCwAA6QsAADYMAAA3DAAAuw0AALwNAACADgAAgQ4AAIIOAACr DgAA/Q4AAP4OAAAADwAABw8AAA0PAADsAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAA AAAAAADqAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA 6gAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOoAAAAA AAAAAAAAAADkAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAA AAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoA AAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAFiQBSWYBAAAAAAUQAA+EAABehAAAAAEAABMAAA3GEQAF AABwCEALEA7gEAAAAAAAEmTwAAAANyQAOCQASCQAABkNDwAAGg8AABsPAAAdDwAAgw8AAIQPAACl DwAAHhAAAB8QAAD5AAAAAAAAAAAAAAAARtwIAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAA AACyAAAWJAEXJAFJZgEAAAAClmwABdYYBgEJAAYBCQAGAQkABgEJAAYBCQAGAQkACNZcAAQw/QT/ 4AdUGDQjAAbUAQAAAAAAAAAAAAAAAAAAAAAABtwIAAAAAAAAAAAAAAAAAAAAAAAGdBAAAAAAAAAA AAAAAAAAAAAAAAbgCgAAAAAAAAAAAAAAAAAAAAAJ1ggJBQkFCQUJBQp0FwC/ABLWKAAAgAD///8A AQAAAIAA////AAEAAACAAP///wABAAAAgAD///8AAQAT1jAAAIAABgEAAAAAgAAGAQAAAACAAAYB AAAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAU9gMEJhf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8A AAD/G9YQAAAA/wAAAP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8A AAD/NNYGAAEKA2wAYfYDnP0GAAAWJAFJZgEAAAAACB8QAABtEAAAbhAAANQQAAD4EAAAUREAAFIR AABUEQAAbREAAG4RAACPEQAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAABXdAQAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAACXAAAWJAEXJAFJZgEAAAAClmwABdYY BgEJAAYBCQAGAQkABgEJAAYBCQAGAQkACNZcAAQw/QT/4AdUGDQjAAbUAQAAAAAAAAAAAAAAAAAA AAAABtwIAAAAAAAAAAAAAAAAAAAAAAAGdBAAAAAAAAAAAAAAAAAAAAAAAAbgCgAAAAAAAAAAAAAA AAAAAAAKdBcAvwAT1jAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAAACA AAYBAAAU9gMEJhf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAAAP8AAAD/AAAA /xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDnP0ACQAA CiYAC0YBABYkAUlmAQAAAAYAABYkAUlmAQAAAAAKjxEAANQRAADVEQAAWBIAAG4SAABvEgAAcRIA AIsSAAALEwAADBMAAJ0TAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAAV1wNAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAJcAABYkARckAUlmAQAAAAKWbAAF1hgG AQkABgEJAAYBCQAGAQkABgEJAAYBCQAI1lwABDD9BP/gB1QYNCMABtQBAAAAAAAAAAAAAAAAAAAA AAAG3AgAAAAAAAAAAAAAAAAAAAAAAAZ0EAAAAAAAAAAAAAAAAAAAAAAABuAKAAAAAAAAAAAAAAAA AAAAAAp0FwC/ABPWMAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAA BgEAABT2AwQmF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/ HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gOc/QAJAAAK JgALRgIAFiQBSWYBAAAABgAAFiQBSWYBAAAAAAqdEwAAnhMAAJcUAAAXFQAAxRUAAMYVAADIFQAA 2RUAANoVAAAFFgAAYxYAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8A AAAAAAAAAAAAAABXzAIAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAA AAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAAAlwAAFiQBFyQBSWYBAAAAApZsAAXWGAYB CQAGAQkABgEJAAYBCQAGAQkABgEJAAjWXAAEMP0E/+AHVBg0IwAG1AEAAAAAAAAAAAAAAAAAAAAA AAbcCAAAAAAAAAAAAAAAAAAAAAAABnQQAAAAAAAAAAAAAAAAAAAAAAAG4AoAAAAAAAAAAAAAAAAA AAAACnQXAL8AE9YwAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAAgAAG AQAAFPYDBCYX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c 1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2A5z9AAkAAAom AAtGBAAWJAFJZgEAAAAGAAAWJAFJZgEAAAAACmMWAAB4FgAAeRYAAHsWAADKFgAAyxYAAOAWAAD5 FgAAehcAAPUAAAAAAAAAAAAAAABdZAQAAAAAAAAAAAAAVwAAAAAAAAAAAAAAAFcAAAAAAAAAAAAA AABXAAAAAAAAAAAAAAAAVwAAAAAAAAAAAAAAAFcAAAAAAAAAAAAAAABXAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAABYkAUlmAQAAAACXAAAWJAEXJAFJZgEA AAAClmwABdYYBgEJAAYBCQAGAQkABgEJAAYBCQAGAQkACNZcAAQw/QT/4AdUGDQjAAbUAQAAAAAA AAAAAAAAAAAAAAAABtwIAAAAAAAAAAAAAAAAAAAAAAAGdBAAAAAAAAAAAAAAAAAAAAAAAAbgCgAA AAAAAAAAAAAAAAAAAAAKdBcAvwAT1jAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAA gAAGAQAAAACAAAYBAAAU9gMEJhf2AwAAGPYDAAAa1hAAAAD/AAAA/wAAAP8AAAD/G9YQAAAA/wAA AP8AAAD/AAAA/xzWEAAAAP8AAAD/AAAA/wAAAP8d1hAAAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wA YfYDnP0ACQAACiYAC0YFABYkAUlmAQAAAAAIehcAAJEXAACSFwAAlBcAAKcXAADHGAAAyBgAADYZ AAA3GQAA9QAAAAAAAAAAAAAAAF3wDgAAAAAAAAAAAABXAAAAAAAAAAAAAAAAVwAAAAAAAAAAAAAA AEwAAAAAAAAAAAAAAABMAAAAAAAAAAAAAAAATAAAAAAAAAAAAAAAAEwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAACgAAFiQBNyQAOCQASCQASWYBAAAABgAAFiQBSWYBAAAAAJcAABYkARckAUlmAQAA AAKWbAAF1hgGAQkABgEJAAYBCQAGAQkABgEJAAYBCQAI1lwABDD9BP/gB1QYNCMABtQBAAAAAAAA AAAAAAAAAAAAAAAG3AgAAAAAAAAAAAAAAAAAAAAAAAZ0EAAAAAAAAAAAAAAAAAAAAAAABuAKAAAA AAAAAAAAAAAAAAAAAAp0FwC/ABPWMAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAAACA AAYBAAAAAIAABgEAABT2AwQmF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA/wAAAP8b1hAAAAD/AAAA /wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh 9gOc/QAJAAAKJgALRgcAFiQBSWYBAAAAAAg3GQAA1xkAAEsaAADiGgAA4xoAAPEaAADyGgAATRsA APQAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAA AAAAAAAAAAAA5AAAAAAAAAAAAAAAANoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAkAAAomAAtGGgAWJAFJZgEAAAAGAAAWJAFJZgEAAAAACQAACiYAC0YJABYkAUlmAQAA AAAKAAAWJAE3JAA4JABIJABJZgEAAAAAB00bAABOGwAAUBsAAIwbAADPGwAA+xsAAPwbAAD+GwAA GhwAAGe4AgAAAAAAAAAAAABhAAAAAAAAAAAAAAAAYQAAAAAAAAAAAAAAAFYAAAAAAAAAAAAAAABM AAAAAAAAAAAAAAAAZ3QJAAAAAAAAAAAAAGEAAAAAAAAAAAAAAABhAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAkAAAomAAtGCgAWJAFJZgEAAAAACgAAFiQBNyQAOCQASCQASWYBAAAABgAAFiQBSWYB AAAAAJcAABYkARckAUlmAQAAAAKWbAAF1hgGAQkABgEJAAYBCQAGAQkABgEJAAYBCQAI1lwABDD9 BP/gB1QYNCMABtQBAAAAAAAAAAAAAAAAAAAAAAAG3AgAAAAAAAAAAAAAAAAAAAAAAAZ0EAAAAAAA AAAAAAAAAAAAAAAABuAKAAAAAAAAAAAAAAAAAAAAAAp0FwC/ABPWMAAAgAAGAQAAAACAAAYBAAAA AIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAABT2AwQmF/YDAAAY9gMAABrWEAAAAP8AAAD/ AAAA/wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/ AAAA/wAAAP801gYAAQoDbABh9gOc/QAIGhwAAD8cAABAHAAAgB0AANgdAADuHQAAJh4AAFgeAABZ HgAA9AAAAAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoA AAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAFJADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAlwAAFiQBFyQBSWYBAAAAApZsAAXWGAYBCQAGAQkABgEJAAYBCQAG AQkABgEJAAjWXAAEMP0E/+AHVBg0IwAG1AEAAAAAAAAAAAAAAAAAAAAAAAbcCAAAAAAAAAAAAAAA AAAAAAAABnQQAAAAAAAAAAAAAAAAAAAAAAAG4AoAAAAAAAAAAAAAAAAAAAAACnQXAL8AE9YwAACA AAYBAAAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAFPYDBCYX9gMAABj2 AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8A AAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2A5z9AAkAAAomAAtGEAAWJAFJZgEAAAAA CgAAFiQBNyQAOCQASCQASWYBAAAAAAhZHgAAWx4AAHUeAABNHwAATh8AAHAgAABxIAAATSEAAGgh AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA+QAA AAAAAAAAAAAAAPkAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQAACiYAC0YSABYkAUlmAQAAAAAKAAAWJAE3JAA4JABI JABJZgEAAAAGAAAWJAFJZgEAAAAACGghAABpIQAAbCEAAKEhAABVIgAAbSIAAG4iAABxIgAAtyIA AGcUBAAAAAAAAAAAAABhAAAAAAAAAAAAAAAAYQAAAAAAAAAAAAAAAFYAAAAAAAAAAAAAAABMAAAA AAAAAAAAAAAAZyQIAAAAAAAAAAAAAGEAAAAAAAAAAAAAAABhAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAkAAAomAAtGFAAWJAFJZgEAAAAACgAAFiQBNyQAOCQASCQASWYBAAAABgAAFiQBSWYBAAAA AJcAABYkARckAUlmAQAAAAKWbAAF1hgGAQkABgEJAAYBCQAGAQkABgEJAAYBCQAI1lwABDD9BP/g B1QYNCMABtQBAAAAAAAAAAAAAAAAAAAAAAAG3AgAAAAAAAAAAAAAAAAAAAAAAAZ0EAAAAAAAAAAA AAAAAAAAAAAABuAKAAAAAAAAAAAAAAAAAAAAAAp0FwC/ABPWMAAAgAAGAQAAAACAAAYBAAAAAIAA BgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAABT2AwQmF/YDAAAY9gMAABrWEAAAAP8AAAD/AAAA /wAAAP8b1hAAAAD/AAAA/wAAAP8AAAD/HNYQAAAA/wAAAP8AAAD/AAAA/x3WEAAAAP8AAAD/AAAA /wAAAP801gYAAQoDbABh9gOc/QAItyIAABEjAAA0IwAAdiQAAHckAAB6JAAAjSUAACcmAAD0AAAA AAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAABS6AgAAAAAAAAAAAAATAAAAAAAAAAA AAAAAEwAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAGAAAWJAFJZgEAAAAAlwAAFiQBFyQBSWYBAAAAApZsAAXWGAYBCQAGAQkABgEJAAYBCQAGAQkA BgEJAAjWXAAEMP0E/+AHVBg0IwAG1AEAAAAAAAAAAAAAAAAAAAAAAAbcCAAAAAAAAAAAAAAAAAAA AAAABnQQAAAAAAAAAAAAAAAAAAAAAAAG4AoAAAAAAAAAAAAAAAAAAAAACnQXAL8AE9YwAACAAAYB AAAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAFPYDBCYX9gMAABj2AwAA GtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAAAP8c1hAAAAD/AAAA/wAAAP8AAAD/ HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2A5z9AAkAAAomAAtGFgAWJAFJZgEAAAAACgAA FiQBNyQAOCQASCQASWYBAAAAAAcnJgAAsCYAALEmAACyJgAAsyYAAPUAAAAAAAAAAAAAAABdAAAA AAAAAAAAAAAAWwAAAAAAAAAAAAAAAFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAlwAAFiQBFyQBSWYBAAAAApZsAAXW GAYBCQAGAQkABgEJAAYBCQAGAQkABgEJAAjWXAAEMP0E/+AHVBg0IwAG1AEAAAAAAAAAAAAAAAAA AAAAAAbcCAAAAAAAAAAAAAAAAAAAAAAABnQQAAAAAAAAAAAAAAAAAAAAAAAG4AoAAAAAAAAAAAAA AAAAAAAACnQXAL8AE9YwAACAAAYBAAAAAIAABgEAAAAAgAAGAQAAAACAAAYBAAAAAIAABgEAAAAA gAAGAQAAFPYDBCYX9gMAABj2AwAAGtYQAAAA/wAAAP8AAAD/AAAA/xvWEAAAAP8AAAD/AAAA/wAA AP8c1hAAAAD/AAAA/wAAAP8AAAD/HdYQAAAA/wAAAP8AAAD/AAAA/zTWBgABCgNsAGH2A5z9AAkA AAomAAtGGAAWJAFJZgEAAAAABCAAMZBoAR+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAFAARAAoAAQBpAA8AAwAAAAAAAAAAADgAAEDx/wIAOAAMAAYATgBv AHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABtSAkEc0gJBHRICQRSAAFAAQACAFIADAAJAEgA ZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYAHgA1CIFDSiAAS0ggAE9KAgBRSgIA XAiBXkoCAGFKIAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAwBFgBEAGUAZgBhAHUAbAB0ACAA UABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADYAQmABAPIANgAMAAkAQgBv AGQAeQAgAFQAZQB4AHQAAAAIAA8AAyQBYSQBCgA1CIFDSiAAXAiBPABDYAEAAgE8AAwAEABCAG8A ZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUAbgB0AAAACgAQAA+EaAFehGgBAAAAAAAAsyIAABYAAEoA ABcA/////wAAAABoAAAAaQAAAHwAAACnAAAAqAAAALYAAACXAQAAmAEAAEwCAABNAgAAXAIAAMMC AADEAgAAegMAAHsDAAC9AwAAvgMAADcEAABwBAAArgQAAO0EAAADBQAACQUAAEkFAABKBQAAiwUA AIwFAADOBQAAzwUAAAYGAAAHBgAAPgYAAD8GAADoBwAA6QcAADYIAAA3CAAAuwkAALwJAACACgAA gQoAAIIKAACrCgAA/QoAAP4KAAAACwAABwsAAA0LAAAaCwAAGwsAAB0LAACDCwAAhAsAAKULAAAe DAAAHwwAAG0MAABuDAAA1AwAAPgMAABRDQAAUg0AAFQNAABtDQAAbg0AAI8NAADUDQAA1Q0AAFgO AABuDgAAbw4AAHEOAACLDgAACw8AAAwPAACdDwAAng8AAJcQAAAXEQAAxREAAMYRAADIEQAA2REA ANoRAAAFEgAAYxIAAHgSAAB5EgAAexIAAMoSAADLEgAA4BIAAPkSAAB6EwAAkRMAAJITAACUEwAA pxMAAMcUAADIFAAANhUAADcVAADXFQAASxYAAOIWAADjFgAA8RYAAPIWAABNFwAAThcAAFAXAACM FwAAzxcAAPsXAAD8FwAA/hcAABoYAAA/GAAAQBgAAIAZAADYGQAA7hkAACYaAABYGgAAWRoAAFsa AAB1GgAATRsAAE4bAABwHAAAcRwAAE0dAABoHQAAaR0AAGwdAAChHQAAVR4AAG0eAABuHgAAcR4A ALceAAARHwAANB8AAHYgAAB3IAAAeiAAAI0hAAAnIgAAsCIAALEiAACyIgAAtSIAAJgAAAAPMAAA AAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAAAACAAAAAgJgAAAAPMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgAgAHyABMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA qAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAA AJgAHyAAMAEAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgA AAAQMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAQMAAAAAAAAACAqAAAAJgAAAAA MAAAAAAAAACAqAAAAJgAAAAQMAAAAAAAAACAqAAAAJgCCSAAMAAAAAAAAACAqAAAAJgCCSAAMAEA AAAAAACAqAAAAJgCCSAAMAIAAAAAAACAqAAAAJgCCSAAMAMAAAAAAACAqAAAAJgAAAAAMAAAAAAA AACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACA qAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAQMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAA AJgAAAAQMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAQMAAAAAAAAACAqAAAAJgA AAAAMAAAAAAAAACAqAAAAJgAAAAQMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAQ MAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAA AAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAA AACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACAqAAAAJgAAAAAMAAAAAAAAACA qAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAA AKkAAAAAMAAAAAAAAACAqAAAAJkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkA AAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAA MAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAA AAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAASAAMAAAAAAAAACAqAAAAKkAASAAMAEAAAAA AACAqAAAAJkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACA qAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAA AKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAiAAMAAAAAAAAACAqAAAAJkA AAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAA MAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAA AAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkABCAAMAAAAAAAAACAqAAAAKkABCAAMAEAAAAA AACAqAAAAJkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACA qAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAA AKkABSAAMAAAAAAAAACAqAAAAJkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkA AAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAA MAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAByAAMAAAAAAAAACAqAAAAJkAAAAAMAAA AAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAA AACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACAqAAAAKkAAAAAMAAAAAAAAACA qAAAAKkAAAAAMAAAAAAAAACAqAAAAKkACSAAMAEAAAAAAACAqAAAAKkACSAAMAIAAAAAAACAqAAA AKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkA GiAAMAAAAAAAAACAaQAAAJkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAA MAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkACiAAMAAAAAAAAACAaQAAAJkAAAAAMAAA AAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAA AACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAECAAMAAAAAAAAACA aQAAAKkAECAAMAEAAAAAAACAaQAAAKkAECAAMAIAAAAAAACAaQAAAKkAECAAMAMAAAAAAACAaQAA AJkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkA AAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAA MAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAEiAAMAAAAAAAAACAaQAAAJkAAAAAMAAA AAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAA AACAaQAAAKkAFCAAMAAAAAAAAACAaQAAAJkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACA aQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAFiAAMAAAAAAAAACAaQAA AKkAFiAAMAEAAAAAAACAaQAAAJkAAAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkA AAAAMAAAAAAAAACAaQAAAKkAAAAAMAAAAAAAAACAaQAAAKkAGCAAMAAAAAAAAACAaQAAAJkAAAAA MAAAAAAAAACAaQAAAJgAAAAAMAAAAAAAAACAaQAAAJgAAAAAMAAAAAAAAACAAAAAgAAEAACzJgAA FAAAAAAEAAAJCQAADQ8AAB8QAACPEQAAnRMAAGMWAAB6FwAANxkAAE0bAAAaHAAAWR4AAGghAAC3 IgAAJyYAALMmAAAVAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEA AAAiAAAAIwAAACQAAAAABAAAsyYAABYAAAAAAAAA3AAAAOMAAAAXAQAAHQEAAB4BAAAlAQAA7AEA APIBAABTAwAAVwMAALEDAAC6AwAAUgQAAFQEAACDBAAAhQQAAI4EAACQBAAAmAQAAJoEAADGBAAA yAQAANMEAADVBAAAfgYAAIEGAABTBwAAVgcAAFgHAABbBwAAmgcAAKYHAAAhCAAAIwgAAKYIAACu CAAACQoAABIKAADkCgAA6goAAOsKAADyCgAAHQsAADELAAAyCwAARgsAAEcLAABbCwAAXAsAAG8L AABwCwAAggsAAJgLAACkCwAAVA0AAGwNAACCDQAAjg0AAHEOAACKDgAA3Q4AAOIOAABwEAAAhhAA AMgRAADYEQAA7hEAAAQSAAB7EgAAoRIAAKISAADIEgAA4BIAAPgSAACUEwAAphMAAFAXAABqFwAA bBcAAIsXAAD+FwAAGRgAAPQYAAD+GAAACRoAABcaAAA7GgAASRoAAFsaAAB0GgAASBsAAEsbAACd GwAAoBsAAOYbAADpGwAAPRwAAEAcAAAVHQAAGB0AAGwdAACFHQAAhx0AAKAdAABxHgAAkx4AAJUe AAC2HgAAox8AAMgfAAAPIAAAMyAAAGUgAAByIAAAeiAAAKQgAACmIAAAzSAAAM8gAAD2IAAA+CAA ACAhAAAiIQAASiEAAEwhAABrIQAAbSEAAIwhAABdIgAAhyIAALUiAAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAAAAAAD0EAABGBAAA1QQAANcEAAArBwAAMgcAAKsKAAD8CgAAHQsA ADELAABxDgAAig4AAKoPAAC/DwAAexIAAKESAAAnEwAALBMAAAEVAAALFQAAsRUAALUVAAAXFwAA JBcAAFAXAABqFwAA4hcAAOQXAAD+FwAAGRgAAFsaAAB0GgAAYh0AAGQdAABsHQAAhR0AAHEeAACT HgAAeiAAAKQgAAC1IgAABwAzAAcAMwAHADMABwAEAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHAAAAAABnAAAApgAAAJYBAABL AgAAAgMAAAIDAAATAwAAFAMAAEgDAABJAwAAXgMAAF8DAABYBQAAXwUAAGMFAABkBQAAmgUAAKEF AAClBQAAzQUAABUGAAAcBgAAIAYAAD0GAAD4BwAA/wcAAAMIAAAVCAAARggAAFMIAADSCAAA0wgA AN8IAADgCAAAHwkAACAJAACsCQAArQkAALkJAAC6CQAA5QkAAOUJAADuCQAAEgoAAIEKAACBCgAA qwoAALMKAADiCgAA5AoAALIiAACyIgAAtSIAAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwD//xQAAAAHAG0AbwByAHIAaQBzAHIAYwBDADoAXABDAGUAcgB0 AGkAZgBpAGMAYQB0AGkAbwBuAFwARQB1AHIAbwAtAEMAZQByAHQAaQBmAGkAYwBhAHQAaQBvAG4A XABFAHUAcgBvAFAAYQBjAGsAZQB0AEMAYQBiAGwAZQBcAGEAcgByAGkAcwAtAHIAZQBwAGwAeQAt AHMAaQBnAG0AaQBiAC0AMAAxAC0AbwB1AHQAcwB0AGEAbgBkAGkAbgBnAC0AaQBzAHMAdQBlAHMA XwB2ADQALgBkAG8AYwAHAG0AbwByAHIAaQBzAHIAYwBDADoAXABDAGUAcgB0AGkAZgBpAGMAYQB0 AGkAbwBuAFwARQB1AHIAbwAtAEMAZQByAHQAaQBmAGkAYwBhAHQAaQBvAG4AXABFAHUAcgBvAFAA YQBjAGsAZQB0AEMAYQBiAGwAZQBcAGEAcgByAGkAcwAtAHIAZQBwAGwAeQAtAHMAaQBnAG0AaQBi AC0AMAAxAC0AbwB1AHQAcwB0AGEAbgBkAGkAbgBnAC0AaQBzAHMAdQBlAHMAXwB2ADQALgBkAG8A YwAHAG0AbwByAHIAaQBzAHIAYwBDADoAXABDAGUAcgB0AGkAZgBpAGMAYQB0AGkAbwBuAFwARQB1 AHIAbwAtAEMAZQByAHQAaQBmAGkAYwBhAHQAaQBvAG4AXABFAHUAcgBvAFAAYQBjAGsAZQB0AEMA YQBiAGwAZQBcAGEAcgByAGkAcwAtAHIAZQBwAGwAeQAtAHMAaQBnAG0AaQBiAC0AMAAxAC0AbwB1 AHQAcwB0AGEAbgBkAGkAbgBnAC0AaQBzAHMAdQBlAHMAXwB2ADQALgBkAG8AYwAHAG0AbwByAHIA aQBzAHIAhgBDADoAXABEAG8AYwB1AG0AZQBuAHQAcwAgAGEAbgBkACAAUwBlAHQAdABpAG4AZwBz AFwAcgBtAG8AcgByAGkAcwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0AGEAXABNAGkA YwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2 AGUAIABvAGYAIABhAHIAcgBpAHMALQByAGUAcABsAHkALQBzAGkAZwBtAGkAYgAtADAAMQAtAG8A dQB0AHMAdABhAG4AZABpAG4AZwAtAGkAcwBzAHUAZQBzAF8AdgA0AC4AYQBzAGQABwBtAG8AcgBy AGkAcwByAGMAQwA6AFwAQwBlAHIAdABpAGYAaQBjAGEAdABpAG8AbgBcAEUAdQByAG8ALQBDAGUA cgB0AGkAZgBpAGMAYQB0AGkAbwBuAFwARQB1AHIAbwBQAGEAYwBrAGUAdABDAGEAYgBsAGUAXABh AHIAcgBpAHMALQByAGUAcABsAHkALQBzAGkAZwBtAGkAYgAtADAAMQAtAG8AdQB0AHMAdABhAG4A ZABpAG4AZwAtAGkAcwBzAHUAZQBzAF8AdgA0AC4AZABvAGMABwBtAG8AcgByAGkAcwByAGMAQwA6 AFwAQwBlAHIAdABpAGYAaQBjAGEAdABpAG8AbgBcAEUAdQByAG8ALQBDAGUAcgB0AGkAZgBpAGMA YQB0AGkAbwBuAFwARQB1AHIAbwBQAGEAYwBrAGUAdABDAGEAYgBsAGUAXABhAHIAcgBpAHMALQBy AGUAcABsAHkALQBzAGkAZwBtAGkAYgAtADAAMQAtAG8AdQB0AHMAdABhAG4AZABpAG4AZwAtAGkA cwBzAHUAZQBzAF8AdgA0AC4AZABvAGMABwBtAG8AcgByAGkAcwByAGMAQwA6AFwAQwBlAHIAdABp AGYAaQBjAGEAdABpAG8AbgBcAEUAdQByAG8ALQBDAGUAcgB0AGkAZgBpAGMAYQB0AGkAbwBuAFwA RQB1AHIAbwBQAGEAYwBrAGUAdABDAGEAYgBsAGUAXABhAHIAcgBpAHMALQByAGUAcABsAHkALQBz AGkAZwBtAGkAYgAtADAAMQAtAG8AdQB0AHMAdABhAG4AZABpAG4AZwAtAGkAcwBzAHUAZQBzAF8A dgA0AC4AZABvAGMABwBtAG8AcgByAGkAcwByAIYAQwA6AFwARABvAGMAdQBtAGUAbgB0AHMAIABh AG4AZAAgAFMAZQB0AHQAaQBuAGcAcwBcAHIAbQBvAHIAcgBpAHMAXABBAHAAcABsAGkAYwBhAHQA aQBvAG4AIABEAGEAdABhAFwATQBpAGMAcgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBS AGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAYQByAHIAaQBzAC0AcgBlAHAAbAB5AC0A cwBpAGcAbQBpAGIALQAwADEALQBvAHUAdABzAHQAYQBuAGQAaQBuAGcALQBpAHMAcwB1AGUAcwBf AHYANAAuAGEAcwBkAAcAbQBvAHIAcgBpAHMAcgBjAEMAOgBcAEMAZQByAHQAaQBmAGkAYwBhAHQA aQBvAG4AXABFAHUAcgBvAC0AQwBlAHIAdABpAGYAaQBjAGEAdABpAG8AbgBcAEUAdQByAG8AUABh AGMAawBlAHQAQwBhAGIAbABlAFwAYQByAHIAaQBzAC0AcgBlAHAAbAB5AC0AcwBpAGcAbQBpAGIA LQAwADEALQBvAHUAdABzAHQAYQBuAGQAaQBuAGcALQBpAHMAcwB1AGUAcwBfAHYANAAuAGQAbwBj AAcAbQBvAHIAcgBpAHMAcgCGAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUA dAB0AGkAbgBnAHMAXAByAG0AbwByAHIAaQBzAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAARABh AHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUA cgB5ACAAcwBhAHYAZQAgAG8AZgAgAGEAcgByAGkAcwAtAHIAZQBwAGwAeQAtAHMAaQBnAG0AaQBi AC0AMAAxAC0AbwB1AHQAcwB0AGEAbgBkAGkAbgBnAC0AaQBzAHMAdQBlAHMAXwB2ADQALgBhAHMA ZAAfAGJI8gEaVBIR/w//D/8P/w//D/8P/w//D/8PEABRYx4CDpCW1f8P/w//D/8P/w//D/8P/w// DxAAv1WJB6rjvnH/D/8P/w//D/8P/w//D/8P/w8QACdXgQwSzmTE/w//D/8P/w//D/8P/w//D/8P EADLIUIWfPJg7/8P/w//D/8P/w//D/8P/w//DxAA/XaCG3raAjr/D/8P/w//D/8P/w//D/8P/w8Q AEJ6DyHsEPoD/w//D/8P/w//D/8P/w//D/8PEAApTK479p+IR/8P/w//D/8P/w//D/8P/w//DxAA 6USSParjvnH/D/8P/w//D/8P/w//D/8P/w8QAAd2CT/sCFSa/w//D/8P/w//D/8P/w//D/8PEABh UYhA7BD6A/8P/w//D/8P/w//D/8P/w//DxAATSMkRgiSGO7/D/8P/w//D/8P/w//D/8P/w8QANtf skZ62gI6/w//D/8P/w//D/8P/w//D/8PEACRTXFIMtzy7f8P/w//D/8P/w//D/8P/w//DxAA9EJl UkzGMKD/D/8P/w//D/8P/w//D/8P/w8QADZ0MFTewyjX/w//D/8P/w//D/8P/w//D/8PAABzMR5Y NtTkf/8P/w//D/8P/w//D/8P/w//DxAAZ3fBWTJxVkL/D/8P/w//D/8P/w//D/8P/w8QACsKPlxo Z/R6/w//D/8P/w//D/8P/w//D/8PEABySltcNtTkf/8P/w//D/8P/w//D/8P/w//DxAAciscXqw1 nt//D/8P/w//D/8P/w//D/8P/w8QAC15ymMaVBIR/w//D/8P/w//D/8P/w//D/8PEAA+C3tk7AhU mv8P/w//D/8P/w//D/8P/w//DxAAgzo0ZQiSGO7/D/8P/w//D/8P/w//D/8P/w8QAMElQWZMxjCg /w//D/8P/w//D/8P/w//D/8PEADbB15wCJIY7v8P/w//D/8P/w//D/8P/w//DxAASAwScQiSGO7/ D/8P/w//D/8P/w//D/8P/w8QALgvenSCU37G/w//D/8P/w//D/8P/w//D/8PEAAHIEd33sMo1/8P /w//D/8P/w//D/8P/w//DwAA4ibhfAhAJqv/D/8P/w//D/8P/w//D/8P/w8QAIkmLn2o+tQ8/w// D/8P/w//D/8P/w//D/8PEAABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUA AdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXG BQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4V xgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+ FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM /xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGE mP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYR hJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZ EYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TQ AhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAP hHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAA D4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgA AA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAY AAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAA GAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAA ABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAA AAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAABABAAAAAAAAAAAAaAEAAAAA AAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAA AAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAA AAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEA AAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABo AQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAA aAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgAAAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAATGAAAD4TcBRGEmP4VxgUAAdwFBl6E3AVghJj+T0oEAFBKAABRSgQAXkoAAG8o AAEA8PABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SsCBGEmP4VxgUAAawIBl6ErAhghJj+ T0oDAFFKAwBeSgMAbygAh2gAAAAAiEgAAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAA D4R8CxGEmP4VxgUAAXwLBl6EfAtghJj+T0oEAFFKBABvKACHaAAAAACISAAAAQCn8AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAABUYAAAPhEwOEYSY/hXGBQABTA4GXoRMDmCEmP5PSgEAUUoBAG8oAIdo AAAAAIhIAAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+EHBERhJj+FcYFAAEcEQZe hBwRYISY/k9KAwBRSgMAXkoDAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAAFRgAAA+E7BMRhJj+FcYFAAHsEwZehOwTYISY/k9KBABRSgQAbygAh2gAAAAAiEgAAAEAp/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4S8FhGEmP4VxgUAAbwWBl6EvBZghJj+T0oBAFFK AQBvKACHaAAAAACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABkYAAAPhIwZEYSY/hXG BQABjBkGXoSMGWCEmP5PSgMAUUoDAF5KAwBvKACHaAAAAACISAAAAQBvAAEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAABUYAAAPhFwcEYSY/hXGBQABXBwGXoRcHGCEmP5PSgQAUUoEAG8oAIdoAAAAAIhI AAABAKfwAQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCE mP5vKAACAAEAKQABAAAABAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4QkCRGEmP4VxgUAASQJBl6E JAlghJj+bygAAgACACkAAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFA CwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXGBQAB EA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8VxgUA AeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+FcYF AAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY/hXG BQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGETP8V xgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+ FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygAAQC38AEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAY AAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAA GAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAA ABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAA AAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAA AAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAA AAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAA AAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEA AAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAAuAAEAAAAEkAEAAAAAAAAAAABo AQAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAA aAEAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAA AGgBAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAA AAAAaAEAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAMAAQAA AAAAAAAAAAAAAAAAAAAAAxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/m8oAAIAAAApAAEAAAAE gAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP6HaAAAAACISAAA AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EQAsRhEz/FcYFAAFACwZehEALYIRM /4doAAAAAIhIAAACAAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4QQDhGEmP4VxgUA ARAOBl6EEA5ghJj+h2gAAAAAiEgAAAIAAwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAP hOAQEYSY/hXGBQAB4BAGXoTgEGCEmP6HaAAAAACISAAAAgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAA AAAAAAAAChgAAA+EsBMRhEz/FcYFAAGwEwZehLATYIRM/4doAAAAAIhIAAACAAUALgABAAAAAIAB AAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+h2gAAAAAiEgAAAIA BgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP6H aAAAAACISAAAAgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EIBwRhEz/FcYFAAEg HAZehCAcYIRM/4doAAAAAIhIAAACAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQ AhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAAASQAQAAAAAAAAAAAGgBAAAA AAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAA AAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEA AAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABo AQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAA aAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAABABAAAAAAAA AAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAA AAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEA AAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJAB AAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQ AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAAC kgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBv KAABALfwAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY /gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCE TP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtg hJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAO YISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTg EGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6E sBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZe hIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkG XoRQGWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdAC Bl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAI EYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RA CxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E EA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAP hOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAA D4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAY AAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAA GAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAA ABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAA AAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAA AAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAA AAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAA AAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEA AAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABo AQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAABABAAAAAAAAAAAA aAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAA AAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAA AAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEA AAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAABAB AAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQ AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAAC kgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAA AJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAA AASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEA AAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgAB AAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4A AQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAu AAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgA LgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TRARGEL/4VxgUAAdEBBl6E0QFghC/+bygA AwAAAC4AMAABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAADGAAAD4ShBBGEL/4VxgUAAaEEBl6EoQRg hC/+bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAAD4RwCBGEMP0VxgUAAXAI Bl6EcAhghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAAxgAAA+EQAsR hDD9FcYFAAFACwZehEALYIQw/W8oAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAAAAAAAAAA AAAAAAADGAAAD4R4DxGEyPsVxgUAAXgPBl6EeA9ghMj7bygACQAAAC4AAQAuAAIALgADAC4ABAAB AAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4RIEhGEyPsVxgUAAUgSBl6ESBJghMj7bygACwAA AC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxgAAA+EgBYRhGD6 FcYFAAGAFgZehIAWYIRg+m8oAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUH CQsNDwAAAAAAAAAAAAADGAAAD4RQGRGEYPoVxgUAAVAZBl6EUBlghGD6bygADwAAAC4AAQAuAAIA LgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADGAAAD4SIHRGE+PgV xgUAAYgdBl6EiB1ghPj4bygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAA AAAQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAAuAAEA AAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgAB AAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4A AQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAu AAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQA LgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAF AC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIA BgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4C AAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/ AgAIAC4AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY /k9KAQBRSgEAbygAAQC38AEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXGBQAB oAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8VxgUA AXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+FcYF AAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY/hXG BQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGETP8V xgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAWEYSY /hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQGRGE TP8VxgUAAVAZBl6EUBlghEz/AgAIAC4ABQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/m8oAAIAAAApAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAP hHAIEYSY/hXGBQABcAgGXoRwCGCEmP6HaAAAAACISAAAAgABAC4AAQAAAAKCAQAAAAAAAAAAAAAA AAAAAAAAChgAAA+EQAsRhEz/FcYFAAFACwZehEALYIRM/4doAAAAAIhIAAACAAIALgABAAAAAIAB AAAAAAAAAAAAAAAAAAAAAAAKGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+h2gAAAAAiEgAAAIA AwAuAAEAAAAEgAEAAAAAAAAAAAAAAAAAAAAAAAoYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP6H aAAAAACISAAAAgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAChgAAA+EsBMRhEz/FcYFAAGw EwZehLATYIRM/4doAAAAAIhIAAACAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAKGAAAD4SA FhGEmP4VxgUAAYAWBl6EgBZghJj+h2gAAAAAiEgAAAIABgAuAAEAAAAEgAEAAAAAAAAAAAAAAAAA AAAAAAoYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP6HaAAAAACISAAAAgAHAC4AAQAAAAKCAQAA AAAAAAAAAAAAAAAAAAAAChgAAA+EIBwRhEz/FcYFAAEgHAZehCAcYIRM/4doAAAAAIhIAAACAAgA LgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oB AFFKAQBvKAABALfwAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgG XoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUAL Bl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB 4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUA AbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXG BQABUBkGXoRQGWCETP8CAAgALgABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4V xgUAAdACBl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM /xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGE mP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4R hJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQ EYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4Sw ExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E gBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAP hFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAA D4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAAASQAQAAAAAAAAAAAGgB AAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABo AQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAA aAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAA AABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAA AAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAFxAAAAAA AAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfw AQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAu AAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIA LgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgAD AC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIA BAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8C AAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY /gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCE TP8CAAgALgABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJg hJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAF YISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRw CGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAG XoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbAT Bl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQAB UBkGXoRQGWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUA AdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAP hHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAA D4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgA AA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAY AAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAA GAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAA ABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAA AAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAAASQAQAAAAAA AAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAA AAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAA AAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAA AAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEA AAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJAB AAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQ AQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAAC kgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAA FxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFFKAQBv KAABALfwAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY /gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCE TP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtg hJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAO YISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTg EGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6E sBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZe hIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkG XoRQGWCETP8CAAgALgABAAAAABABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TQAhGEmP4VxgUAAdAC Bl6E0AJghJj+AgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EoAURhJj+FcYFAAGg BQZehKAFYISY/gIAAQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhHAIEYRM/xXGBQAB cAgGXoRwCGCETP8CAAIALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RACxGEmP4VxgUA AUALBl6EQAtghJj+AgADAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EEA4RhJj+FcYF AAEQDgZehBAOYISY/gIABAAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhOAQEYRM/xXG BQAB4BAGXoTgEGCETP8CAAUALgABAAAAAJABAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4SwExGEmP4V xgUAAbATBl6EsBNghJj+AgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EgBYRhJj+ FcYFAAGAFgZehIAWYISY/gIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhFAZEYRM /xXGBQABUBkGXoRQGWCETP8CAAgALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TRARGE L/4VxgUAAdEBBl6E0QFghC/+bygAAwAAAC4AMAABAAAAAAABAwAAAAAAAAAAAAAAAAAAAAADGAAA D4ShBBGEL/4VxgUAAaEEBl6EoQRghC/+bygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAA AAADGAAAD4RwCBGEMP0VxgUAAXAIBl6EcAhghDD9bygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAA AAAAAAAAAAAAAAAAAxgAAA+EQAsRhDD9FcYFAAFACwZehEALYIQw/W8oAAcAAAAuAAEALgACAC4A AwABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAADGAAAD4R4DxGEyPsVxgUAAXgPBl6EeA9ghMj7bygA CQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4RIEhGEyPsV xgUAAUgSBl6ESBJghMj7bygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAA AAAAAAAAAAAAAxgAAA+EgBYRhGD6FcYFAAGAFgZehIAWYIRg+m8oAA0AAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADGAAAD4RQGRGEYPoVxgUAAVAZBl6E UBlghGD6bygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEA AAAAAAAAAAADGAAAD4SIHRGE+PgVxgUAAYgdBl6EiB1ghPj4bygAEQAAAC4AAQAuAAIALgADAC4A BAAuAAUALgAGAC4ABwAuAAgAAQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E0AIRhJj+FcYF AAHQAgZehNACYISY/gIAAAAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhKAFEYSY/hXG BQABoAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RwCBGETP8V xgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EQAsRhJj+ FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhBAOEYSY /hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4TgEBGE TP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+EsBMR hJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAPhIAW EYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAAD4RQ GRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AAQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAAABgAAA+E 0AIRhJj+FcYFAAHQAgZehNACYISY/gIAAAAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAYAAAP hKAFEYSY/hXGBQABoAUGXoSgBWCEmP4CAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAAGAAA D4RwCBGETP8VxgUAAXAIBl6EcAhghEz/AgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAABgA AA+EQAsRhJj+FcYFAAFACwZehEALYISY/gIAAwAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAAAAAY AAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP4CAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAA GAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAA ABgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/gIABgAuAAEAAAAEkAEAAAAAAAAAAABoAQAAAAAA AAAYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP4CAAcALgABAAAAApIBAAAAAAAAAAAAaAEAAAAA AAAAGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/AgAIAC4AHwAAAHIrHF4AAAAAAAAAAAAAAAAH dgk/AAAAAAAAAAAAAAAAPgt7ZAAAAAAAAAAAAAAAALgvenQAAAAAAAAAAAAAAAC/VYkHAAAAAAAA AAAAAAAA6USSPQAAAAAAAAAAAAAAAPRCZVIAAAAAAAAAAAAAAADBJUFmAAAAAAAAAAAAAAAAyyFC FgAAAAAAAAAAAAAAAIM6NGUAAAAAAAAAAAAAAADbB15wAAAAAAAAAAAAAAAAYkjyAQAAAAAAAAAA AAAAAC15ymMAAAAAAAAAAAAAAACJJi59AAAAAAAAAAAAAAAATSMkRgAAAAAAAAAAAAAAAFFjHgIA AAAAAAAAAAAAAABIDBJxAAAAAAAAAAAAAAAAczEeWAAAAAAAAAAAAAAAAHJKW1wAAAAAAAAAAAAA AADbX7JGAAAAAAAAAAAAAAAA/XaCGwAAAAAAAAAAAAAAAEJ6DyEAAAAAAAAAAAAAAABhUYhAAAAA AAAAAAAAAAAAkU1xSAAAAAAAAAAAAAAAAGd3wVkAAAAAAAAAAAAAAADiJuF8AAAAAAAAAAAAAAAA Kwo+XAAAAAAAAAAAAAAAACdXgQwAAAAAAAAAAAAAAAApTK47AAAAAAAAAAAAAAAAByBHdwAAAAAA AAAAAAAAADZ0MFQAAAAAAAAAAAAAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8fAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//x8AAAASAA8ACQQZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSANZhtOkD AAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBGBrTBVowAYEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgABAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAsGcyvBkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgABAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAAQAJBBkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgABAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZ AAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkE DwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQAABIADwAJ BBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgABAAkEGQAJBBsACQQPAAkEGQAJBBsA CQQPAAkEGQAJBBsACQQSALTUrOsZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAAQAJ BBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsA CQQPAAkEGQAJBBsACQQSAAEACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAAQAJ BBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgAPAAkEGQAJBBsACQQPAAkEGQAJBBsA CQQPAAkEGQAJBBsACQQSAAEACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBBIAAQAJ BBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgABAAkEGQAJBBsACQQPAAkEGQAJBBsA CQQPAAkEGQAJBBsACQQSAA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJBAAAEgAP AAkEGQAJBBsACQQPAAkEGQAJBBsACQQPAAkEGQAJBBsACQQSAA8ACQQZAAkEGwAJBA8ACQQZAAkE GwAJBA8ACQQZAAkEGwAJBAAAAAD+CgAAAAsAAAcLAAANCwAAGgsAABsLAAAdCwAApQsAANQMAABR DQAAUg0AAFQNAACPDQAAWA4AAG4OAABvDgAAcQ4AAIsOAACXEAAAxREAAMYRAADIEQAABRIAAGMS AAB4EgAAeRIAAHsSAAD5EgAAehMAAJETAACSEwAAlBMAAKcTAADXFQAATRcAAE4XAABQFwAAjBcA AM8XAAD7FwAA/BcAAP4XAAAaGAAAgBkAAFgaAABZGgAAWxoAAHUaAABNHQAAaB0AAGkdAABsHQAA oR0AAFUeAABtHgAAbh4AAHEeAAC3HgAAER8AAHYgAAB3IAAAeiAAAI0hAAAnIgAAsCIAALEiAAC1 IgAAAAAAAAgAAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAACeAQAEAgEAAAIB AAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAACeAQAEAgEA AAIBAAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAACeAQAE AgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAACe AQAEAgEAAAIBAAACAQAAAgEAAJ4BAAQCAQAAAgEAAAIBAAACAQAAlgEABP9AA4ABAOQKAADkCgAA QMR0AAEAAQDkCgAAAAAAAOQKAAAAAAAAAhAAAAAAAAAAsyIAAGABAAgAQAAA//8BAAAABwBVAG4A awBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAA AAUAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAA TgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAA AAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAA QQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBId6ACAAAACACAAAAAAAAAD/AQAAAAAAAEMAbwB1 AHIAaQBlAHIAIABOAGUAdwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAA AABXAGkAbgBnAGQAaQBuAGcAcwAAACIABABxCIgYAPDQAgAAaAEAAAAABMx3pjvMd6Z7cncmFQA3 AAAABAUAAJwcAAABAA4AAAAEAAMQPQAAAD4FAADjHQAAAQAPAAAAPwAAAAAAAAAhAwDwEAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIB6AFtAC0AIGBMjAAABAAGQBkAAAAGQAAACIjAAAhIwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADiFgAAAAAAAAAAAAAAAAAAAAAA AAAAAgAAAAAAAAAAAAwzg1EA8BAACNwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAD//xIA AAAAAAAALwBTAGkAZwBuAGEAbABpAG4AZwAgAE0ASQBCACAAVgBlAHIAcwBpAG8AbgAgADEAIABP AHAAZQBuACAASQBzAHMAdQBlAHMAIAAtACAANgAvADMAMAAvADIAMAAwADMAAAAAAAAACABNAG8A dABvAHIAbwBsAGEABwBtAG8AcgByAGkAcwByAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EI ACsns9kwAAAAmAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAANAAAAAEAAAA3AAAAAUAAADwAAAA BwAAAPwAAAAIAAAAEAEAAAkAAAAgAQAAEgAAACwBAAAKAAAASAEAAAsAAABUAQAADAAAAGABAAAN AAAAbAEAAA4AAAB4AQAADwAAAIABAAAQAAAAiAEAABMAAACQAQAAAgAAAOQEAAAeAAAAMAAAAFNp Z25hbGluZyBNSUIgVmVyc2lvbiAxIE9wZW4gSXNzdWVzIC0gNi8zMC8yMDAzAB4AAAABAAAAAGln bh4AAAAJAAAATW90b3JvbGEAIE1JHgAAAAEAAAAAb3RvHgAAAAsAAABOb3JtYWwuZG90AEkeAAAA CAAAAG1vcnJpc3IAHgAAAAMAAAAyMQByHgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAb0AAAAAA CvSuBwAAAEAAAAAAKkkTEErDAUAAAAAAOD/j51LDAUAAAAAAQjOS71LDAQMAAAABAAAAAwAAAAQF AAADAAAAnBwAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP7/AAAFAAIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAA ACABAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACEAAAABgAAAIwAAAARAAAAlAAAABcAAACcAAAA CwAAAKQAAAAQAAAArAAAABMAAAC0AAAAFgAAALwAAAANAAAAxAAAAAwAAAAAAQAAAgAAAOQEAAAe AAAACQAAAE1vdG9yb2xhAAAgAAMAAAA9AAAAAwAAAA4AAAADAAAAIiMAAAMAAADtDgkACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAADAAAABTaWduYWxpbmcgTUlCIFZlcnNp b24gMSBPcGVuIElzc3VlcyAtIDYvMzAvMjAwMwAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAA AA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAA HQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAA/v///ycAAAAoAAAAKQAAACoAAAAr AAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkA AAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAA AEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAA VgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAA/v///2AAAABhAAAAYgAAAGMAAABk AAAAZQAAAGYAAAD+////aAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAP7////9////cQAAAP7/ ///+/////v////////////////////////////////////////////////////////////////// /1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAMDJCJjv UsMBcwAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAmAAAAAXEAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQUAAAD//////////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiSgAAAAAAAAUAUwB1AG0AbQBhAHIA eQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAA AAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAXwAAAAAQAAAAAAAA BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAA AAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABnAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAQEAAAAGAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABqAAAAAAAAAE8AYgBqAGUAYwB0AFAAbwBvAGwAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAEA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAADAyQiY71LDAcDJCJjvUsMBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB AAAA/v////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////wEA /v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYYAAAATWljcm9zb2Z0IFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_000_01C35530.E3817850-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 09:50:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22709 for ; Tue, 29 Jul 2003 09:50:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUra-0003Sy-1g for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 09:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TDo2ds013319 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 09:50:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUrY-0003Sb-W4; Tue, 29 Jul 2003 09:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hUrU-0003SJ-LW for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 09:49:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22690 for ; Tue, 29 Jul 2003 09:49:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hUrS-0005cq-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 09:49:54 -0400 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 19hUrR-0005cn-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 09:49:54 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id h6TDnrG7014611 for ; Tue, 29 Jul 2003 06:49:53 -0700 (MST) Received: from ca25exm01.GI.COM (ca25exm01.w1.bcs.mot.com [168.84.84.121]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h6TDnorx015258 for ; Tue, 29 Jul 2003 08:49:51 -0500 Received: by ca25exm01 with Internet Mail Service (5.5.2657.2) id ; Tue, 29 Jul 2003 06:49:51 -0700 Message-ID: From: Beacham Gordon-CGB005 To: "'ipcdn@ietf.org'" Date: Tue, 29 Jul 2003 06:49:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C355D7.AECC0362" Subject: [ipcdn] RE: Publication of PacketCable IETF MIBs - SIG draft 01 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C355D7.AECC0362 Content-Type: text/plain It has been brought to my attention that a pending PC Signaling MIB ECO should be considered for item 1 (pktcSigDevCodecTable). Instead of obsoleting pktcSigDevCodecTable, the suggestion is to adopt the changes in sigmib-o-03004-v2 as the new definition for the pktcSigDevCodecTable, and only obsolete the pktcSigDevCodecMax object. Gordon -----Original Message----- From: Beacham Gordon-CGB005 Sent: Monday, July 28, 2003 10:52 AM To: 'ipcdn@ietf.org' Subject: FW: Publication of PacketCable IETF MIBs - SIG draft 01 Rick, Thanks for your review of the signaling MIB recommendations and for providing additional suggestions. For items 1-5 and 7,8, and 10 there is substantial agreement, and I have made the changes as indicated in the open issues list (as posted on the IPCDN web site and included in your document), however, there is one minor exception on item 8. It turns out that sixteenthousand is more commonly used than twelvethousand. Consequently, the description and default are recommended to be sixteenthousand not twelvethousand. For item 9, Motorola agrees with the default change recommended. For item 11, Motorola agrees with the recommendation to obsolete these objects. These objects are product hardware design issues. For item 6, Motorola, after further review determined that there is already an object for setting the level for dtmf or any other tone (pktcSigDevToneDbLevel), which can vary by geographic location. Consequently, the only change recommended for item 6 then is the addition of 3 user defined tones. For item 12, Motorola does not agree with obsoleting these objects. The dial pulse objects vary by geographic location (e.g., NA, Europe, Japan, etc), and need to be retained in order to be adjusted as necessary by the operator. Gordon Beacham Digital Core Gateways, BCS Motorola, Inc. 858-404-2335 gordon.beacham@motorola.com -----Original Message----- From: Rick.Morris@arrisi.com [mailto:Rick.Morris@arrisi.com] Sent: Friday, July 25, 2003 2:08 PM To: Wim De Ketelaere Cc: Gordon Beacham; billy.hare@arrisi.com; walter.daniel@arrisi.com Subject: Re: Fw: Publication of PacketCable IETF MIBs - SIB draft 01 Wim and Gorden, I apologize for the length of time it has taken me to get this response back to you. However, we wanted to make sure that we had thoroughly reviewed and considered each of Gorden's suggestions. Please distribute our comments to your list as appropriate. I would like to say that Gorden has done an excellent job of scoping out several suggested changes. The attached document from ARRIS contains any agreements with his recommendations, along with a couple of additional comments. ARRIS would be very interested with discussing our comments with you, and others on your distribution list at your convenience. Thank you both for your efforts in working to clean up this MIB's contents. With the joint cooperation of tComLabs and the MTA vendors, I feel confident we can all move towards a successful certification wave in ECW13. Regards, Rick Morris ARRIS, SrMgr - Engineering, Certification and Standards +001 770 622 8619 "Wim De Ketelaere" 07/03/2003 01:53 PM To: cc: Subject: Fw: Publication of PacketCable IETF MIBs - SIB draft 01 Hi Rick, Here's the document ! Thanks, Best regards, Wim ------_=_NextPart_001_01C355D7.AECC0362 Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KDQoNCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA2LjAwLjI4MDAuMTE0MSIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gY2xhc3M9MDQ2MzM0 NTEzLTI5MDcyMDAzPkl0IGhhcyANCmJlZW4gYnJvdWdodCB0byBteSBhdHRlbnRpb24gdGhhdCBh IHBlbmRpbmcgUEMgU2lnbmFsaW5nIE1JQiBFQ08gc2hvdWxkIGJlIA0KY29uc2lkZXJlZCBmb3Ig aXRlbSAxIChwa3RjU2lnRGV2Q29kZWNUYWJsZSkuPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTA0NjMz NDUxMy0yOTA3MjAwMz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MDQ2MzM0NTEzLTI5MDcy MDAzPkluc3RlYWQgb2Ygb2Jzb2xldGluZyBwa3RjU2lnRGV2Q29kZWNUYWJsZSwgdGhlIA0Kc3Vn Z2VzdGlvbiBpcyB0byBhZG9wdCB0aGUgY2hhbmdlcyBpbiBzaWdtaWItby0wMzAwNC12MiBhcyB0 aGUgbmV3IGRlZmluaXRpb24gDQpmb3IgdGhlIHBrdGNTaWdEZXZDb2RlY1RhYmxlLCBhbmQgb25s eSBvYnNvbGV0ZSB0aGUgcGt0Y1NpZ0RldkNvZGVjTWF4IA0Kb2JqZWN0LjwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQpjbGFzcz0wNDYzMzQ1MTMtMjkwNzIwMDM+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTA0 NjMzNDUxMy0yOTA3MjAwMz5Hb3Jkb248L1NQQU4+PC9GT05UPjwvRElWPg0KPEJMT0NLUVVPVEU+ DQogIDxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgZGlyPWx0ciBhbGlnbj1sZWZ0PjxG T05UIGZhY2U9VGFob21hIA0KICBzaXplPTI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+ PEI+RnJvbTo8L0I+IEJlYWNoYW0gR29yZG9uLUNHQjAwNSANCiAgPEJSPjxCPlNlbnQ6PC9CPiBN b25kYXksIEp1bHkgMjgsIDIwMDMgMTA6NTIgQU08QlI+PEI+VG86PC9CPiANCiAgJ2lwY2RuQGll dGYub3JnJzxCUj48Qj5TdWJqZWN0OjwvQj4gRlc6IFB1YmxpY2F0aW9uIG9mIFBhY2tldENhYmxl IElFVEYgTUlCcyAtIA0KICBTSUcgZHJhZnQgMDE8QlI+PEJSPjwvRk9OVD48L0RJVj4NCiAgPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxGT05UIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPg0KICA8UD5SaWNrLDwvRk9OVD48Rk9OVCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0zPiANCiAgPC9GT05UPjwvUD48L0ZPTlQ+DQogIDxQ PlRoYW5rcyBmb3IgeW91ciByZXZpZXcgb2YgdGhlIHNpZ25hbGluZyBNSUIgcmVjb21tZW5kYXRp b25zIGFuZCBmb3IgDQogIHByb3ZpZGluZyBhZGRpdGlvbmFsIHN1Z2dlc3Rpb25zLjwvUD4NCiAg PFA+Rm9yIGl0ZW1zIDEtNSBhbmQgNyw4LCBhbmQgMTAmbmJzcDs8U1BBTiBjbGFzcz00MjkyNzI0 MTctMjgwNzIwMDM+dGhlcmUgaXMgDQogIHN1YnN0YW50aWFsIGFncmVlbWVudCwgYW5kIDwvU1BB Tj5JIGhhdmUgbWFkZSB0aGUgY2hhbmdlcyBhcyZuYnNwOzxTUEFOIA0KICBjbGFzcz00MjkyNzI0 MTctMjgwNzIwMDM+aW5kaWNhdGVkIDwvU1BBTj5pbiB0aGUgb3BlbiBpc3N1ZXMgbGlzdDxTUEFO IA0KICBjbGFzcz00MjkyNzI0MTctMjgwNzIwMDM+IChhcyBwb3N0ZWQgb24gdGhlIElQQ0ROIHdl YiBzaXRlIGFuZCBpbmNsdWRlZCBpbiANCiAgeW91ciBkb2N1bWVudCk8L1NQQU4+LCBob3dldmVy LCB0aGVyZSBpcyBvbmUmbmJzcDs8U1BBTiANCiAgY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPm1p bm9yIDwvU1BBTj5leGNlcHRpb24gb24gaXRlbSA4LiBJdCB0dXJucyANCiAgb3V0Jm5ic3A7PFNQ QU4gY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPnRoYXQgPC9TUEFOPnNpeHRlZW50aG91c2FuZCBp cyBtb3JlIA0KICBjb21tb25seSB1c2VkIHRoYW4gdHdlbHZldGhvdXNhbmQuIENvbnNlcXVlbnRs eSwgdGhlIGRlc2NyaXB0aW9uIGFuZCBkZWZhdWx0IA0KICBhcmUgcmVjb21tZW5kZWQgdG8gYmUg c2l4dGVlbnRob3VzYW5kIG5vdCB0d2VsdmV0aG91c2FuZC48Rk9OVCANCiAgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4gPC9QPjwvRk9OVD4NCiAgPFA+Rm9yIGl0ZW0gOSwgTW90b3JvbGEgYWdyZWVz IHdpdGggdGhlIGRlZmF1bHQgY2hhbmdlIHJlY29tbWVuZGVkLjxGT05UIA0KICBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPiA8L1A+PC9GT05UPg0KICA8UD5Gb3IgaXRlbSAxMSwgTW90b3JvbGEgYWdy ZWVzIHdpdGggdGhlIHJlY29tbWVuZGF0aW9uIHRvIG9ic29sZXRlIHRoZXNlIA0KICBvYmplY3Rz LiBUaGVzZSBvYmplY3RzIGFyZSBwcm9kdWN0IGhhcmR3YXJlIGRlc2lnbiBpc3N1ZXMuPEZPTlQg DQogIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvUD48L0ZPTlQ+DQogIDxQPkZvciBpdGVtIDYs Jm5ic3A7PFNQQU4gY2xhc3M9NDI5MjcyNDE3LTI4MDcyMDAzPk1vdG9yb2xhLCA8L1NQQU4+PFNQ QU4gDQogIGNsYXNzPTQyOTI3MjQxNy0yODA3MjAwMz5hPC9TUEFOPjxTUEFOIGNsYXNzPTQyOTI3 MjQxNy0yODA3MjAwMz5mdGVyIGZ1cnRoZXIgDQogIHJldmlldyZuYnNwOzwvU1BBTj48U1BBTiBj bGFzcz00MjkyNzI0MTctMjgwNzIwMDM+ZGV0ZXJtaW5lZCB0aGF0IHRoZXJlIGlzIA0KICBhbHJl YWR5IGFuIG9iamVjdCBmb3Igc2V0dGluZyB0aGUgbGV2ZWwgZm9yIGR0bWYgb3IgYW55IG90aGVy IHRvbmUgKDxTUEFOIA0KICBzdHlsZT0iRk9OVC1TSVpFOiAxMnB0OyBGT05ULUZBTUlMWTogJ1Rp bWVzIE5ldyBSb21hbic7IG1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiBCYXRhbmc7IG1zby1hbnNp LWxhbmd1YWdlOiBFTi1VUzsgbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IEVOLVVTOyBtc28tYmlkaS1s YW5ndWFnZTogQVItU0EiPjxGT05UIA0KICBjb2xvcj0jMDAwMDAwPnBrdGNTaWdEZXZUb25lRGJM ZXZlbCk8L0ZPTlQ+PC9TUEFOPjwvU1BBTj48U1BBTiANCiAgY2xhc3M9NDI5MjcyNDE3LTI4MDcy MDAzPiwgd2hpY2ggY2FuIHZhcnkgYnkgZ2VvZ3JhcGhpYyBsb2NhdGlvbjwvU1BBTj4uPFNQQU4g DQogIGNsYXNzPTQyOTI3MjQxNy0yODA3MjAwMz4gQ29uc2VxdWVudGx5LCB0aGUgb25seSBjaGFu Z2UgcmVjb21tZW5kZWQgZm9yIGl0ZW0gNiANCiAgdGhlbiBpcyB0aGUgYWRkaXRpb24gb2YgMyB1 c2VyIGRlZmluZWQgdG9uZXMuPC9TUEFOPjwvUD4NCiAgPFA+PFNQQU4gY2xhc3M9NDI5MjcyNDE3 LTI4MDcyMDAzPkZvciBpdGVtIDEyLCBNb3Rvcm9sYSBkb2VzIG5vdCBhZ3JlZSB3aXRoIA0KICBv YnNvbGV0aW5nIHRoZXNlIG9iamVjdHM8U1BBTiBjbGFzcz00MjkyNzI0MTctMjgwNzIwMDM+LiBU aGUgZGlhbCBwdWxzZSANCiAgb2JqZWN0cyB2YXJ5IGJ5IGdlb2dyYXBoaWMgbG9jYXRpb24gKGUu Zy4sIE5BLCBFdXJvcGUsIEphcGFuLCBldGMpLCBhbmQgbmVlZCANCiAgdG8gYmUgcmV0YWluZWQg aW4gb3JkZXIgdG8gYmUgYWRqdXN0ZWQgYXMgbmVjZXNzYXJ5IGJ5IHRoZSANCiAgb3BlcmF0b3I8 L1NQQU4+LjwvU1BBTj48L1A+PEZPTlQgZmFjZT0iQm9vayBBbnRpcXVhIj4NCiAgPFA+R29yZG9u IEJlYWNoYW08L1A+DQogIDxQPkRpZ2l0YWwgQ29yZSBHYXRld2F5cywgQkNTPC9QPg0KICA8UD5N b3Rvcm9sYSwgSW5jLjwvUD4NCiAgPFA+ODU4LTQwNC0yMzM1PC9QPg0KICA8UD5nb3Jkb24uYmVh Y2hhbUBtb3Rvcm9sYS5jb208L1A+PC9GT05UPjwvRk9OVD48L0RJVj4NCiAgPERJViBjbGFzcz1P dXRsb29rTWVzc2FnZUhlYWRlciBkaXI9bHRyIGFsaWduPWxlZnQ+PEZPTlQgZmFjZT1UYWhvbWEg DQogIHNpemU9Mj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj48Qj5Gcm9tOjwvQj4gUmlj ay5Nb3JyaXNAYXJyaXNpLmNvbSANCiAgW21haWx0bzpSaWNrLk1vcnJpc0BhcnJpc2kuY29tXTxC Uj48Qj5TZW50OjwvQj4gRnJpZGF5LCBKdWx5IDI1LCAyMDAzIDI6MDggDQogIFBNPEJSPjxCPlRv OjwvQj4gV2ltIERlIEtldGVsYWVyZTxCUj48Qj5DYzo8L0I+IEdvcmRvbiBCZWFjaGFtOyANCiAg YmlsbHkuaGFyZUBhcnJpc2kuY29tOyB3YWx0ZXIuZGFuaWVsQGFycmlzaS5jb208QlI+PEI+U3Vi amVjdDo8L0I+IFJlOiBGdzogDQogIFB1YmxpY2F0aW9uIG9mIFBhY2tldENhYmxlIElFVEYgTUlC cyAtIFNJQiBkcmFmdCANCiAgMDE8QlI+PEJSPjwvRk9OVD48L0RJVj48QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTE+V2ltIGFuZCBHb3JkZW4sPC9GT05UPiANCiAgPEJSPjxCUj48Rk9OVCBmYWNl PUFyaWFsIHNpemU9MT5JIGFwb2xvZ2l6ZSBmb3IgdGhlIGxlbmd0aCBvZiB0aW1lIGl0IGhhcyAN CiAgdGFrZW4gbWUgdG8gZ2V0IHRoaXMgcmVzcG9uc2UgYmFjayB0byB5b3UuICZuYnNwOyAmbmJz cDsgSG93ZXZlciwgd2Ugd2FudGVkIHRvIA0KICBtYWtlIHN1cmUgdGhhdCB3ZSBoYWQgdGhvcm91 Z2hseSByZXZpZXdlZCBhbmQgY29uc2lkZXJlZCBlYWNoIG9mIEdvcmRlbidzIA0KICBzdWdnZXN0 aW9ucy4gJm5ic3A7UGxlYXNlIGRpc3RyaWJ1dGUgb3VyIGNvbW1lbnRzIHRvIHlvdXIgbGlzdCBh cyANCiAgYXBwcm9wcmlhdGUuPC9GT05UPiA8QlI+PEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0x Pkkgd291bGQgbGlrZSB0byBzYXkgdGhhdCANCiAgR29yZGVuIGhhcyBkb25lIGFuIGV4Y2VsbGVu dCBqb2Igb2Ygc2NvcGluZyBvdXQgc2V2ZXJhbCBzdWdnZXN0ZWQgY2hhbmdlcy4gDQogICZuYnNw O1RoZSBhdHRhY2hlZCBkb2N1bWVudCBmcm9tIEFSUklTIGNvbnRhaW5zIGFueSBhZ3JlZW1lbnRz IHdpdGggaGlzIA0KICByZWNvbW1lbmRhdGlvbnMsIGFsb25nIHdpdGggYSBjb3VwbGUgb2YgYWRk aXRpb25hbCBjb21tZW50cy4gJm5ic3A7QVJSSVMgd291bGQgDQogIGJlIHZlcnkgaW50ZXJlc3Rl ZCB3aXRoIGRpc2N1c3Npbmcgb3VyIGNvbW1lbnRzIHdpdGggeW91LCBhbmQgb3RoZXJzIG9uIHlv dXIgDQogIGRpc3RyaWJ1dGlvbiBsaXN0IGF0IHlvdXIgY29udmVuaWVuY2UuPC9GT05UPiA8QlI+ PEJSPjxGT05UIGZhY2U9QXJpYWwgDQogIHNpemU9MT5UaGFuayB5b3UgYm90aCBmb3IgeW91ciBl ZmZvcnRzIGluIHdvcmtpbmcgdG8gY2xlYW4gdXAgdGhpcyBNSUIncyANCiAgY29udGVudHMuICZu YnNwO1dpdGggdGhlIGpvaW50IGNvb3BlcmF0aW9uIG9mIHRDb21MYWJzIGFuZCB0aGUgTVRBIHZl bmRvcnMsIEkgDQogIGZlZWwgY29uZmlkZW50IHdlIGNhbiBhbGwgbW92ZSB0b3dhcmRzIGEgc3Vj Y2Vzc2Z1bCBjZXJ0aWZpY2F0aW9uIHdhdmUgaW4gDQogIEVDVzEzLjwvRk9OVD4gPEJSPjxCUj48 Rk9OVCBmYWNlPUFyaWFsIHNpemU9MT5SZWdhcmRzLDwvRk9OVD4gPEJSPjxGT05UIA0KICBmYWNl PUFyaWFsIHNpemU9MT5SaWNrIE1vcnJpczwvRk9OVD4gPEJSPjxGT05UIGZhY2U9QXJpYWwgc2l6 ZT0xPkFSUklTLCBTck1nciANCiAgLSBFbmdpbmVlcmluZywgQ2VydGlmaWNhdGlvbiBhbmQgU3Rh bmRhcmRzPC9GT05UPiA8QlI+PEZPTlQgZmFjZT1BcmlhbCANCiAgc2l6ZT0xPiswMDEgNzcwIDYy MiA4NjE5PC9GT05UPiA8QlI+PEJSPjxCUj48QlI+PEJSPjxCUj48QlI+PEJSPjxCUj4NCiAgPFRB QkxFIHdpZHRoPSIxMDAlIj4NCiAgICA8VEJPRFk+DQogICAgPFRSIHZBbGlnbj10b3A+DQogICAg ICA8VEQ+DQogICAgICA8VEQ+PEZPTlQgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT48Qj4iV2ltIERl IEtldGVsYWVyZSIgDQogICAgICAgICZsdDtkZWtldGVsYWVyZUB0Y29tbGFicy5jb20mZ3Q7PC9C PjwvRk9OVD4gDQogICAgICAgIDxQPjxGT05UIGZhY2U9c2Fucy1zZXJpZiBzaXplPTE+MDcvMDMv MjAwMyAwMTo1MyBQTTwvRk9OVD4gPEJSPjwvUD4NCiAgICAgIDxURD48Rk9OVCBmYWNlPUFyaWFs IHNpemU9MT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9GT05UPjxCUj48Rk9OVCANCiAg ICAgICAgZmFjZT1zYW5zLXNlcmlmIHNpemU9MT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg VG86ICZuYnNwOyAmbmJzcDsgDQogICAgICAgICZuYnNwOyAmbmJzcDsmbHQ7cmljay5tb3JyaXNA YXJyaXNpLmNvbSZndDs8L0ZPTlQ+IDxCUj48Rk9OVCANCiAgICAgICAgZmFjZT1zYW5zLXNlcmlm IHNpemU9MT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY2M6ICZuYnNwOyAmbmJzcDsgDQog ICAgICAgICZuYnNwOyAmbmJzcDsmbHQ7R29yZG9uLkJlYWNoYW1AbW90b3JvbGEuY29tJmd0Ozwv Rk9OVD4gPEJSPjxGT05UIA0KICAgICAgICBmYWNlPXNhbnMtc2VyaWYgc2l6ZT0xPiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBTdWJqZWN0OiAmbmJzcDsgDQogICAgICAgICZuYnNwOyAmbmJz cDsgJm5ic3A7Rnc6IFB1YmxpY2F0aW9uIG9mIFBhY2tldENhYmxlIElFVEYgTUlCcyAtIFNJQiBk cmFmdCANCiAgICAgICAgMDE8L0ZPTlQ+PC9URD48L1RSPjwvVEJPRFk+PC9UQUJMRT48QlI+PEJS PjxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgDQogIHNpemU9Mj5IaSBSaWNrLDxCUj48QlI+ SGVyZSdzIHRoZSBkb2N1bWVudCAhPEJSPjxCUj5UaGFua3MsPEJSPiZuYnNwO0Jlc3QgDQogIHJl Z2FyZHMsPEJSPiZuYnNwOyANCiZuYnNwO1dpbTxCUj48QlI+PEJSPjxCUj48L0ZPTlQ+PEJSPjxC Uj48L0JMT0NLUVVPVEU+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C355D7.AECC0362-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 10:19:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24576 for ; Tue, 29 Jul 2003 10:19:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVJf-0004O4-BA for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 10:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TEJ30H016857 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 10:19:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVJe-0004Ni-21; Tue, 29 Jul 2003 10:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hVIh-0004L5-JO for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 10:18:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24562 for ; Tue, 29 Jul 2003 10:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hVIf-0005wr-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 10:18:01 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19hVIe-0005wU-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 10:18:00 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6TEHIdS010578; Tue, 29 Jul 2003 08:17:19 -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, 29 Jul 2003 08:17:18 -0600 Message-ID: Thread-Topic: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Thread-Index: AcNVXcCyXjtWREbjRYe9AHfo4hGpNgAcv3Mw From: "Eduardo Cardona" To: "Minnie Lu" , "DOCSIS OSS Majordomo List" , Cc: X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. As you mentioned, this is a very common situation where the updated version of the spec has no equivalent attibutes for the older spec. I would like to know if there is already a proposed text for the enumeration update unknown(0) plus the DESCRIPTION explaining the value zero; David Raftus may have some details around.=20 In the mean time,=20 I have not strong position to prefer other(0) rather than unknown(0), let's leave for now unknown(0) Below is the definition from draft-ipcdn-rfmibv2-06.txt docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts" REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, Table 8-19." DEFVAL { qpsk0 } ::=3D { docsIfCmtsModulationEntry 16 } Tentative proposed: ( extended the REFERENCES to link the 1.x burst considerations) docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown'=20 represents a row entry with DOCSIS 1.x burst only" REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and=20 section 6.2.9 Preamble Prepend." DEFVAL { qpsk0 } ::=3D { docsIfCmtsModulationEntry 16 } Comments are very welcome, Until a resolution is taken in the ipcdn group, we can arrange a quick spec update before then a new RFI mib RFC is assigned and then required in the RFI spec. Regards Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Monday, July 28, 2003 5:13 PM To: DOCSIS OSS Majordomo List; Eduardo Cardona Cc: milu@cisco.com Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, I know this issue described as below will be addressed in the next revision=20 of RF mib v2 draft. But it seems that it will take some time to have next=20 revision to be published and accepted by CableLabs as part of official=20 DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I think=20 we need one. 5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the=20 docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only object=20 in this table without a meaningful default value when this parameter does not make sense. For=20 instance, for a TDMA modulation profile using QAM16, the actual preamble type is indeed not QPSK0 but=20 something else. Does it make sense to have a value of 0 in this case, like=20 docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? (Eduardo) for the benefit of clarifications wouldn't be good to have a=20 enumeration unknown(0) for this object when not a 2.0 burst ? Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1)=20 a value unknown(0) is used for this object" I would say unknown(0) rather than unknown(3) since it looks like the=20 possible current implementation may be reporting '0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs Thanks a lot for your help ! Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 11:32:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26374 for ; Tue, 29 Jul 2003 11:32:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWSI-0006kc-CE for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 11:32:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TFW2Fl025944 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 11:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWSH-0006k3-5i; Tue, 29 Jul 2003 11:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWRh-0006iy-Vb for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 11:31:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26356 for ; Tue, 29 Jul 2003 11:31:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hWRg-0006Y1-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 11:31:24 -0400 Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com) by ietf-mx with esmtp (Exim 4.12) id 19hWRZ-0006Xp-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 11:31:18 -0400 Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59) id ; Tue, 29 Jul 2003 08:29:25 -0700 Message-ID: From: "Raftus, David" To: "'Eduardo Cardona'" , Minnie Lu , DOCSIS OSS Majordomo List , ipcdn@ietf.org Cc: "Raftus, David" Date: Tue, 29 Jul 2003 08:29:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C355E6.3357FFB0" Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C355E6.3357FFB0 Content-Type: text/plain; charset="iso-8859-1" Hi, I agree that 'unknown (0)' matches the precedent set previously in the RF mib, and is preferable to 'other (0)'. Also, use of the value (0) is acceptable according to minutes of the IPCDN Feb 13/03 interim meeting: If enumeration has to start at 0, author to put description for Why. Otherwise start enumeration at 1. - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE SYNTAX INTEGER { unknown (0), validCmChained (1), validCmTrusted (2), invalidCmUntrusted (3), invalidCAUntrusted (4), invalidCmOther (5), invalidCAOther (6) } Here's a suggestion for Description wording, open to comments: "Preamble type for DOCSIS 2.0 bursts. The value 'unknown (0)' represents a row entry consisting only of DOCSIS 1.x bursts." Thanks, Dave ************************************ David Raftus Software Manager Terayon Communications Canada 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@terayon.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Eduardo Cardona [mailto:e.cardona@CableLabs.com] Sent: Tuesday, July 29, 2003 10:17 AM To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org Cc: david.raftus@imedia.com Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. As you mentioned, this is a very common situation where the updated version of the spec has no equivalent attibutes for the older spec. I would like to know if there is already a proposed text for the enumeration update unknown(0) plus the DESCRIPTION explaining the value zero; David Raftus may have some details around. In the mean time, I have not strong position to prefer other(0) rather than unknown(0), let's leave for now unknown(0) Below is the definition from draft-ipcdn-rfmibv2-06.txt docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts" REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, Table 8-19." DEFVAL { qpsk0 } ::= { docsIfCmtsModulationEntry 16 } Tentative proposed: ( extended the REFERENCES to link the 1.x burst considerations) docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' represents a row entry with DOCSIS 1.x burst only" REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and section 6.2.9 Preamble Prepend." DEFVAL { qpsk0 } ::= { docsIfCmtsModulationEntry 16 } Comments are very welcome, Until a resolution is taken in the ipcdn group, we can arrange a quick spec update before then a new RFI mib RFC is assigned and then required in the RFI spec. Regards Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com] Sent: Monday, July 28, 2003 5:13 PM To: DOCSIS OSS Majordomo List; Eduardo Cardona Cc: milu@cisco.com Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, I know this issue described as below will be addressed in the next revision of RF mib v2 draft. But it seems that it will take some time to have next revision to be published and accepted by CableLabs as part of official DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I think we need one. 5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only object in this table without a meaningful default value when this parameter does not make sense. For instance, for a TDMA modulation profile using QAM16, the actual preamble type is indeed not QPSK0 but something else. Does it make sense to have a value of 0 in this case, like docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? (Eduardo) for the benefit of clarifications wouldn't be good to have a enumeration unknown(0) for this object when not a 2.0 burst ? Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1) a value unknown(0) is used for this object" I would say unknown(0) rather than unknown(3) since it looks like the possible current implementation may be reporting '0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs Thanks a lot for your help ! Minnie ------_=_NextPart_001_01C355E6.3357FFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: any ECR for docsIfCmtsModPreambleType value for = TDMA/ATDMA

Hi,

I agree that 'unknown (0)' matches the precedent set = previously in the RF mib, and is preferable to 'other (0)'.

Also, use of the value (0) is acceptable according to = minutes of the IPCDN Feb 13/03 interim meeting:

If enumeration has to start at 0, author to put = description for Why.  Otherwise start enumeration at 1.
 -       = docsBpi2CmtsAuthBpkmCmCertValid       = ;  OBJECT-TYPE
           = SYNTAX    INTEGER {
          &nb= sp;           &nb= sp;      unknown (0),
          &nb= sp;           &nb= sp;      validCmChained (1),
          &nb= sp;           &nb= sp;      validCmTrusted (2),
          &nb= sp;           &nb= sp;      invalidCmUntrusted (3),
          &nb= sp;           &nb= sp;      invalidCAUntrusted (4),
          &nb= sp;           &nb= sp;      invalidCmOther (5),
          &nb= sp;           &nb= sp;      invalidCAOther (6)
          &nb= sp;           &nb= sp;      }

Here's a suggestion for Description wording, open to = comments:
          &nb= sp; "Preamble type for DOCSIS 2.0 bursts. The value 'unknown (0)' = represents a row entry consisting only of DOCSIS 1.x = bursts."

Thanks,
Dave


************************************
David Raftus
Software Manager
Terayon Communications Canada
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

david.raftus@terayon.com      &nb= sp;   
613.592.1052  ext 222
************************************    &nb= sp;         


-----Original Message-----
From: Eduardo Cardona [mailto:e.cardona@CableLabs.com]
Sent: Tuesday, July 29, 2003 10:17 AM
To: Minnie Lu; DOCSIS OSS Majordomo List; = ipcdn@ietf.org
Cc: david.raftus@imedia.com
Subject: RE: any ECR for docsIfCmtsModPreambleType = value for TDMA/ATDMA


Hi Minie, Thanks for tracking the topic, I am copying = the IPCDN list.

As you mentioned, this is a very common situation = where the updated
version of the spec has no equivalent attibutes for = the older spec.


I would like to know if there is already a proposed = text for the
enumeration update unknown(0) plus the DESCRIPTION = explaining the value
zero; David Raftus may have some details = around.

In the mean time,

I have not strong position to prefer other(0) rather = than unknown(0),
let's leave for now unknown(0)

Below is the definition from = draft-ipcdn-rfmibv2-06.txt


docsIfCmtsModPreambleType      &n= bsp; OBJECT-TYPE
        = SYNTAX       INTEGER {
          &nb= sp; qpsk0(1),
          &nb= sp; qpsk1(2)
        }
        = MAX-ACCESS  read-create
        = STATUS      current
        = DESCRIPTION
          &nb= sp; "Preamble type for DOCSIS 2.0 bursts"
        = REFERENCE
          &nb= sp; "Data-Over-Cable Service Interface Specifications: = Radio
          &nb= sp;  Frequency Interface Specification = SP-RFIv2.0-IO2-020617,
          &nb= sp;  Table 8-19."
        DEFVAL { = qpsk0 }
        ::=3D { = docsIfCmtsModulationEntry 16 }



Tentative proposed: ( extended the REFERENCES to link = the 1.x burst
considerations)


docsIfCmtsModPreambleType      &n= bsp; OBJECT-TYPE
        = SYNTAX       INTEGER {
          &nb= sp; qpsk0(1),
          &nb= sp; qpsk1(2)
        }
        = MAX-ACCESS  read-create
        = STATUS      current
        = DESCRIPTION
          &nb= sp; "Preamble type for DOCSIS 2.0 bursts. The value = 'unknown'
         = ;    represents a row entry with DOCSIS 1.x burst = only"
        = REFERENCE
          &nb= sp; "Data-Over-Cable Service Interface Specifications: = Radio
          &nb= sp;  Frequency Interface Specification = SP-RFIv2.0-IO2-020617,
          &nb= sp;  8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 = and
          &nb= sp;  section 6.2.9 Preamble Prepend."
        DEFVAL { = qpsk0 }
        ::=3D { = docsIfCmtsModulationEntry 16 }


Comments are very welcome, Until a resolution is = taken in the ipcdn
group, we can arrange a quick  spec update = before then a new RFI mib RFC
is assigned and then required in the RFI = spec.


Regards

Eduardo

-----Original Message-----
From: Minnie Lu [mailto:milu@cisco.com]
Sent: Monday, July 28, 2003 5:13 PM
To: DOCSIS OSS Majordomo List; Eduardo = Cardona
Cc: milu@cisco.com
Subject: any ECR for docsIfCmtsModPreambleType value = for TDMA/ATDMA


Hi,

I know this issue described as below will be = addressed in the next
revision
of RF mib v2 draft. But it seems that it will take = some time to have
next
revision to be published and accepted by CableLabs = as part of official
DOCSIS OSS spec.  Is there any ECR/ECO/ECN = already ?  If not yet, I
think
we need one.

5) docsIfCmtsModPreambleType - (Joel) In = docsIfCmtsModulationTable, the
docsIfCmtsModPreambleType object has
2 possible values qpsk0(1) and qpsk1(2). It seems = like it's the only
object
in this table without a
meaningful default value when this parameter does = not make sense. For
instance, for a TDMA modulation
profile using QAM16, the actual preamble type is = indeed not QPSK0 but
something else. Does it make sense
to have a value of 0 in this case, like
docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA = profiles?

(Eduardo) for the benefit of clarifications wouldn't = be good to have a
enumeration unknown(0) for this
object when not a 2.0 burst ?
Also a note in the DESCRIPTION like "if = docsIfCmtsModChannelType is
tdma(1)
a value unknown(0) is used for this = object"
I would say unknown(0) rather than unknown(3) since = it looks like the
possible current implementation may be = reporting
'0' , and defendable in IETF since RFC 3291 uses '0' = for inetAddressType

Contributors - Joel Demarty Juniper, Eduardo Cardona = Cablelabs

  Thanks a lot for your help !
  Minnie

------_=_NextPart_001_01C355E6.3357FFB0-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 11:34:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26471 for ; Tue, 29 Jul 2003 11:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWUC-0006us-MB for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 11:34:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TFY0Yp026539 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 11:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWUC-0006tv-Ei; Tue, 29 Jul 2003 11:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hWU2-0006tR-U4 for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 11:33:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26460 for ; Tue, 29 Jul 2003 11:33:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hWU1-0006ae-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 11:33:50 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19hWU1-0006Zs-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 11:33:49 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6TFXEdU014561; Tue, 29 Jul 2003 09:33: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: Publication of PacketCable IETF MIBs - SIG draft 01 Date: Tue, 29 Jul 2003 09:33:15 -0600 Message-ID: Thread-Topic: [ipcdn] RE: Publication of PacketCable IETF MIBs - SIG draft 01 Thread-Index: AcNV2H5WLpLYZ0E4RfixEXZ2C7QajAADUZiA From: "Jean-Francois Mule" To: "Beacham Gordon-CGB005" , Cc: , , "Venkatesh Sunkad" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Gordon, Thanks for raising this issue on the list. I don't agree with accepting this ECO as part of the ipcdn draft revision unless: 1. the proposed changes are disclose to the ipcdn list the eco you reference is not accessible to IETF & ipcdn folks and ECOs are covered by the IPR agreement. This means that if the authors of the ECO (in copy) want to disclose the proposed changes, they should send text to the ipcdn list. 2. the proposed changes represent a rough consensus I think it needs some more discussions, especially since we have passed WGLC! Jean-Francois=20 -----Original Message----- From: Beacham Gordon-CGB005 [mailto:Gordon.Beacham@motorola.com]=20 Sent: Tuesday, July 29, 2003 7:50 AM To: 'ipcdn@ietf.org' Subject: [ipcdn] RE: Publication of PacketCable IETF MIBs - SIG draft 01 It has been brought to my attention that a pending PC Signaling MIB ECO should be considered for item 1 (pktcSigDevCodecTable). Instead of obsoleting pktcSigDevCodecTable, the suggestion is to adopt the changes in sigmib-o-03004-v2 as the new definition for the pktcSigDevCodecTable, and only obsolete the pktcSigDevCodecMax object. Gordon _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 14:49:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04366 for ; Tue, 29 Jul 2003 14:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZWy-0007od-7H for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 14:49:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TIn4He030037 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 14:49:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZWv-0007nk-21; Tue, 29 Jul 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZW4-0007me-FG for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 14:48:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04358 for ; Tue, 29 Jul 2003 14:48:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZW1-0000uY-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 14:48:05 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19hZW0-0000uJ-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 14:48:04 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6TIlOdS000138; Tue, 29 Jul 2003 12:47:24 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35601.D9A6FD0B" Date: Tue, 29 Jul 2003 12:47:24 -0600 Message-ID: Thread-Topic: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Thread-Index: AcNV6/SQ8rK9PdblRXKfMoRc138LbAAFaEmQ From: "Eduardo Cardona" To: "Craig Patten @ Terayon" , "Raftus, David" , "Minnie Lu " , "DOCSIS OSS Majordomo List" , X-Approved: ondar Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C35601.D9A6FD0B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently, all draft 06 references pointed to I02,=20 =20 I think it is up to David Raftus to decide to update the references before WGLC due the current draft status =20 Eduardo =20 =20 -----Original Message----- From: Craig Patten @ Terayon=20 Sent: Tuesday, July 29, 2003 10:11 AM To: Raftus, David; Eduardo Cardona; 'Minnie Lu '; DOCSIS OSS Majordomo List; 'ipcdn@ietf.org ' Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA =09 =09 Eduardo,=20 Minor documentation issue, I noticed the proposed definition includes a reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, but should the mib actually reference the newer IO3 document AKA SP-RFIv2.0-I03-021218? Thanks,=20 Craig=20 -----Original Message-----=20 From: Raftus, David=20 To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org=20 Cc: Raftus, David=20 Sent: 7/29/2003 8:29 AM=20 Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA=20 Hi,=20 I agree that 'unknown (0)' matches the precedent set previously in the=20 RF mib, and is preferable to 'other (0)'.=20 Also, use of the value (0) is acceptable according to minutes of the=20 IPCDN Feb 13/03 interim meeting:=20 If enumeration has to start at 0, author to put description for Why.=20 Otherwise start enumeration at 1.=20 - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE=20 SYNTAX INTEGER {=20 unknown (0),=20 validCmChained (1),=20 validCmTrusted (2),=20 invalidCmUntrusted (3),=20 invalidCAUntrusted (4),=20 invalidCmOther (5),=20 invalidCAOther (6)=20 }=20 Here's a suggestion for Description wording, open to comments:=20 "Preamble type for DOCSIS 2.0 bursts. The value 'unknown=20 (0)' represents a row entry consisting only of DOCSIS 1.x bursts."=20 Thanks,=20 Dave=20 ************************************=20 David Raftus=20 Software Manager=20 Terayon Communications Canada=20 340 Terry Fox Drive, Suite 202=20 Ottawa Canada K2K 3A2=20 david.raftus@terayon.com =20 613.592.1052 ext 222=20 ************************************ =20 -----Original Message-----=20 From: Eduardo Cardona [ mailto:e.cardona@CableLabs.com=20 ]=20 Sent: Tuesday, July 29, 2003 10:17 AM=20 To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org=20 Cc: david.raftus@imedia.com=20 Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA=20 Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list.=20 As you mentioned, this is a very common situation where the updated=20 version of the spec has no equivalent attibutes for the older spec.=20 I would like to know if there is already a proposed text for the enumeration update unknown(0) plus the DESCRIPTION explaining the value=20 zero; David Raftus may have some details around.=20 In the mean time,=20 I have not strong position to prefer other(0) rather than unknown(0),=20 let's leave for now unknown(0)=20 Below is the definition from draft-ipcdn-rfmibv2-06.txt=20 docsIfCmtsModPreambleType OBJECT-TYPE=20 SYNTAX INTEGER {=20 qpsk0(1),=20 qpsk1(2)=20 }=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Preamble type for DOCSIS 2.0 bursts"=20 REFERENCE=20 "Data-Over-Cable Service Interface Specifications: Radio=20 Frequency Interface Specification SP-RFIv2.0-IO2-020617,=20 Table 8-19."=20 DEFVAL { qpsk0 }=20 ::=3D { docsIfCmtsModulationEntry 16 }=20 Tentative proposed: ( extended the REFERENCES to link the 1.x burst=20 considerations)=20 docsIfCmtsModPreambleType OBJECT-TYPE=20 SYNTAX INTEGER {=20 qpsk0(1),=20 qpsk1(2)=20 }=20 MAX-ACCESS read-create=20 STATUS current=20 DESCRIPTION=20 "Preamble type for DOCSIS 2.0 bursts. The value 'unknown'=20 represents a row entry with DOCSIS 1.x burst only"=20 REFERENCE=20 "Data-Over-Cable Service Interface Specifications: Radio=20 Frequency Interface Specification SP-RFIv2.0-IO2-020617,=20 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and=20 section 6.2.9 Preamble Prepend."=20 DEFVAL { qpsk0 }=20 ::=3D { docsIfCmtsModulationEntry 16 }=20 Comments are very welcome, Until a resolution is taken in the ipcdn=20 group, we can arrange a quick spec update before then a new RFI mib RFC=20 is assigned and then required in the RFI spec.=20 Regards=20 Eduardo=20 -----Original Message-----=20 From: Minnie Lu [ mailto:milu@cisco.com ]=20 Sent: Monday, July 28, 2003 5:13 PM=20 To: DOCSIS OSS Majordomo List; Eduardo Cardona=20 Cc: milu@cisco.com=20 Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA=20 Hi,=20 I know this issue described as below will be addressed in the next=20 revision=20 of RF mib v2 draft. But it seems that it will take some time to have=20 next=20 revision to be published and accepted by CableLabs as part of official=20 DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I=20 think=20 we need one.=20 5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the=20 docsIfCmtsModPreambleType object has=20 2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only=20 object=20 in this table without a=20 meaningful default value when this parameter does not make sense. For=20 instance, for a TDMA modulation=20 profile using QAM16, the actual preamble type is indeed not QPSK0 but=20 something else. Does it make sense=20 to have a value of 0 in this case, like=20 docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles?=20 (Eduardo) for the benefit of clarifications wouldn't be good to have a=20 enumeration unknown(0) for this=20 object when not a 2.0 burst ?=20 Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is=20 tdma(1)=20 a value unknown(0) is used for this object"=20 I would say unknown(0) rather than unknown(3) since it looks like the=20 possible current implementation may be reporting=20 '0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType=20 Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs=20 Thanks a lot for your help !=20 Minnie=20 ------_=_NextPart_001_01C35601.D9A6FD0B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Currently, all draft 06 references pointed to I02, =
 
I=20 think it is up to David Raftus to decide to update the references before = WGLC=20 due the current draft status
 
Eduardo
 
 
-----Original Message-----
From: = Craig Patten @=20 Terayon
Sent: Tuesday, July 29, 2003 10:11 AM
To: = Raftus,=20 David; Eduardo Cardona; 'Minnie Lu '; DOCSIS OSS Majordomo List;=20 'ipcdn@ietf.org '
Subject: RE: any ECR for = docsIfCmtsModPreambleType=20 value for TDMA/ATDMA

 Eduardo,

Minor documentation issue, I noticed the proposed = definition=20 includes a reference SP-RFIv2.0-IO2-020617 spec.  I don't think = it has=20 changed, but should the mib actually reference the newer IO3 document = AKA=20 SP-RFIv2.0-I03-021218?

Thanks,

Craig


-----Original Message-----
From:=20 Raftus, David
To: 'Eduardo Cardona'; Minnie = Lu; DOCSIS=20 OSS Majordomo List; ipcdn@ietf.org
Cc: = Raftus,=20 David
Sent: 7/29/2003 8:29 AM =
Subject: RE: any ECR for docsIfCmtsModPreambleType value for=20 TDMA/ATDMA

Hi,

I agree that 'unknown (0)' matches the precedent set = previously in the
RF mib, and is preferable = to 'other=20 (0)'.

Also, use of the value (0) is acceptable according = to minutes=20 of the
IPCDN Feb 13/03 interim meeting: =

If enumeration has to start at 0, author to put = description=20 for Why.
Otherwise start enumeration at 1.=20
 -      =20 = docsBpi2CmtsAuthBpkmCmCertValid       =  =20 OBJECT-TYPE
          =20 SYNTAX    INTEGER {
          &nbs= p;            = ;     =20 unknown (0),
          &nbs= p;            = ;     =20 validCmChained (1),
          &nbs= p;            = ;     =20 validCmTrusted (2),
          &nbs= p;            = ;     =20 invalidCmUntrusted (3),
          &nbs= p;            = ;     =20 invalidCAUntrusted (4),
          &nbs= p;            = ;     =20 invalidCmOther (5),
          &nbs= p;            = ;     =20 invalidCAOther (6)
          &nbs= p;            = ;     =20 }

Here's a suggestion for Description wording, open to = comments:=20
          &nbs= p;=20 "Preamble type for DOCSIS 2.0 bursts. The value 'unknown =
(0)' represents a row entry consisting only of DOCSIS 1.x=20 bursts."

Thanks,
Dave =


************************************ =
David Raftus
Software Manager =
Terayon Communications Canada
340 = Terry Fox=20 Drive, Suite 202
Ottawa Canada  K2K 3A2 =

david.raftus@terayon.com      &nbs= p;   =20
613.592.1052  ext 222
************************************    &nbs= p;         =20


-----Original Message-----
From:=20 Eduardo Cardona [ mailto:e.cardona@CableLabs.com=20
<mailto:e.cardona@CableLabs.com> ]=20
Sent: Tuesday, July 29, 2003 10:17 AM =
To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org=20
Cc: david.raftus@imedia.com
Subject: RE: any ECR for docsIfCmtsModPreambleType value for = TDMA/ATDMA=20


Hi Minie, Thanks for tracking the topic, I am = copying the=20 IPCDN list.

As you mentioned, this is a very common situation = where the=20 updated
version of the spec has no = equivalent=20 attibutes for the older spec.


I would like to know if there is already a proposed = text for=20 the
enumeration update unknown(0) plus the = DESCRIPTION=20 explaining the value
zero; David Raftus may = have some=20 details around.

In the mean time,

I have not strong position to prefer other(0) rather = than=20 unknown(0),
let's leave for now unknown(0) =

Below is the definition from = draft-ipcdn-rfmibv2-06.txt=20


docsIfCmtsModPreambleType      &nb= sp;=20 OBJECT-TYPE
       =20 SYNTAX       INTEGER {
          &nbs= p;=20 qpsk0(1),
          &nbs= p;=20 qpsk1(2)
        }=20
       =20 MAX-ACCESS  read-create
       =20 STATUS      current
        DESCRIPTION =
          &nbs= p;=20 "Preamble type for DOCSIS 2.0 bursts"
        REFERENCE =
          &nbs= p;=20 "Data-Over-Cable Service Interface Specifications: Radio =
          &nbs= p; =20 Frequency Interface Specification SP-RFIv2.0-IO2-020617, =
          &nbs= p; =20 Table 8-19."
        DEFVAL { qpsk0 }=20
        = ::=3D {=20 docsIfCmtsModulationEntry 16 }



Tentative proposed: ( extended the REFERENCES to = link the 1.x=20 burst
considerations)


docsIfCmtsModPreambleType      &nb= sp;=20 OBJECT-TYPE
       =20 SYNTAX       INTEGER {
          &nbs= p;=20 qpsk0(1),
          &nbs= p;=20 qpsk1(2)
        }=20
       =20 MAX-ACCESS  read-create
       =20 STATUS      current
        DESCRIPTION =
          &nbs= p;=20 "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' =
          &nbs= p; =20 represents a row entry with DOCSIS 1.x burst only"
        REFERENCE =
          &nbs= p;=20 "Data-Over-Cable Service Interface Specifications: Radio =
          &nbs= p; =20 Frequency Interface Specification SP-RFIv2.0-IO2-020617, =
          &nbs= p; =20 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and =
          &nbs= p; =20 section 6.2.9 Preamble Prepend."
        DEFVAL { qpsk0 }=20
        = ::=3D {=20 docsIfCmtsModulationEntry 16 }


Comments are very welcome, Until a resolution is = taken in the=20 ipcdn
group, we can arrange a quick  = spec update=20 before then a new RFI mib RFC

is assigned and then required in the RFI spec. =


Regards

Eduardo

-----Original Message-----
From:=20 Minnie Lu [ mailto:milu@cisco.com <mailto:milu@cisco.com> ] =
Sent: Monday, July 28, 2003 5:13 PM
To: DOCSIS=20 OSS Majordomo List; Eduardo Cardona
Cc: = milu@cisco.com=20
Subject: any ECR for = docsIfCmtsModPreambleType value=20 for TDMA/ATDMA


Hi,

I know this issue described as below will be = addressed in the=20 next
revision
of = RF mib v2=20 draft. But it seems that it will take some time to have =
next
revision to be published and = accepted by=20 CableLabs as part of official
DOCSIS OSS = spec. =20 Is there any ECR/ECO/ECN already ?  If not yet, I =
think
we need one.

5) docsIfCmtsModPreambleType - (Joel) In=20 docsIfCmtsModulationTable, the
docsIfCmtsModPreambleType object has
2 possible=20 values qpsk0(1) and qpsk1(2). It seems like it's the only =
object
in this table without a =
meaningful default value when this parameter does not make = sense. For=20
instance, for a TDMA modulation =
profile using QAM16, the actual preamble type is indeed not = QPSK0 but=20
something else. Does it make sense =
to have a value of 0 in this case, like
docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? =

(Eduardo) for the benefit of clarifications wouldn't = be good=20 to have a
enumeration unknown(0) for this=20
object when not a 2.0 burst ? =
Also a note in the DESCRIPTION like "if = docsIfCmtsModChannelType is=20
tdma(1)
a value = unknown(0) is=20 used for this object"
I would say unknown(0) = rather=20 than unknown(3) since it looks like the
possible=20 current implementation may be reporting
'0' = , and=20 defendable in IETF since RFC 3291 uses '0' for inetAddressType =


Contributors - Joel Demarty Juniper, Eduardo Cardona = Cablelabs=20

  Thanks a lot for your help !
  Minnie

=00 ------_=_NextPart_001_01C35601.D9A6FD0B-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 15:07:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05133 for ; Tue, 29 Jul 2003 15:07:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZoM-0008EB-8X for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 15:07:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TJ728e031628 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 15:07:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZoL-0008Dj-NO; Tue, 29 Jul 2003 15:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZoC-0008DJ-Gk for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 15:06:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05064 for ; Tue, 29 Jul 2003 15:06:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZo9-00010o-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 15:06:49 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19hZo8-00010P-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 15:06:48 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6TJ68dS001223; Tue, 29 Jul 2003 13:06:08 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 29 Jul 2003 13:06:08 -0600 Message-ID: Thread-Topic: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Thread-Index: AcNV/YCJ100to7mdR523Wig4LGOa8AABF0qw From: "Eduardo Cardona" To: "Minnie Lu" , "Craig Patten @ Terayon" , "Raftus, David" Cc: "DOCSIS OSS Majordomo List" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Minnie,=20 I concur with David's proposal and your summary. The point for the ECR would be having that before CW28, ECR deadline, keep watching for extra comments comments and please write the ECR if you have the time for in the comming weeks . Thanks Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Tuesday, July 29, 2003 12:16 PM To: Craig Patten @ Terayon; Eduardo Cardona; Raftus, David Cc: 'Minnie Lu '; DOCSIS OSS Majordomo List; 'ipcdn@ietf.org ' Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, All, Thanks for your help ! The unknown(0) is also good to me. Just to remind=20 that please put the enum unknown(0) in the SYNTAX. As reference, in draft-ietf-ipcdn-docs-rfmibv2-05.txt, the old one refers=20 to a document number and this is the way used throughout the whole MIB. To=20 be consistent with other MIB objects' reference, I think it can be kept the same as before to reference the document number. The next version,=20 David could decide how to change it if necessary.:-) So please allow me to put all your comments together and comes up the=20 tentative proposed like below. Tentative proposed: ( extended the REFERENCES to link the 1.x burst considerations) docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { unknown(0), <------------------------------------ qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' represents a row entry consisting only of DOCSIS 1.x bursts." REFERENCE "Document [25] from References, 8.3.3 Upstream Channel=20 Descriptor (UCD), Table 8-19 and section 6.2.9 Preamble Prepend." DEFVAL { qpsk0 } ::=3D { docsIfCmtsModulationEntry 16 } Hi Eduardo, Possible to help writing up this ECR for DOCSIS OSSIv2.0 ? I think it is=20 too late for OSSIv1.1 now. If you are very busy, please let me know, then=20 I will find time to write it up. Appreciate your help ! Thanks a lot ! Minnie At 09:10 AM 7/29/2003 -0700, Patten, Craig wrote: > Eduardo, > >Minor documentation issue, I noticed the proposed definition includes a >reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, but=20 >should the mib actually reference the newer IO3 document AKA=20 >SP-RFIv2.0-I03-021218? > >Thanks, > >Craig > >-----Original Message----- >From: Raftus, David >To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List;=20 >ipcdn@ietf.org >Cc: Raftus, David >Sent: 7/29/2003 8:29 AM >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi, > >I agree that 'unknown (0)' matches the precedent set previously in the=20 >RF mib, and is preferable to 'other (0)'. > >Also, use of the value (0) is acceptable according to minutes of the=20 >IPCDN Feb 13/03 interim meeting: > >If enumeration has to start at 0, author to put description for Why.=20 >Otherwise start enumeration at 1. > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > SYNTAX INTEGER { > unknown (0), > validCmChained (1), > validCmTrusted (2), > invalidCmUntrusted (3), > invalidCAUntrusted (4), > invalidCmOther (5), > invalidCAOther (6) > } > >Here's a suggestion for Description wording, open to comments: > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown=20 >(0)' represents a row entry consisting only of DOCSIS 1.x bursts." > >Thanks, >Dave > >************************************ >David Raftus >Software Manager >Terayon Communications Canada >340 Terry Fox Drive, Suite 202 >Ottawa Canada K2K 3A2 > >david.raftus@terayon.com >613.592.1052 ext 222 >************************************ > >-----Original Message----- >From: Eduardo Cardona [ >mailto:e.cardona@CableLabs.com > ] >Sent: Tuesday, July 29, 2003 10:17 AM >To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org >Cc: david.raftus@imedia.com >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. > >As you mentioned, this is a very common situation where the updated=20 >version of the spec has no equivalent attibutes for the older spec. > >I would like to know if there is already a proposed text for the=20 >enumeration update unknown(0) plus the DESCRIPTION explaining the value >zero; David Raftus may have some details around. > >In the mean time, > >I have not strong position to prefer other(0) rather than unknown(0),=20 >let's leave for now unknown(0) > >Below is the definition from draft-ipcdn-rfmibv2-06.txt > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts" > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > Table 8-19." > DEFVAL { qpsk0 } > ::=3D { docsIfCmtsModulationEntry 16 } > > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst >considerations) > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' > represents a row entry with DOCSIS 1.x burst only" > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and > section 6.2.9 Preamble Prepend." > DEFVAL { qpsk0 } > ::=3D { docsIfCmtsModulationEntry 16 } > >Comments are very welcome, Until a resolution is taken in the ipcdn=20 >group, we can arrange a quick spec update before then a new RFI mib=20 >RFC > >is assigned and then required in the RFI spec. > >Regards > >Eduardo > >-----Original Message----- >From: Minnie Lu [ mailto:milu@cisco.com > ] >Sent: Monday, July 28, 2003 5:13 PM >To: DOCSIS OSS Majordomo List; Eduardo Cardona >Cc: milu@cisco.com >Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi, > >I know this issue described as below will be addressed in the next=20 >revision of RF mib v2 draft. But it seems that it will take some time=20 >to have next >revision to be published and accepted by CableLabs as part of official >DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I >think >we need one. > >5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the >docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and=20 >qpsk1(2). It seems like it's the only object >in this table without a >meaningful default value when this parameter does not make sense. For >instance, for a TDMA modulation >profile using QAM16, the actual preamble type is indeed not QPSK0 but >something else. Does it make sense >to have a value of 0 in this case, like >docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? > >(Eduardo) for the benefit of clarifications wouldn't be good to have a=20 >enumeration unknown(0) for this object when not a 2.0 burst ? >Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is >tdma(1) >a value unknown(0) is used for this object" >I would say unknown(0) rather than unknown(3) since it looks like the >possible current implementation may be reporting >'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType > >Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs > > Thanks a lot for your help ! > Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Tue Jul 29 23:15:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20924 for ; Tue, 29 Jul 2003 23:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhQb-0005G0-DO for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 23:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U3F1NL020185 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 23:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhQa-0005FH-Ns; Tue, 29 Jul 2003 23:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hX49-0000xd-MG for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 12:11:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27509 for ; Tue, 29 Jul 2003 12:11:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hX48-0006u2-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 12:11:08 -0400 Received: from desktop.terayon.com ([63.201.251.10] helo=SCBH02.terayon.com) by ietf-mx with esmtp (Exim 4.12) id 19hX47-0006tu-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 12:11:07 -0400 Received: by scowa.terayon.com with Internet Mail Service (5.5.2656.59) id ; Tue, 29 Jul 2003 09:09:15 -0700 Message-ID: From: "Patten, Craig" To: "Raftus, David" , "''Eduardo Cardona' '" , "'Minnie Lu '" , "'DOCSIS OSS Majordomo List '" , "'ipcdn@ietf.org '" Date: Tue, 29 Jul 2003 09:10:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C355EB.F1BFCBE0" Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C355EB.F1BFCBE0 Content-Type: text/plain; charset="iso-8859-1" Eduardo, Minor documentation issue, I noticed the proposed definition includes a reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, but should the mib actually reference the newer IO3 document AKA SP-RFIv2.0-I03-021218? Thanks, Craig -----Original Message----- From: Raftus, David To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org Cc: Raftus, David Sent: 7/29/2003 8:29 AM Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, I agree that 'unknown (0)' matches the precedent set previously in the RF mib, and is preferable to 'other (0)'. Also, use of the value (0) is acceptable according to minutes of the IPCDN Feb 13/03 interim meeting: If enumeration has to start at 0, author to put description for Why. Otherwise start enumeration at 1. - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE SYNTAX INTEGER { unknown (0), validCmChained (1), validCmTrusted (2), invalidCmUntrusted (3), invalidCAUntrusted (4), invalidCmOther (5), invalidCAOther (6) } Here's a suggestion for Description wording, open to comments: "Preamble type for DOCSIS 2.0 bursts. The value 'unknown (0)' represents a row entry consisting only of DOCSIS 1.x bursts." Thanks, Dave ************************************ David Raftus Software Manager Terayon Communications Canada 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@terayon.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Eduardo Cardona [ mailto:e.cardona@CableLabs.com ] Sent: Tuesday, July 29, 2003 10:17 AM To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org Cc: david.raftus@imedia.com Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. As you mentioned, this is a very common situation where the updated version of the spec has no equivalent attibutes for the older spec. I would like to know if there is already a proposed text for the enumeration update unknown(0) plus the DESCRIPTION explaining the value zero; David Raftus may have some details around. In the mean time, I have not strong position to prefer other(0) rather than unknown(0), let's leave for now unknown(0) Below is the definition from draft-ipcdn-rfmibv2-06.txt docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts" REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, Table 8-19." DEFVAL { qpsk0 } ::= { docsIfCmtsModulationEntry 16 } Tentative proposed: ( extended the REFERENCES to link the 1.x burst considerations) docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' represents a row entry with DOCSIS 1.x burst only" REFERENCE "Data-Over-Cable Service Interface Specifications: Radio Frequency Interface Specification SP-RFIv2.0-IO2-020617, 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and section 6.2.9 Preamble Prepend." DEFVAL { qpsk0 } ::= { docsIfCmtsModulationEntry 16 } Comments are very welcome, Until a resolution is taken in the ipcdn group, we can arrange a quick spec update before then a new RFI mib RFC is assigned and then required in the RFI spec. Regards Eduardo -----Original Message----- From: Minnie Lu [ mailto:milu@cisco.com ] Sent: Monday, July 28, 2003 5:13 PM To: DOCSIS OSS Majordomo List; Eduardo Cardona Cc: milu@cisco.com Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, I know this issue described as below will be addressed in the next revision of RF mib v2 draft. But it seems that it will take some time to have next revision to be published and accepted by CableLabs as part of official DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I think we need one. 5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only object in this table without a meaningful default value when this parameter does not make sense. For instance, for a TDMA modulation profile using QAM16, the actual preamble type is indeed not QPSK0 but something else. Does it make sense to have a value of 0 in this case, like docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? (Eduardo) for the benefit of clarifications wouldn't be good to have a enumeration unknown(0) for this object when not a 2.0 burst ? Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is tdma(1) a value unknown(0) is used for this object" I would say unknown(0) rather than unknown(3) since it looks like the possible current implementation may be reporting '0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs Thanks a lot for your help ! Minnie ------_=_NextPart_001_01C355EB.F1BFCBE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: any ECR for docsIfCmtsModPreambleType value for = TDMA/ATDMA

 Eduardo,

Minor documentation issue, I noticed the proposed = definition includes a reference SP-RFIv2.0-IO2-020617 spec.  I = don't think it has changed, but should the mib actually reference the = newer IO3 document AKA SP-RFIv2.0-I03-021218?

Thanks,

Craig


-----Original Message-----
From: Raftus, David
To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS = Majordomo List; ipcdn@ietf.org
Cc: Raftus, David
Sent: 7/29/2003 8:29 AM
Subject: RE: any ECR for docsIfCmtsModPreambleType = value for TDMA/ATDMA

Hi,

I agree that 'unknown (0)' matches the precedent set = previously in the
RF mib, and is preferable to 'other (0)'.

Also, use of the value (0) is acceptable according to = minutes of the
IPCDN Feb 13/03 interim meeting:

If enumeration has to start at 0, author to put = description for Why.
Otherwise start enumeration at 1.
 -       = docsBpi2CmtsAuthBpkmCmCertValid       = ;  OBJECT-TYPE
           = SYNTAX    INTEGER {
          &nb= sp;           &nb= sp;      unknown (0),
          &nb= sp;           &nb= sp;      validCmChained (1),
          &nb= sp;           &nb= sp;      validCmTrusted (2),
          &nb= sp;           &nb= sp;      invalidCmUntrusted (3),
          &nb= sp;           &nb= sp;      invalidCAUntrusted (4),
          &nb= sp;           &nb= sp;      invalidCmOther (5),
          &nb= sp;           &nb= sp;      invalidCAOther (6)
          &nb= sp;           &nb= sp;      }

Here's a suggestion for Description wording, open to = comments:
          &nb= sp; "Preamble type for DOCSIS 2.0 bursts. The value 'unknown=
(0)' represents a row entry consisting only of = DOCSIS 1.x bursts."

Thanks,
Dave


************************************
David Raftus
Software Manager
Terayon Communications Canada
340 Terry Fox Drive, Suite 202
Ottawa Canada  K2K 3A2

david.raftus@terayon.com      &nb= sp;   
613.592.1052  ext 222
************************************    &nb= sp;         


-----Original Message-----
From: Eduardo Cardona [ mailto:e.cardona@CableLabs.com
<mailto:e.cardona@CableLabs.com> ]
Sent: Tuesday, July 29, 2003 10:17 AM
To: Minnie Lu; DOCSIS OSS Majordomo List; = ipcdn@ietf.org
Cc: david.raftus@imedia.com
Subject: RE: any ECR for docsIfCmtsModPreambleType = value for TDMA/ATDMA


Hi Minie, Thanks for tracking the topic, I am copying = the IPCDN list.

As you mentioned, this is a very common situation = where the updated
version of the spec has no equivalent attibutes for = the older spec.


I would like to know if there is already a proposed = text for the
enumeration update unknown(0) plus the DESCRIPTION = explaining the value
zero; David Raftus may have some details around. =

In the mean time,

I have not strong position to prefer other(0) rather = than unknown(0),
let's leave for now unknown(0)

Below is the definition from = draft-ipcdn-rfmibv2-06.txt


docsIfCmtsModPreambleType      &n= bsp; OBJECT-TYPE
        = SYNTAX       INTEGER {
          &nb= sp; qpsk0(1),
          &nb= sp; qpsk1(2)
        }
        = MAX-ACCESS  read-create
        = STATUS      current
        = DESCRIPTION
          &nb= sp; "Preamble type for DOCSIS 2.0 bursts"
        REFERENCE =
          &nb= sp; "Data-Over-Cable Service Interface Specifications: Radio =
          &nb= sp;  Frequency Interface Specification SP-RFIv2.0-IO2-020617, =
          &nb= sp;  Table 8-19."
        DEFVAL { = qpsk0 }
        ::=3D { = docsIfCmtsModulationEntry 16 }



Tentative proposed: ( extended the REFERENCES to link = the 1.x burst
considerations)


docsIfCmtsModPreambleType      &n= bsp; OBJECT-TYPE
        = SYNTAX       INTEGER {
          &nb= sp; qpsk0(1),
          &nb= sp; qpsk1(2)
        }
        = MAX-ACCESS  read-create
        = STATUS      current
        = DESCRIPTION
          &nb= sp; "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' =
          &nb= sp;  represents a row entry with DOCSIS 1.x burst only" =
        REFERENCE =
          &nb= sp; "Data-Over-Cable Service Interface Specifications: Radio =
          &nb= sp;  Frequency Interface Specification SP-RFIv2.0-IO2-020617, =
          &nb= sp;  8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and =
          &nb= sp;  section 6.2.9 Preamble Prepend."
        DEFVAL { = qpsk0 }
        ::=3D { = docsIfCmtsModulationEntry 16 }


Comments are very welcome, Until a resolution is = taken in the ipcdn
group, we can arrange a quick  spec update = before then a new RFI mib RFC

is assigned and then required in the RFI spec. =


Regards

Eduardo

-----Original Message-----
From: Minnie Lu [ mailto:milu@cisco.com <mailto:milu@cisco.com> ]
Sent: Monday, July 28, 2003 5:13 PM
To: DOCSIS OSS Majordomo List; Eduardo Cardona =
Cc: milu@cisco.com
Subject: any ECR for docsIfCmtsModPreambleType value = for TDMA/ATDMA


Hi,

I know this issue described as below will be = addressed in the next
revision
of RF mib v2 draft. But it seems that it will take = some time to have
next
revision to be published and accepted by CableLabs = as part of official
DOCSIS OSS spec.  Is there any ECR/ECO/ECN = already ?  If not yet, I
think
we need one.

5) docsIfCmtsModPreambleType - (Joel) In = docsIfCmtsModulationTable, the
docsIfCmtsModPreambleType object has
2 possible values qpsk0(1) and qpsk1(2). It seems = like it's the only
object
in this table without a
meaningful default value when this parameter does = not make sense. For
instance, for a TDMA modulation
profile using QAM16, the actual preamble type is = indeed not QPSK0 but
something else. Does it make sense
to have a value of 0 in this case, like
docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA = profiles?

(Eduardo) for the benefit of clarifications wouldn't = be good to have a
enumeration unknown(0) for this
object when not a 2.0 burst ?
Also a note in the DESCRIPTION like "if = docsIfCmtsModChannelType is
tdma(1)
a value unknown(0) is used for this object" =
I would say unknown(0) rather than unknown(3) since = it looks like the
possible current implementation may be reporting =
'0' , and defendable in IETF since RFC 3291 uses '0' = for inetAddressType


Contributors - Joel Demarty Juniper, Eduardo Cardona = Cablelabs

  Thanks a lot for your help !
  Minnie

------_=_NextPart_001_01C355EB.F1BFCBE0-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 30 00:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20923 for ; Tue, 29 Jul 2003 23:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhQb-0005Fy-D6 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 23:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U3F1QV020186 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 23:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhQb-0005FS-2x; Tue, 29 Jul 2003 23:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hZ1g-0006Ug-TR for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 14:16:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03544 for ; Tue, 29 Jul 2003 14:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hZ1e-0000jn-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 14:16:42 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hZ1d-0000jZ-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 14:16:41 -0400 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TIG8uD025268; Tue, 29 Jul 2003 11:16:08 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE35385; Tue, 29 Jul 2003 11:16:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20030729105606.04c368d8@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Jul 2003 11:16:06 -0700 To: "Patten, Craig" , "''Eduardo Cardona' '" , "Raftus, David" From: Minnie Lu Cc: "'Minnie Lu '" , "'DOCSIS OSS Majordomo List '" , "'ipcdn@ietf.org '" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, All, Thanks for your help ! The unknown(0) is also good to me. Just to remind that please put the enum unknown(0) in the SYNTAX. As reference, in draft-ietf-ipcdn-docs-rfmibv2-05.txt, the old one refers to a document number and this is the way used throughout the whole MIB. To be consistent with other MIB objects' reference, I think it can be kept the same as before to reference the document number. The next version, David could decide how to change it if necessary.:-) So please allow me to put all your comments together and comes up the tentative proposed like below. Tentative proposed: ( extended the REFERENCES to link the 1.x burst considerations) docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { unknown(0), <------------------------------------ qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' represents a row entry consisting only of DOCSIS 1.x bursts." REFERENCE "Document [25] from References, 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and section 6.2.9 Preamble Prepend." DEFVAL { qpsk0 } ::= { docsIfCmtsModulationEntry 16 } Hi Eduardo, Possible to help writing up this ECR for DOCSIS OSSIv2.0 ? I think it is too late for OSSIv1.1 now. If you are very busy, please let me know, then I will find time to write it up. Appreciate your help ! Thanks a lot ! Minnie At 09:10 AM 7/29/2003 -0700, Patten, Craig wrote: > Eduardo, > >Minor documentation issue, I noticed the proposed definition includes a >reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, but >should the mib actually reference the newer IO3 document AKA >SP-RFIv2.0-I03-021218? > >Thanks, > >Craig > >-----Original Message----- >From: Raftus, David >To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org >Cc: Raftus, David >Sent: 7/29/2003 8:29 AM >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi, > >I agree that 'unknown (0)' matches the precedent set previously in the >RF mib, and is preferable to 'other (0)'. > >Also, use of the value (0) is acceptable according to minutes of the >IPCDN Feb 13/03 interim meeting: > >If enumeration has to start at 0, author to put description for Why. >Otherwise start enumeration at 1. > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > SYNTAX INTEGER { > unknown (0), > validCmChained (1), > validCmTrusted (2), > invalidCmUntrusted (3), > invalidCAUntrusted (4), > invalidCmOther (5), > invalidCAOther (6) > } > >Here's a suggestion for Description wording, open to comments: > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown >(0)' represents a row entry consisting only of DOCSIS 1.x bursts." > >Thanks, >Dave > >************************************ >David Raftus >Software Manager >Terayon Communications Canada >340 Terry Fox Drive, Suite 202 >Ottawa Canada K2K 3A2 > >david.raftus@terayon.com >613.592.1052 ext 222 >************************************ > >-----Original Message----- >From: Eduardo Cardona [ >mailto:e.cardona@CableLabs.com > ] >Sent: Tuesday, July 29, 2003 10:17 AM >To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org >Cc: david.raftus@imedia.com >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. > >As you mentioned, this is a very common situation where the updated >version of the spec has no equivalent attibutes for the older spec. > >I would like to know if there is already a proposed text for the >enumeration update unknown(0) plus the DESCRIPTION explaining the value >zero; David Raftus may have some details around. > >In the mean time, > >I have not strong position to prefer other(0) rather than unknown(0), >let's leave for now unknown(0) > >Below is the definition from draft-ipcdn-rfmibv2-06.txt > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts" > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > Table 8-19." > DEFVAL { qpsk0 } > ::= { docsIfCmtsModulationEntry 16 } > > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst >considerations) > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' > represents a row entry with DOCSIS 1.x burst only" > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and > section 6.2.9 Preamble Prepend." > DEFVAL { qpsk0 } > ::= { docsIfCmtsModulationEntry 16 } > >Comments are very welcome, Until a resolution is taken in the ipcdn >group, we can arrange a quick spec update before then a new RFI mib RFC > >is assigned and then required in the RFI spec. > >Regards > >Eduardo > >-----Original Message----- >From: Minnie Lu [ mailto:milu@cisco.com > ] >Sent: Monday, July 28, 2003 5:13 PM >To: DOCSIS OSS Majordomo List; Eduardo Cardona >Cc: milu@cisco.com >Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi, > >I know this issue described as below will be addressed in the next >revision >of RF mib v2 draft. But it seems that it will take some time to have >next >revision to be published and accepted by CableLabs as part of official >DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I >think >we need one. > >5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the >docsIfCmtsModPreambleType object has >2 possible values qpsk0(1) and qpsk1(2). It seems like it's the only >object >in this table without a >meaningful default value when this parameter does not make sense. For >instance, for a TDMA modulation >profile using QAM16, the actual preamble type is indeed not QPSK0 but >something else. Does it make sense >to have a value of 0 in this case, like >docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? > >(Eduardo) for the benefit of clarifications wouldn't be good to have a >enumeration unknown(0) for this >object when not a 2.0 burst ? >Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is >tdma(1) >a value unknown(0) is used for this object" >I would say unknown(0) rather than unknown(3) since it looks like the >possible current implementation may be reporting >'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType > >Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs > > Thanks a lot for your help ! > Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 30 00:04:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20925 for ; Tue, 29 Jul 2003 23:15:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhQb-0005Gw-V5 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 23:15:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U3F1dd020249 for ipcdn-archive@odin.ietf.org; Tue, 29 Jul 2003 23:15:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hhQb-0005GS-KV; Tue, 29 Jul 2003 23:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hb9s-0003tb-Sh for ipcdn@optimus.ietf.org; Tue, 29 Jul 2003 16:33:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08138 for ; Tue, 29 Jul 2003 16:33:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hb9r-0001ZF-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 16:33:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hb9p-0001Z2-00 for ipcdn@ietf.org; Tue, 29 Jul 2003 16:33:18 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 13:35:28 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TKWhuD024207; Tue, 29 Jul 2003 13:32:43 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-51-93.cisco.com [171.71.51.93]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE56408; Tue, 29 Jul 2003 13:32:42 -0700 (PDT) Message-Id: <4.3.2.7.2.20030729133222.04d13f70@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 29 Jul 2003 13:32:42 -0700 To: "Eduardo Cardona" From: Minnie Lu Cc: "Minnie Lu" , "Craig Patten @ Terayon" , "Raftus, David" , "DOCSIS OSS Majordomo List" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, Thanks a lot ! I will write it up. Minnie At 01:06 PM 7/29/2003 -0600, Eduardo Cardona wrote: >Minnie, >I concur with David's proposal and your summary. > >The point for the ECR would be having that before CW28, ECR deadline, >keep watching for extra comments comments and please write the ECR if >you have the time for in the comming weeks . > >Thanks >Eduardo > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Tuesday, July 29, 2003 12:16 PM >To: Craig Patten @ Terayon; Eduardo Cardona; Raftus, David >Cc: 'Minnie Lu '; DOCSIS OSS Majordomo List; 'ipcdn@ietf.org ' >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > >Hi, All, > >Thanks for your help ! The unknown(0) is also good to me. Just to >remind >that please put the enum unknown(0) in the SYNTAX. > >As reference, in draft-ietf-ipcdn-docs-rfmibv2-05.txt, the old one >refers >to a document number and this is the way used throughout the whole MIB. >To >be consistent with other MIB objects' reference, I think it can be kept > >the same as before to reference the document number. The next version, >David could decide how to change it if necessary.:-) > >So please allow me to put all your comments together and comes up the >tentative proposed like below. > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst >considerations) > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > unknown(0), <------------------------------------ > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' > >represents > a row entry consisting only of DOCSIS 1.x bursts." > REFERENCE > "Document [25] from References, 8.3.3 Upstream Channel >Descriptor (UCD), > Table 8-19 and section 6.2.9 Preamble Prepend." > DEFVAL { qpsk0 } > ::= { docsIfCmtsModulationEntry 16 } > >Hi Eduardo, > > Possible to help writing up this ECR for DOCSIS OSSIv2.0 ? I think it >is >too late for OSSIv1.1 now. If you are very busy, please let me know, >then >I will find time to write it up. > > Appreciate your help ! > Thanks a lot ! > Minnie > >At 09:10 AM 7/29/2003 -0700, Patten, Craig wrote: > > > Eduardo, > > > >Minor documentation issue, I noticed the proposed definition includes a > >reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, >but > >should the mib actually reference the newer IO3 document AKA > >SP-RFIv2.0-I03-021218? > > > >Thanks, > > > >Craig > > > >-----Original Message----- > >From: Raftus, David > >To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List; > >ipcdn@ietf.org > >Cc: Raftus, David > >Sent: 7/29/2003 8:29 AM > >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi, > > > >I agree that 'unknown (0)' matches the precedent set previously in the > >RF mib, and is preferable to 'other (0)'. > > > >Also, use of the value (0) is acceptable according to minutes of the > >IPCDN Feb 13/03 interim meeting: > > > >If enumeration has to start at 0, author to put description for Why. > >Otherwise start enumeration at 1. > > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > > SYNTAX INTEGER { > > unknown (0), > > validCmChained (1), > > validCmTrusted (2), > > invalidCmUntrusted (3), > > invalidCAUntrusted (4), > > invalidCmOther (5), > > invalidCAOther (6) > > } > > > >Here's a suggestion for Description wording, open to comments: > > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown > >(0)' represents a row entry consisting only of DOCSIS 1.x bursts." > > > >Thanks, > >Dave > > > >************************************ > >David Raftus > >Software Manager > >Terayon Communications Canada > >340 Terry Fox Drive, Suite 202 > >Ottawa Canada K2K 3A2 > > > >david.raftus@terayon.com > >613.592.1052 ext 222 > >************************************ > > > >-----Original Message----- > >From: Eduardo Cardona [ > >mailto:e.cardona@CableLabs.com > > ] > >Sent: Tuesday, July 29, 2003 10:17 AM > >To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org > >Cc: david.raftus@imedia.com > >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. > > > >As you mentioned, this is a very common situation where the updated > >version of the spec has no equivalent attibutes for the older spec. > > > >I would like to know if there is already a proposed text for the > >enumeration update unknown(0) plus the DESCRIPTION explaining the value > > >zero; David Raftus may have some details around. > > > >In the mean time, > > > >I have not strong position to prefer other(0) rather than unknown(0), > >let's leave for now unknown(0) > > > >Below is the definition from draft-ipcdn-rfmibv2-06.txt > > > >docsIfCmtsModPreambleType OBJECT-TYPE > > SYNTAX INTEGER { > > qpsk0(1), > > qpsk1(2) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Preamble type for DOCSIS 2.0 bursts" > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > > Table 8-19." > > DEFVAL { qpsk0 } > > ::= { docsIfCmtsModulationEntry 16 } > > > > > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst > >considerations) > > > >docsIfCmtsModPreambleType OBJECT-TYPE > > SYNTAX INTEGER { > > qpsk0(1), > > qpsk1(2) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' > > represents a row entry with DOCSIS 1.x burst only" > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > > 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and > > section 6.2.9 Preamble Prepend." > > DEFVAL { qpsk0 } > > ::= { docsIfCmtsModulationEntry 16 } > > > >Comments are very welcome, Until a resolution is taken in the ipcdn > >group, we can arrange a quick spec update before then a new RFI mib > >RFC > > > >is assigned and then required in the RFI spec. > > > >Regards > > > >Eduardo > > > >-----Original Message----- > >From: Minnie Lu [ mailto:milu@cisco.com > > ] > >Sent: Monday, July 28, 2003 5:13 PM > >To: DOCSIS OSS Majordomo List; Eduardo Cardona > >Cc: milu@cisco.com > >Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi, > > > >I know this issue described as below will be addressed in the next > >revision of RF mib v2 draft. But it seems that it will take some time > >to have next > >revision to be published and accepted by CableLabs as part of official > >DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I > >think > >we need one. > > > >5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the > > >docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and > >qpsk1(2). It seems like it's the only object > >in this table without a > >meaningful default value when this parameter does not make sense. For > >instance, for a TDMA modulation > >profile using QAM16, the actual preamble type is indeed not QPSK0 but > >something else. Does it make sense > >to have a value of 0 in this case, like > >docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? > > > >(Eduardo) for the benefit of clarifications wouldn't be good to have a > >enumeration unknown(0) for this object when not a 2.0 burst ? > >Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is > >tdma(1) > >a value unknown(0) is used for this object" > >I would say unknown(0) rather than unknown(3) since it looks like the > >possible current implementation may be reporting > >'0' , and defendable in IETF since RFC 3291 uses '0' for >inetAddressType > > > >Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs > > > > Thanks a lot for your help ! > > Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 30 10:09:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01994 for ; Wed, 30 Jul 2003 10:09:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrdV-00020Z-Ol for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 10:09:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UE91fp007715 for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 10:09:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrdV-00020G-66; Wed, 30 Jul 2003 10:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrdA-0001zU-TL for ipcdn@optimus.ietf.org; Wed, 30 Jul 2003 10:08:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01910 for ; Wed, 30 Jul 2003 10:08:33 -0400 (EDT) From: Wilson.Sawyer@arrisi.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrd7-0000O9-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 10:08:37 -0400 Received: from [63.86.74.152] (helo=titan.arrisi.com) by ietf-mx with esmtp (Exim 4.12) id 19hrd6-0000O6-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 10:08:36 -0400 To: ipcdn@ietf.org Cc: bwijnen@lucent.com X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Wed, 30 Jul 2003 10:08:30 -0400 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.12 |February 13, 2003) at 07/30/2003 10:08:36 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] subscriber management MIB: RFC3289 compliance statements Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Colleagues: Per Jean-Francois's suggestion, I'm including module compliance statements for how docsis subscriber management uses RFC3289 in the next internet-draft. This is a statement of which parts of 3289 must be implemented in order to claim compliance with subscriber management. Below are the OBJECT clauses I'm considering. They: -- require (at minimum) only IPv4 address classification -- require (at minimum) only Nonvolatile storage -- carry over some RFC3289 allowances on RowStatus objects -- require only always-drop for the algorithmic-drop table. If you are a CMTS operator or vendor, please review these carefully. Thank you Wilson Sawyer OBJECT diffServDataPathStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServClfrElementStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServMultiFieldClfrAddrType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServMultiFieldClfrSrcAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServMultiFieldClfrDstAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT diffServAlgDropStatus -- same as RFC3289 SYNTAX RowStatus { active(1) } WRITE-SYNTAX RowStatus { createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notInService is not required." OBJECT diffServDataPathStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServClfrStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServClfrElementStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServMultiFieldClfrStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServActionStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServCountActStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServAlgDropStorage SYNTAX StorageType { nonVolatile(3) } DESCRIPTION "An implementation is only required to support nonvolatile storage." OBJECT diffServAlgDropType SYNTAX INTEGER { alwaysDrop(5) } DESCRIPTION "For DOCSIS subscriber management, this object is only used to provide packet filtering. Implementations need not support other values of this enumeration." _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 30 11:26:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04861 for ; Wed, 30 Jul 2003 11:26:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsq3-0004Yn-5W for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 11:26:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFQ3YP017523 for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 11:26:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hsq1-0004YQ-Qy; Wed, 30 Jul 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hspx-0004YA-4n for ipcdn@optimus.ietf.org; Wed, 30 Jul 2003 11:25:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04849 for ; Wed, 30 Jul 2003 11:25:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hspu-00014c-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 11:25:54 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19hspt-00014K-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 11:25:53 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6UFPCdS021052; Wed, 30 Jul 2003 09:25: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Date: Wed, 30 Jul 2003 09:25:12 -0600 Message-ID: Thread-Topic: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Thread-Index: AcNWSN7T7K04bd8uRbe38WGRV2EgqgAZWw+w From: "Eduardo Cardona" To: "Minnie Lu" , "Craig Patten @ Terayon" , "Raftus, David" Cc: "DOCSIS OSS Majordomo List" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Minnie, Good summary, thanks again for doing that.=20 Only one thing,=20 IETF does not like references into the DESCRIPTION nor REFERENCE clauses, the reason for that is because when an operator stripped out the mib from the RFC document, the reference section ins gone, better to leave the full document name,=20 Thanks Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Tuesday, July 29, 2003 12:16 PM To: Craig Patten @ Terayon; Eduardo Cardona; Raftus, David Cc: 'Minnie Lu '; DOCSIS OSS Majordomo List; 'ipcdn@ietf.org ' Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, All, Thanks for your help ! The unknown(0) is also good to me. Just to remind=20 that please put the enum unknown(0) in the SYNTAX. As reference, in draft-ietf-ipcdn-docs-rfmibv2-05.txt, the old one refers=20 to a document number and this is the way used throughout the whole MIB. To=20 be consistent with other MIB objects' reference, I think it can be kept the same as before to reference the document number. The next version,=20 David could decide how to change it if necessary.:-) So please allow me to put all your comments together and comes up the=20 tentative proposed like below. Tentative proposed: ( extended the REFERENCES to link the 1.x burst considerations) docsIfCmtsModPreambleType OBJECT-TYPE SYNTAX INTEGER { unknown(0), <------------------------------------ qpsk0(1), qpsk1(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' represents a row entry consisting only of DOCSIS 1.x bursts." REFERENCE "Document [25] from References, 8.3.3 Upstream Channel=20 Descriptor (UCD), Table 8-19 and section 6.2.9 Preamble Prepend." DEFVAL { qpsk0 } ::=3D { docsIfCmtsModulationEntry 16 } Hi Eduardo, Possible to help writing up this ECR for DOCSIS OSSIv2.0 ? I think it is=20 too late for OSSIv1.1 now. If you are very busy, please let me know, then=20 I will find time to write it up. Appreciate your help ! Thanks a lot ! Minnie At 09:10 AM 7/29/2003 -0700, Patten, Craig wrote: > Eduardo, > >Minor documentation issue, I noticed the proposed definition includes a >reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, but=20 >should the mib actually reference the newer IO3 document AKA=20 >SP-RFIv2.0-I03-021218? > >Thanks, > >Craig > >-----Original Message----- >From: Raftus, David >To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List;=20 >ipcdn@ietf.org >Cc: Raftus, David >Sent: 7/29/2003 8:29 AM >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi, > >I agree that 'unknown (0)' matches the precedent set previously in the=20 >RF mib, and is preferable to 'other (0)'. > >Also, use of the value (0) is acceptable according to minutes of the=20 >IPCDN Feb 13/03 interim meeting: > >If enumeration has to start at 0, author to put description for Why.=20 >Otherwise start enumeration at 1. > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > SYNTAX INTEGER { > unknown (0), > validCmChained (1), > validCmTrusted (2), > invalidCmUntrusted (3), > invalidCAUntrusted (4), > invalidCmOther (5), > invalidCAOther (6) > } > >Here's a suggestion for Description wording, open to comments: > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown=20 >(0)' represents a row entry consisting only of DOCSIS 1.x bursts." > >Thanks, >Dave > >************************************ >David Raftus >Software Manager >Terayon Communications Canada >340 Terry Fox Drive, Suite 202 >Ottawa Canada K2K 3A2 > >david.raftus@terayon.com >613.592.1052 ext 222 >************************************ > >-----Original Message----- >From: Eduardo Cardona [ >mailto:e.cardona@CableLabs.com > ] >Sent: Tuesday, July 29, 2003 10:17 AM >To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org >Cc: david.raftus@imedia.com >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. > >As you mentioned, this is a very common situation where the updated=20 >version of the spec has no equivalent attibutes for the older spec. > >I would like to know if there is already a proposed text for the=20 >enumeration update unknown(0) plus the DESCRIPTION explaining the value >zero; David Raftus may have some details around. > >In the mean time, > >I have not strong position to prefer other(0) rather than unknown(0),=20 >let's leave for now unknown(0) > >Below is the definition from draft-ipcdn-rfmibv2-06.txt > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts" > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > Table 8-19." > DEFVAL { qpsk0 } > ::=3D { docsIfCmtsModulationEntry 16 } > > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst >considerations) > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' > represents a row entry with DOCSIS 1.x burst only" > REFERENCE > "Data-Over-Cable Service Interface Specifications: Radio > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and > section 6.2.9 Preamble Prepend." > DEFVAL { qpsk0 } > ::=3D { docsIfCmtsModulationEntry 16 } > >Comments are very welcome, Until a resolution is taken in the ipcdn=20 >group, we can arrange a quick spec update before then a new RFI mib=20 >RFC > >is assigned and then required in the RFI spec. > >Regards > >Eduardo > >-----Original Message----- >From: Minnie Lu [ mailto:milu@cisco.com > ] >Sent: Monday, July 28, 2003 5:13 PM >To: DOCSIS OSS Majordomo List; Eduardo Cardona >Cc: milu@cisco.com >Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > >Hi, > >I know this issue described as below will be addressed in the next=20 >revision of RF mib v2 draft. But it seems that it will take some time=20 >to have next >revision to be published and accepted by CableLabs as part of official >DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I >think >we need one. > >5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the >docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and=20 >qpsk1(2). It seems like it's the only object >in this table without a >meaningful default value when this parameter does not make sense. For >instance, for a TDMA modulation >profile using QAM16, the actual preamble type is indeed not QPSK0 but >something else. Does it make sense >to have a value of 0 in this case, like >docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? > >(Eduardo) for the benefit of clarifications wouldn't be good to have a=20 >enumeration unknown(0) for this object when not a 2.0 burst ? >Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is >tdma(1) >a value unknown(0) is used for this object" >I would say unknown(0) rather than unknown(3) since it looks like the >possible current implementation may be reporting >'0' , and defendable in IETF since RFC 3291 uses '0' for inetAddressType > >Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs > > Thanks a lot for your help ! > Minnie _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 30 14:50:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12619 for ; Wed, 30 Jul 2003 14:50:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hw1R-0007PY-Lm for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 14:50:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIo160028484 for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 14:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hw1Q-0007PD-Im; Wed, 30 Jul 2003 14:50:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hw1N-0007Ov-VV for ipcdn@optimus.ietf.org; Wed, 30 Jul 2003 14:49:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12600 for ; Wed, 30 Jul 2003 14:49:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hw1L-0002hQ-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 14:49:55 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19hw1K-0002hN-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 14:49:54 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h6UInDdS001799; Wed, 30 Jul 2003 12:49:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Date: Wed, 30 Jul 2003 12:49:13 -0600 Message-ID: Thread-Topic: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Thread-Index: AcNWxFVLhRqLZZ5TThWfVbBrMUWfzQAAWEUw From: "Eduardo Cardona" To: "Minnie Lu" Cc: "Craig Patten @ Terayon" , "Raftus, David" , "DOCSIS OSS Majordomo List" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Minnie,=20 That's why I would prefer having first the RFI new draft before rolling the ECR,=20 In such way we keep consistent references, and will be still on track for CW28 Eduardo -----Original Message----- From: Minnie Lu [mailto:milu@cisco.com]=20 Sent: Wednesday, July 30, 2003 11:57 AM To: Eduardo Cardona Cc: Minnie Lu; Craig Patten @ Terayon; Raftus, David; DOCSIS OSS Majordomo List; ipcdn@ietf.org Subject: RE: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Hi, Eduardo, I totally agree with you ! I personally also prefer the full document name. For this ECR, if only docsIfCmtsModPreambleType REFERENCE is modified as=20 your original proposal, then it would not be consistent with=20 others. Either we modify all the REFERENCE or leave all as they are. But I don't think this ECR needs to modify all the REFERENCE through=20 whole MIB in draft-ietf-ipcdn-docs-rfmibv2-05.txt. I think David will fix=20 all the REFERENCE in his next revision.:-) Do you still want me to modify only the docsIfCmtsModPreambleType=20 REFERENCE ? I would follow your advice if you still think so. Thanks a lot ! Minnie At 09:25 AM 7/30/2003 -0600, Eduardo Cardona wrote: >Minnie, > >Good summary, thanks again for doing that. >Only one thing, > >IETF does not like references into the DESCRIPTION nor REFERENCE=20 >clauses, the reason for that is because when an operator stripped out=20 >the mib from the RFC document, the reference section ins gone, better=20 >to leave the full document name, > > >Thanks > >Eduardo > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Tuesday, July 29, 2003 12:16 PM >To: Craig Patten @ Terayon; Eduardo Cardona; Raftus, David >Cc: 'Minnie Lu '; DOCSIS OSS Majordomo List; 'ipcdn@ietf.org ' >Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for=20 >TDMA/ATDMA > > >Hi, All, > >Thanks for your help ! The unknown(0) is also good to me. Just to=20 >remind that please put the enum unknown(0) in the SYNTAX. > >As reference, in draft-ietf-ipcdn-docs-rfmibv2-05.txt, the old one=20 >refers to a document number and this is the way used throughout the=20 >whole MIB. To >be consistent with other MIB objects' reference, I think it can be kept > >the same as before to reference the document number. The next version, >David could decide how to change it if necessary.:-) > >So please allow me to put all your comments together and comes up the=20 >tentative proposed like below. > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst >considerations) > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > unknown(0), <------------------------------------ > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts. The value=20 >'unknown(0)' > >represents > a row entry consisting only of DOCSIS 1.x bursts." > REFERENCE > "Document [25] from References, 8.3.3 Upstream Channel=20 >Descriptor (UCD), > Table 8-19 and section 6.2.9 Preamble Prepend." > DEFVAL { qpsk0 } > ::=3D { docsIfCmtsModulationEntry 16 } > >Hi Eduardo, > > Possible to help writing up this ECR for DOCSIS OSSIv2.0 ? I think=20 >it is too late for OSSIv1.1 now. If you are very busy, please let me=20 >know, then >I will find time to write it up. > > Appreciate your help ! > Thanks a lot ! > Minnie > >At 09:10 AM 7/29/2003 -0700, Patten, Craig wrote: > > > Eduardo, > > > >Minor documentation issue, I noticed the proposed definition includes > >a reference SP-RFIv2.0-IO2-020617 spec. I don't think it has=20 > >changed, >but > >should the mib actually reference the newer IO3 document AKA=20 > >SP-RFIv2.0-I03-021218? > > > >Thanks, > > > >Craig > > > >-----Original Message----- > >From: Raftus, David > >To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List;=20 > >ipcdn@ietf.org > >Cc: Raftus, David > >Sent: 7/29/2003 8:29 AM > >Subject: RE: any ECR for docsIfCmtsModPreambleType value for=20 > >TDMA/ATDMA > > > >Hi, > > > >I agree that 'unknown (0)' matches the precedent set previously in=20 > >the RF mib, and is preferable to 'other (0)'. > > > >Also, use of the value (0) is acceptable according to minutes of the=20 > >IPCDN Feb 13/03 interim meeting: > > > >If enumeration has to start at 0, author to put description for Why.=20 > >Otherwise start enumeration at 1. > > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > > SYNTAX INTEGER { > > unknown (0), > > validCmChained (1), > > validCmTrusted (2), > > invalidCmUntrusted (3), > > invalidCAUntrusted (4), > > invalidCmOther (5), > > invalidCAOther (6) > > } > > > >Here's a suggestion for Description wording, open to comments: > > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown > >(0)' represents a row entry consisting only of DOCSIS 1.x bursts." > > > >Thanks, > >Dave > > > >************************************ > >David Raftus > >Software Manager > >Terayon Communications Canada > >340 Terry Fox Drive, Suite 202 > >Ottawa Canada K2K 3A2 > > > >david.raftus@terayon.com > >613.592.1052 ext 222 > >************************************ > > > >-----Original Message----- > >From: Eduardo Cardona [=20 > >mailto:e.cardona@CableLabs.com > > ] > >Sent: Tuesday, July 29, 2003 10:17 AM > >To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org > >Cc: david.raftus@imedia.com > >Subject: RE: any ECR for docsIfCmtsModPreambleType value for=20 > >TDMA/ATDMA > > > >Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. > > > >As you mentioned, this is a very common situation where the updated=20 > >version of the spec has no equivalent attibutes for the older spec. > > > >I would like to know if there is already a proposed text for the=20 > >enumeration update unknown(0) plus the DESCRIPTION explaining the=20 > >value > > >zero; David Raftus may have some details around. > > > >In the mean time, > > > >I have not strong position to prefer other(0) rather than unknown(0), > >let's leave for now unknown(0) > > > >Below is the definition from draft-ipcdn-rfmibv2-06.txt > > > >docsIfCmtsModPreambleType OBJECT-TYPE > > SYNTAX INTEGER { > > qpsk0(1), > > qpsk1(2) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Preamble type for DOCSIS 2.0 bursts" > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > > Table 8-19." > > DEFVAL { qpsk0 } > > ::=3D { docsIfCmtsModulationEntry 16 } > > > > > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst > >considerations) > > > >docsIfCmtsModPreambleType OBJECT-TYPE > > SYNTAX INTEGER { > > qpsk0(1), > > qpsk1(2) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' > > represents a row entry with DOCSIS 1.x burst only" > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > > 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and > > section 6.2.9 Preamble Prepend." > > DEFVAL { qpsk0 } > > ::=3D { docsIfCmtsModulationEntry 16 } > > > >Comments are very welcome, Until a resolution is taken in the ipcdn=20 > >group, we can arrange a quick spec update before then a new RFI mib=20 > >RFC > > > >is assigned and then required in the RFI spec. > > > >Regards > > > >Eduardo > > > >-----Original Message----- > >From: Minnie Lu [ mailto:milu@cisco.com > > ] > >Sent: Monday, July 28, 2003 5:13 PM > >To: DOCSIS OSS Majordomo List; Eduardo Cardona > >Cc: milu@cisco.com > >Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi, > > > >I know this issue described as below will be addressed in the next=20 > >revision of RF mib v2 draft. But it seems that it will take some time > >to have next revision to be published and accepted by CableLabs as=20 > >part of official DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? > >If not yet, I think > >we need one. > > > >5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable,=20 > >the > > >docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and=20 > >qpsk1(2). It seems like it's the only object in this table without a > >meaningful default value when this parameter does not make sense. For > >instance, for a TDMA modulation > >profile using QAM16, the actual preamble type is indeed not QPSK0 but > >something else. Does it make sense > >to have a value of 0 in this case, like > >docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? > > > >(Eduardo) for the benefit of clarifications wouldn't be good to have=20 > >a enumeration unknown(0) for this object when not a 2.0 burst ? Also=20 > >a note in the DESCRIPTION like "if docsIfCmtsModChannelType is > >tdma(1) > >a value unknown(0) is used for this object" > >I would say unknown(0) rather than unknown(3) since it looks like the > >possible current implementation may be reporting '0' , and defendable > >in IETF since RFC 3291 uses '0' for >inetAddressType > > > >Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs > > > > Thanks a lot for your help ! > > Minnie > > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Wed Jul 30 17:11:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18069 for ; Wed, 30 Jul 2003 17:11:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyDv-0004aB-Ht for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 17:11:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULB3lj017611 for ipcdn-archive@odin.ietf.org; Wed, 30 Jul 2003 17:11:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyDu-0004Zs-0N; Wed, 30 Jul 2003 17:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvFy-0004ia-DK for ipcdn@optimus.ietf.org; Wed, 30 Jul 2003 14:00:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10877 for ; Wed, 30 Jul 2003 14:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvF2-0002KK-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 14:00:00 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hvF1-0002KF-00 for ipcdn@ietf.org; Wed, 30 Jul 2003 13:59:59 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2003 11:02:23 -0700 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6UHvKuG014085; Wed, 30 Jul 2003 10:57:27 -0700 (PDT) Received: from milu-w2k.cisco.com (dhcp-171-71-187-43.cisco.com [171.71.187.43]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKF76421; Wed, 30 Jul 2003 10:57:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20030730104241.01f873e8@mira-sjc5-1.cisco.com> X-Sender: milu@mira-sjc5-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 30 Jul 2003 10:57:18 -0700 To: "Eduardo Cardona" From: Minnie Lu Subject: RE: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA Cc: "Minnie Lu" , "Craig Patten @ Terayon" , "Raftus, David" , "DOCSIS OSS Majordomo List" , In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Hi, Eduardo, I totally agree with you ! I personally also prefer the full document name. For this ECR, if only docsIfCmtsModPreambleType REFERENCE is modified as your original proposal, then it would not be consistent with others. Either we modify all the REFERENCE or leave all as they are. But I don't think this ECR needs to modify all the REFERENCE through whole MIB in draft-ietf-ipcdn-docs-rfmibv2-05.txt. I think David will fix all the REFERENCE in his next revision.:-) Do you still want me to modify only the docsIfCmtsModPreambleType REFERENCE ? I would follow your advice if you still think so. Thanks a lot ! Minnie At 09:25 AM 7/30/2003 -0600, Eduardo Cardona wrote: >Minnie, > >Good summary, thanks again for doing that. >Only one thing, > >IETF does not like references into the DESCRIPTION nor REFERENCE >clauses, the reason for that is because when an operator stripped out >the mib from the RFC document, the reference section ins gone, better to >leave the full document name, > > >Thanks > >Eduardo > >-----Original Message----- >From: Minnie Lu [mailto:milu@cisco.com] >Sent: Tuesday, July 29, 2003 12:16 PM >To: Craig Patten @ Terayon; Eduardo Cardona; Raftus, David >Cc: 'Minnie Lu '; DOCSIS OSS Majordomo List; 'ipcdn@ietf.org ' >Subject: [ipcdn] RE: any ECR for docsIfCmtsModPreambleType value for >TDMA/ATDMA > > >Hi, All, > >Thanks for your help ! The unknown(0) is also good to me. Just to >remind >that please put the enum unknown(0) in the SYNTAX. > >As reference, in draft-ietf-ipcdn-docs-rfmibv2-05.txt, the old one >refers >to a document number and this is the way used throughout the whole MIB. >To >be consistent with other MIB objects' reference, I think it can be kept > >the same as before to reference the document number. The next version, >David could decide how to change it if necessary.:-) > >So please allow me to put all your comments together and comes up the >tentative proposed like below. > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst >considerations) > >docsIfCmtsModPreambleType OBJECT-TYPE > SYNTAX INTEGER { > unknown(0), <------------------------------------ > qpsk0(1), > qpsk1(2) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown(0)' > >represents > a row entry consisting only of DOCSIS 1.x bursts." > REFERENCE > "Document [25] from References, 8.3.3 Upstream Channel >Descriptor (UCD), > Table 8-19 and section 6.2.9 Preamble Prepend." > DEFVAL { qpsk0 } > ::= { docsIfCmtsModulationEntry 16 } > >Hi Eduardo, > > Possible to help writing up this ECR for DOCSIS OSSIv2.0 ? I think it >is >too late for OSSIv1.1 now. If you are very busy, please let me know, >then >I will find time to write it up. > > Appreciate your help ! > Thanks a lot ! > Minnie > >At 09:10 AM 7/29/2003 -0700, Patten, Craig wrote: > > > Eduardo, > > > >Minor documentation issue, I noticed the proposed definition includes a > >reference SP-RFIv2.0-IO2-020617 spec. I don't think it has changed, >but > >should the mib actually reference the newer IO3 document AKA > >SP-RFIv2.0-I03-021218? > > > >Thanks, > > > >Craig > > > >-----Original Message----- > >From: Raftus, David > >To: 'Eduardo Cardona'; Minnie Lu; DOCSIS OSS Majordomo List; > >ipcdn@ietf.org > >Cc: Raftus, David > >Sent: 7/29/2003 8:29 AM > >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi, > > > >I agree that 'unknown (0)' matches the precedent set previously in the > >RF mib, and is preferable to 'other (0)'. > > > >Also, use of the value (0) is acceptable according to minutes of the > >IPCDN Feb 13/03 interim meeting: > > > >If enumeration has to start at 0, author to put description for Why. > >Otherwise start enumeration at 1. > > - docsBpi2CmtsAuthBpkmCmCertValid OBJECT-TYPE > > SYNTAX INTEGER { > > unknown (0), > > validCmChained (1), > > validCmTrusted (2), > > invalidCmUntrusted (3), > > invalidCAUntrusted (4), > > invalidCmOther (5), > > invalidCAOther (6) > > } > > > >Here's a suggestion for Description wording, open to comments: > > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown > >(0)' represents a row entry consisting only of DOCSIS 1.x bursts." > > > >Thanks, > >Dave > > > >************************************ > >David Raftus > >Software Manager > >Terayon Communications Canada > >340 Terry Fox Drive, Suite 202 > >Ottawa Canada K2K 3A2 > > > >david.raftus@terayon.com > >613.592.1052 ext 222 > >************************************ > > > >-----Original Message----- > >From: Eduardo Cardona [ > >mailto:e.cardona@CableLabs.com > > ] > >Sent: Tuesday, July 29, 2003 10:17 AM > >To: Minnie Lu; DOCSIS OSS Majordomo List; ipcdn@ietf.org > >Cc: david.raftus@imedia.com > >Subject: RE: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi Minie, Thanks for tracking the topic, I am copying the IPCDN list. > > > >As you mentioned, this is a very common situation where the updated > >version of the spec has no equivalent attibutes for the older spec. > > > >I would like to know if there is already a proposed text for the > >enumeration update unknown(0) plus the DESCRIPTION explaining the value > > >zero; David Raftus may have some details around. > > > >In the mean time, > > > >I have not strong position to prefer other(0) rather than unknown(0), > >let's leave for now unknown(0) > > > >Below is the definition from draft-ipcdn-rfmibv2-06.txt > > > >docsIfCmtsModPreambleType OBJECT-TYPE > > SYNTAX INTEGER { > > qpsk0(1), > > qpsk1(2) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Preamble type for DOCSIS 2.0 bursts" > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > > Table 8-19." > > DEFVAL { qpsk0 } > > ::= { docsIfCmtsModulationEntry 16 } > > > > > >Tentative proposed: ( extended the REFERENCES to link the 1.x burst > >considerations) > > > >docsIfCmtsModPreambleType OBJECT-TYPE > > SYNTAX INTEGER { > > qpsk0(1), > > qpsk1(2) > > } > > MAX-ACCESS read-create > > STATUS current > > DESCRIPTION > > "Preamble type for DOCSIS 2.0 bursts. The value 'unknown' > > represents a row entry with DOCSIS 1.x burst only" > > REFERENCE > > "Data-Over-Cable Service Interface Specifications: Radio > > Frequency Interface Specification SP-RFIv2.0-IO2-020617, > > 8.3.3 Upstream Channel Descriptor (UCD), Table 8-19 and > > section 6.2.9 Preamble Prepend." > > DEFVAL { qpsk0 } > > ::= { docsIfCmtsModulationEntry 16 } > > > >Comments are very welcome, Until a resolution is taken in the ipcdn > >group, we can arrange a quick spec update before then a new RFI mib > >RFC > > > >is assigned and then required in the RFI spec. > > > >Regards > > > >Eduardo > > > >-----Original Message----- > >From: Minnie Lu [ mailto:milu@cisco.com > > ] > >Sent: Monday, July 28, 2003 5:13 PM > >To: DOCSIS OSS Majordomo List; Eduardo Cardona > >Cc: milu@cisco.com > >Subject: any ECR for docsIfCmtsModPreambleType value for TDMA/ATDMA > > > >Hi, > > > >I know this issue described as below will be addressed in the next > >revision of RF mib v2 draft. But it seems that it will take some time > >to have next > >revision to be published and accepted by CableLabs as part of official > >DOCSIS OSS spec. Is there any ECR/ECO/ECN already ? If not yet, I > >think > >we need one. > > > >5) docsIfCmtsModPreambleType - (Joel) In docsIfCmtsModulationTable, the > > >docsIfCmtsModPreambleType object has 2 possible values qpsk0(1) and > >qpsk1(2). It seems like it's the only object > >in this table without a > >meaningful default value when this parameter does not make sense. For > >instance, for a TDMA modulation > >profile using QAM16, the actual preamble type is indeed not QPSK0 but > >something else. Does it make sense > >to have a value of 0 in this case, like > >docsIfCmtsModScdmaInterleaverStepSize for non-SCDMA profiles? > > > >(Eduardo) for the benefit of clarifications wouldn't be good to have a > >enumeration unknown(0) for this object when not a 2.0 burst ? > >Also a note in the DESCRIPTION like "if docsIfCmtsModChannelType is > >tdma(1) > >a value unknown(0) is used for this object" > >I would say unknown(0) rather than unknown(3) since it looks like the > >possible current implementation may be reporting > >'0' , and defendable in IETF since RFC 3291 uses '0' for >inetAddressType > > > >Contributors - Joel Demarty Juniper, Eduardo Cardona Cablelabs > > > > Thanks a lot for your help ! > > Minnie > > >_______________________________________________ >IPCDN mailing list >IPCDN@ietf.org >https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 31 19:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18733 for ; Thu, 31 Jul 2003 19:21:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMjG-00026V-Qw for ipcdn-archive@odin.ietf.org; Thu, 31 Jul 2003 19:21:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VNL2lp008083 for ipcdn-archive@odin.ietf.org; Thu, 31 Jul 2003 19:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMjF-000262-6y; Thu, 31 Jul 2003 19:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMiJ-00024g-02 for ipcdn@optimus.ietf.org; Thu, 31 Jul 2003 19:20:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18635 for ; Thu, 31 Jul 2003 19:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMiE-0000iF-00 for ipcdn@ietf.org; Thu, 31 Jul 2003 19:19:58 -0400 Received: from news.ti.com ([192.94.94.33] helo=dragon.ti.com) by ietf-mx with esmtp (Exim 4.12) id 19iMiD-0000iB-00 for ipcdn@ietf.org; Thu, 31 Jul 2003 19:19:57 -0400 Received: from dlep50.itg.ti.com ([157.170.141.74]) by dragon.ti.com (8.12.9/8.12.9) with ESMTP id h6VNJR1p003827; Thu, 31 Jul 2003 18:19:27 -0500 (CDT) Received: from dflp2.itg.ti.com (localhost [127.0.0.1]) by dlep50.itg.ti.com (8.12.9/8.12.9) with ESMTP id h6VNJR20025937; Thu, 31 Jul 2003 18:19:27 -0500 (CDT) Received: from dbde01.itg.ti.com (dbde01.itg.ti.com [157.87.95.201]) by dflp2.itg.ti.com (8.9.3/8.9.3) with ESMTP id SAA08158; Thu, 31 Jul 2003 18:19:25 -0500 (CDT) Received: by dbde01.itg.ti.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Aug 2003 04:49:24 +0530 Message-ID: From: "Kumar, Satish" To: "'Beacham Gordon-CGB005'" Cc: "'ipcdn@ietf.org'" Date: Fri, 1 Aug 2003 04:49:22 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] Question on on IETF Signaling MIB Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Gordon, In signaling MIB I can see TWO identical MIBS pktcSigDevRsCadence and pktcSigDevRingSplashCadence How does these TWO differ? Please throw some light on this. For me both looks same and doing same functionality! Thanks, Satish Kumar Texas Instruments ===== pktcSigDevRsCadence OBJECT-TYPE SYNTAX PktcRingCadence MAX-ACCESS read-write STATUS current DESCRIPTION " This object specifies ring cadence rs (a user defined field) where each bit represents a duration of 100 milliseconds (6 seconds total), except the LSB 4 bits which are used to represent repeatable characteristics. The MTA MUST reject any attempt to make this object repeatable." DEFVAL {{ interval1, interval2, interval3, interval4, interval5, repeat1 }} -- 11111000000000000000000000000000000000000000000000000000000 -- 01000 ::= { pktcSigDevConfigObjects 22 } pktcSigDevRingSplashCadence OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2..28)) MAX-ACCESS read-write STATUS current DESCRIPTION " This is the Ring Cadence Octet String for splash ring. The first octet of the bit string represents the length in bits of the duration of the cadence. Each Bit after the first octet represents 50 ms and 1 represents ring and 0 represents silent. The first bit of the second octet is the first bit of the ring cadence. Only 216 Bits can be set total to represent 10800 ms of total cadence cycle." ::= { pktcSigDevConfigObjects 34 } ======= _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From exim@www1.ietf.org Thu Jul 31 20:54:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20341 for ; Thu, 31 Jul 2003 20:54:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOBF-0004zV-VI for ipcdn-archive@odin.ietf.org; Thu, 31 Jul 2003 20:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h710s1xc019169 for ipcdn-archive@odin.ietf.org; Thu, 31 Jul 2003 20:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOBF-0004yw-Ik; Thu, 31 Jul 2003 20:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOAW-0004yY-Mo for ipcdn@optimus.ietf.org; Thu, 31 Jul 2003 20:53:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20313 for ; Thu, 31 Jul 2003 20:53:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iOAU-00017X-00 for ipcdn@ietf.org; Thu, 31 Jul 2003 20:53:14 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 19iOAS-00017O-00 for ipcdn@ietf.org; Thu, 31 Jul 2003 20:53:12 -0400 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.9/8.12.9) with ESMTP id h710qadS024726; Thu, 31 Jul 2003 18:52:37 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C357C7.330BC2A3" Subject: RE: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01 Date: Thu, 31 Jul 2003 18:52:36 -0600 Message-ID: Thread-Topic: [ipcdn] FW: Publication of PacketCable IETF MIBs - SIG draft 01 Thread-Index: AcNVMRH2HbJx5n4ZRU+AXeF/2eqwvACkytbA From: "Jean-Francois Mule" To: , , "Wim De Ketelaere" , Cc: , , "Satish Kumar at Texas Instruments" , "Sumanth Channabasappa" , "Rick Vetter" X-Approved: ondar Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C357C7.330BC2A3 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, The co-authors of the ipcdn IPCablecom/PacketCable sig mib intend to = address all the pending comments including those received during WGLC by = August 8 and release an updated draft by August 15. Gordon Beacham, Satish Kumar and a couple of us from the packetcable oss = team spent some time today to try to review the comments and address = them. Here are the notes I took to document the consensus we had. Please review & comment by August 5, 2003. Jean-Francois. =20 --- Participants Gordon Beacham - Motorola Robert Lund - Terayon Satish Kumar - TI Paul Duffy - Cisco Eugene Nechamkin - Broadcom Rick Vetter - Lemur Networks Jean-Francois Mule - CableLabs --- Notes for ipcdn distribution ipcdn documents we reviewed: - Signaling MIB = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.txt= + Comments on draft-ietf-ipcdn-pktc-signaling-01.txt We have 3 sets of comments on the ipcdn sig MIB from the WGLC review: 1.a) List of outstanding issues provided by Gordon 1.b) Proposal to consider PacketCable Engineering Change Request mibsig-o-03004-v3 - additional input 1.c) Comments from Satish logged in these meeting notes ----------------------------------- 1.a) Review of outstanding issues provided by Gordon http://www.ipcdn.org/meetings/sigmib-01-outstanding-issues.html = =20 Note that Arris also provided input on these at: http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00754.h= tml = =20 - Issue 1 - pktcSigDevCodecTable=20 Motorola (Gordon) and Arris' proposal was to delete this object (i.e. delete it in the IETF version of the mib). We (Paul, Rik, Eugene, Jean-Francois) had consensus that having knowledge of the MTA supported codecs can actually serve to the operators. Consensus: we must not delete the codec table object. We discussed pktcSigDevCodecTable along with 1.b) mibsig-o-03004-v3 which is a proposal to enhance the table by adding several objects. Jean-Francois expressed various comments on the motivations of this ECO - I'll start a separate thread. Rick & Eugene also expressed why they believe it is needed. Overall, there is no consensus on this ECO and, it needs to be discussed on the list. More opinions must be expressed on the mailing list. See separate thread to follow. AI: - Rick to send proposed ECO to ipcdn list for full disclosure - team to review ECO mibsig-o-03004-v3 and make comments. - Issue 2 - PktcSigDevConnectionMode For review by COB 8/5/2003. Consensus : delete object. - Issue 3 - pktcSigPowerRingFrequency For review by COB 8/5/2003. No consensus , Eugene & Paul to send comments on this one. - Issue 4 - PktcSigPCMCoding For review by COB 8/5/2003. Consensus : delete object. - Issue 5 - pktcNcsEndPntConfigNomJitterBufferSize =20 pktcNcsEndPntConfigMaxJitterBufferSize For review by COB 8/5/2003. Consensus : delete objects. - Issue 6 - PktcSigDevToneType For review by COB 8/5/2003. Consensus : 1/ keep DTMF 0-15 as read-write (Gordon agrees) 2/ add 3 user-defined tones - Issue 7 - pktcSigPulseSignalDuration For review by COB 8/5/2003. Consensus : replace < pktcSigPulseSignalDuration OBJECT-TYPE =20 < SYNTAX Unsigned32 (1..5000) =20 by > pktcSigPulseSignalDuration OBJECT-TYPE =20 > SYNTAX Unsigned32 (50..5000) =20 And replace < pktcSigPulseSignalPauseDuration OBJECT-TYPE =20 < SYNTAX Unsigned32 (1..5000) =20 by > pktcSigPulseSignalPauseDuration OBJECT-TYPE =20 > SYNTAX Unsigned32 (50..5000) =20 - Issue 8 - pktcSigPulseSignalFrequency For review by COB 8/5/2003. Consensus : replace < pktcSigPulseSignalFrequency OBJECT-TYPE =20 < SYNTAX INTEGER { =20 < zero (1), =20 < fifty(2), =20 < twelvethousand(3), =20 < sixteenthousand(4)=20 < } =20 with > pktcSigPulseSignalFrequency OBJECT-TYPE =20 > SYNTAX INTEGER { =20 > zero (1), =20 > twelvethousand(2), =20 > sixteenthousand(3)=20 > } and make DEFVAL sixteenthousand(3) - Issue 9 - pktcSigPulseSignalDbLevel For review by COB 8/5/2003. Consensus : replace < pktcSigPulseSignalDbLevel OBJECT-TYPE =20 < SYNTAX TenthdBm (-250..150) =20 with > pktcSigPulseSignalDbLevel OBJECT-TYPE =20 > SYNTAX TenthdBm (-200..30) =20 - Issue 10 =20 For review by COB 8/5/2003. Consensus : delete pktcNcsEndPntConfigTxGain, pktcNcsEndPntConfigRxGain - Issue 11 For review by COB 8/5/2003. Consensus : delete pktcNcsEndPntConfigOffHookDebounce, = pktcNcsEndPntConfigOnHookDebounce - Issue 12 For review by COB 8/5/2003. Consensus : For the objects below, redefine the range to be based on real-world mins pktcNcsEndPntConfigPulseDialInterdigitTime, pktcNcsEndPntConfigPulseDialMinMakeTime, pktcNcsEndPntConfigPulseDialMaxMakeTime, pktcNcsEndPntConfigPulseDialMinBreakTime, pktcNcsEndPntConfigPulseDialMaxBreakTime, pktcNcsEndPntConfigMinHookFlash, pktcNcsEndPntConfigMaxHookFlash. For e.g., replace < pktcNcsEndPntConfigPulseDialMinMakeTime OBJECT-TYPE =20 < SYNTAX Unsigned32 (1..200) =20 with > pktcNcsEndPntConfigPulseDialMinMakeTime OBJECT-TYPE =20 > SYNTAX Unsigned32 (20..200) =20 ----------------------------------- 1.b) Proposal to consider mibsig-o-03004-v3 as additional input We addressed this proposal as part of issue #1. No consensus, more text on the mailing lists. ----------------------------------- 1.c) Comments from Satish logged in these meeting notes - PktcRingCadence - need to know the MSB Team debated that this is covered by SNMP STD RFCs. interval(0) is MSB; we found RFC 2579 section 3.1. as a possible normative reference for this. Team is ok with Satish proposing one sentence to clarify text. - pktcSigServiceClassNameMask =20 Satish raised a comment re: syntax of this object. What does it mean to have a non-zero value for the mask? Eugene said: see DOCSIS RFI 1.1 page 144, IP classifier def has 3 masks: " IP Classification Parameters: zero or more of the IP classification parameters (IP TOS Range/Mask, IP Protocol, IP Source Address/Mask, IP Destination Address/Mask, TCP/UDP Source Port Start, TCP/UDP Source Port End, TCP/UDP Destination Port Start, TCP/UCP Destination Port End)" =3D> the question still remains: We dismissed the TOS masks in DOCSIS mibs so we eliminated that one. Still, is the mask defined in pktcSigServiceClassNameMask applicable to = IP source mask or destination or both? AI: Based upon the answer, revise description clause. pktcSigServiceClassNameMask OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION " This object contains a value used for the NCS Call Signaling classifier mask. If this object is set to a zero value, an MTA MUST delete both NCS SFs. When this object is set to a non-zero value, an MTA MUST create the NCS SF for which the corresponding MIB object (pktcSigServiceClassNameUS or pktcSigServiceClassNameDS) has a non-empty value, if the NCS SF does not already exist." DEFVAL { 0 } ::=3D { pktcSigDevConfigObjects 14 } - pktcSigPulseSignalRepeatCount=20 do we need a DEFVAL for this object? AI: team to comment pktcSigPulseSignalRepeatCount OBJECT-TYPE SYNTAX Unsigned32 (0..5000) MAX-ACCESS read-write STATUS current DESCRIPTION " This is the repeat count, which signifies how many times to repeat the pulse." ::=3D{ pktcSigPulseSignalEntry 6 } - pktcNcsEndPntConfigEntry Nit: junk char in description pktcNcsEndPntConfigEntry OBJECT-TYPE SYNTAX PktcNcsEndPntConfigEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entries in pktcNcsEndPntConfigTable =FB Each entry = describes -> ^^^^ what signaling type a particular endpoint uses." >end.=20 ------_=_NextPart_001_01C357C7.330BC2A3 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message

All,

The co-authors = of the ipcdn=20 IPCablecom/PacketCable sig mib intend to address all the pending = comments=20 including those received during WGLC by August 8 and release an updated = draft by=20 August 15.

Gordon Beacham, Satish Kumar and a couple of us from = the=20 packetcable oss team spent some time today to try to review the comments = and=20 address them. Here are the notes I took to document the consensus we=20 had.
Please review & comment by August 5, 2003.

Jean-Francois.



  

--- Participants
Gordon Beacham - Motorola
Robert Lund - Terayon
Satish Kumar - TI
Paul Duffy - Cisco
Eugene Nechamkin - Broadcom
Rick Vetter - Lemur Networks
Jean-Francois Mule - CableLabs

--- Notes for ipcdn distribution
ipcdn documents we reviewed:
 - Signaling MIB
  =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-pktc-signaling-01.txt=


+ Comments on =
draft-ietf-ipcdn-pktc-signaling-01.txt
We have 3 sets of comments on the ipcdn sig MIB from the WGLC review:
 1.a) List of outstanding issues provided by Gordon
 1.b) Proposal to consider PacketCable Engineering Change Request
      mibsig-o-03004-v3 - additional input
 1.c) Comments from Satish logged in these meeting notes
-----------------------------------
 1.a) Review of outstanding issues provided by Gordon
=
http://www.ipcdn.org/meetings/sigmib-01-outstanding-issues.html<=
/FONT>
Note that Arris also provided input on these at:
http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/m=
sg00754.html

- Issue 1 - pktcSigDevCodecTable =

Motorola (Gordon) and Arris' proposal was to delete this object
(i.e. delete it in the IETF version of the mib). We (Paul, Rik,
Eugene, Jean-Francois) had consensus that having knowledge of the MTA
supported codecs can actually serve to the operators.
 Consensus: we must not delete the codec table object.
We discussed pktcSigDevCodecTable along with 1.b) mibsig-o-03004-v3
which is a proposal to enhance the table by adding several objects.
Jean-Francois expressed various comments on the motivations of this
ECO - I'll start a separate thread. Rick & Eugene also expressed why
they believe it is needed. Overall, there is no consensus on this ECO
and, it needs to be discussed on the list.
More opinions must be expressed on the mailing list. See separate
thread to follow.

AI:
  - Rick to send proposed ECO to ipcdn list for full disclosure
  - team to review ECO mibsig-o-03004-v3 and make comments.

- Issue 2 - PktcSigDevConnectionMode
For review by COB 8/5/2003.
Consensus : delete object.

- Issue 3 - pktcSigPowerRingFrequency
For review by COB 8/5/2003.
No consensus , Eugene & Paul to send comments on this one.

- Issue 4 - PktcSigPCMCoding
For review by COB 8/5/2003.
Consensus : delete object.

- Issue 5 - pktcNcsEndPntConfigNomJitterBufferSize =
 
            pktcNcsEndPntConfigMaxJitterBufferSize
For review by COB 8/5/2003.
Consensus : delete objects.

- Issue 6 - PktcSigDevToneType
For review by COB 8/5/2003.
Consensus :
  1/ keep DTMF 0-15 as read-write (Gordon agrees)
  2/ add 3 user-defined tones

- Issue 7 - pktcSigPulseSignalDuration
For review by COB 8/5/2003.
Consensus :
replace
<   pktcSigPulseSignalDuration    OBJECT-TYPE  =

<       SYNTAX       Unsigned32 (1..5000)  =

by
>   pktcSigPulseSignalDuration    OBJECT-TYPE  =

>       SYNTAX       Unsigned32 (50..5000)  =


And replace
< pktcSigPulseSignalPauseDuration    =
OBJECT-TYPE  
<       SYNTAX       Unsigned32 (1..5000)  =

by
> pktcSigPulseSignalPauseDuration    =
OBJECT-TYPE  
>       SYNTAX       Unsigned32 (50..5000)  =


- Issue 8 - pktcSigPulseSignalFrequency
For review by COB 8/5/2003.
Consensus :
replace
<   pktcSigPulseSignalFrequency    OBJECT-TYPE  =

<       SYNTAX       INTEGER {  
<                    zero (1),  
<                    fifty(2),  
<                    twelvethousand(3),  =

<                    sixteenthousand(4) 
<       }             
with
>   pktcSigPulseSignalFrequency    OBJECT-TYPE  =

>       SYNTAX       INTEGER {  
>                    zero (1),  
>                    twelvethousand(2),  =

>                    sixteenthousand(3) 
>       }
and make DEFVAL sixteenthousand(3)


- Issue 9 - pktcSigPulseSignalDbLevel
For review by COB 8/5/2003.
Consensus :
replace
<   pktcSigPulseSignalDbLevel    OBJECT-TYPE  =

<       SYNTAX       TenthdBm (-250..150)  =

with
>  pktcSigPulseSignalDbLevel    OBJECT-TYPE  =

>      SYNTAX       TenthdBm (-200..30)  =



- Issue 10  
For review by COB 8/5/2003.
Consensus :
  delete pktcNcsEndPntConfigTxGain, pktcNcsEndPntConfigRxGain

- Issue 11
For review by COB 8/5/2003.
Consensus :
  delete pktcNcsEndPntConfigOffHookDebounce, =
pktcNcsEndPntConfigOnHookDebounce

- Issue 12
For review by COB 8/5/2003.
Consensus :
For the objects below, redefine the range to be based on real-world
mins
 pktcNcsEndPntConfigPulseDialInterdigitTime,
 pktcNcsEndPntConfigPulseDialMinMakeTime,
 pktcNcsEndPntConfigPulseDialMaxMakeTime,
 pktcNcsEndPntConfigPulseDialMinBreakTime,
 pktcNcsEndPntConfigPulseDialMaxBreakTime,
 pktcNcsEndPntConfigMinHookFlash,
 pktcNcsEndPntConfigMaxHookFlash.

For e.g.,
replace
< pktcNcsEndPntConfigPulseDialMinMakeTime    =
OBJECT-TYPE  
<       SYNTAX       Unsigned32 (1..200)  =

with
> pktcNcsEndPntConfigPulseDialMinMakeTime    =
OBJECT-TYPE  
>       SYNTAX       Unsigned32 (20..200)  =


-----------------------------------
 1.b) Proposal to consider mibsig-o-03004-v3 as additional input
 We addressed this proposal as part of issue #1.
 No consensus, more text on the mailing lists.

-----------------------------------
 1.c) Comments from Satish logged in these meeting notes
- PktcRingCadence - need to know the MSB
 Team debated that this is covered by SNMP STD RFCs. interval(0) is
MSB; we found RFC 2579 section 3.1. as a possible normative reference
for this. Team is ok with Satish proposing one sentence to clarify
text.

- pktcSigServiceClassNameMask  
   Satish raised a comment re: syntax of this object. What does it
mean to have a non-zero value for the mask?
   Eugene said: see DOCSIS RFI 1.1 page 144, IP classifier def has 3
masks:
"   IP Classification Parameters: zero or more of the IP classification
parameters (IP TOS Range/Mask, IP Protocol, IP Source Address/Mask, IP
Destination Address/Mask, TCP/UDP Source Port Start, TCP/UDP Source
Port End, TCP/UDP Destination Port Start, TCP/UCP Destination Port
End)"
=3D> the question still remains:
We dismissed the TOS masks in DOCSIS mibs so we eliminated that one.
Still, is the mask defined in pktcSigServiceClassNameMask applicable to =
IP
source mask or destination or both?
AI: Based upon the answer, revise description clause.
   pktcSigServiceClassNameMask  OBJECT-TYPE
        SYNTAX     Integer32
        MAX-ACCESS  read-write
        STATUS     current
        DESCRIPTION
            " This object contains a value used for the NCS Call
              Signaling classifier mask. If this object is set to a
              zero value, an MTA MUST delete both NCS SFs. When
              this object is set to a non-zero value, an MTA MUST
              create the NCS SF for which the corresponding MIB object
              (pktcSigServiceClassNameUS  or pktcSigServiceClassNameDS)
              has a non-empty value, if the NCS SF does not already
              exist."
        DEFVAL { 0 }
        ::=3D { pktcSigDevConfigObjects 14 }

- pktcSigPulseSignalRepeatCount 
  do we need a DEFVAL for this object?
  AI: team to comment
    pktcSigPulseSignalRepeatCount    OBJECT-TYPE
       SYNTAX       Unsigned32 (0..5000)
       MAX-ACCESS   read-write
       STATUS       current
       DESCRIPTION
           " This is the repeat count, which signifies how many times
             to repeat the pulse."
       ::=3D{ pktcSigPulseSignalEntry 6 }

- pktcNcsEndPntConfigEntry
   Nit: junk char in description
   pktcNcsEndPntConfigEntry  OBJECT-TYPE
       SYNTAX        PktcNcsEndPntConfigEntry
       MAX-ACCESS    not-accessible
       STATUS        current
       DESCRIPTION
           " Entries in pktcNcsEndPntConfigTable =FB Each entry =
describes
->                                             =
^^^^
             what signaling type a particular endpoint uses."



>end.
=00 ------_=_NextPart_001_01C357C7.330BC2A3-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn