From mailnull@www1.ietf.org Sat Mar 1 12:50:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12950 for ; Sat, 1 Mar 2003 12:50:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h21HxIB04964 for ipcdn-archive@odin.ietf.org; Sat, 1 Mar 2003 12:59:18 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21Hx7p04951; Sat, 1 Mar 2003 12:59:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21Hwap04927 for ; Sat, 1 Mar 2003 12:58:36 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12898; Sat, 1 Mar 2003 12:48:34 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h21HoYFP008356; Sat, 1 Mar 2003 10:50:34 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id KAA18903; Sat, 1 Mar 2003 10:50:33 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id <1SR755FR>; Sat, 1 Mar 2003 12:50:32 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C0849AA@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'internet-drafts@ietf.org'" Cc: "'Michael W. Patrick (E-mail)'" , "'Docsis-Oss (E-mail) (E-mail)'" , "'IPCDN (E-mail) (E-mail)'" , "'Richard Woundy (E-mail)'" Date: Sat, 1 Mar 2003 12:50:28 -0500 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E01B.08ABBAEA" Subject: [ipcdn] draft-ietf-ipcdn-qos-mib-08.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: , 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_01C2E01B.08ABBAEA Content-Type: text/plain; charset="iso-8859-1" Please post the following draft, Tiitle: Data Over Cable System Quality of Service Management Information Base (DOCSIS-QOS MIB) Version: 8 Dated: March 1, 2003 Work Group: IPCDN Authors: Michael Patrick and William Murwin ______________________________ William Murwin Broadband Communications Sector Motorola Inc. Email: W.Murwin@motorola.com Tel: (508) 851-8385 <> ------_=_NextPart_000_01C2E01B.08ABBAEA Content-Type: text/plain; name="draft-ietf-ipcdn-qos-mib-08.txt" Content-Disposition: attachment; filename="draft-ietf-ipcdn-qos-mib-08.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= IPCDN Working Group Michael = Patrick=0A= William = Murwin=0A= Motorola BCS=0A= =0A= =0A= =0A= Data Over Cable System Interface Specification=0A= Quality of Service=0A= Management Information Base (DOCSIS-QOS MIB)=0A= =0A= March 1, 2003=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance = with=0A= all the provisions of Section 10 of RFC2026. Internet-Drafts are=0A= working documents of the Internet Engineering Task Force (IETF), = its=0A= Areas, and its Working Groups. Note that other groups may also=0A= distribute working documents as Internet-Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six = months=0A= and may be updated, replaced, or obsoleted by other documents at = any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as a "work in progress".=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= =0A= Copyright (c) The Internet Society 2003. All Rights Reserved.=0A= =0A= =0A= Abstract=0A= =0A= This document defines a basic set of managed objects for = SNMP-based=0A= management of extended QOS features of Cable Modems (CMs) and = Cable=0A= Modem Termination Systems (CMTSs) conforming to the Data over = Cable=0A= System (DOCSIS) standard version 1.1 and 2.0.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 1]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= Table of Contents=0A= =0A= =0A= Status of this Memo............................... 1=0A= Abstract.......................................... 1=0A= =0A= 1. Introduction...................................... 3=0A= 1.1 The Internet-Standard Management Framework... 3=0A= 1.2 Glossary..................................... 3=0A= =0A= 2. Overview.......................................... 5=0A= 2.1 Textual Conventions.......................... 5=0A= 2.2 MIB Organization............................ 5=0A= 2.2.1 docsQosPktClassTable................. 9=0A= 2.2.2 docsQosParamSetTable................. 9=0A= 2.2.2.1 Interoperation with DOCSIS 1.0....... 11=0A= 2.2.3 docsQosServiceFlowTable.............. 12=0A= 2.2.4 docsQosServiceFlowStatsTable......... 13=0A= 2.2.5 docsQosUpstreamStatsTable............ 14=0A= 2.2.6 docsQosDynamicServiceStatsTable...... 14=0A= 2.2.7 docsQosServiceFlowLogTable........... 14=0A= 2.2.8 docsQosServiceClassTable............. 15=0A= 2.2.9 docsQosServiceClassPolicyTable....... 15=0A= 2.2.10 docsQosPHSTable...................... 15=0A= 2.2.11 docsQosCmtsMacToSrvFlowTable......... 16=0A= =0A= 3. Externally Administered Classification............ 16=0A= =0A= 4. Definitions....................................... 20=0A= =0A= 5. Security Considerations........................... 78=0A= =0A= 6. Intellectual Property............................. 79=0A= =0A= 7. Acknowledgement................................... 80=0A= =0A= 8. Normative References.............................. 80=0A= =0A= 9. Informative References............................ 81=0A= =0A= 10. Author's Address.................................. 81=0A= =0A= 11. Full Copyright Statement.......................... 82=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 2]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 1. Introduction=0A= =0A= This memo is a product of the IPCDN working group within the = Internet=0A= Engineering Task Force. Comments are solicited and should be=0A= addressed to the working group's mailing list at ipcdn@ietf.org=0A= and/or the author.=0A= =0A= =0A= 1.1 The Internet-Standard Management Framework=0A= =0A= For a detailed overview of the documents that describe the = current=0A= Internet-Standard Management Framework, please refer to section 7 = of=0A= RFC 3410 [13].=0A= =0A= Managed objects are accessed via a virtual information store, = termed=0A= the Management Information Base or MIB. MIB objects are = generally=0A= accessed through the Simple Network Management Protocol (SNMP).=0A= Objects in the MIB are defined using the mechanisms defined in = the=0A= Structure of Management Information (SMI). This memo specifies a = MIB=0A= module that is compliant to the SMIv2, which is described in STD = 58,=0A= RFC 2578 [1], STD 58, RFC 2579 [2] and STD 58, RFC 2580 [3].=0A= =0A= 1.2 Glossary=0A= =0A= =0A= =0A= Active QPS Active Qos Parameter Set. The set of QOS = parameters=0A= that describe the current level service provided to = a=0A= Service Flow.=0A= =0A= Active SF Active Service Flow. An SF with a non-empty Active=0A= QPS.=0A= =0A= Admitted QPS Admitted Qos Parameter Set. The set of QOS = parameters=0A= that describe a level of service which the Service=0A= Flow is not currently using, but which it is=0A= guaranteed to receive upon the SF's request to = make=0A= the set Active.=0A= =0A= Admitted SF A Service Flow with a non-empty Admitted QPS.=0A= =0A= CATV Cable TV=0A= =0A= CM Cable Modem, a modem connecting a subscriber's LAN = the=0A= CATF RF network. DOCSIS CMs operate as a MAC layer=0A= bridge between the home LAN and the RF network.=0A= =0A= CMTS Cable Modem Termination System, the "head-end" = device=0A= providing connectivity between the RF network and = the=0A= Internet.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 3]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= Downstream The direction from the head end towards the=0A= subscriber.=0A= =0A= DSA Dynamic Service Addition, a DOCSIS MAC management=0A= message requesting the dynamic creation of a new=0A= Service Flow. New SFs are created with a three-=0A= message exchange of a DSA-REQ, DSA-RSP, and = DSA-ACK.=0A= =0A= DSC Dynamic Service Change, a DOCSIS MAC management=0A= message requesting a change to the attributes of a=0A= Service Flow. SFs are changed with a = three-message=0A= exchange of a DSC-REQ, DSC-RSP, and DSC-ACK.=0A= =0A= DSD Dynamic Service Delete, a DOCSIS MAC management=0A= message requesting the deletion of a Service Flow. = SFs=0A= are deleted with a two-message exchange of a = DSD-REQ=0A= and DSD-ACK.=0A= =0A= Head-end The origination point in most cable systems of the=0A= subsriber video signals. It is generally also the=0A= location of the CMTS.=0A= =0A= PHS Payload Header Suppression, a feature of DOCSIS = 1.1=0A= and 2.0 in which header bytes that are common in a=0A= sequence of packets of a Service Flow are replaced = by=0A= a one-byte PHSI Index (PHSI) when transmitting the=0A= packet on the RF network.=0A= =0A= Provisioned QPS A QOS Parameter Set describing an envelope of = service=0A= within which a Service Flow is authorized to = request=0A= admission. All existing service flows must have a=0A= non-empty Provisioned QPS, hence all SFs are=0A= considered to be "Provisioned".=0A= =0A= SCN Service Class Name -- a named set of QOS = parameters.=0A= A Service Flow may or may not be associated with a=0A= single named Service Class. A Service Class has as = an=0A= attribute a Qos Parameter Set that is used as the=0A= default set of values for all Service Flows = belonging=0A= to the Service Class.=0A= =0A= SID Service ID. A 16-bit integer assigned by the CMTS = for=0A= an Upstream Service Flow with a non-empty Active = QOS=0A= Parameter Set.=0A= =0A= SF Service Flow. A unidirectional stream of packets=0A= between the CM and CMTS. SFs are characterized as=0A= upstream or downstream. The SF is the fundamental=0A= unit of service provided on a DOCSIS CATV network.=0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 4]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= SFID Service Flow ID. A 32-bit unsigned integer = assigned=0A= by the CMTS to each Service Flows=0A= =0A= Upstream The direction from a subscriber CM to the head-end=0A= CMTS.=0A= =0A= =0A= =0A= =0A= 2. Overview=0A= =0A= This MIB provides a set of objects required for the management of=0A= DOCSIS 1.1 and 2.0 compliant Cable Modems (CM) and Cable Modem=0A= Termination Systems (CMTS). The specification is derived from the=0A= DOCSIS 1.1 Radio Frequency Interface specification [4]. Please = note=0A= that the referenced DOCSIS standard only requires Cable Modems to=0A= process IPv4 customer traffic. Design choices in this MIB reflect=0A= those requirements. Future versions of the DOCSIS standard are=0A= expected to require support for IPv6 as well.=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this=0A= document are to be interpreted as described in [7].=0A= =0A= =0A= 2.1 Textual Conventions=0A= =0A= The textual convention "DocsRfMacIfDirection" is defined to = indicate=0A= the direction of a packet classifier relative to an interface. It=0A= takes the values of either downstream(1) or upstream(2).=0A= =0A= The textual convention "DocsBitRate" corresponds to the bits per=0A= second as defined for QOS Parameter Sets in DOCSIS 1.1 and 2.0. = This=0A= definition includes all bits of the Ethernet MAC frame as = transmitted=0A= on the RF network, starting with the Destination Address and = ending=0A= with the Ethernet FCS. It does NOT includes bits in the DOCSIS = MAC=0A= header.=0A= =0A= =0A= =0A= =0A= =0A= 2.2 MIB Organization=0A= =0A= =0A= The structure of the MIB is summarized below:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 5]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosMIB=0A= docsQosMIBObjects=0A= docsQosPktClassTable=0A= docsQosPktClassEntry=0A= docsQosPktClassId=0A= docsQosPktClassDirection=0A= docsQosPktClassPriority=0A= docsQosPktClassIpTosLow=0A= docsQosPktClassIpTosHigh=0A= docsQosPktClassIpTosMask=0A= docsQosPktClassIpProtocol=0A= docsQosPktClassInetAddressType=0A= docsQosPktClassInetSourceAddr=0A= docsQosPktClassInetSourceMask=0A= docsQosPktClassInetDestAddr=0A= docsQosPktClassInetDestMask=0A= docsQosPktClassSourcePortStart=0A= docsQosPktClassSourcePortEnd=0A= docsQosPktClassDestPortStart=0A= docsQosPktClassDestPortEnd=0A= docsQosPktClassDestMacAddr=0A= docsQosPktClassDestMacMask=0A= docsQosPktClassSourceMacAddr=0A= docsQosPktClassEnetProtocolType=0A= docsQosPktClassEnetProtocol=0A= docsQosPktClassUserPriLow=0A= docsQosPktClassUserPriHigh=0A= docsQosPktClassVlanId=0A= docsQosPktClassStateActive=0A= docsQosPktClassPkts=0A= docsQosPktClassBitMap=0A= docsQosParamSetTable=0A= docsQosParamSetEntry=0A= docsQosParamSetServiceClassName=0A= docsQosParamSetPriority=0A= docsQosParamSetMaxTrafficRate=0A= docsQosParamSetMaxTrafficBurst=0A= docsQosParamSetMinReservedRate=0A= docsQosParamSetMinReservedPkt=0A= docsQosParamSetActiveTimeout=0A= docsQosParamSetAdmittedTimeout=0A= docsQosParamSetMaxConcatBurst=0A= docsQosParamSetSchedulingType=0A= docsQosParamSetNomPollInterval=0A= docsQosParamSetTolPollJitter=0A= docsQosParamSetUnsolicitGrantSize=0A= docsQosParamSetNomGrantInterval=0A= docsQosParamSetTolGrantJitter=0A= docsQosParamSetGrantsPerInterval=0A= docsQosParamSetTosAndMask=0A= docsQosParamSetTosOrMask=0A= =0A= =0A= =0A= Expires September 2003 [Page 6]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosParamSetMaxLatency=0A= docsQosParamSetType=0A= docsQosParamSetRequestPolicyOct=0A= docsQosParamSetBitMap=0A= docsQosServiceFlowTable=0A= docsQosServiceFlowEntry=0A= docsQosServiceFlowId=0A= docsQosServiceFlowSID=0A= docsQosServiceFlowDirection=0A= docsQosServiceFlowPrimary=0A= docsQosServiceFlowStatsTable=0A= docsQosServiceFlowStatsEntry=0A= docsQosServiceFlowPkts=0A= docsQosServiceFlowOctets=0A= docsQosServiceFlowTimeCreated=0A= docsQosServiceFlowTimeActive=0A= docsQosServiceFlowPHSUnknowns=0A= docsQosServiceFlowPolicedDropPkts=0A= docsQosServiceFlowPolicedDelayPkts=0A= docsQosUpstreamStatsTable=0A= docsQosUpstreamStatsEntry=0A= docsQosSID=0A= docsQosUpstreamFragments=0A= docsQosUpstreamFragDiscards=0A= docsQosUpstreamConcatBursts=0A= docsQosDynamicServiceStatsTable=0A= docsQosDynamicServiceStatsEntry=0A= docsQosIfDirection=0A= docsQosDSAReqs=0A= docsQosDSARsps=0A= docsQosDSAAcks=0A= docsQosDSCReqs=0A= docsQosDSCRsps=0A= docsQosDSCAcks=0A= docsQosDSDReqs=0A= docsQosDSDRsps=0A= docsQosDynamicAdds=0A= docsQosDynamicAddFails=0A= docsQosDynamicChanges=0A= docsQosDynamicChangeFails=0A= docsQosDynamicDeletes=0A= docsQosDynamicDeleteFails=0A= docsQosDCCReqs=0A= docsQosDCCRsps=0A= docsQosDCCAcks=0A= docsQosDCCs=0A= docsQosDCCFails=0A= docsQosServiceFlowLogTable=0A= docsQosServiceFlowLogEntry=0A= docsQosServiceFlowLogIndex=0A= docsQosServiceFlowLogIfIndex=0A= =0A= =0A= =0A= Expires September 2003 [Page 7]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosServiceFlowLogSFID=0A= docsQosServiceFlowLogCmMac=0A= docsQosServiceFlowLogPkts=0A= docsQosServiceFlowLogOctets=0A= docsQosServiceFlowLogTimeDeleted=0A= docsQosServiceFlowLogTimeCreated=0A= docsQosServiceFlowLogTimeActive=0A= docsQosServiceFlowLogDirection=0A= docsQosServiceFlowLogPrimary=0A= docsQosServiceFlowLogServiceClassName=0A= docsQosServiceFlowLogPolicedDropPkts=0A= docsQosServiceFlowLogPolicedDelayPkts=0A= docsQosServiceFlowLogControl=0A= docsQosServiceClassTable=0A= docsQosServiceClassEntry=0A= docsQosServiceClassName=0A= docsQosServiceClassStatus=0A= docsQosServiceClassMaxTrafficRate=0A= docsQosServiceClassMaxTrafficBurst=0A= docsQosServiceClassMinReservedRate=0A= docsQosServiceClassMinReservedPkt=0A= docsQosServiceClassMaxConcatBurst=0A= docsQosServiceClassNomPollInterval=0A= docsQosServiceClassTolPollJitter=0A= docsQosServiceClassUnsolicitGrantSize=0A= docsQosServiceClassNomGrantInterval=0A= docsQosServiceClassTolGrantJitter=0A= docsQosServiceClassGrantsPerInterval=0A= docsQosServiceClassMaxLatency=0A= docsQosServiceClassActiveTimeout=0A= docsQosServiceClassAdmittedTimeout=0A= docsQosServiceClassSchedulingType=0A= docsQosServiceClassRequestPolicy=0A= docsQosServiceClassTosAndMask=0A= docsQosServiceClassTosOrMask=0A= docsQosServiceClassDirection=0A= docsQosServiceClassStorageType=0A= docsQosServiceClassPolicyTable=0A= docsQosServiceClassPolicyEntry=0A= docsQosServiceClassPolicyIndex=0A= docsQosServiceClassPolicyName=0A= docsQosServiceClassPolicyRulePriority=0A= docsQosServiceClassPolicyStatus=0A= docsQosServiceClassPolicyStorageType=0A= docsQosPHSTable=0A= docsQosPHSEntry=0A= docsQosPHSField=0A= docsQosPHSMask=0A= docsQosPHSSize=0A= docsQosPHSVerify=0A= docsQosPHSIndex=0A= =0A= =0A= =0A= Expires September 2003 [Page 8]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosCmtsMacToSrvFlowTable=0A= docsQosCmtsMacToSrvFlowEntry=0A= docsQosCmtsCmMac=0A= docsQosCmtsServiceFlowId=0A= docsQosCmtsIfIndex=0A= =0A= =0A= =0A= The MIB is organized as 11 tables. Most tables are implemented in=0A= both the CM and CMTS; the docsQosUpstreamStatsTable and=0A= docsQosServiceFlowLogTable are implemented on the CMTS only.=0A= =0A= =0A= 2.2.1 docsQosPktClassTable=0A= =0A= The docsQosPktClassTable reports the Service Flow Classifiers=0A= implemented by the managed device. The table is indexed by the = tuple=0A= { ifIndex, docsQosServiceFlowId, docsQosPktClassId }. The = ifIndex=0A= corresponds to an CATV MAC interface. Each CATV MAC interfaces has = a=0A= set of Service Flows, identified with a docsQosServiceFlowId = value=0A= that is unique for that interface. Each service flow may have a=0A= number of packet classifiers that map packets to the flow. The=0A= ClassifierId for the classifier is unique only within a = particular=0A= service flow.=0A= =0A= The semantics of packet classification are provided in [4]. = Briefly,=0A= the DOCSIS MAC interface calls for matching packets based on = values=0A= within the 802.2 (LLC), 802.3, IP, and/or UDP/TCP headers. = Packets=0A= which map more than one classifier are prioritized according to = their=0A= docsQosPktClassPriority value. The docsQosServiceFlowId (an index=0A= object) indicates to which service flow the packet is classified.=0A= =0A= The docsQosPktClassTable is distinct from the docsDevIpFilterTable = of=0A= [9] in that docsQosPktClassTable is intended only to reflect the=0A= state of the Service Flow Classifiers. Service Flow Classifiers = may=0A= be created only via a CM configuration file or from the Dynamic=0A= Service Addition (DSA) messages. For this reason,=0A= docsQosPktClassTable is read-only.=0A= =0A= The docsDevIpFilterTable is intended for external policy-based=0A= administration of packet classifiers. See the section = "Externally=0A= Administered Classification", below.=0A= =0A= =0A= 2.2.2 docsQosParamSetTable=0A= =0A= The docsQosParamSetTable reports the values of Qos Parameter Set = as=0A= defined in Section C.2.2 of [4].=0A= =0A= In general, a Service Flow is associated with three different Qos=0A= Parameter Sets (QPSs): an "active" QPS, an "admitted" QPS, and a=0A= =0A= =0A= =0A= Expires September 2003 [Page 9]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= "provisioned" or "authorized" QPS. The relationship of these = three=0A= sets is represented below:=0A= =0A= =0A= =0A= =0A= =0A= +---------------------+=0A= | Provisioned |=0A= | |=0A= | +---------------+ |=0A= | | Admitted | |=0A= | | | |=0A= | | +---------+ | |=0A= | | | Active | | |=0A= | | | | | |=0A= | | +---------+ | |=0A= | | | |=0A= | +---------------+ |=0A= | |=0A= +---------------------+=0A= =0A= Figure 1: Qos Parameter Sets=0A= =0A= =0A= =0A= The Provisioned QPS describes the maximum service envelope for = which=0A= the SF is authorized. The Admitted QPS is the set of services for=0A= which a service flow has requested admission to the DOCSIS RF=0A= network, but which is not yet active. The Admitted QPS is used = during=0A= the two-phase process of IP Telephony service flow admission to = admit=0A= the bandwidth for a bidirectional voice call when the far end is=0A= ringing. Since ringing may occur for up to four minutes, this=0A= permits the bandwidth to be reserved but not actually consumed = during=0A= this interval. The Active QPS is the set of services actually = being=0A= used by the Service Flow. The DOCSIS v1.1 specification [4] = defines=0A= what it means for a QPS envelope to be "within" another. In = general,=0A= an inner QPS is considered to be "within" an outer QPS when all = QOS=0A= parameters represent demands of equal or fewer resources of the=0A= network.=0A= =0A= In addition to their use as attributes of a Service Flow, a QPS = is=0A= also an attribute of a Service Class. A DOCSIS CM configuration = file=0A= or DSA message may request the creation of a new SF and give only = the=0A= Service Class Name. The CMTS "expands the macro" of a Service = Class=0A= Name creation by populating the Provisioned, Admitted, and/or = Active=0A= QPSs of the Service Flow with the QPS of the Service Class Name. = All=0A= of the QPSs of a Service Flow must be expansions of the same = Service=0A= Class, and in this case the SF is said to "belong" to the Service=0A= Class. Changing the contents of a Service Class' QPS does not = affect=0A= the QPS of any Service Flow earlier expanded from that Service = Class=0A= =0A= =0A= =0A= Expires September 2003 [Page 10]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= name. Only the CMTS implements docsQosServiceClassTable.=0A= =0A= See [4] section 8 for a full description and the theory of = operation=0A= of Docsis 1.1 QOS operation.=0A= =0A= =0A= =0A= The docsQosParamSetTable sets are indexed by { ifIndex,=0A= docsQosServiceFlowId, docsQosParamSetType}. ifIndex indicates a=0A= particular "DOCSIS MAC Domain". docsQosServiceFlowId uniquely=0A= identifies a service flow on that MAC domain. The=0A= docsQosParamSetType indicates whether the row describes an = active,=0A= admitted, or provisioned Qos Parameter Set.=0A= =0A= The docsQosParamSetTable is read-only, because it indicates the = Qos=0A= Parameter Set contents as defined by DOCSIS signaling. The=0A= docsQosServiceClassTable is read-create to permit managers to = define=0A= a template of Qos Parameters that can be referenced by DOCSIS = modems=0A= when creating their Qos Parameter Sets.=0A= =0A= =0A= 2.2.2.1 Interoperation with DOCSIS 1.0=0A= =0A= The DOCSIS 1.0 DOCS-IF-MIB [10] specifies a docsIfQosProfileTable = to=0A= describe the set of Class Of Service (COS) parameters associated = with=0A= a COS "profile". The docsIfCmServiceTable, which contains one = entry=0A= per SID, references this table with a docsIfCmServiceQosProfile=0A= number.=0A= =0A= The DOCSIS 1.1 and 2.0 CM registration process allows a modem to=0A= register as operating either with DOCSIS 1.0, DOCSIS 1.1, or = DOCSIS=0A= 2.0 functionality. For ease of expression, we call a modem=0A= registering with DOCSIS 1.0 functionality a "DOCSIS 1.0 modem",=0A= regardless of the modem's capabilities.=0A= =0A= A CMTS or CM supporting both DOCSIS 1.0, DOCSIS 1.1, and DOCSIS = 2.0=0A= implements both the tables of [10] and the tables of this MIB. = The=0A= interoperation goal is that before modem registration, the DOCSIS = 1.0=0A= MIB [10] applies. After registration, either the DOCSIS 1.0 or = DOCSIS=0A= 1.1/2.0 MIB applies, depending on the mode with which the modem=0A= registered. The specific interoperation rules are:=0A= =0A= =0A= 1. When a CM initially ranges, the CM implements a row in the=0A= DOCS-IF-MIB docsIfCmServiceTable and the CMTS implements a = row=0A= in the DOCS-IF-MIB docsIfCmtsServiceTable corresponding to = the=0A= default upstream Service ID (SID) used for = pre-registration=0A= upstream traffic. For historical compatibility a row may be=0A= created for the docsIfQosProfileTable with default values,=0A= which may be referenced by the docsIfCmServiceTable = entries.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 11]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 2. Both a CMTS and CM implementing this MIB MUST NOT implement=0A= docsQosParamSetTable or docsQosServiceFlowTable rows until=0A= after the CM registers with DOCSIS 1.1 or 2.0 modem = operation.=0A= =0A= =0A= 3. When a modem registers with the CMTS as a "DOCSIS 1.1" or=0A= "DOCSIS 2.0" modem, any exclusively-referenced row in = DOCS-IF-=0A= MIB docsQosProfileTable representing the modems upstream = Qos=0A= profile for pre-registration traffic MUST be removed.=0A= Multiply-referenced rows may remain. The=0A= docsQosIfCmServiceQosProfile object in the CM's row of=0A= docsIfCmServiceTable MUST be set to zero. The=0A= docsIfCmServiceTable row for the DOCSIS 1.1 or DOCSIS 2.0 = modem=0A= continues to exist, and the various statistic objects in = that=0A= row are incremented. The CMTS should retain the=0A= docsIfCmtsServiceTable entry for the DOCSIS 1.1 or DOCSIS = 2.0=0A= CM.=0A= =0A= =0A= 4. When a DOCSIS 1.1 or DOCSIS 2.0 modem registers, both the = CMTS=0A= and CM represent all service flows described in the modem=0A= configuration file in docsQosParamSetTable and=0A= docsQosServiceFlowTable.=0A= =0A= =0A= 5. At the CMTS, the Docsis 1.0 MIB objects=0A= docsIfCmtsServiceInPackets and docsIfCmtsServiceInOctets for = a=0A= SID assigned to a Docsis 1.1 or Docsis 2.0 modem count only = the=0A= pre-registration packets/bytes of those modems.=0A= =0A= =0A= 6. DOCSIS 1.0 modems do not have entries in the = DOCS-IETF-QOS-MIB.=0A= =0A= =0A= =0A= 2.2.3 docsQosServiceFlowTable=0A= =0A= The docsQosServiceFlowTable provides read-only information about = all=0A= of the service flows known by the device. It is indexed by the=0A= combination of { ifIndex, dosQosServiceFlowId }, where ifIndex=0A= corresponds to a CATV MAC interface and docsQosServiceFlowId is = the=0A= 32- bit integer assigned by the CMTS controlling the MAC domain. = A=0A= CM typically has only a single CATV MAC interface, while a CMTS = may=0A= have several. See [10] for a description of the ifIndex = numbering=0A= for DOCSIS devices.=0A= =0A= The table indicates whether a given SF is in the upstream or=0A= downstream direction, and whether it is the "primary" SF in that=0A= direction. The primary SF carries traffic that is not otherwise=0A= classified to any other SF in that direction.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 12]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 2.2.4 docsQosServiceFlowStatsTable=0A= =0A= The docsQosServiceFlowStatsTable provides statistics for all=0A= currently existing SFs known by the managed device. It provides=0A= basic packet and octet counters, as well as certain other = SF-specific=0A= stats such as the time at which the flow was created and how many=0A= seconds it has been active.=0A= =0A= The table also provides objects which can be used to fine-tune=0A= admission control decisions, namely the number of packets dropped = or=0A= delayed due to QOS policing decisions enforced by the managed = device.=0A= =0A= The model of the service flows stats table is that there exists a=0A= service flow Classification function followed by a service flow=0A= maximum rate Policing function for packets transmitted onto the=0A= Docsis RF network, as depicted below=0A= =0A= =0A= +----------+=0A= +------------+ clsfy 1 -----+ | Per-SF | = forwarded=0A= Pkts | |-----------> | | Maximum |---> for = Docsis=0A= ----->| Classify | clsfy 2 SF1 |--> | Rate | RF = Network=0A= | Function |-----------> | | Policing | = transmission=0A= | | -----+ | Function |=0A= | | | |----+=0A= | | | | |=0A= | | +----------+ = Dropped=0A= +------------+ | ^=0A= +----+ Delayed=0A= =0A= Packets intended for transmission onto the Docsis RF network=0A= (upstream or downstream) are first classified to a service flow = by=0A= matching one of several possible classifiers associated with that=0A= service flow. The docsQosPktClassPkts count includes the number = of=0A= packets that match the classifier, regardless of the eventual=0A= disposition of the packet.=0A= =0A= DOCSIS requires that each service flow be policed to maintain a=0A= maximum rate of transmission. This is performed by either dropping = or=0A= delaying a packet on that service flow. The=0A= docsQosServiceFlowPolicedDropPkts object counts the number of = service=0A= flow packets dropped by the policing function. The=0A= docsQosServiceFlowPolicedDelayPkts counts the number of packet=0A= delayed but still forwarded. The docsQosServiceFlowPkts object=0A= counts the total number of packets forwarded beyond the policing=0A= function intended for eventual transmission onto the DOCSIS RF=0A= network. Although packets may be latter dropped by other = functions=0A= (e.g. a transmit queue overflow on a DOCSIS hardware = transmitter),=0A= the docsQos MIB per service-flow counters are not affected in = this=0A= case.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 13]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 2.2.5 docsQosUpstreamStatsTable=0A= =0A= This table provides statistics that are measured only at the CMTS = in=0A= the upstream direction. These include a count of the number of=0A= fragmentation headers received, fragments discarded, and the = number=0A= of concatenation headers received.=0A= =0A= =0A= 2.2.6 docsQosDynamicServiceStatsTable=0A= =0A= This table provides read-only stats on the operation of the = Dynamic=0A= Service state machines as specified in section 9.4 of [4]. It=0A= provides a set of 14 counters *in each direction* for a Docsis = MAC=0A= layer interface. That is, each Docsis MAC layer interface has one = row=0A= for downstream stats, and a second row for upstream stats.=0A= =0A= Eight of the counters are DSx packet type counts, one counter for=0A= each of the eight DSx packet types. For example, the = docsQosDSAReqs=0A= object in the upstream row at the CMTS counts the number of = DSA-REQ=0A= messages received by the CMTS from that interface. The=0A= docsQosDSAReqs object in the downstream row at the CMTS counts = the=0A= number of DSA-REQ messages transmitted by the CMTS on that = interface.=0A= =0A= The remaining six counters per (interface, direction) combination=0A= count the number of successful and unsuccessful *transactions* = that=0A= were initiated on the interface and direction. For example, the=0A= upstream docsQosDynamicAdds on a CMTS is the number of = successfully=0A= completed CM-initiated dynamic additions, because at the CMTS a = CM-=0A= initiated DSA starts in the upstream direction. The downstream=0A= docsQosDynamicAdds at a CMTS is the number of successful CMTS-=0A= initiated DSA transactions.=0A= =0A= Dynamic service transactions can fail for a number of reasons, as=0A= listed in the state machines of section 9.4. Rather than include=0A= still more counters for each different failure reason, they are=0A= grouped into a single count, e.g docsQosDynamicAddFails. Again, = this=0A= object exists in both directions, so that locally originated vs=0A= remotely originated transaction failures are counted separately.=0A= Further troubleshooting of transaction failures will require = vendor-=0A= specific queries and operation.=0A= =0A= =0A= 2.2.7 docsQosServiceFlowLogTable=0A= =0A= This table contains a log of the Service Flows no longer existing = in=0A= the docsQosServiceFlowTable. It is intended to be periodically = polled=0A= by traffic monitoring and billing agents. It is implemented only = at=0A= the CMTS.=0A= =0A= It contains a chronological log of SF session statistics, including = a=0A= total count of packets and octets transferred on the SF. It = includes=0A= =0A= =0A= =0A= Expires September 2003 [Page 14]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= time stamps of the SF creation and deletion time, as well as its=0A= number of active seconds. The active second count is the count of=0A= seconds that the SF had a non-empty Active Qos Parameter Set, i.e. = it=0A= was eligible to pass data. For unicast SFs, it includes the CM = MAC=0A= address associated with the flow for billing reference purposes.=0A= =0A= The maximum number of log records kept by a CMTS, and the = duration=0A= that a log record is maintained in the table is vendor-specific. = An=0A= explicit control object is provided so that the monitoring=0A= application can explicitly delete records it has read.=0A= =0A= =0A= 2.2.8 docsQosServiceClassTable=0A= =0A= This table defines the Service Class Name and references a Qos=0A= Parameter Set for each Service Class defined in a CMTS. It is=0A= indexed by the Service Class Name string itself. The table is = read-=0A= create on a CMTS, and is not implemented in a CM. Each entry of = the=0A= docsQosServiceClassTable should define a template for flows in a=0A= given direction (upstream or downstream). Some parameters of the=0A= docsQosServiceClassTable are specific to a particular direction, = and=0A= so their values are not-applicable when used as a template for = flows=0A= in the other direction.=0A= =0A= =0A= =0A= 2.2.9 docsQosServiceClassPolicyTable=0A= =0A= =0A= The docsQosServiceClassPolicyTable can be referenced by the=0A= docsDevFilterPolicyTable of [9] in order to have a "policy" that=0A= classifies packets to a named Service Class. This is one mechanism = by=0A= which "external" entities (like an SNMP manager) may control the=0A= classification of packet for QOS purposes. Entries are indexed by = a=0A= small integer docsQosServiceClassPolicyIndex. They provide a = Service=0A= Class Name and a Rule Priority. A policy referencing a row of = this=0A= table intends the packet to be forwarded on a Service Flow=0A= "belonging" to the named Service Class. See the section = "Externally=0A= Administered Classification", below.=0A= =0A= This table is implemented on both the CM and CMTS, and is = read-create=0A= on both.=0A= =0A= =0A= 2.2.10 docsQosPHSTable=0A= =0A= The Payload Header Suppression (PHS) feature of DOCSIS 1.1 and = 2.0=0A= permits packets to replace the unchanging bytes of the Ethernet, = IP,=0A= and UDP headers with a one-byte index when transmitting on the = cable=0A= network. This is especially useful for IP Telephony packets, = where=0A= such suppression can result in almost twice the number of calls=0A= =0A= =0A= =0A= Expires September 2003 [Page 15]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= supported within the same upstream channel.=0A= =0A= Each entry of the table corresponds to a PHS Rule as described in=0A= section 8.4 of [4]. The rules are identified by their = corresponding=0A= service flow ID and docsQosPktClassId. A PHS rule is associated = with=0A= exactly one classifier. The table is therefore indexed by the = tuple=0A= { ifIndex, docsQosServiceFlowId, docsQosPktClassId}.=0A= =0A= This table is read-only, and MUST be implemented on both the CM = and=0A= CMTS when PHS is supported.=0A= =0A= =0A= 2.2.11 docsQosCmtsMacToSrvFlowTable=0A= =0A= The docsQosCmtsMacToSrvFlowTable provides describes the mapping of = CM=0A= mac addresses to the Service Flow Ids that are uniquely = identified=0A= with that CM. External applications may collect statistics on = all=0A= packets flowing through a CM by determining the SFID of all of = its=0A= flows, and then collecting the statistics of packets and bytes = for=0A= each flow.=0A= =0A= Downstream multicast service flows are not indicated in the=0A= docsQosCmtsMacToSrvFlowTable because they are not associated with=0A= only one CM.=0A= =0A= =0A= =0A= =0A= 3. Externally Administered Classification=0A= =0A= Docsis 1.1 and 2.0 provides rich semantics for the classification = of=0A= packets to service flows with it Service Flow Classifier table.=0A= Service Flow Classifiers may be created statically in the DOCSIS = CM=0A= configuration file, or may be created dynamically with Dynamic=0A= Service Addition (DSA) and Dynamic Service Change (DSC) DOCSIS = MAC=0A= messages.=0A= =0A= Several major issues arose with the concept of externally=0A= administered classification, i.e. should an external SNMP manager = be=0A= permitted to create classification rows? One problem was the co-=0A= ordination of classifier IDs, since such an approach would = require=0A= either separate classifier ID number spaces or objects to = co-ordinate=0A= both internal and external classifier ID assignments. A more = serious=0A= problem, however, was the requirement that external creation of = SF=0A= Classifiers would require "knowledge" of the individual Service = Flow=0A= ID for service flows by external applications. It was strongly = felt=0A= by the committee that SFIDs should remain an internal Docsis = object,=0A= and not be transmitted as part of protocol flows, e.g. for IP = packet=0A= telephony signaling. Docsis 1.1 introduced the concept of named=0A= Service Classes for ease of administration within a domain of CMs = and=0A= CMTSs. What was desired was to permit external classification of=0A= =0A= =0A= =0A= Expires September 2003 [Page 16]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= packets to a Service Class, not a particular Service Flow.=0A= =0A= The DOCSIS committee therefore decided to use the already-defined = IP=0A= Packet Filter Table [9] for the external classification of = packets=0A= for QOS purposes. The docsDevIpPacketFilterTable defines similar=0A= packet matching criteria as docsQosPktClassTable, but it matches = a=0A= packet to an arbitrary "policy set" instead of a particular = Service=0A= Flow. One of the policies in the policy set then selects the = Service=0A= Class of the SF on which to forward the packet. The=0A= docsQosServiceClassPolicyTable of this MIB defines the Service = Class=0A= Name to which a packet is classified.=0A= =0A= The interaction of external and internal packet classification is=0A= depicted below.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 17]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= =0A= =0A= |=0A= | Outbound Pkt=0A= V=0A= docsDevIpFilterTable------> docsDevFilterPolicyTable=0A= | |=0A= | V=0A= | docsQosServiceClassPolicyTable=0A= | |=0A= | Pkt | ServiceClassName,=0A= | | = ServiceClassPolicyRulePriority=0A= V V=0A= +--------------------------------------------------------+=0A= | | DOCSIS MAC LAYER ENTITY | |=0A= | | | Select any |=0A= | V | SFID Y in SCN|=0A= | docsQosPktClassTable <---------------| |=0A= | | | |=0A= | | docsQosPktClassPriority, | |=0A= | | SFID X | |=0A= | V V |=0A= | ----------------------------------------+ |=0A= | | Select the SFID associated with the | |=0A= | | higher of docsQosPktClassPriority or | |=0A= | | docsQosServiceClassPolicyRulePriority | |=0A= | +---------------------------------------+ |=0A= | | |=0A= | V |=0A= | | | | | |=0A= | | | ... | | Service Flows |=0A= | +----+ +----+ |=0A= | SFID X SFID Y |=0A= +--------------------------------------------------------+=0A= =0A= Figure 2: Docsis Packet Classification=0A= =0A= =0A= The processing of an outgoing packet proceeds as follows:=0A= =0A= 1. The packet is first checked for matches with rows of = the=0A= docsDevIpFilterTable. If it matches, the matching row=0A= provides a docsDevFilterPolicyId integer.=0A= =0A= 2. The docsDevFilterPolicyId indexes into one (or more) = rows=0A= of docsDevFilterPolicyTable. Each row provides an=0A= arbitrary RowPointer (docsDevFilterPolicyPtr),=0A= corresponding to a policy to be applied to the packet.=0A= =0A= 3. This MIB defines a docsQosServiceClassPolicyTable = whose=0A= entries may be pointed to by docsDevFilterPolicyPtr in=0A= =0A= =0A= =0A= Expires September 2003 [Page 18]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= order to administratively classify packets to a named=0A= DOCSIS Service Class. The = docsQosServiceClassPolicyEntry=0A= provides a Service Class Name (SCN) as=0A= docsQosServiceClassPolicyName and a classification = rule=0A= priority as docsQosServiceClassPolicyRulePriority. = These=0A= are submitted to the device's Docsis MAC Layer entity as = a=0A= special form of the MAC_DATA.request primitive, as=0A= described in Section E.2.1 of [4].=0A= =0A= 4. The MAC Layer selects an SFID ("Y") of an active = Service=0A= Flow belonging to the named class, choosing an SF=0A= arbitrarily if there is more than one.=0A= =0A= 5. The packet is then classified according to the=0A= docsQosPktClassTable, which may classify the packet to = a=0A= different SFID "X". Associated with the classifier is = a=0A= docsQosPktClassPriority.=0A= =0A= 6. In the event of a conflict between the SCN-determined = SFID=0A= and the classified SFID, the greater of=0A= docsQosPktClassPriority and=0A= docsQosServiceClassPolicyRulePriority determines which=0A= SFID is selected to forward the packet.=0A= =0A= A packet which does not match a = docsQosServiceClassPolicyEntry=0A= is directly submitted to the Docsis MAC layer, where the=0A= docsQosPktClassTable selects the SID on which it is to be=0A= forwarded.=0A= =0A= By convention (in [4]), the "internal" = docsQosPktClassPriority=0A= values should be in the range of 64-191, while the = "external"=0A= priorities may be either in the range 192-255 to override = the=0A= internal classification or the range 0-63 to be overridden = by=0A= internal classification.=0A= =0A= This classification mechanism applies both upstream from the = CM=0A= and downstream from the CMTS.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 19]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 4. Definitions=0A= =0A= --=0A= -- Docsis QOS Extensions MIB=0A= --=0A= =0A= DOCS-IETF-QOS-MIB DEFINITIONS ::=3D BEGIN=0A= =0A= IMPORTS=0A= MODULE-IDENTITY,=0A= OBJECT-TYPE,=0A= Integer32,=0A= Counter32,=0A= Unsigned32,=0A= Counter64=0A= FROM SNMPv2-SMI=0A= =0A= TEXTUAL-CONVENTION,=0A= MacAddress,=0A= RowStatus,=0A= TruthValue,=0A= DisplayString,=0A= TimeStamp,=0A= StorageType=0A= FROM SNMPv2-TC=0A= =0A= OBJECT-GROUP,=0A= MODULE-COMPLIANCE=0A= FROM SNMPv2-CONF=0A= =0A= ifIndex,=0A= InterfaceIndex=0A= FROM IF-MIB=0A= =0A= docsIfMib=0A= FROM DOCS-IF-MIB=0A= =0A= InetAddressType,=0A= InetAddress,=0A= InetPortNumber=0A= FROM INET-ADDRESS-MIB;=0A= =0A= docsQosMIB MODULE-IDENTITY=0A= LAST-UPDATED "200303010000Z" -- March 1, 2003=0A= ORGANIZATION "IETF IPCDN Working Group"=0A= CONTACT-INFO=0A= "=0A= Co-Author: Michael Patrick=0A= Postal: Motorola BCS=0A= 20 Cabot Blvd, MS M2-330=0A= Mansfield, MA 02048-1193=0A= =0A= =0A= =0A= Expires September 2003 [Page 20]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= U.S.A.=0A= Phone: +1 508 851 8402=0A= E-mail: michael.patrick@motorola.com=0A= =0A= Co-Author: William Murwin=0A= Postal: Motorola BCS=0A= 20 Cabot Blvd, MS M2-330=0A= Mansfield, MA 02048-1193=0A= U.S.A.=0A= Phone: +1 508 851 8385=0A= E-mail: w.murwin@motorola.com"=0A= =0A= DESCRIPTION=0A= "This is the management information for=0A= Quality Of Service (QOS) for DOCSIS 1.1 and 2.0."=0A= =0A= REVISION "200303010000Z" -- March 1, 2003=0A= DESCRIPTION=0A= "Initial version, published as RFC xxxx."=0A= ::=3D { docsIfMib xx } -- xx to be assignrd by IANA=0A= =0A= docsQosMIBObjects OBJECT IDENTIFIER ::=3D { docsQosMIB 1 }=0A= =0A= -- Textual Conventions=0A= DocsQosRfMacIfDirection ::=3D TEXTUAL-CONVENTION=0A= STATUS current=0A= DESCRIPTION "Indicates a direction on an RF MAC interface.=0A= =0A= The value downstream(1) is from Cable Modem=0A= Termination System to Cable Modem.=0A= =0A= The value upstream(2) is from Cable Modem to=0A= Cable Modem Termination System."=0A= SYNTAX INTEGER {=0A= downstream(1),=0A= upstream(2)=0A= }=0A= =0A= DocsQosBitRate ::=3D TEXTUAL-CONVENTION=0A= DISPLAY-HINT "d"=0A= STATUS current=0A= DESCRIPTION "The rate of traffic in unit of bits per second.=0A= Used to specify traffic rate for QOS."=0A= SYNTAX Unsigned32=0A= =0A= DocsQosSchedulingType ::=3D TEXTUAL-CONVENTION=0A= STATUS current=0A= DESCRIPTION "The scheduling service provided by a CMTS for = an=0A= upstream service flow. If the parameter is = omitted=0A= from an upstream QOS Parameter Set, this object = takes=0A= the value of bestEffort (2). This parameter must = be=0A= =0A= =0A= =0A= Expires September 2003 [Page 21]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= reported as undefined (1) for downstream QOS = Parameter=0A= Sets."=0A= SYNTAX INTEGER {=0A= undefined (1),=0A= bestEffort (2),=0A= nonRealTimePollingService(3),=0A= realTimePollingService(4),=0A= unsolictedGrantServiceWithAD(5),=0A= unsolictedGrantService(6)=0A= }=0A= =0A= -----------------------------------------------------------------------=0A= --=0A= -- Packet Classifier Table=0A= --=0A= docsQosPktClassTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosPktClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the packet classification=0A= configured on the CM or CMTS.=0A= The model is that a packet either received=0A= as input from an interface or transmitted=0A= for output on an interface may be compared=0A= against an ordered list of rules pertaining to=0A= the packet contents. Each rule is a row of this=0A= table. A matching rule provides a service flow=0A= id to to which the packet is classified.=0A= All rules need to match for a packet to match=0A= a classifier.=0A= =0A= The objects in this row correspond to a set of=0A= Classifier Encoding parameters in a DOCSIS=0A= MAC management message. The = docsQosPktClassBitMap=0A= indicates which particular parameters were = present=0A= in the classifier as signaled in the DOCSIS = message.=0A= If the referenced parameter was not present=0A= in the signaled DOCSIS 1.1 and 2.0 Classifier, = the=0A= corresponding object in this row reports a=0A= value as specified in the DESCRIPTION section.=0A= "=0A= ::=3D { docsQosMIBObjects 1 }=0A= =0A= =0A= docsQosPktClassEntry OBJECT-TYPE=0A= SYNTAX DocsQosPktClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An entry in this table provides a single packet=0A= classifier rule. The index ifIndex is an ifType=0A= of docsCableMaclayer(127)."=0A= =0A= =0A= =0A= Expires September 2003 [Page 22]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId,=0A= docsQosPktClassId=0A= }=0A= ::=3D { docsQosPktClassTable 1 }=0A= =0A= =0A= =0A= DocsQosPktClassEntry ::=3D SEQUENCE {=0A= docsQosPktClassId Unsigned32,=0A= docsQosPktClassDirection DocsQosRfMacIfDirection,=0A= docsQosPktClassPriority Integer32,=0A= docsQosPktClassIpTosLow OCTET STRING,=0A= docsQosPktClassIpTosHigh OCTET STRING,=0A= docsQosPktClassIpTosMask OCTET STRING,=0A= docsQosPktClassIpProtocol Integer32,=0A= docsQosPktClassInetAddressType InetAddressType,=0A= docsQosPktClassInetSourceAddr InetAddress,=0A= docsQosPktClassInetSourceMask InetAddress,=0A= docsQosPktClassInetDestAddr InetAddress,=0A= docsQosPktClassInetDestMask InetAddress,=0A= docsQosPktClassSourcePortStart InetPortNumber,=0A= docsQosPktClassSourcePortEnd InetPortNumber,=0A= docsQosPktClassDestPortStart InetPortNumber,=0A= docsQosPktClassDestPortEnd InetPortNumber,=0A= docsQosPktClassDestMacAddr MacAddress,=0A= docsQosPktClassDestMacMask MacAddress,=0A= docsQosPktClassSourceMacAddr MacAddress,=0A= docsQosPktClassEnetProtocolType INTEGER,=0A= docsQosPktClassEnetProtocol Integer32,=0A= docsQosPktClassUserPriLow Integer32,=0A= docsQosPktClassUserPriHigh Integer32,=0A= docsQosPktClassVlanId Integer32,=0A= docsQosPktClassStateActive TruthValue,=0A= docsQosPktClassPkts Counter64,=0A= docsQosPktClassBitMap BITS=0A= }=0A= =0A= docsQosPktClassId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..65535)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Index assigned to packet classifier entry by=0A= the CMTS which is unique per service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.2"=0A= ::=3D { docsQosPktClassEntry 1 }=0A= =0A= docsQosPktClassDirection OBJECT-TYPE=0A= SYNTAX DocsQosRfMacIfDirection=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires September 2003 [Page 23]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "Indicates the direction to which the classifier=0A= is applied."=0A= ::=3D { docsQosPktClassEntry 2 }=0A= =0A= docsQosPktClassPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value specifies the order of evaluation=0A= of the classifiers.=0A= The higher the value the higher the priority.=0A= The value of 0 is used as default in=0A= provisioned service flows classifiers.=0A= The default value of 64 is used for dynamic=0A= service flow classifiers.=0A= If the referenced parameter is not present=0A= in a classifier, this object reports the default = value=0A= as defined above."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5"=0A= ::=3D { docsQosPktClassEntry 3 }=0A= =0A= docsQosPktClassIpTosLow OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The low value of a range of TOS byte values.=0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0.=0A= =0A= RFC 3260 refers to a TOS byte as the textual=0A= convention of 'Dscp' of 6-bits however the=0A= DOCSIS Specification calls for this object to=0A= be 1 byte."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 4 }=0A= =0A= docsQosPktClassIpTosHigh OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The 8-bit high value of a range of TOS byte=0A= values.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0.=0A= =0A= RFC 3260 refers to a TOS byte as the textual=0A= convention of 'Dscp' of 6-bits however the=0A= DOCSIS Specification calls for this object to=0A= be 1 byte."=0A= =0A= =0A= =0A= Expires September 2003 [Page 24]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= REFERENCE "SP-RFIv1.1-I07-010829, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 5 }=0A= =0A= docsQosPktClassIpTosMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The mask value is bitwise ANDed with TOS byte=0A= in an IP packet and this value is used check=0A= range checking of TosLow and TosHigh.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0.=0A= =0A= RFC 3260 refers to a TOS byte as the textual=0A= convention of 'Dscp' of 6-bits however the=0A= DOCSIS Specification calls for this object to=0A= be 1 byte."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.1"=0A= ::=3D { docsQosPktClassEntry 6 }=0A= =0A= docsQosPktClassIpProtocol OBJECT-TYPE=0A= SYNTAX Integer32 (0..258)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the value of the IP=0A= Protocol field required for IP packets to match=0A= this rule.=0A= =0A= The value 256 matches traffic with any IP = Protocol=0A= value. The value 257 by convention matches both = TCP=0A= and UDP.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 258."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.2"=0A= ::=3D { docsQosPktClassEntry 7 }=0A= =0A= docsQosPktClassInetAddressType OBJECT-TYPE=0A= SYNTAX InetAddressType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The type of the internet address for=0A= docsQosPktClassInetSourceAddr,=0A= docsQosPktClassInetSourceMask,=0A= docsQosPktClassInetDestAddr, and=0A= docsQosPktClassInetDestMask.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= ipv4(1)."=0A= =0A= =0A= =0A= Expires September 2003 [Page 25]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= ::=3D { docsQosPktClassEntry 8 }=0A= =0A= docsQosPktClassInetSourceAddr OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the value of the IP=0A= Source Address required for packets to match=0A= this rule. An IP packet matches the rule when=0A= the packet ip source address bitwise ANDed=0A= with the docsQosPktClassInetSourceMask value=0A= equals the docsQosPktClassInetSourceAddr value.=0A= =0A= The address type of this object is specified by=0A= docsQosPktClassInetAddressType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '00000000'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.3"=0A= ::=3D { docsQosPktClassEntry 9 }=0A= =0A= docsQosPktClassInetSourceMask OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies which bits of a packet's=0A= IP Source Address that are compared to match=0A= this rule.=0A= An IP packet matches the rule when the packet=0A= source address bitwise ANDed with the=0A= docsQosPktClassInetSourceMask value equals the=0A= docsQosIpPktClassInetSourceAddr value.=0A= =0A= The address type of this object is specified by=0A= docsQosPktClassInetAddressType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFF'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.4"=0A= ::=3D { docsQosPktClassEntry 10 }=0A= =0A= docsQosPktClassInetDestAddr OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the value of the IP=0A= Destination Address required for packets to = match=0A= this rule. An IP packet matches the rule when=0A= =0A= =0A= =0A= Expires September 2003 [Page 26]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= the packet ip destination address=0A= bitwise ANDed with the=0A= docsQosPktClassInetDestMask value=0A= equals the docsQosPktClassInetDestAddr value.=0A= =0A= The address type of this object is specified by=0A= docsQosPktClassInetAddressType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '00000000'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.5"=0A= ::=3D { docsQosPktClassEntry 11 }=0A= =0A= docsQosPktClassInetDestMask OBJECT-TYPE=0A= SYNTAX InetAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies which bits of a packet's=0A= IP Destination Address that are compared to=0A= match this rule.=0A= An IP packet matches the rule when the packet=0A= destination address bitwise ANDed with the=0A= docsQosPktClassInetDestMask value equals the=0A= docsQosIpPktClassInetDestAddr value.=0A= =0A= The address type of this object is specified by=0A= docsQosPktClassInetAddressType.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFF'H."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.6"=0A= ::=3D { docsQosPktClassEntry 12 }=0A= =0A= docsQosPktClassSourcePortStart OBJECT-TYPE=0A= SYNTAX InetPortNumber=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the low end inclusive=0A= range of TCP/UDP source port numbers to which=0A= a packet is compared. This object is irrelevant=0A= for non-TCP/UDP IP packets.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.7"=0A= ::=3D { docsQosPktClassEntry 13 }=0A= =0A= docsQosPktClassSourcePortEnd OBJECT-TYPE=0A= SYNTAX InetPortNumber=0A= =0A= =0A= =0A= Expires September 2003 [Page 27]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the high end inclusive=0A= range of TCP/UDP source port numbers to which=0A= a packet is compared. This object is irrelevant=0A= for non-TCP/UDP IP packets.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 65535."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.8"=0A= ::=3D { docsQosPktClassEntry 14 }=0A= =0A= docsQosPktClassDestPortStart OBJECT-TYPE=0A= SYNTAX InetPortNumber=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the low end inclusive=0A= range of TCP/UDP destination port numbers to=0A= which a packet is compared.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.9"=0A= ::=3D { docsQosPktClassEntry 15 }=0A= =0A= docsQosPktClassDestPortEnd OBJECT-TYPE=0A= SYNTAX InetPortNumber=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object specifies the high end inclusive=0A= range of TCP/UDP destination port numbers to = which=0A= a packet is compared.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 65535."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.5.10"=0A= ::=3D { docsQosPktClassEntry 16 }=0A= =0A= docsQosPktClassDestMacAddr OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches an entry when its=0A= destination MAC address bitwise ANDed with=0A= docsQosPktClassDestMacMask equals the value of=0A= docsQosPktClassDestMacAddr.=0A= =0A= =0A= If the referenced parameter is not present=0A= =0A= =0A= =0A= Expires September 2003 [Page 28]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= in a classifier, this object reports the value = of=0A= '000000000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1"=0A= ::=3D { docsQosPktClassEntry 17 }=0A= =0A= docsQosPktClassDestMacMask OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches an entry when its=0A= destination MAC address bitwise ANDed with=0A= docsQosPktClassDestMacMask equals the value of=0A= docsQosPktClassDestMacAddr.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= '000000000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.1"=0A= ::=3D { docsQosPktClassEntry 18 }=0A= =0A= docsQosPktClassSourceMacAddr OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "An Ethernet packet matches this entry when its=0A= source MAC address equals the value of=0A= this object.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value = of=0A= 'FFFFFFFFFFFF'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.2"=0A= ::=3D { docsQosPktClassEntry 19 }=0A= =0A= docsQosPktClassEnetProtocolType OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= none(0),=0A= ethertype(1),=0A= dsap(2),=0A= mac(3),=0A= all(4)=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the format of the layer 3=0A= protocol id in the Ethernet packet. A value of=0A= none(0) means that the rule does not use the=0A= layer 3 protocol type as a matching criteria.=0A= =0A= =0A= =0A= Expires September 2003 [Page 29]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= A value of ethertype(1) means that the rule=0A= applies only to frames which contains an=0A= EtherType value. Ethertype values are contained=0A= in packets using the Dec-Intel-Xerox (DIX)=0A= encapsulation or the RFC1042 Sub-Network Access=0A= Protocol (SNAP) encapsulation formats.=0A= =0A= A value of dsap(2) means that the rule applies=0A= only to frames using the IEEE802.3=0A= encapsulation format with a Destination Service=0A= Access Point (DSAP) other=0A= than 0xAA (which is reserved for SNAP).=0A= =0A= A value of mac(3) means that the rule applies=0A= only to MAC management messages for MAC = management=0A= messages.=0A= =0A= A value of all(4) means that the rule matches=0A= all Ethernet packets.=0A= =0A= If the Ethernet frame contains an 802.1P/Q Tag=0A= header (i.e. EtherType 0x8100), this object=0A= applies to the embedded EtherType field within=0A= the 802.1P/Q header.=0A= =0A= If the referenced parameter is not present=0A= in a classifier, this object reports the value of = 0.=0A= =0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3"=0A= ::=3D { docsQosPktClassEntry 20 }=0A= =0A= docsQosPktClassEnetProtocol OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "If docsQosEthPktClassProtocolType is none(0),=0A= this object is ignored when considering whether=0A= a packet matches the current rule.=0A= =0A= If dosQosPktClassEnetProtocolType is = ethertype(1),=0A= this object gives the 16-bit value of the=0A= EtherType that the packet must match in order to=0A= match the rule.=0A= =0A= If docsQosPktClassEnetProtocolType is dsap(2), = the=0A= lower 8 bits of this object's value must match = the=0A= DSAP byte of the packet in order to match the=0A= rule.=0A= =0A= If docsQosPktClassEnetProtocolType is mac(3), = the=0A= =0A= =0A= =0A= Expires September 2003 [Page 30]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= lower 8 bits of this object value represent a=0A= lower bound (inclusive) of MAC management = message=0A= type codes matched, and the upper 8 bits of this=0A= object value represent the upper bound = (inclusive)=0A= of matched MAC message type codes. Certain=0A= message type codes are excluded from matching, = as=0A= specified in the reference.=0A= =0A= If the Ethernet frame contains an 802.1P/Q Tag = header=0A= (i.e. EtherType 0x8100), this object applies to = the=0A= embedded EtherType field within the 802.1P/Q = header.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported as = 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.6.3"=0A= ::=3D { docsQosPktClassEntry 21 }=0A= =0A= docsQosPktClassUserPriLow OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Q tag header (indicated with=0A= EtherType 0x8100). Such frames include a 16-bit=0A= Tag that contains a 3 bit Priority field and=0A= a 12 bit VLAN number.=0A= =0A= Tagged Ethernet packets must have a 3-bit=0A= Priority field within the range of=0A= docsQosPktClassPriLow and docsQosPktClassPriHigh = in=0A= order to match this rule.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported as = 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1"=0A= ::=3D { docsQosPktClassEntry 22 }=0A= =0A= docsQosPktClassUserPriHigh OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Qtag header (indicated with=0A= EtherType 0x8100). Such frames include a 16-bit=0A= Tag that contains a 3 bit Priority field and=0A= a 12 bit VLAN number.=0A= =0A= Tagged Ethernet packets must have a 3-bit=0A= Priority field within the range of=0A= =0A= =0A= =0A= Expires September 2003 [Page 31]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosPktClassPriLow and=0A= docsQosPktClassPriHigh in order to match this=0A= rule.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as 7.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.1"=0A= ::=3D { docsQosPktClassEntry 23 }=0A= =0A= docsQosPktClassVlanId OBJECT-TYPE=0A= SYNTAX Integer32 (0..4095)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object applies only to Ethernet frames=0A= using the 802.1P/Q tag header.=0A= =0A= If this object's value is nonzero, tagged=0A= packets must have a VLAN Identifier that matches=0A= the value in order to match the rule.=0A= =0A= Only the least significant 12 bits of this = object's=0A= value are valid.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.7.2"=0A= ::=3D { docsQosPktClassEntry 24 }=0A= =0A= docsQosPktClassStateActive OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates whether or not the = classifier=0A= is enabled to classify packets to a Service = Flow.=0A= =0A= If the referenced parameter is not present in = the=0A= classifier, the value of this object is reported=0A= as true(1)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.6"=0A= ::=3D { docsQosPktClassEntry 25 }=0A= =0A= docsQosPktClassPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object counts the number of packets that = have=0A= been classified using this entry. This=0A= =0A= =0A= =0A= Expires September 2003 [Page 32]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= includes all packets delivered to a service flow=0A= maximum rate policing function, whether or not = that=0A= function drops the packets.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosPktClassEntry 26 }=0A= =0A= =0A= docsQosPktClassBitMap OBJECT-TYPE=0A= SYNTAX BITS { -- Reference = SP-RFIv1.1-I09-020830=0A= rulePriority(0), -- Appendix C.2.1.3.4=0A= activationState(1), -- Appendix C.2.1.3.6=0A= ipTos(2), -- Appendix C.2.1.5.1=0A= ipProtocol(3), -- Appendix C.2.1.5.2=0A= ipSourceAddr(4), -- Appendix C.2.1.5.3=0A= ipSourceMask(5), -- Appendix C.2.1.5.4=0A= ipDestAddr(6), -- Appendix C.2.1.5.5=0A= ipDestMask(7), -- Appendix C.2.1.5.6=0A= sourcePortStart(8), -- Appendix C.2.1.5.7=0A= sourcePortEnd(9), -- Appendix C.2.1.5.8=0A= destPortStart(10), -- Appendix C.2.1.5.9=0A= destPortEnd(11), -- Appendix C.2.1.5.10=0A= destMac(12), -- Appendix C.2.1.6.1=0A= sourceMac(13), -- Appendix C.2.1.6.2=0A= ethertype(14), -- Appendix C.2.1.6.3=0A= userPri(15), -- Appendix C.2.1.7.1=0A= vlanId(16) -- Appendix C.2.1.7.2=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION=0A= "This object indicates which parameter encodings = were=0A= actually present in the DOCSIS packet classifier=0A= encoding signaled in the DOCSIS message that=0A= created or modified the classifier. Note that=0A= Dynamic Service Change messages have replace=0A= semantics, so that all non-default parameters = must=0A= be present whether the classifier is being = created=0A= or changed.=0A= =0A= A bit of of this object is set to 1 if the = parameter=0A= indicated by the comment was present in the = classifier=0A= encoding, and 0 otherwise.=0A= =0A= Note that BITS are encoded most significant bit=0A= first, so that if e.g. bits 6 and 7 are set, this = object=0A= is encoded as the octet string '030000'H.=0A= "=0A= ::=3D { docsQosPktClassEntry 27 }=0A= =0A= =0A= =0A= Expires September 2003 [Page 33]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= =0A= --=0A= -- QOS Parameter Set Table=0A= --=0A= docsQosParamSetTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosParamSetEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of DOCSIS 1.1 and = 2.0=0A= QOS parameters defined in a managed device.=0A= =0A= The ifIndex index specifies a DOCSIS MAC Domain.=0A= The docsQosServiceFlowId index specifies a = particular=0A= Service Flow.=0A= The docsQosParamSetType index indicates whether=0A= the active, admitted, or provisioned QOS = Parameter=0A= Set is being described by the row.=0A= =0A= Only the QOS Parameter Sets of Docsis 1.1 and = 2.0=0A= service flows are represented in this table.=0A= Docsis 1.0 QOS service profiles are not=0A= represented in this table.=0A= =0A= Each row corresponds to a DOCSIS QOS Parameter = Set=0A= as signaled via DOCSIS MAC management messages.=0A= Each object in the row corresponds to one or=0A= part of one DOCSIS 1.1 Service Flow Encoding.=0A= The docsQosParamSetBitMap object in the row = indicates=0A= which particular parameters were signaled in=0A= the original registration or dynamic service=0A= request message that created the QOS Parameter = Set.=0A= =0A= In many cases, even if a QOS Parameter Set = parameter=0A= was not signaled, the DOCSIS specification calls=0A= for a default value to be used. That default = value=0A= is reported as the value of the corresponding = object=0A= in this row.=0A= =0A= Many objects are not applicable depending on=0A= the service flow direction or upstream = scheduling=0A= type. The object value reported in this case=0A= is specified in the DESCRIPTION clause.=0A= "=0A= ::=3D { docsQosMIBObjects 2 }=0A= =0A= -- docsQosParamSetEntry { docsQosParamSetTable 1 } was=0A= -- removed in an initial and unimplemented version of this mib.=0A= =0A= docsQosParamSetEntry OBJECT-TYPE=0A= SYNTAX DocsQosParamSetEntry=0A= MAX-ACCESS not-accessible=0A= =0A= =0A= =0A= Expires September 2003 [Page 34]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION=0A= "A unique set of QOS parameters."=0A= INDEX {=0A= ifIndex, docsQosServiceFlowId, docsQosParamSetType=0A= }=0A= ::=3D { docsQosParamSetTable 1 }=0A= =0A= DocsQosParamSetEntry ::=3D SEQUENCE {=0A= docsQosParamSetServiceClassName DisplayString,=0A= docsQosParamSetPriority Integer32,=0A= docsQosParamSetMaxTrafficRate DocsQosBitRate,=0A= docsQosParamSetMaxTrafficBurst Unsigned32,=0A= docsQosParamSetMinReservedRate DocsQosBitRate,=0A= docsQosParamSetMinReservedPkt Integer32,=0A= docsQosParamSetActiveTimeout Integer32,=0A= docsQosParamSetAdmittedTimeout Integer32,=0A= docsQosParamSetMaxConcatBurst Integer32,=0A= docsQosParamSetSchedulingType DocsQosSchedulingType,=0A= docsQosParamSetNomPollInterval Unsigned32,=0A= docsQosParamSetTolPollJitter Unsigned32,=0A= docsQosParamSetUnsolicitGrantSize Integer32,=0A= docsQosParamSetNomGrantInterval Unsigned32,=0A= docsQosParamSetTolGrantJitter Unsigned32,=0A= docsQosParamSetGrantsPerInterval Integer32,=0A= docsQosParamSetTosAndMask OCTET STRING,=0A= docsQosParamSetTosOrMask OCTET STRING,=0A= docsQosParamSetMaxLatency Unsigned32,=0A= docsQosParamSetType INTEGER,=0A= docsQosParamSetRequestPolicyOct OCTET STRING,=0A= docsQosParamSetBitMap BITS=0A= }=0A= =0A= docsQosParamSetServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Refers to the Service Class Name that the=0A= parameter set values were derived.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is a zero length string.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4"=0A= ::=3D { docsQosParamSetEntry 4 }=0A= =0A= docsQosParamSetPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= =0A= =0A= =0A= Expires September 2003 [Page 35]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= DESCRIPTION "The relative priority of a service flow.=0A= Higher numbers indicate higher priority.=0A= This priority should only be used to = differentiate=0A= service flow with identical parameter sets.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter is=0A= not applicable, the reported value is 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.1"=0A= ::=3D { docsQosParamSetEntry 5 }=0A= =0A= docsQosParamSetMaxTrafficRate OBJECT-TYPE=0A= SYNTAX DocsQosBitRate=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Maximum sustained traffic rate allowed for this=0A= service flow in bits/sec. Must count all MAC = frame=0A= data PDU from the bytes following the MAC header = HCS to=0A= the end of the CRC. The number of bytes=0A= forwarded is limited during any time interval.=0A= The value 0 means no maximum traffic rate is=0A= enforced. This object applies to both upstream = and=0A= downstream service flows.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter is=0A= not applicable, it is reported as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.2"=0A= ::=3D { docsQosParamSetEntry 6 }=0A= =0A= docsQosParamSetMaxTrafficBurst OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the token bucket size in bytes=0A= for this parameter set. The value is calculated=0A= from the byte following the MAC header HCS to=0A= the end of the CRC. This object is applied in=0A= conjunction with docsQosParamSetMaxTrafficRate = to=0A= calculate maximum sustained traffic rate.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object for scheduling types=0A= bestEffort (2), nonRealTimePollingService(3),=0A= and realTimePollingService(4) is 3044.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 36]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= If this parameter is not applicable, it is = reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.3"=0A= ::=3D { docsQosParamSetEntry 7 }=0A= =0A= docsQosParamSetMinReservedRate OBJECT-TYPE=0A= SYNTAX DocsQosBitRate=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the guaranteed minimum rate in=0A= bits/sec for this parameter set. The value is=0A= calculated from the byte following the MAC=0A= header HCS to the end of the CRC. The default=0A= value of 0 has the meaning that no bandwidth=0A= is reserved.=0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0. If the parameter=0A= is not applicable, it is reported as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.4"=0A= ::=3D { docsQosParamSetEntry 8 }=0A= =0A= docsQosParamSetMinReservedPkt OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies an assumed minimum packet size in=0A= bytes for which the = docsQosParamSetMinReservedRate=0A= will be provided. The value is calculated from=0A= the byte following the MAC header HCS to the=0A= end of the CRC.=0A= =0A= If the referenced parameter is omitted from a=0A= DOCSIS QOS parameter set, the default value is=0A= CMTS implementation dependent. In this case, the=0A= CMTS reports the default value it is using and = the=0A= CM reports a value of 0. If the referenced=0A= parameter is not applicable to the direction or=0A= scheduling type of the service flow, both CMTS = and=0A= CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.5"=0A= ::=3D { docsQosParamSetEntry 9 }=0A= =0A= docsQosParamSetActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= =0A= =0A= =0A= Expires September 2003 [Page 37]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= DESCRIPTION "Specifies the maximum duration in seconds that=0A= resources remain unused on an active service=0A= flow before CMTS signals that both active and=0A= admitted parameters set are null.=0A= The default value of 0 signifies an=0A= infinite amount of time.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object is 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.6"=0A= ::=3D { docsQosParamSetEntry 10 }=0A= =0A= docsQosParamSetAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum duration in seconds that=0A= resources remain in admitted state before=0A= resources must be released.=0A= The value of 0 signifies an infinite amount=0A= of time.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the=0A= default value of this object is 200.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.5.7"=0A= DEFVAL { 200 }=0A= ::=3D { docsQosParamSetEntry 11 }=0A= =0A= docsQosParamSetMaxConcatBurst OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum concatenated burst in=0A= bytes which an upstream service flow is = allowed.=0A= The value is calculated from the FC byte of the=0A= Concatenation MAC Header to the last CRC byte in=0A= of the last concatenated MAC frame, inclusive.=0A= The value of 0 specifies no maximum burst.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set, the = default=0A= value of this object for scheduling types=0A= bestEffort(2), nonRealTimePollingService(3), and=0A= realTimePollingService(4) is 1522. If the = parameter=0A= =0A= =0A= =0A= Expires September 2003 [Page 38]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= is not applicable, this object's value is = reported=0A= as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.1"=0A= ::=3D { docsQosParamSetEntry 12 }=0A= =0A= =0A= docsQosParamSetSchedulingType OBJECT-TYPE=0A= SYNTAX DocsQosSchedulingType=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the upstream scheduling service used = for=0A= upstream service flow.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding DOCSIS QOS Parameter Set of an=0A= upstream service flow, the default value of this=0A= object is bestEffort(2). For QOS parameter sets = of=0A= downstream service flows, this object's value is=0A= reported as undefined(1).=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.2"=0A= ::=3D { docsQosParamSetEntry 13 }=0A= =0A= docsQosParamSetNomPollInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the nominal interval in microseconds=0A= between successive unicast request=0A= opportunities on an upstream service flow.=0A= =0A= This object applies only to upstream service = flows=0A= with DocsQosSchedulingType of value=0A= nonRealTimePollingService(3),=0A= realTimePollingService(4), and=0A= unsolictedGrantServiceWithAD(5). The parameter = is=0A= mandatory for realTimePollingService(4). If the=0A= parameter is omitted with=0A= nonRealTimePollingService(3), the CMTS uses an=0A= implementation dependent value. If the = parameter=0A= is omitted with unsolictedGrantServiceWithAD(5),=0A= the CMTS uses as a default value the value of = the=0A= Nominal Grant Interval parameter. In all cases,=0A= the CMTS reports the value it is using when the=0A= parameter is applicable. The CM reports the=0A= signaled parameter value if it was signaled,=0A= and 0 otherwise.=0A= =0A= If the referenced parameter is not applicable to=0A= =0A= =0A= =0A= Expires September 2003 [Page 39]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.4"=0A= ::=3D { docsQosParamSetEntry 15 }=0A= =0A= docsQosParamSetTolPollJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum amount of time in=0A= microseconds that the unicast request interval=0A= may be delayed from the nominal periodic=0A= schedule on an upstream service flow.=0A= =0A= This parameter is applicable only to upstream=0A= service flows with a DocsQosSchedulingType of=0A= realTimePollingService(4) or=0A= unsolictedGrantServiceWithAD(5).=0A= =0A= If the referenced parameter is applicable but = not=0A= present in the corresponding DOCSIS QOS = Parameter=0A= Set, the CMTS uses an implementation dependent=0A= value and reports the value it is using.=0A= The CM reports a value of 0 in this case.=0A= =0A= If the parameter is not applicable to the=0A= direction or upstream scheduling type of the=0A= service flow, both CMTS and CM report this=0A= object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.5"=0A= ::=3D { docsQosParamSetEntry 16 }=0A= =0A= docsQosParamSetUnsolicitGrantSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the unsolicited grant size in bytes.=0A= The grant size includes the entire MAC frame=0A= data PDU from the Frame Control byte to end of=0A= the MAC frame.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a DocsQosSchedulingType = of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report=0A= the signaled value of the parameter in this=0A= =0A= =0A= =0A= Expires September 2003 [Page 40]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.6"=0A= ::=3D { docsQosParamSetEntry 17 }=0A= =0A= docsQosParamSetNomGrantInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the nominal interval in microseconds=0A= between successive data grant opportunities=0A= on an upstream service flow.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a DocsQosSchedulingType = of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.7"=0A= ::=3D { docsQosParamSetEntry 18 }=0A= =0A= docsQosParamSetTolGrantJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum amount of time in=0A= microseconds that the transmission opportunities=0A= may be delayed from the nominal periodic = schedule.=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a DocsQosSchedulingType = of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 41]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.8"=0A= ::=3D { docsQosParamSetEntry 19 }=0A= =0A= docsQosParamSetGrantsPerInterval OBJECT-TYPE=0A= SYNTAX Integer32 (0..127)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the number of data grants per Nominal=0A= Grant Interval=0A= (docsQosParamSetNomGrantInterval).=0A= =0A= The referenced parameter is applicable only=0A= for upstream flows with a DocsQosSchedulingType = of=0A= of unsolicitedGrantServicewithAD(5) or=0A= unsolicitedGrantService(6), and is mandatory=0A= when applicable. Both CMTS and CM report the=0A= signaled value of the parameter in this case.=0A= =0A= If the referenced parameter is not applicable to=0A= the direction or scheduling type of the=0A= corresponding DOCSIS QOS Parameter Set, both=0A= CMTS and CM report this object's value as 0.=0A= "=0A= =0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.9"=0A= ::=3D { docsQosParamSetEntry 20 }=0A= =0A= docsQosParamSetTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the AND mask for IP TOS byte for = overwriting=0A= IP packets TOS value. The IP packets TOS byte = is=0A= bitwise ANDed with docsQosParamSetTosAndMask and=0A= result is bitwise ORed with = docsQosParamSetTosORMask=0A= and result is written to IP packet TOS byte.=0A= A value of 'FF'H for docsQosParamSetTosAndMask = and=0A= a value of '00'H for docsQosParamSetTosOrMask = means=0A= that IP Packet TOS byte is not overwritten.=0A= =0A= This combination is reported if the referenced=0A= parameter is not present in a QOS Parameter Set.=0A= =0A= Even though the this object is only enforced by = the=0A= Cable Modem Termination System (CMTS),=0A= Cable Modems must report the value as signaled = in=0A= =0A= =0A= =0A= Expires September 2003 [Page 42]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= the referenced parameter."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10"=0A= ::=3D { docsQosParamSetEntry 21 }=0A= =0A= docsQosParamSetTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the OR mask for IP TOS byte.=0A= See the description of docsQosParamSetTosAndMask=0A= for further details."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.10"=0A= ::=3D { docsQosParamSetEntry 22 }=0A= =0A= docsQosParamSetMaxLatency OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies the maximum latency between the=0A= reception of a packet by the CMTS on its NSI=0A= and the forwarding of the packet to the RF=0A= interface. A value of 0 signifies no maximum=0A= latency enforced. This object only applies to=0A= downstream service flows.=0A= =0A= If the referenced parameter is not present in = the=0A= corresponding downstream DOCSIS QOS Parameter = Set,=0A= the default value is 0. This parameter is=0A= not applicable to upstream DOCSIS QOS Parameter = Sets,=0A= and its value is reported as 0 in this case.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1"=0A= ::=3D { docsQosParamSetEntry 23 }=0A= =0A= =0A= docsQosParamSetType OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active (1),=0A= admitted (2),=0A= provisioned (3)=0A= }=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Defines the type of the QOS parameter set = defined=0A= by this row. active(1) indicates the Active QOS=0A= parameter set, describing the service currently=0A= being provided by the Docsis MAC domain to the=0A= service flow. admitted(2) indicates the Admitted=0A= QOS Parameter Set, describing services reserved = by=0A= by the Docsis MAC domain for use by the service = flow.=0A= =0A= =0A= =0A= Expires September 2003 [Page 43]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= provisioned (3) describes the QOS Parameter Set=0A= defined in the DOCSIS CM Configuration file for=0A= the service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, 8.1.5"=0A= ::=3D { docsQosParamSetEntry 24 }=0A= =0A= docsQosParamSetRequestPolicyOct OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= -- A 32-bit mask represented most significant = byte=0A= -- first. The 32 bit integer represented in this = manner=0A= -- equals the binary value of the referenced = integer=0A= -- parameter of the DOCSIS RFI specification.=0A= -- The BITS syntax is not used in order to avoid=0A= -- the confusion caused by different bit = numbering=0A= -- conventions.=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Specifies which transmit interval opportunities=0A= the CM omits for upstream transmission requests = and=0A= packet transmissions. This object takes its=0A= default value for downstream service flows.=0A= =0A= Unless otherwise indicated, a bit value of 1 = means=0A= that a CM must *not* use that opportunity for=0A= upstream transmission.=0A= =0A= Calling bit 0 the least significant bit of the=0A= least significant (4th) octet, and increasing=0A= bit number with significance, the bit = definitions=0A= are as defined below:=0A= =0A= broadcastReqOpp(0):=0A= all CMs broadcast request opportunities=0A= =0A= priorityReqMulticastReq(1):=0A= priority request multicast request = opportunities=0A= =0A= reqDataForReq(2):=0A= request/data opportunities for requests=0A= =0A= reqDataForData(3):=0A= request/data opportunities for data=0A= =0A= piggybackReqWithData(4):=0A= piggyback requests with data=0A= =0A= concatenateData(5):=0A= concatenate data=0A= =0A= fragmentData(6):=0A= fragment data=0A= =0A= =0A= =0A= Expires September 2003 [Page 44]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= suppresspayloadheaders(7):=0A= suppress payload headers=0A= =0A= dropPktsExceedUGSize(8):=0A= A value of 1 mean that service flow must = drop=0A= packet that do not fit in the Unsolicited=0A= Grant size=0A= =0A= If the referenced parameter is not present in=0A= a QOS Parameter Set, the value of this object is=0A= reported as '00000000'H.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.6.3"=0A= ::=3D { docsQosParamSetEntry 25 }=0A= =0A= docsQosParamSetBitMap OBJECT-TYPE=0A= -- Each bit corresponds to a = parameter=0A= -- from SP-RFI-v1.1-I07-010829, = Appendix C=0A= SYNTAX BITS { -- in the indicated section number.=0A= trafficPriority(0), -- C.2.2.5.1=0A= maxTrafficRate(1), -- C.2.2.5.2=0A= maxTrafficBurst(2), -- C.2.2.5.3=0A= minReservedRate(3), -- C.2.2.5.4=0A= minReservedPkt(4), -- C.2.2.5.5=0A= activeTimeout(5), -- C.2.2.5.6=0A= admittedTimeout(6), -- C.2.2.5.7=0A= maxConcatBurst(7), -- C.2.2.6.1=0A= schedulingType(8), -- C.2.2.6.2=0A= requestPolicy(9), -- C.2.2.6.3=0A= nomPollInterval(10), -- C.2.2.6.4=0A= tolPollJitter(11), -- C.2.2.6.5=0A= unsolicitGrantSize(12), -- C.2.2.6.6=0A= nomGrantInterval(13), -- C.2.2.6.7=0A= tolGrantJitter(14), -- C.2.2.6.8=0A= grantsPerInterval(15), -- C.2.2.6.9=0A= tosOverwrite(16), -- C.2.2.6.10=0A= maxLatency(17) -- C.2.2.7.1=0A= }=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object indicates the set of QOS Parameter=0A= Set parameters actually signaled in the=0A= DOCSIS registration or dynamic service request=0A= message that created or modified the QOS Parameter = Set.=0A= A bit is set to 1 when the parameter described=0A= by the indicated reference section is present=0A= in the original request.=0A= =0A= Note that when Service Class names are expanded,=0A= the registration or dynamic response message may=0A= contain parameters as expanded by the CMTS based=0A= =0A= =0A= =0A= Expires September 2003 [Page 45]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= on a stored service class. These expanded=0A= parameters are *not* indicated by a 1 bit in = this=0A= object.=0A= =0A= Note that even though some QOS Parameter Set=0A= parameters may not be signaled in a message=0A= (so that the paramater's bit in this object is = 0)=0A= the DOCSIS specification calls for default=0A= values to be used. These default values are=0A= reported as the corresponding object's value in=0A= the row.=0A= =0A= Note that BITS objects are encoded most=0A= significant bit first. For example, if bits=0A= 1 and 16 are set, the value of this object=0A= is the octet string '400080'H.=0A= =0A= "=0A= ::=3D { docsQosParamSetEntry 26 }=0A= =0A= --=0A= -- Service Flow Table=0A= --=0A= docsQosServiceFlowTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 3 }=0A= =0A= docsQosServiceFlowEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a service flow.=0A= An entry in the table exists for each=0A= Service Flow ID. The ifIndex is an=0A= ifType of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId=0A= }=0A= ::=3D { docsQosServiceFlowTable 1 }=0A= =0A= DocsQosServiceFlowEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowId Unsigned32,=0A= docsQosServiceFlowSID Unsigned32,=0A= docsQosServiceFlowDirection = DocsQosRfMacIfDirection,=0A= docsQosServiceFlowPrimary TruthValue=0A= }=0A= =0A= =0A= =0A= Expires September 2003 [Page 46]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosServiceFlowId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An index assigned to a service flow by CMTS."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.2"=0A= ::=3D { docsQosServiceFlowEntry 1 }=0A= =0A= docsQosServiceFlowSID OBJECT-TYPE=0A= SYNTAX Unsigned32 (0..16383)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Service Identifier (SID) assigned to an=0A= admitted or active service flow. This object=0A= reports a value of 0 if a Service Id is not=0A= associated with the service flow. Only active=0A= or admitted upstream service flows will have a=0A= Service Id (SID)."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.3"=0A= ::=3D { docsQosServiceFlowEntry 2 }=0A= =0A= docsQosServiceFlowDirection OBJECT-TYPE=0A= SYNTAX DocsQosRfMacIfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The direction of the service flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.1/2"=0A= ::=3D { docsQosServiceFlowEntry 3 }=0A= =0A= docsQosServiceFlowPrimary OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Object reflects whether service flow is the = primary=0A= or a secondary service flow.=0A= =0A= A primary service flow is the default service = flow=0A= for otherwise unclassified traffic and all MAC=0A= messages."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Section 8.1 "=0A= ::=3D { docsQosServiceFlowEntry 4 }=0A= =0A= --=0A= -- Service Flow Stats Table=0A= --=0A= docsQosServiceFlowStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with = the=0A= Service Flows in a managed device. "=0A= =0A= =0A= =0A= Expires September 2003 [Page 47]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= ::=3D { docsQosMIBObjects 4 }=0A= =0A= docsQosServiceFlowStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of service flow statistics.=0A= An entry in the table exists for each=0A= Service Flow ID. The ifIndex is an=0A= ifType of docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId=0A= }=0A= ::=3D { docsQosServiceFlowStatsTable 1 }=0A= =0A= DocsQosServiceFlowStatsEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowPkts Counter64,=0A= docsQosServiceFlowOctets Counter64,=0A= docsQosServiceFlowTimeCreated TimeStamp,=0A= docsQosServiceFlowTimeActive Counter32,=0A= docsQosServiceFlowPHSUnknowns Counter32,=0A= docsQosServiceFlowPolicedDropPkts Counter32,=0A= docsQosServiceFlowPolicedDelayPkts Counter32=0A= }=0A= =0A= docsQosServiceFlowPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Packet Data PDUs classified to = this=0A= service flow and forwarded beyond a service flow=0A= maximum rate policing function.=0A= This object does not count MAC-specific=0A= management messages.=0A= CMs not classifying downstream packets may = report=0A= this object's value as 0.=0A= =0A= Particularly for UGS flows, packets sent on the=0A= primary service flow in violation of the UGS = grant=0A= size should be counted only on the primary = service=0A= flow's counters.=0A= =0A= Unclassified upstream user data packets (i.e. = non=0A= MAC-management) forwarded to the default = upstream=0A= service flow should be incremented for this = object.=0A= =0A= This object does include packets counted by=0A= docsQosServiceFlowPolicedDelayPkts, but does not = include=0A= packets counted by = docsQosServiceFlowPolicedDropPkts.=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 48]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosServiceFlowStatsEntry 1 }=0A= =0A= docsQosServiceFlowOctets OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets from the byte after the MAC=0A= header HCS to the end of the CRC for all packets = counted=0A= in the docsQosServiceFlowPkts object for this = row.=0A= Note that this counts the octets after payload = header=0A= suppression has been applied. CMs not classifying = to a=0A= downstream service flow may report this object's=0A= value as 0 for that flow.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosServiceFlowStatsEntry 2 }=0A= =0A= docsQosServiceFlowTimeCreated OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was created."=0A= ::=3D { docsQosServiceFlowStatsEntry 3 }=0A= =0A= docsQosServiceFlowTimeActive OBJECT-TYPE=0A= SYNTAX Counter32=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of seconds that the service flow=0A= has been active.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosServiceFlowStatsEntry 4 }=0A= =0A= docsQosServiceFlowPHSUnknowns OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets received on the service = flow=0A= with an unknown payload header suppression = index.=0A= =0A= This counter's last discontinuity is the=0A= =0A= =0A= =0A= Expires September 2003 [Page 49]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosServiceFlowStatsEntry 5 }=0A= =0A= docsQosServiceFlowPolicedDropPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Packet Data PDUs classified to = this=0A= service flow dropped due to:=0A= (1) implementation-dependent excessive delay = while=0A= enforcing the Maximum Sustained Traffic = Rate; or=0A= (2) UGS packets dropped due to exceeding the=0A= Unsolicited Grant Size with a=0A= Request/Transmission policy that requires = such=0A= packets to be dropped.=0A= Classified packets dropped due to other reasons = must be=0A= counted in ifOutDiscards for interface of this=0A= service flow.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosServiceFlowStatsEntry 6 }=0A= =0A= docsQosServiceFlowPolicedDelayPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "This object counts only packets delayed in order = to=0A= maintain the Maximum Sustained Traffic Rate. This = object=0A= will always report a value of 0 for UGS flows = because the=0A= Maximum Sustained Traffic Rate does not apply.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosServiceFlowStatsEntry 7 }=0A= =0A= --=0A= -- Upstream Service Flow Stats Table (CMTS ONLY)=0A= --=0A= docsQosUpstreamStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosUpstreamStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with=0A= upstream service flows. All counted frames must=0A= be received without an FCS error."=0A= ::=3D { docsQosMIBObjects 5 }=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 50]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosUpstreamStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosUpstreamStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of upstream service flow = statistics.=0A= An entry in the table exists for each=0A= upstream Service Flow in a managed device.=0A= The ifIndex is an ifType of = docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosSID=0A= }=0A= ::=3D { docsQosUpstreamStatsTable 1 }=0A= =0A= DocsQosUpstreamStatsEntry ::=3D SEQUENCE {=0A= docsQosSID Unsigned32,=0A= docsQosUpstreamFragments Counter32,=0A= docsQosUpstreamFragDiscards Counter32,=0A= docsQosUpstreamConcatBursts Counter32=0A= }=0A= =0A= docsQosSID OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..16383)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Identifies a service id for an admitted or = active=0A= upstream service flow."=0A= ::=3D { docsQosUpstreamStatsEntry 1 }=0A= =0A= docsQosUpstreamFragments OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of fragmentation headers received on = an=0A= upstream service flow, regardless of whether=0A= the fragment was correctly reassembled into a=0A= valid packet.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosUpstreamStatsEntry 2 }=0A= =0A= docsQosUpstreamFragDiscards OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of upstream fragments discarded and = not=0A= assembled into a valid upstream packet.=0A= =0A= This counter's last discontinuity is the=0A= =0A= =0A= =0A= Expires September 2003 [Page 51]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosUpstreamStatsEntry 3 }=0A= =0A= docsQosUpstreamConcatBursts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of concatenation headers received on = an=0A= upstream service flow.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosUpstreamStatsEntry 4 }=0A= =0A= =0A= --=0A= -- Dynamic Service Stats Table=0A= --=0A= docsQosDynamicServiceStatsTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosDynamicServiceStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes statistics associated with = the=0A= Dynamic Service Flows in a managed device. "=0A= ::=3D { docsQosMIBObjects 6 }=0A= =0A= docsQosDynamicServiceStatsEntry OBJECT-TYPE=0A= SYNTAX DocsQosDynamicServiceStatsEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Describes a set of dynamic service flow = statistics.=0A= Two entries exist for each Docsis mac layer=0A= interface for the upstream and downstream = direction.=0A= On the CMTS, the downstream direction row = indicates=0A= messages transmitted or transactions originated=0A= by the CMTS. The upstream direction row = indicates=0A= messages received or transaction originated by = the=0A= CM. On the CM, the downstream direction row=0A= indicates messages received or transactions=0A= originated by the CMTS. The upstream direction=0A= row indicates messages transmitted by the CM or=0A= transactions originated by the CM.=0A= The ifIndex is an ifType of = docsCableMaclayer(127)."=0A= INDEX {=0A= ifIndex,=0A= docsQosIfDirection=0A= }=0A= ::=3D { docsQosDynamicServiceStatsTable 1 }=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 52]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= DocsQosDynamicServiceStatsEntry ::=3D SEQUENCE {=0A= docsQosIfDirection = DocsQosRfMacIfDirection,=0A= docsQosDSAReqs Counter32,=0A= docsQosDSARsps Counter32,=0A= docsQosDSAAcks Counter32,=0A= docsQosDSCReqs Counter32,=0A= docsQosDSCRsps Counter32,=0A= docsQosDSCAcks Counter32,=0A= docsQosDSDReqs Counter32,=0A= docsQosDSDRsps Counter32,=0A= docsQosDynamicAdds Counter32,=0A= docsQosDynamicAddFails Counter32,=0A= docsQosDynamicChanges Counter32,=0A= docsQosDynamicChangeFails Counter32,=0A= docsQosDynamicDeletes Counter32,=0A= docsQosDynamicDeleteFails Counter32,=0A= docsQosDCCReqs Counter32,=0A= docsQosDCCRsps Counter32,=0A= docsQosDCCAcks Counter32,=0A= docsQosDCCs Counter32,=0A= docsQosDCCFails Counter32=0A= }=0A= =0A= docsQosIfDirection OBJECT-TYPE=0A= SYNTAX DocsQosRfMacIfDirection=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The direction of interface."=0A= ::=3D { docsQosDynamicServiceStatsEntry 1 }=0A= =0A= docsQosDSAReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition Requests,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 2 }=0A= =0A= docsQosDSARsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition = Responses,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= =0A= =0A= =0A= Expires September 2003 [Page 53]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 3 }=0A= =0A= docsQosDSAAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Addition = Acknowledgements,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 4 }=0A= =0A= docsQosDSCReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change Requests,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 5 }=0A= =0A= docsQosDSCRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change Responses,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 6 }=0A= =0A= docsQosDSCAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Change = Acknowledgements,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 7 }=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 54]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosDSDReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Delete Requests,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 8 }=0A= =0A= docsQosDSDRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Service Delete Responses,=0A= including retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 9 }=0A= =0A= docsQosDynamicAdds OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service = Addition=0A= transactions.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 10 }=0A= =0A= docsQosDynamicAddFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Addition=0A= transactions.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 11 }=0A= =0A= docsQosDynamicChanges OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires September 2003 [Page 55]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service Change=0A= transactions.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 12 }=0A= =0A= docsQosDynamicChangeFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Change=0A= transactions.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 13 }=0A= =0A= docsQosDynamicDeletes OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Service Delete=0A= transactions.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 14 }=0A= =0A= docsQosDynamicDeleteFails OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Service Delete=0A= transactions.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 15 }=0A= =0A= =0A= docsQosDCCReqs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change Request = messages=0A= =0A= =0A= =0A= Expires September 2003 [Page 56]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= traversing an interface. This count is nonzero only = on=0A= downstream direction rows. This count should=0A= include number of retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 16 }=0A= =0A= docsQosDCCRsps OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change Response = messages=0A= traversing an interface. This count is nonzero=0A= only on upstream direction rows. This count = should=0A= include number of retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 17 }=0A= =0A= docsQosDCCAcks OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of Dynamic Channel Change = Acknowledgement=0A= messages traversing an interface. This count=0A= is nonzero only on downstream direction rows.=0A= This count should include number of retries.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 18 }=0A= =0A= docsQosDCCs OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of successful Dynamic Channel Change=0A= transactions. This count is nonzero only on = downstream=0A= direction rows.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 19 }=0A= =0A= docsQosDCCFails OBJECT-TYPE=0A= =0A= =0A= =0A= Expires September 2003 [Page 57]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of failed Dynamic Channel Change=0A= transactions. This count is nonzero only on=0A= downstream direction rows.=0A= =0A= This counter's last discontinuity is the=0A= ifCounterDiscontinuityTime for same ifIndex that=0A= indexes this object."=0A= ::=3D { docsQosDynamicServiceStatsEntry 20 }=0A= =0A= =0A= --=0A= -- Service Flow Log Table (CMTS ONLY)=0A= --=0A= docsQosServiceFlowLogTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceFlowLogEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table contains a log of the disconnected=0A= Service Flows in a managed device."=0A= ::=3D { docsQosMIBObjects 7 }=0A= =0A= docsQosServiceFlowLogEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceFlowLogEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The information regarding a single disconnected=0A= service flow."=0A= INDEX {=0A= docsQosServiceFlowLogIndex=0A= }=0A= ::=3D { docsQosServiceFlowLogTable 1 }=0A= =0A= DocsQosServiceFlowLogEntry ::=3D SEQUENCE {=0A= docsQosServiceFlowLogIndex Unsigned32,=0A= docsQosServiceFlowLogIfIndex InterfaceIndex,=0A= docsQosServiceFlowLogSFID Unsigned32,=0A= docsQosServiceFlowLogCmMac MacAddress,=0A= docsQosServiceFlowLogPkts Counter64,=0A= docsQosServiceFlowLogOctets Counter64,=0A= docsQosServiceFlowLogTimeDeleted TimeStamp,=0A= docsQosServiceFlowLogTimeCreated TimeStamp,=0A= docsQosServiceFlowLogTimeActive Counter32,=0A= docsQosServiceFlowLogDirection = DocsQosRfMacIfDirection,=0A= docsQosServiceFlowLogPrimary TruthValue,=0A= docsQosServiceFlowLogServiceClassName DisplayString,=0A= docsQosServiceFlowLogPolicedDropPkts Counter32,=0A= docsQosServiceFlowLogPolicedDelayPkts Counter32,=0A= docsQosServiceFlowLogControl INTEGER=0A= =0A= =0A= =0A= Expires September 2003 [Page 58]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= }=0A= =0A= docsQosServiceFlowLogIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Unique index for a logged service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 1 }=0A= =0A= docsQosServiceFlowLogIfIndex OBJECT-TYPE=0A= SYNTAX InterfaceIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The ifIndex of ifType docsCableMaclayer(127)=0A= on the CMTS where the service flow was = present."=0A= ::=3D { docsQosServiceFlowLogEntry 2 }=0A= =0A= docsQosServiceFlowLogSFID OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The index assigned to the service flow by the = CMTS."=0A= ::=3D { docsQosServiceFlowLogEntry 3 }=0A= =0A= docsQosServiceFlowLogCmMac OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The MAC address for the cable modem associated = with=0A= the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 4 }=0A= =0A= docsQosServiceFlowLogPkts OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of packets counted on this service = flow=0A= after payload header suppression."=0A= ::=3D { docsQosServiceFlowLogEntry 5 }=0A= =0A= docsQosServiceFlowLogOctets OBJECT-TYPE=0A= SYNTAX Counter64=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The number of octets counted on this service = flow=0A= after payload header suppression."=0A= ::=3D { docsQosServiceFlowLogEntry 6 }=0A= =0A= docsQosServiceFlowLogTimeDeleted OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= =0A= =0A= =0A= Expires September 2003 [Page 59]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was deleted."=0A= ::=3D { docsQosServiceFlowLogEntry 7 }=0A= =0A= docsQosServiceFlowLogTimeCreated OBJECT-TYPE=0A= SYNTAX TimeStamp=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of sysUpTime when the service flow=0A= was created."=0A= ::=3D { docsQosServiceFlowLogEntry 8 }=0A= =0A= docsQosServiceFlowLogTimeActive OBJECT-TYPE=0A= SYNTAX Counter32=0A= UNITS "seconds"=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The total time that service flow was active."=0A= ::=3D { docsQosServiceFlowLogEntry 9 }=0A= =0A= docsQosServiceFlowLogDirection OBJECT-TYPE=0A= SYNTAX DocsQosRfMacIfDirection=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosServiceFlowDirection=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 10 }=0A= =0A= docsQosServiceFlowLogPrimary OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosServiceFlowPrimary for the=0A= service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 11 }=0A= =0A= docsQosServiceFlowLogServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The value of docsQosParamSetServiceClassName for=0A= the provisioned QOS Parameter Set of the=0A= service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 12 }=0A= =0A= docsQosServiceFlowLogPolicedDropPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The final value of = docsQosServiceFlowPolicedDropPkts=0A= =0A= =0A= =0A= Expires September 2003 [Page 60]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 13 }=0A= =0A= docsQosServiceFlowLogPolicedDelayPkts OBJECT-TYPE=0A= SYNTAX Counter32=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The final value of = docsQosServiceFlowPolicedDelayPkts=0A= for the service flow."=0A= ::=3D { docsQosServiceFlowLogEntry 14 }=0A= =0A= docsQosServiceFlowLogControl OBJECT-TYPE=0A= SYNTAX INTEGER {=0A= active(1),=0A= destroy(6)=0A= }=0A= =0A= MAX-ACCESS read-write=0A= STATUS current=0A= DESCRIPTION "Setting this object to the value destroy(6) = removes=0A= this entry from the table.=0A= Reading this object return the value active(1)."=0A= ::=3D { docsQosServiceFlowLogEntry 15 }=0A= =0A= --=0A= -- Service Class Table (CMTS ONLY)=0A= --=0A= docsQosServiceClassTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Classes in a CMTS. "=0A= ::=3D { docsQosMIBObjects 8 }=0A= =0A= docsQosServiceClassEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceClassEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A provisioned service class on a CMTS.=0A= Each entry defines a template for certain=0A= DOCSIS QOS Parameter Set values. When a CM=0A= creates or modifies an Admitted QOS Parameter Set for = a=0A= Service Flow, it may reference a Service Class=0A= Name instead of providing explicit QOS Parameter=0A= Set values. In this case, the CMTS populates=0A= the QOS Parameter Set with the applicable=0A= corresponding values from the named Service Class.=0A= Subsequent changes to a Service Class row do *not*=0A= affect the QOS Parameter Set values of any service = flows=0A= already admitted.=0A= =0A= =0A= =0A= Expires September 2003 [Page 61]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= =0A= A service class template applies to only=0A= a single direction, as indicated in the=0A= docsQosServiceClassDirection object.=0A= "=0A= INDEX {=0A= docsQosServiceClassName=0A= }=0A= ::=3D { docsQosServiceClassTable 1 }=0A= =0A= DocsQosServiceClassEntry ::=3D SEQUENCE {=0A= docsQosServiceClassName DisplayString,=0A= docsQosServiceClassStatus RowStatus,=0A= docsQosServiceClassPriority Integer32,=0A= docsQosServiceClassMaxTrafficRate DocsQosBitRate,=0A= docsQosServiceClassMaxTrafficBurst Unsigned32,=0A= docsQosServiceClassMinReservedRate DocsQosBitRate,=0A= docsQosServiceClassMinReservedPkt Integer32,=0A= docsQosServiceClassMaxConcatBurst Integer32,=0A= docsQosServiceClassNomPollInterval Unsigned32,=0A= docsQosServiceClassTolPollJitter Unsigned32,=0A= docsQosServiceClassUnsolicitGrantSize Integer32,=0A= docsQosServiceClassNomGrantInterval Unsigned32,=0A= docsQosServiceClassTolGrantJitter Unsigned32,=0A= docsQosServiceClassGrantsPerInterval Integer32,=0A= docsQosServiceClassMaxLatency Unsigned32,=0A= docsQosServiceClassActiveTimeout Integer32,=0A= docsQosServiceClassAdmittedTimeout Integer32,=0A= docsQosServiceClassSchedulingType DocsQosSchedulingType,=0A= docsQosServiceClassRequestPolicy OCTET STRING,=0A= docsQosServiceClassTosAndMask OCTET STRING,=0A= docsQosServiceClassTosOrMask OCTET STRING,=0A= docsQosServiceClassDirection DocsQosRfMacIfDirection,=0A= docsQosServiceClassStorageType StorageType=0A= }=0A= =0A= docsQosServiceClassName OBJECT-TYPE=0A= SYNTAX DisplayString (SIZE(2..15))=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Service Class Name. DOCSIS specifies that the=0A= maximum size is 16 ASCII characters including=0A= a terminating zero. The terminating zero is not=0A= represented in this DisplayString syntax object.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.3.4"=0A= ::=3D { docsQosServiceClassEntry 1 }=0A= =0A= docsQosServiceClassStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= =0A= =0A= =0A= Expires September 2003 [Page 62]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "Used to create or delete rows in this table.=0A= There is no restriction on the ability=0A= to change values in this row while the row is = active.=0A= Inactive rows need not be timed out."=0A= ::=3D { docsQosServiceClassEntry 2 }=0A= =0A= docsQosServiceClassPriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..7)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetPriority."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 3 }=0A= =0A= docsQosServiceClassMaxTrafficRate OBJECT-TYPE=0A= SYNTAX DocsQosBitRate=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxTrafficRate."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 4 }=0A= =0A= docsQosServiceClassMaxTrafficBurst OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxTrafficBurst."=0A= DEFVAL { 3044 }=0A= ::=3D { docsQosServiceClassEntry 5 }=0A= =0A= docsQosServiceClassMinReservedRate OBJECT-TYPE=0A= SYNTAX DocsQosBitRate=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSEtMinReservedRate."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 6 }=0A= =0A= docsQosServiceClassMinReservedPkt OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMinReservedPkt."=0A= ::=3D { docsQosServiceClassEntry 7 }=0A= =0A= docsQosServiceClassMaxConcatBurst OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetMaxConcatBurst."=0A= =0A= =0A= =0A= Expires September 2003 [Page 63]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= DEFVAL { 1522 }=0A= ::=3D { docsQosServiceClassEntry 8 }=0A= =0A= docsQosServiceClassNomPollInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetNomPollInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 9 }=0A= =0A= docsQosServiceClassTolPollJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTolPollJitter."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 10 }=0A= =0A= docsQosServiceClassUnsolicitGrantSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetUnsolicitGrantSize."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 11 }=0A= =0A= docsQosServiceClassNomGrantInterval OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetNomGrantInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 12 }=0A= =0A= docsQosServiceClassTolGrantJitter OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTolGrantJitter."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 13 }=0A= =0A= docsQosServiceClassGrantsPerInterval OBJECT-TYPE=0A= SYNTAX Integer32 (0..127)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= =0A= =0A= =0A= Expires September 2003 [Page 64]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= DESCRIPTION "Template for docsQosParamSetGrantsPerInterval."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 14 }=0A= =0A= docsQosServiceClassMaxLatency OBJECT-TYPE=0A= SYNTAX Unsigned32=0A= UNITS "microseconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetClassMaxLatency."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.7.1"=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 15 }=0A= =0A= docsQosServiceClassActiveTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetActiveTimeout."=0A= DEFVAL { 0 }=0A= ::=3D { docsQosServiceClassEntry 16 }=0A= =0A= docsQosServiceClassAdmittedTimeout OBJECT-TYPE=0A= SYNTAX Integer32 (0..65535)=0A= UNITS "seconds"=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetAdmittedTimeout."=0A= DEFVAL { 200 }=0A= ::=3D { docsQosServiceClassEntry 17 }=0A= =0A= docsQosServiceClassSchedulingType OBJECT-TYPE=0A= SYNTAX DocsQosSchedulingType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetSchedulingType."=0A= DEFVAL { bestEffort }=0A= ::=3D { docsQosServiceClassEntry 18 }=0A= =0A= docsQosServiceClassRequestPolicy OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(4))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetRequestPolicyOct."=0A= DEFVAL { '00000000'H } -- no bits are set=0A= ::=3D { docsQosServiceClassEntry 19 }=0A= =0A= docsQosServiceClassTosAndMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-create=0A= =0A= =0A= =0A= Expires September 2003 [Page 65]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTosAndMask."=0A= DEFVAL { 'FF'H }=0A= ::=3D { docsQosServiceClassEntry 20 }=0A= =0A= docsQosServiceClassTosOrMask OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(1))=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Template for docsQosParamSetTosOrMask."=0A= DEFVAL { '00'H }=0A= ::=3D { docsQosServiceClassEntry 21 }=0A= =0A= docsQosServiceClassDirection OBJECT-TYPE=0A= SYNTAX DocsQosRfMacIfDirection=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Specifies whether the service class template=0A= applies to upstream or downstream service = flows."=0A= DEFVAL { upstream }=0A= ::=3D { docsQosServiceClassEntry 22 }=0A= =0A= docsQosServiceClassStorageType OBJECT-TYPE=0A= SYNTAX StorageType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "This object defines whether this row is kept in=0A= volatile storage and lost upon reboot or if this=0A= row is backed up by non-volatile or permanent=0A= storage. 'permanent' entries need not allow=0A= writable access to any object."=0A= DEFVAL { nonVolatile }=0A= ::=3D { docsQosServiceClassEntry 23 }=0A= =0A= --=0A= -- Service Class PolicyTable=0A= --=0A= docsQosServiceClassPolicyTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosServiceClassPolicyEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes the set of Docsis-QOS=0A= Service Class Policies.=0A= =0A= This table is an adjunct to the=0A= docsDevFilterPolicy table. Entries in=0A= docsDevFilterPolicy table can point to=0A= specific rows in this table.=0A= =0A= This table permits mapping a packet to a service=0A= class name of an active service flow so long as=0A= =0A= =0A= =0A= Expires September 2003 [Page 66]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= a classifier does not exist at a higher=0A= priority.=0A= "=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1"=0A= ::=3D { docsQosMIBObjects 9 }=0A= =0A= docsQosServiceClassPolicyEntry OBJECT-TYPE=0A= SYNTAX DocsQosServiceClassPolicyEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A service class name policy entry."=0A= INDEX {=0A= docsQosServiceClassPolicyIndex=0A= }=0A= ::=3D { docsQosServiceClassPolicyTable 1 }=0A= =0A= DocsQosServiceClassPolicyEntry ::=3D SEQUENCE {=0A= docsQosServiceClassPolicyIndex Unsigned32,=0A= docsQosServiceClassPolicyName DisplayString,=0A= docsQosServiceClassPolicyRulePriority Integer32,=0A= docsQosServiceClassPolicyStatus RowStatus,=0A= docsQosServiceClassPolicyStorageType StorageType=0A= }=0A= =0A= docsQosServiceClassPolicyIndex OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..2147483647)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "Index value to uniquely identify an entry in=0A= this table."=0A= ::=3D { docsQosServiceClassPolicyEntry 1 }=0A= =0A= docsQosServiceClassPolicyName OBJECT-TYPE=0A= SYNTAX DisplayString=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Service Class Name to identify the name of the=0A= service class flow to which the packet should be=0A= directed."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix E.2.1"=0A= ::=3D { docsQosServiceClassPolicyEntry 2 }=0A= =0A= docsQosServiceClassPolicyRulePriority OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Service Class Policy rule priority for the=0A= entry."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.1.3.5"=0A= ::=3D { docsQosServiceClassPolicyEntry 3 }=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 67]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosServiceClassPolicyStatus OBJECT-TYPE=0A= SYNTAX RowStatus=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "Used to create or delete rows in this table.=0A= This object should not be deleted if it is=0A= reference by an entry in docsDevFilterPolicy.=0A= The reference should be deleted first.=0A= There is no restriction on the ability=0A= to change values in this row while the row is = active.=0A= Inactive rows need not be timed out."=0A= ::=3D { docsQosServiceClassPolicyEntry 4 }=0A= =0A= docsQosServiceClassPolicyStorageType OBJECT-TYPE=0A= SYNTAX StorageType=0A= MAX-ACCESS read-create=0A= STATUS current=0A= DESCRIPTION "This object defines whether this row is kept in=0A= volatile storage and lost upon reboot or if this=0A= row is backed up by non-volatile or permanent=0A= storage. 'permanent' entries need not allow=0A= writable access to any object."=0A= DEFVAL { nonVolatile }=0A= ::=3D { docsQosServiceClassPolicyEntry 5 }=0A= =0A= --=0A= -- Payload Header Suppression(PHS) Table=0A= --=0A= docsQosPHSTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosPHSEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table describes set of payload header=0A= suppression entries."=0A= ::=3D { docsQosMIBObjects 10 }=0A= =0A= docsQosPHSEntry OBJECT-TYPE=0A= SYNTAX DocsQosPHSEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "A payload header suppression entry.=0A= The ifIndex is an ifType of = docsCableMaclayer(127).=0A= The index docsQosServiceFlowId selects one=0A= service flow from the cable MAC layer = interface.=0A= The docsQosPktClassId index matches an=0A= index of the docsQosPktClassTable.=0A= "=0A= INDEX {=0A= ifIndex,=0A= docsQosServiceFlowId,=0A= docsQosPktClassId=0A= =0A= =0A= =0A= Expires September 2003 [Page 68]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= }=0A= ::=3D { docsQosPHSTable 1 }=0A= =0A= DocsQosPHSEntry ::=3D SEQUENCE {=0A= docsQosPHSField OCTET STRING,=0A= docsQosPHSMask OCTET STRING,=0A= docsQosPHSSize Integer32,=0A= docsQosPHSVerify TruthValue,=0A= docsQosPHSIndex Integer32=0A= }=0A= =0A= -- docsQosPHSIndex { docsQosPHSEntry 1 } was=0A= -- moved to docsQosPHSIndex { docsQosPHSEntry 7 }=0A= -- in an ealier revisions of the mib.=0A= =0A= docsQosPHSField OBJECT-TYPE=0A= SYNTAX OCTET STRING (SIZE(0..255))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression field defines the=0A= bytes of the header which must be=0A= suppressed/restored by the sending/receiving=0A= device.=0A= =0A= The number of octets in this object should be=0A= the same as the value of docsQosPHSSize."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.1"=0A= ::=3D { docsQosPHSEntry 2 }=0A= =0A= docsQosPHSMask OBJECT-TYPE=0A= SYNTAX OCTET STRING(SIZE(0..32))=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression mask defines the=0A= bit mask which used in combination with the=0A= docsQosPHSField defines which bytes in header=0A= must be suppressed/restored by the sending or=0A= receiving device.=0A= =0A= Each bit of this bit mask corresponds to a byte=0A= in the docsQosPHSField, with the least=0A= significant bit corresponding to first byte of=0A= the docsQosPHSField.=0A= =0A= Each bit of the bit mask specifies whether of=0A= not the corresponding byte should be suppressed=0A= in the packet. A bit value of '1' indicates that=0A= the byte should be suppressed by the sending=0A= device and restored by the receiving device.=0A= A bit value of '0' indicates that=0A= the byte should not be suppressed by the sending=0A= =0A= =0A= =0A= Expires September 2003 [Page 69]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= device or restored by the receiving device.=0A= =0A= If the bit mask does not contain a bit for each=0A= byte in the docsQosPHSField then the bit mask is=0A= extended with bit values of '1' to be the=0A= necessary length."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.3"=0A= ::=3D { docsQosPHSEntry 3 }=0A= =0A= docsQosPHSSize OBJECT-TYPE=0A= SYNTAX Integer32 (0..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression size specifies the=0A= number of bytes in the header to be suppressed=0A= and restored.=0A= =0A= The value of this object must match the number=0A= of bytes in the docsQosPHSField."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.4"=0A= ::=3D { docsQosPHSEntry 4 }=0A= =0A= docsQosPHSVerify OBJECT-TYPE=0A= SYNTAX TruthValue=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression verification value of=0A= 'true' the sender must verify docsQosPHSField=0A= is the same as what is contained in the packet=0A= to be suppressed."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.5"=0A= ::=3D { docsQosPHSEntry 5 }=0A= =0A= docsQosPHSIndex OBJECT-TYPE=0A= SYNTAX Integer32 (1..255)=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "Payload header suppression index uniquely=0A= references the PHS rule for a given service = flow."=0A= REFERENCE "SP-RFIv1.1-I09-020830, Appendix C.2.2.10.2"=0A= ::=3D { docsQosPHSEntry 6 }=0A= =0A= =0A= --=0A= -- docsQosCmtsMacToSrvFlowTable (CMTS Only)=0A= --=0A= docsQosCmtsMacToSrvFlowTable OBJECT-TYPE=0A= SYNTAX SEQUENCE OF DocsQosCmtsMacToSrvFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "This table provide for referencing the service = flows=0A= =0A= =0A= =0A= Expires September 2003 [Page 70]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= associated with a particular cable modem. This = allows=0A= for indexing into other docsQos tables that are=0A= indexed by docsQosServiceFlowId and ifIndex."=0A= ::=3D { docsQosMIBObjects 11 }=0A= =0A= docsQosCmtsMacToSrvFlowEntry OBJECT-TYPE=0A= SYNTAX DocsQosCmtsMacToSrvFlowEntry=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An entry is created by CMTS for each service = flow=0A= connected to this CMTS."=0A= INDEX {=0A= docsQosCmtsCmMac,=0A= docsQosCmtsServiceFlowId=0A= }=0A= ::=3D { docsQosCmtsMacToSrvFlowTable 1 }=0A= =0A= DocsQosCmtsMacToSrvFlowEntry ::=3D SEQUENCE {=0A= docsQosCmtsCmMac MacAddress,=0A= docsQosCmtsServiceFlowId Unsigned32,=0A= docsQosCmtsIfIndex InterfaceIndex=0A= }=0A= =0A= docsQosCmtsCmMac OBJECT-TYPE=0A= SYNTAX MacAddress=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "The MAC address for the referenced CM."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 1 }=0A= =0A= docsQosCmtsServiceFlowId OBJECT-TYPE=0A= SYNTAX Unsigned32 (1..4294967295)=0A= MAX-ACCESS not-accessible=0A= STATUS current=0A= DESCRIPTION "An index assigned to a service flow by CMTS."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 2 }=0A= =0A= docsQosCmtsIfIndex OBJECT-TYPE=0A= SYNTAX InterfaceIndex=0A= MAX-ACCESS read-only=0A= STATUS current=0A= DESCRIPTION "The ifIndex of ifType docsCableMacLayter(127)=0A= on the CMTS that is connected to the Cable = Modem."=0A= ::=3D { docsQosCmtsMacToSrvFlowEntry 3 }=0A= =0A= =0A= --=0A= -- Placeholder for notifications/traps.=0A= --=0A= docsQosNotification OBJECT IDENTIFIER ::=3D { docsQosMIB 2 }=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 71]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= --=0A= -- Conformance definitions=0A= --=0A= docsQosConformance OBJECT IDENTIFIER ::=3D { docsQosMIB 3 }=0A= docsQosGroups OBJECT IDENTIFIER ::=3D { docsQosConformance 1 = }=0A= docsQosCompliances OBJECT IDENTIFIER ::=3D { docsQosConformance 2 = }=0A= =0A= docsQosCompliance MODULE-COMPLIANCE=0A= STATUS current=0A= DESCRIPTION=0A= "The compliance statement for MCNS Cable Modems and=0A= Cable Modem Termination Systems that implement DOCSIS=0A= Service Flows."=0A= =0A= MODULE -- docsQosMIB=0A= MANDATORY-GROUPS { docsQosBaseGroup }=0A= =0A= GROUP docsQosCmtsGroup=0A= DESCRIPTION=0A= "This group is mandatory for only Cable Modem = Termination=0A= Systems (CMTS) and not implemented for Cable Modems."=0A= =0A= GROUP docsQosParamSetGroup=0A= DESCRIPTION=0A= "This group is mandatory for Cable Modem Termination=0A= Systems (CMTS) and Cable Modems. Cable modems only = implement=0A= objects in this group as read-only."=0A= =0A= GROUP docsQosSrvClassPolicyGroup=0A= DESCRIPTION=0A= "This group is optional for Cable Modem Termination=0A= Systems (CMTS) and Cable Modems. This group only needs = to=0A= be implement if policy based service flow = classification=0A= is implemented. See docsDevPolicyTable in=0A= DOCS-CABLE-DEVICE-MIB for more details. "=0A= =0A= GROUP docsQosServiceClassGroup=0A= DESCRIPTION=0A= "The docsQosServiceClassTable group of objects."=0A= =0A= OBJECT docsQosPktClassPkts=0A= DESCRIPTION=0A= "This object only needs to be implemented in entries=0A= that are classifying packets and not policing packets."=0A= =0A= OBJECT docsQosPktClassInetAddressType=0A= SYNTAX InetAddressType { ipv4(1) }=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 72]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= OBJECT docsQosPktClassInetSourceAddr=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetSourceMask=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestAddr=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosPktClassInetDestMask=0A= SYNTAX InetAddress (SIZE(4))=0A= DESCRIPTION=0A= "An implementation is only required to support IPv4=0A= address."=0A= =0A= OBJECT docsQosServiceClassStorageType=0A= SYNTAX StorageType { nonVolatile(3) }=0A= DESCRIPTION=0A= "An implementation is only required to support = nonvolatile=0A= storage."=0A= =0A= OBJECT docsQosServiceClassPolicyStorageType=0A= SYNTAX StorageType { nonVolatile(3) }=0A= DESCRIPTION=0A= "An implementation is only required to support = nonvolatile=0A= storage."=0A= =0A= ::=3D { docsQosCompliances 1 }=0A= =0A= docsQosBaseGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosPktClassDirection,=0A= docsQosPktClassPriority,=0A= docsQosPktClassIpTosLow,=0A= docsQosPktClassIpTosHigh,=0A= docsQosPktClassIpTosMask,=0A= docsQosPktClassIpProtocol,=0A= docsQosPktClassSourcePortStart,=0A= docsQosPktClassSourcePortEnd,=0A= docsQosPktClassDestPortStart,=0A= docsQosPktClassDestPortEnd,=0A= docsQosPktClassDestMacAddr,=0A= =0A= =0A= =0A= Expires September 2003 [Page 73]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosPktClassDestMacMask,=0A= docsQosPktClassSourceMacAddr,=0A= docsQosPktClassEnetProtocolType,=0A= docsQosPktClassEnetProtocol,=0A= docsQosPktClassUserPriLow,=0A= docsQosPktClassUserPriHigh,=0A= docsQosPktClassVlanId,=0A= docsQosPktClassStateActive,=0A= docsQosPktClassPkts,=0A= docsQosPktClassBitMap,=0A= docsQosPktClassInetAddressType,=0A= docsQosPktClassInetSourceAddr,=0A= docsQosPktClassInetSourceMask,=0A= docsQosPktClassInetDestAddr,=0A= docsQosPktClassInetDestMask,=0A= =0A= docsQosServiceFlowSID,=0A= docsQosServiceFlowDirection,=0A= docsQosServiceFlowPrimary,=0A= =0A= docsQosServiceFlowPkts, -- not sure if CM should implement=0A= docsQosServiceFlowOctets,=0A= docsQosServiceFlowTimeCreated,=0A= docsQosServiceFlowTimeActive,=0A= docsQosServiceFlowPHSUnknowns,=0A= docsQosServiceFlowPolicedDropPkts,=0A= docsQosServiceFlowPolicedDelayPkts,=0A= =0A= docsQosDSAReqs,=0A= docsQosDSARsps,=0A= docsQosDSAAcks,=0A= docsQosDSCReqs,=0A= docsQosDSCRsps,=0A= docsQosDSCAcks,=0A= docsQosDSDReqs,=0A= docsQosDSDRsps,=0A= docsQosDynamicAdds,=0A= docsQosDynamicAddFails,=0A= docsQosDynamicChanges,=0A= docsQosDynamicChangeFails,=0A= docsQosDynamicDeletes,=0A= docsQosDynamicDeleteFails,=0A= docsQosDCCReqs,=0A= docsQosDCCRsps,=0A= docsQosDCCAcks,=0A= docsQosDCCs,=0A= docsQosDCCFails,=0A= =0A= docsQosPHSField,=0A= docsQosPHSMask,=0A= docsQosPHSSize,=0A= =0A= =0A= =0A= Expires September 2003 [Page 74]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosPHSVerify,=0A= docsQosPHSIndex=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemented in both Cable Modems and=0A= Cable Modem Termination Systems."=0A= ::=3D { docsQosGroups 1 }=0A= =0A= docsQosParamSetGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosParamSetServiceClassName,=0A= docsQosParamSetPriority,=0A= docsQosParamSetMaxTrafficRate,=0A= docsQosParamSetMaxTrafficBurst,=0A= docsQosParamSetMinReservedRate,=0A= docsQosParamSetMinReservedPkt,=0A= docsQosParamSetActiveTimeout,=0A= docsQosParamSetAdmittedTimeout,=0A= docsQosParamSetMaxConcatBurst,=0A= docsQosParamSetSchedulingType,=0A= docsQosParamSetNomPollInterval,=0A= docsQosParamSetTolPollJitter,=0A= docsQosParamSetUnsolicitGrantSize,=0A= docsQosParamSetNomGrantInterval,=0A= docsQosParamSetTolGrantJitter,=0A= docsQosParamSetGrantsPerInterval,=0A= docsQosParamSetTosAndMask,=0A= docsQosParamSetTosOrMask,=0A= docsQosParamSetMaxLatency,=0A= docsQosParamSetRequestPolicyOct,=0A= docsQosParamSetBitMap=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemenented in both Cable Modems and=0A= Cable Modem Termination Systems for QOS parameter sets."=0A= ::=3D { docsQosGroups 2 }=0A= =0A= =0A= docsQosCmtsGroup OBJECT-GROUP=0A= OBJECTS {=0A= =0A= docsQosUpstreamFragments,=0A= docsQosUpstreamFragDiscards,=0A= docsQosUpstreamConcatBursts,=0A= =0A= docsQosServiceFlowLogIfIndex,=0A= docsQosServiceFlowLogSFID,=0A= docsQosServiceFlowLogCmMac,=0A= docsQosServiceFlowLogPkts,=0A= =0A= =0A= =0A= Expires September 2003 [Page 75]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosServiceFlowLogOctets,=0A= docsQosServiceFlowLogTimeDeleted,=0A= docsQosServiceFlowLogTimeCreated,=0A= docsQosServiceFlowLogTimeActive,=0A= docsQosServiceFlowLogDirection,=0A= docsQosServiceFlowLogPrimary,=0A= docsQosServiceFlowLogServiceClassName,=0A= docsQosServiceFlowLogPolicedDropPkts,=0A= docsQosServiceFlowLogPolicedDelayPkts,=0A= docsQosServiceFlowLogControl,=0A= =0A= docsQosCmtsIfIndex -- docsQosCmtsMacToSrvFlowTable = required=0A= =0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Mandatory group of objects implemented only in the CMTS."=0A= ::=3D { docsQosGroups 3 }=0A= =0A= docsQosSrvClassPolicyGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosServiceClassPolicyName,=0A= docsQosServiceClassPolicyRulePriority,=0A= docsQosServiceClassPolicyStatus,=0A= docsQosServiceClassPolicyStorageType=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "Group of objects implemented in both Cable Modems and=0A= Cable Modem Termination Systems when supporting policy = based=0A= service flows."=0A= ::=3D { docsQosGroups 4 }=0A= =0A= docsQosServiceClassGroup OBJECT-GROUP=0A= OBJECTS {=0A= docsQosServiceClassStatus,=0A= docsQosServiceClassPriority,=0A= docsQosServiceClassMaxTrafficRate,=0A= docsQosServiceClassMaxTrafficBurst,=0A= docsQosServiceClassMinReservedRate,=0A= docsQosServiceClassMinReservedPkt,=0A= docsQosServiceClassMaxConcatBurst,=0A= docsQosServiceClassNomPollInterval,=0A= docsQosServiceClassTolPollJitter,=0A= docsQosServiceClassUnsolicitGrantSize,=0A= docsQosServiceClassNomGrantInterval,=0A= docsQosServiceClassTolGrantJitter,=0A= docsQosServiceClassGrantsPerInterval,=0A= docsQosServiceClassMaxLatency,=0A= docsQosServiceClassActiveTimeout,=0A= docsQosServiceClassAdmittedTimeout,=0A= =0A= =0A= =0A= Expires September 2003 [Page 76]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosServiceClassSchedulingType,=0A= docsQosServiceClassRequestPolicy,=0A= docsQosServiceClassTosAndMask,=0A= docsQosServiceClassTosOrMask,=0A= docsQosServiceClassDirection,=0A= docsQosServiceClassStorageType=0A= }=0A= STATUS current=0A= DESCRIPTION=0A= "The docsQosServiceClassTable objects. If a CMTS implements=0A= expansion of Service Class Names in a QOS Parameter Set,=0A= this group is mandatory on the CMTS. If the CMTS does not=0A= support Service Class Names, this group may be = unimplemented=0A= in the CMTS. This group is not implemented on the CM.=0A= "=0A= ::=3D { docsQosGroups 5 }=0A= =0A= END=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 77]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 5. Security Considerations=0A= =0A= =0A= This MIB relates to a agent which will provide metropolitan = public=0A= internet access. As such, improper manipulation of the objects=0A= represented by this MIB may result in denial of service to a = large=0A= number of end-users [9]. Manipulation of the=0A= docsQosServiceClassTable and docsQosServiceClassPolicyTable may = allow=0A= an end-user to increase their service levels, or affect other = end-=0A= users in either a positive or negative manner. In addition,=0A= manipulation of docsQosServiceFlowLogControl could allow an = attacker=0A= to remove logs of packet and byte counts forwarded on a service = flow.=0A= If such logs were used for billing, the attacker would obtain = free=0A= service.=0A= =0A= There are a number of management objects defined in this MIB = module=0A= with a MAX-ACCESS clause of read-write and/or read-create. Such=0A= objects may be considered sensitive or vulnerable in some network=0A= environments. The support for SET operations in a non-secure=0A= environment without proper protection can have a negative effect = on=0A= network operations. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o The docsQosServiceClassTable provides a template of QOS=0A= parameters such as maximum rate limits for a named service=0A= class. Changing these parameters would allow an attacker = to=0A= obtain unauthorized class of service.=0A= =0A= o The docsQosServiceClassPolicyTable applies CMTS vendor=0A= proprietary policies for packet forwarding, including=0A= dropping, scheduling, notification, or other policies.=0A= Changing this table could allow an attacker to deny = service=0A= to all subscribers of the CMTS or grant the attacker=0A= unauthorized forwarding policies.=0A= =0A= o The docsQosServiceFlowLogControl object controls the = deletion=0A= of entries in the docsQosServiceFlowLogTable, which acts as = a=0A= historical "detail record" of DOCSIS service flow packets = and=0A= bytes transmitted. Such records may be used for billing=0A= purposes, so the unauthorized deletion of the records can=0A= result in free service.=0A= =0A= Some of the readable objects in this MIB module (i.e., objects with = a=0A= MAX-ACCESS other than not-accessible) may be considered sensitive = or=0A= vulnerable in some network environments. It is thus important to=0A= control even GET access to these objects and possibly to even = encrypt=0A= the values of these objects when sending them over the network = via=0A= SNMP. These are the tables and objects and their=0A= sensitivity/vulnerability:=0A= =0A= o Unauthorized SNMP GET access of the docsQosPktClassTable = or=0A= =0A= =0A= =0A= Expires September 2003 [Page 78]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= docsQosPHSTable can allow an attacker to learn IP = addresses=0A= permitted to have enhanced quality of service, for = possible=0A= spoofing. This table typically contains the IP addresses=0A= involved in voice-over-IP sessions, for example.=0A= =0A= o Unauthorized SNMP GET access of the docsQosParamSetTable=0A= allows an attacker to learn the names of service classes=0A= which are permitted to have enhanced QOS service, and the=0A= values of that enhanced service. That name can be = referenced=0A= in an unauthorized DOCSIS cable modem configuration file = to=0A= obtain enhanced service.=0A= =0A= o Unauthorized SNMP GET access of the = docsQosServiceFlowTable=0A= can tell an attacker when service flows are active, e.g.=0A= when a voice-over-IP call is in progress.=0A= =0A= o Unauthorized SNMP GET access of the=0A= docsQosServiceFlowStatsTable, docsQosUpstreamStatsTable,=0A= docsQosDynamicServiceStatsTable, = docsQosServiceFlogLogTable,=0A= and docsQosCmtsMacToSrvFlowTable can tell an attacker the=0A= volume of traffic to and from any service flow in the = system,=0A= resulting in loss of privacy of the amount and direction = of=0A= data transfer.=0A= =0A= SNMP versions prior to SNMPv3 did not include adequate security.=0A= Even if the network itself is secure (for example by using = IPSec),=0A= even then, there is no control as to who on the secure network is=0A= allowed to access and GET/SET (read/change/create/delete) the = objects=0A= in this MIB module. It is RECOMMENDED that implementers consider = the=0A= security features as provided by the SNMPv3 framework (see [13],=0A= section 8), including full support for the SNMPv3 cryptographic=0A= mechanisms (for authentication and privacy). Further, deployment = of=0A= SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is=0A= RECOMMENDED to deploy SNMPv3 and to enable cryptographic = security.=0A= It is then a customer/operator responsibility to ensure that the = SNMP=0A= entity giving access to an instance of this MIB module, is = properly=0A= configured to give access to the objects only to those principals=0A= (users) that have legitimate rights to indeed GET or SET=0A= (change/create/delete) them.=0A= =0A= =0A= =0A= 6. Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= intellectual property or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described = in=0A= this document or the extent to which any license under such = rights=0A= might or might not be available; neither does it represent that = it=0A= has made any effort to identify any such rights. Information on = the=0A= IETF's procedures with respect to rights in standards-track and=0A= =0A= =0A= =0A= Expires September 2003 [Page 79]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= standards-related documentation can be found in BCP-11. Copies = of=0A= claims of rights made available for publication and any assurances = of=0A= licenses to be made available, or the result of an attempt made = to=0A= obtain a general license or permission for the use of such=0A= proprietary rights by implementers or users of this specification = can=0A= be obtained from the IETF Secretariat.=0A= =0A= The IETF invites any interested party to bring to its attention = any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights which may cover technology that may be required to = practice=0A= this standard. Please address the information to the IETF = Executive=0A= Director.=0A= =0A= =0A= =0A= 7. Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= 8. Normative References=0A= =0A= [1] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure = of=0A= Management Information for Version 2 (SMIv2)", STD 58,=0A= RFC 2578, April 1999.=0A= =0A= [2] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual=0A= Conventions for SMIv2", STD 58, RFC 2579, April 1999.=0A= =0A= [3] McCloghrie, K., Perkins, D. and J. Schoenwaelder, = "Conformance=0A= Statements for SMIv2", STD 58, RFC 2580, April 1999.=0A= =0A= [4] "Data-Over-Cable Service Interface Specifications:=0A= Radio Frequency Interface Specification = SP-RFIv1.1-I09-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= [5] L. Steinberg, "Techniques for Managing Asynchronously = Generated=0A= Alerts", RFC 1224, May 1991.=0A= =0A= [6] "Data-Over-Cable Service Interface Specifications: Operations=0A= Support System Interface Specification = SP-OSSIv1.1-I06-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= [7] Bradner, S., "Key words for use in RFCs to Indicate = Requirement=0A= Levels", RFC2119, March 1997.=0A= =0A= [8] "Data-Over-Cable Service Interface Specifications: Baseline=0A= Privacy Plus Interface Specification SP-BPI+-I07-020830",=0A= DOCSIS, August 2002, http://www.cablemodem.com/.=0A= =0A= =0A= =0A= Expires September 2003 [Page 80]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= [9] St. Johns, M., "Cable Device Management Information Base for=0A= DOCSIS compliant Cable Modems and Cable Modem Termination=0A= Systems", RFC 2669, August 1999.=0A= =0A= [10] St. Johns, M., "Radio Frequency (RF) Interface Management=0A= Information Base for MCNS/DOCSIS compliant RF interfaces",=0A= RFC 2670, August 1999.=0A= =0A= [11] Daniele, M. et. al.,"Textual Conventions for Internet = Network=0A= Addresses", RFC 2851, June 2000.=0A= =0A= [12] "Data-Over-Cable Service Interface Specifications:=0A= Radio Frequency Interface Specification = SP-RFIv2.0-I03-021218",=0A= DOCSIS, December 2002, http://www.cablemodem.com/.=0A= =0A= =0A= =0A= 9. Informative References=0A= =0A= [13] Case, J., Mundy, R., Partain, D. and B. Stewart,=0A= "Introduction and Applicability Statements for Internet-=0A= Standard Management Framework", RFC 3410, December 2002.=0A= =0A= =0A= =0A= 10. Author's Address=0A= =0A= Michael Patrick=0A= Motorola Broadband Communications Sector=0A= 20 Cabot Blvd., MS M2-330=0A= Mansfield, MA 02048=0A= Phone: (508) 851-8402=0A= Email: michael.patrick@motorola.com=0A= =0A= William Murwin=0A= Motorola Broadband Communications Sector=0A= 20 Cabot Blvd., MS M2-330=0A= Mansfield, MA 02048=0A= Phone: (508) 851-8385=0A= Email: w.murwin@motorola.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 81]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= INTERNET-DRAFT March 2003=0A= =0A= =0A= =0A= 11. Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2003). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished = to=0A= others, and derivative works that comment on or otherwise explain = it=0A= or assist in its implementation may be prepared, copied, = published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph = are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by = removing=0A= the copyright notice or references to the Internet Society or = other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other = than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not = be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on = an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET = ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, = INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Expires September 2003 [Page 82]=0A= =0A= =0A= =0A= =0A= ------_=_NextPart_000_01C2E01B.08ABBAEA-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Sun Mar 2 09:14:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11462 for ; Sun, 2 Mar 2003 09:14:52 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h22EOOj07599 for ipcdn-archive@odin.ietf.org; Sun, 2 Mar 2003 09:24:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22ENKp07538; Sun, 2 Mar 2003 09:23:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h22EMdp07513 for ; Sun, 2 Mar 2003 09:22:39 -0500 Received: from SCBH02.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11421; Sun, 2 Mar 2003 09:12:22 -0500 (EST) Received: by SCBH02.terayon.com with Internet Mail Service (5.5.2653.19) id ; Sun, 2 Mar 2003 06:13:46 -0800 Message-ID: From: "Raftus, David" To: "'internet-drafts@ietf.org'" , "Natalia Syracuse (Ietf) (E-mail)" Cc: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" , "Rich Woundy (Work) (E-mail)" Date: Sun, 2 Mar 2003 06:14:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2E0C5.FFFA2D40" Subject: [ipcdn] draft-ietf-ipcdn-docs-rfmibv6 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_01C2E0C5.FFFA2D40 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E0C5.FFFA2D40" ------_=_NextPart_001_01C2E0C5.FFFA2D40 Content-Type: text/plain; charset="iso-8859-1" Hi, Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 to v6. The draft has been updated to incorporate editorial suggestions from the Feb 13 IPCDN WG meeting, and is intended for last call submission. Thanks, Dave ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@terayon.com 613.592.1052 ext 222 ************************************ ------_=_NextPart_001_01C2E0C5.FFFA2D40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

=

Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 to v6. The = draft has been updated to incorporate editorial suggestions from the Feb 13 IPCDN = WG meeting, and is intended for last call = submission.

 

=

Thanks,<= /span>

Dave

 

=

************************************

David = Raftus

Terayon Canada = Ltd

340 Terry Fox Drive, Suite = 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com           =

613.592.1052  ext 222

************************************             &= nbsp; 

 

 

------_=_NextPart_001_01C2E0C5.FFFA2D40-- ------_=_NextPart_000_01C2E0C5.FFFA2D40 Content-Type: application/octet-stream; name="draft-ietf-ipcdn-docs-rfmibv6.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-ietf-ipcdn-docs-rfmibv6.zip" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 UEsDBBQAAAAIABBIYi4r5i1Y1jQBAABQCAAhAAAAZHJhZnQtaWV0Zi1pcGNkbi1kb2NzLXJmbWli djYuZG9j7FxLjCTJWa6dtd1azGAb4UWyDQQNiG5NV01X9XNWLHJP9fRu46np3q6eXaNlJLIyo6pi Jx/lfHR3rebgM+KABVoLsReEEWfuCIvHHa7AxZgjFuIIFw//IyIysiqrX7vIHEipJ7MyM77444// HZHzj//wpR/86V9+5V8bM8dvNl5t/Pjla43POfdeg79f+Yz+8cVG49fg+hW4/PHLly/x1lfg91fh 72vw9wvw94vw90vwJ+Dvl+FvGf5e/v/xf+r40Z//TaMnXoOZ+c+f/b6dWTjgzn//3auNn2kMPhh8 8MM3f/hmY+547TOvN9r5Zxvffq9Bf/H3X6X7vzf/Kh0vX37hymtzhPTvj7S04dm9XnT+OQeh8Vk+ ffMLd+bOu3D+Azjj+9+D88efK9///e/eaXwRXn38Or+P5xU45/r37Pno5+vPnwccvLr7Xf59nfOv wvnjP77TEHDrr/7kTuOf4Xcb7n+5MX+YcZv+Zo9FdJlzW/f7pYDPs/w04zMH/v4XOB9Au9eddrNn xD/92jzO7O/Pf7eKb9rf9HD5jQfifLRU4v3F8zuNv4bLf//OncZ/vTI/ztseyUdVOfg6nH8azuLj 3/3y3//gb19BefrmT92xcvdnG3ca/9FsNP7tD1n+XJyP4fw7QP96g+UPj6/+EfARLj/6mH9/x7vT +Lbz2/Rv+abl15yv0pc7jX+Cfw+Pu/tPxHtJ+lzFI/FWmhSTpf2WOPGGeZEtLR3GuUxjmYv9FO4s ncrUmyax6HqxF3jicR60lpb2E7+IZJy/IQJ8qalkPmyqiR/EzSDxs2Y6jNTgrNNc317qeak/Fp31 9Y2lpSWxtPToYqJSmb0h+nKSy2ggU/PwaJAloczx2clBt7O9sw437969K/g48QKViINUfquQsT8V KycHq4KIHXq+FD2gbySRKLg5TNLIyxWQ/dDLpEFwD3hD7B91+4d90WmtCz+JJqHyoPHJgVAGNLt7 t597wBWRDEU+VpnoySghik7xV6DZIODai4XhXJM4B3cCfKBiMSzCELpgsmIg9lzlYyEQx4MnkzQ5 UxlQS/30pU+Ut9fxF3JivbPdok6rHUCfKUDpeTS0aFqlfVk8ikcqljKFt4hyL3suDpIUyFg5fHR6 sLomFGN52RoTDT8N7AjFI2sJ8STJJeB6OWIk0EGqn4nIm8IwskQEKstTNSjyOqq8rCQfIXgIi8dF guW0P/NCFdC0edDjhYqKCEeaqQtEiJI4H2dEPZIzkKKYBF4ugzWRykkIcwlX0DbRMhaIwZRHga0d KnHapiJXkYQxH+Y8gd4EpmiSKg9ZkIiCRWqO6gz6GspU4gyD+AHHvRA7hSa+Iu7JSLMOGBnT9Gdi GXmFUgJ9jEAzstayljApQuAojtIv0pQlu9qlD1IHY/V8kNUMBsWzM87zyRv375+fn7dQMVtJOrqP F/fbKmh6A5gkzwfW5xf5XEczItwfe0FyLvZBY/08SZW8SZcZNW6N8yiEae4mk2mqRuMcJUn5krou b650V4kQK7X9xAckUHO0DqstsQeKcoKvZuJEZjI9kwGg7unRlDoZgYaSPmoJSiXrllGLLAch8dIg E9jwOSpYE21NCxGOQ1ACeEdKsWz08IHowmSNYOjDNImMaVrWohjIzE/VJNc9sCwGaqh8sj+gOVVL AY1QvbKC+Ae/zhUMzIilpQZxzscyJj6DnQxaMyMM5BCUGoc5SdLcGd8ldlCs9A4frt7V1g+kmO0Q cJtEMCpbgijmiZ+EZL0qxgQMZVTEKp+2WAXExIPu/SL0UrQjDl0DL1M+sJLkirEDGOgHwNaMCOg/ 6R2TKYA3ZeB2Dw20bXbsco35x8alsZ5lEQkBjCQo/NwaRfJ9FeNGTOBhulrtmk3HZrZQaCNtLMBM wbwpVO6AbE82ToowoDGBigRByjoCBgA7r3T762g4VYi/SfnA8pAD/brRHzIPcXAfDQg09op8nKQZ aVJ8Bv2TvygQnoh3hMxq9XM5xU5B1pd7T/uny2t8Fk+O6Prk0TtPD08e7eN1/+29x4/thX4DceDG 0dPH+h28Klt3j3q9R0/2CQCQ9357mf3H8tHx6eHRk73Hy0gaglTII74BS4BFNHmTlAwymEJWpgEP 6WH3WLQ3mQhQC9Fptx+I91H94OIZ8OHuqTcIJc4scCTHGaGBt2noKFyuLhykXiRJzFtXHWIDYTri rTDJMi+dXt2i9tAwrbbo7p2+e0uQEqZDZiiW4e2QDMyG6PZuTQvAbDLMJsCc9m8/KA2zBVMX4LQE t4IyMNti38s9cQz2HBT36nYzh4HZEcHD6BPMlIbZNcbr6iZ1h4F5IPaT8xjcm/SiW0AZGAgj35Ze 0JTxrXgstjRMW/T2urdnsYHpiF73ya0Fx8JsiJ6KVTMLk1sQU8JsineO+9/4xNRsiXf2bq9VFmYb k4+r319wWJgd0Z9GgyRsYhSb3RTQwuyKp5NbS5+G2RBHZxCqKXl+W2VgGDCi/TwFP16k0gY6hw+v DSq2NQwAYYJ6OMR46EgHI1e310cJ09Ew3ejGIM6gwBobmDy7OTU7DNOBgDjkaHOsJibYsJlxdgWn LAzw5rE35YCnB2b5Zp6mhOmId1WaF5D7dFXqF+pGzBEPDMyGUMNTmeXs5a9uWTlKmE2AOfHP9jgY uyFYCbMFMI/i/HbRgAMDTDZAVIIoTXwZyC7qogJzLSCFdRscMc5nhK3pOJVpBFktJQb9aZbL6PpT VCWic2MiuCfRbpcwVRBrda5mCMBsODDAkiuRPn2OzNBw9WDq+IEwWyXMRj2IzxHgZaSJ9rYDMyMk FqhrgP432LEtSgo2K/2T2YYogszMFYCivYswm2IfM0rF6c7lTeoO0aFcekvs+c/j5DyUwYiTt6ub OgeIK8GAhzblhP0y8b8BbxhmRzzhxPwMMn5TMrqBCmqY3TLDvw0QwJDkPsCSY5FCTo+JVKYCmXo3 GJaBgUCzrlByA94wTBupGEJWnWOhJwkLkkKqVLCzfHSRL3Zp0J70CAJN9IBhCD4VXdFxmkxkml/b fBuYDbFHiTek69qF3MjTt1kdIdA8wBpwWe/CujJnplejMAwc7ValRtbs61pWbaJLyfCBLlLlngqx /GKiMR1DlYVPrOza/JuemZojwlyvxzUx4foZlUExEMl0DW2HULicLTY2QVQwkceLZ1y16c3Uh7BE YEuMZ8qDQZzpoEI5Va0sT1LJJQIgMMJSyxUlMOAHyE5LkAS5vSHGSMYg+2E4LfvOx2lSjMaE21cR DFA80fUyp5tjXS9DkBUsPazysExMp6to2CfVtqlIFogiw1gLn0QSbbvKosw+1G0QphL7LhjdSr93 uNpy61/ZRPpqqKgYRzyG3qMkKEKu42N9rCyv6agRQM46a+J8rPwxvlCpyBApp/tia3eNKzJbO7tc kYGLZ2uzzx6YZw+eUVnIPEYYfmV3Xb+yS3JwtwP0m6qLLWLhxGZzNS7NxxQsXyCkoqI6mZ0YORIK H70aQmTkvoDVwDRaAqC3qsLvZVniY3U/YDuDT6migNkLgrCP7KPy+E5oLfrMYq71Yq0RpaaFA2lj oXDv9F0WA9B5cKcoWMtdU0AVe1i0ij1wtqF2KstrQP45F/VgQqwaefEUYXyud6ViPB2kuBiicPUM WctP7FC5OUTwwJ0UFCeQIA1qBBRkpCqA6BZygVzkvA4KiOI9Iz0+8MuUXGEAiR4qscmLMWEFrVNF tGbFDZdWiFpdrjpXAbwL8/c22N8PxYo/9UOQSbDGaB6SOFilIQymwpfI2LJDKjG/Z6uz4mnfTASH JGuimIuMUCysGmN7TTSQZSd+q7nZ6b39oUjRW6GshygM52hO5sBmzEIN2HpzZ2u9hAvkRMYB6nVi a8q+N/EGKoQgRtrluRHMTaynrKUlfToBUQrFIE28wPey3FCCGJaNmhOgC9vQKzSdDQ/51cxd4jwD hWpZh/CoQGcIs+eKTS03sR3NTFJgEEfuB1GKCU4fxFJkkWbbOYJiIMBkShhuZ0sgp0AAt8m9wg8u GeOgwuTcAQ3KXGIRLCIY5M0dQkas3Z0WddO6nKmWowjDLEGm7tqWHkcOEw/9GwgmCxeuxiUQZaUx OTjmHULAxIfJFCcewTTjc7DrcRImI1azDVSznjUoFHS3tMLBfc/nZURPLGehdyaXcbWK9A3m3Ztf E+H5C8BSlZaO+tmkfk771Z5qwnrTOYk4KDsaW+jgjKsAnu4Brc2ILA//BpeIiopEYfOxri+2aBTQ qxkHeTZgOar6ZQMpjRuOpVQKXn9FlCQG7TMY5L1yULcsUjnz3gqLWcHGScpTXMHC5pk/luD4SCtL eSVbyDAZL7+DqKuqP+j22J5v0cIP16o1z0COcOkRWJXlwDqt16Bg5xggPUpT4Fc3SVMdAyENkSTr THZpAFymFtqGeiLEtIhnpI8rkOiCmuiCmtfyP7hvAhfJSM2t0V7krPrHzZMDcPat9ebhUae53lnf bu8sQ1Mc7TaM1impW1888aYhqNHcmqOtDBOvdqA1VtI1nyKICXXsAkNlPyTOkjAHjyw8FIG8CCQG HQkEaBOyAuARQUOVVqyc5JYX7Sk0rXIewjIZ4L4KFMAPZQqu76Hph+AQBQQJWKLOvFByuLO529rZ 4oq/ftfSwlIKT4/GkatWu8gWkl0a2rKNEa4XICy3kB04GGxN3p3UzFTsTp82T8VvQerRgdgglhfi oV2tJmPOKhKZTF3bHvH+zjOi7gFSZxXBzlmgjARan2UUFno+56Vw1JFiwLFeygHMOsCZlQMLlnAk w+FOonDrSwwUZXnVl9jFdovJUQiRzYEId4JhUik9WmC0eTjef8ovYXCCqwbM9F4RYmEbFYa5buJx tmjI5LeswzabP5BMCgF1cMJdMDwaZbuaQH0cxsbnoznh2s0Z7uUY0s6QMjwu4wGWTGxMFpBCLHbx YNe59gFGC65xsrXpIjGLS/dpZ6r1kzQBa2wC2uhDaHUEToUXpB4lIMdjzKL6YzXMxTckujvjQsqN AJxleK7VS+JKtNii0b2/zYLbRuOKKyiVnvasNvYs3HX7cjoST7OCREFeTHg5HiE4fhVxQRvQFARs yBOdjGXqQ7vK4MCDR8mwokC/EGRFtkZU7wLaV+2QKMnATUS802eQJM+RpAAUJ8fEhONuPV8Ig94W KeYNJeQUcSsI0Bt6WtX09jPmFhrnkwPixMymCH6O5tddAbrUXSGnZjn4ExU/GsKuE9ZeZsgc++Ka MhuQQE6J2m0WoTSU4iUR2nYXUHqsd6mYegCSDp0FtmhZ2ZuCIGiO7s/FY26stdLtcWKzIAAjHnPC toImY7W681CnBFmFY5SQc8qreOcNolhuuJEqdFxu4qlk8bOTypN9rXmtm1Rqfo15beFUoLmvW8ir TgycMvNSwHFkCtLI2w3foHcTIYRbCXGLQljng2iBvfwAtLBabjcTgzB0XB4hZ2Z6VuYWDnWR59q0 VMjAiNaSsDKzmvgJkGdljA4zFAqjV+bWHHV3tDiWmf1Q0gMfx1OUGebrHVN2F1cRk0KSfW0KNIeI A0Y8xAJHMjSCtWY3r1StECSd6P0p8HWUbA1RZO6joUvOM+GDHaAtQkWe4PB96pDNrw4JA0kC7Pk+ BOgcVCEIWQOwC+eYuuEOXDUquLq9yvtWQU/K9J724o0h8cI9pupCCyniVJryVi+9MVizotxEFhmq yeNjvxAAc47Dm57MaDTljm0xCU6liAHWCLfV+jlVdeaJWUnR2jHoqqFHaxvq25zY0lzz3TJc1PPD 66NN1sWcUzJtPNi0wtyB/WGE2QQ90y6Mc0Cd1YPNlmSx5t8n46VbtByqjOW/OU3zFYwaikxh277s 5oDEXy2rdbS9k2THaTJUobySLN6xXCqDa2gnjJFZDzOf/jqd9ilk1kg1/arMFv2iJFZ5kpaZFqJ8 S9Mwo3yooHZ6yrDckQ4/UxlKTtcUsKbC9MyC5natoyhpAuGxGoHpyHUuV+7pBM9DK2imuqBVFzcW Z8UEU0stvR0rvdYwOtR1o57nX48ZyGDdOZgbhLCOVpdPaU+zr1e/0NKA/bvIZUyE6vxMr2S2KjTw 9wE1ZEQe9AF/WRlmAgvYapBtN2sP2D+W19Btz2R5tHsY6OGtrBhnwPzh09w4biyEAGko32vOXpIK XaacX1KUqUhB7My2xHRtogjSFc7tgGAMm2ZGzCJ8pfhb9cq4AQuiLDDgOvOgf2xC9AMAKJm4bKx6 oIgxO1ZND82NGWqVEk2A7p2sjg2Z3HGagAR70CK44YigdZcVduSZI4b7VbuU688hSNPInxJzZ2Ww NQO4UKbmI1ZvNErlCN1JZTKZC2kShk1w12CIiOsgafKsXO1LfLCETpW6iEH2Q6pgQlzdnN1YvUC6 FirfOAkDN2IhcR0kRS5wIR78lmrJFhXNoUf8TGOksFKIH2robc8T3LufFBn4QAhcINhZpbUjV0E0 +WbpQ8+09q0kVzSVVfYuFOCSv7T8pxWf56qMvFLcbcVjnJVxLWKzPZYJbE2nWEPAGIfrlZwN6l6d zKziMMC4l2sUc2tXC4aNYpp0o8UUDLE4rkcOk2/H7k48t+YFWYzc9B53sWJVZ3WxXGt//jQHT/Lh InbYOaBgKKNgD2Go7sglHPKS5Jzz3MPKbjkPKONOoDEZTzMDYDg2SxXGQJqyLuvPDaiaJ6UmLAKB dj4g8pC7E1ADbIajIt2jgQGoryd8jsynk0+RyLk46bYk3t0gL331BsQywzN7AnzwQLw8zWGig5CY r+0gGSzlsArIK8e72xvPsPJyhrEyf8PGKzSpAeStBOZTDNZl6nGYoNhra6eJMmk3LfRHvByp9Gdd qQwWE2OXpQEcEhBetiWDShVc6lBH9KQftpCQU3ZFhLeYmxizV/dhcgEH65AI5lPibLZVyQuYaLYK 5GDANNTtwlvDNxDGvDS/MW2tBLEPw2REi2cme9Nps9ubzd9aPMMYJ4F78J+zgNpZEvTlycDlLUeN AVyqIeXCrhCAZYPwrd4VnVamT154tC8DkrcC6PZycpDG0zqhHtnHJJ7NXmh+zh1jPtvdJccL8Rtv vonDMB9REStso3vNuUM0mzV3K8c92/5Fbaea6wuPF27/NZ0t7F8/uOcOuoaEeqqE7tig8/kePbjn 3tL3ah8gwAtHgtu6sxdlPbBdIcB50MFfDOAeL5x/q/dqH7hDcMm959685w5h5sFCiXF7qvRaeVDX nHrgfyrXix7UYbzADR7NNl3xdYfvLnhQi7Gyd/90v7e3iq+u9Jtdfb3owcKxNB2Sm+5Y5h/wB+B7 9sPTDFf7dfwOplkr/xpZWK0YpcbDC6SQYGo4AM2TiYnyZyxAjfaXWxMcg8kepLYDgw6EWgv6uGpB 0cHcZf9RQz/EcpCFm08gIZ+WFyZ49/HDQvqqMNOmT1dC1fCQ3uNDDU+nE1nDduFuWDVWDSeaQgyq H0KASGNZaXd2Vp2G9Pma3barm25UmpYKC413y8bUtM4faZTNCophGmA8mCNg3mFpjK1PAWO7FkPP 2UpnfWt1HsNsl2KEnU+MsPuJER58AgQjEuhaKXrKJglvY9LuXIBU0gfg5ySJOX6cPJBvVBzkC3HI L7+NpZ+Ut3m/MAiPcSle36v3MOt1NzvlvfpW5QvOzY3y3g1abZb3btBqq7xX36qEdW5ul/du0Gqn vFffqiTGublb3rtBqwflvfpWJZNrJ3FBq3LgN2lVDvwmrcqB36RVOfAFrbAZakrmRdLxBhF9NYWO iv4/jIG032fjHs/JOMFV4RR/+FTIP5F5kZpNgBntDpngmgO9UH0qVtw1HnAC5zKEeJyqWZcvYK1q jY2TnNc2jKdbEwNI8cw6lJu3Ep7Nl8vlI12eRatA62oVOnVuwI3nC/HIFfwvB8jP0d4n5hYG5UlB yyPuf5ygA323g6czmCvZKiV38CsIy/UUJ5FFCMjOwJFnBWQrwLXj42PaAk68wkc66cIkdvartTJl 5b0EwCIwf8hGzQe7Jd0337lxvKBop6CHwQG8jShAU6iYM5RCcm6r+8Yao/OpmxUu9/M3LLhPeKlN f2mFpXlIcu5TnmNzKk6faGYRRml6zfosLiepeBjiGm7JMdwDoAaamk2iZuaLOYem2W/pLqeMiKgh 7jaUbbXs513z1YTAbuamNU4K8NTQfhFjC756aZ9eRZBy17Jy/qcLm9i3/oe98wCMrKgb+EuCNDlQ EAQReAJKTpJc+hWl5JLcEbhcQpKjF/eyL8nCZjfsbu4uSFOKIIpIly5FepGiVEGQ6gcoIEoX6V3p IML3m5nX39uSa3s59n3fD+9l35s3M///zPyn/UcthJDjpaKfLwfok/HRYeGrZziWMQdenTXl7l1B 8w3MNDvydU70zYwK2Sznyug8T1pKmLaHKAfMZU+uXQHSuZNtxcYG1DIr9dfkgC+9ZmmpMXNWaHFC p2iOmLWEe9LEmXaQoQsvRnLESGapmhm1B6OrpY36Xf5Xzq+mVGkW6/S8n1JDTlZ9FPIx+1NmpMI+ 1DWasb4kQnF/zBFEQaLQg3vjgpVr2rTBVVlwLstHiPh1G8+lB/6S81LBu018cbWbgy8qfmHRV8NW YsWTHGlxt3PONX9M5rt7XivYgRDa2NEyt0X1RHS5NDvc7LdC6B0xKE/OZdbfQohp+ZM1vhccK60J j2ifLLkiFN5W8YiZ44aRhfp89MJeHj+fenhKOjwY67vOCLWtfzJyctGUnjJbjuA1LJYeUpMbrn0i ztye+LLa1iDDkUlRGSLMYXemLM8MyZISYzCicqqwTAkPReRUgZkSHoCVUyqbuofG0tYmO3HZhoVu DI9kxPrvlL3eMDbQEqUsmu7ZxCWyJCL+JryQReSWSGuNRiCFZhBdRMwVgur8mKsDxHbBiNmu5Qun MzPqSZY0DV2LCOOR1KCYCR8Q67PMyTk1nJElW2QEEr6vVXkbq2R/xhALPUJDEDEw1SLRHx+NmqPs cSMxmLFW9cg+vVgqZy06F/VMlwzVCqbHXX3KJ3ZotZ6xX5kndlV0759J53jFfsZ+Sy7jtd8Mf8vz jP3mTGsnR443Pc/Yb7bF0v1ykWAwptYjctl+ePrt9CbkBKbc85cOe4Q2yJONQhiZpFj86ZQLJT17 KXDGHEAaUkveRSK8oQRKpyVWIcQR2aynfd2C4CUngsyHzY0SObUjPBSvyhBNjwL0eYr/vISUnx3D 3Ol1BbTU0+uKr1etnM97VTJwhX/DVZc7ybZDCkt4eDiB4p61ZOfPjWwJ95YK3U64t0SNI53OpqoV Kp2ech5a+kYz87Eao3aYsk4Oj8hCsSglqkI0ojV6dzKdjgmzi2Y6Lcx8+nozwl+dPyp6IMIrXEps dnHF0FPNeIuMJ0rmuK/oKmVrLNxFKjoqO5iGDN1uVumcEP3R5KhYiGBYkhyIxNOGyyiuXwyjuGT+ Fsv8XdFtX7N2WR6Gb2hWOAbuCpQdJQPXvOxVp85EXjHN3BwGmh1Tn7XiDSKrteJuoPKaK65GLp91 lj0Af0q91nlu6yx7Yt2hLPXEOpH1WmDO5wMWW/Aq0A6zkpilVggYJ7mTGB6KZZ2EJjFoa4X1WELD DU3izIAJthSTGB6EywALTaK3mxVWuGxFs81GMcAqZifCvzhfTPo7Nlj2ymAkzDjLZof5e3vewhFL eE1EGUWxSjMitiKHR0EZXnLhqljVpPYTDqtabr4hHaIrpxxyUD00CLFyVs6eqoUF2Wq+UCtUimNW a6+KR7YeqzeZsspO2w49RtWjZqqF94TsBrq5ck1+tZBgzDbJ1zsO68Dbz2TpZGZ5xz/KUGhfL2dx 8/XsC+pDjSdAT2kJf8SjpiGPBC1803GMqCp8ExqWwe8394NrI1QuSlvbnGuQLbJlYZutqxBttuUX w6Np5R1ebanyrytQdresA4VO5vObt3wmPJxZCFdaw+Y71CSECCPPPET2GQ/X5IpMUPB73tmVPFMr IoywCY/6wIRHWPZ6e3ah2wjFtQLNewRTsVy6ffZnpZIX0Ouzjquw9pWZPsWEQCtFz970qpGlPbAf nuwqhub8aP5BFOfrrq/G0vY6bsPZ5Nyf5agUeRJBKmxOP+LaVGmoHVfiY3QMwsNx5OREpoCuYin/ zCs0/4QVn7E2EsbsjXmRVJZAKuum1Om1tbWCyfp3xZItke1F6KOGRk9WjyljQDhuVA2MtB2dUERt KLPbysXwcOTi+4Cp25sk0qJ6FY4KRc1rhxMeypD0xmRtIxHCSpgLDrwhiwfDQ3BeqdFbEmPqYILe 9r6gIW7X4SGBRMTSmYh8T7gW8WeBk9g8ipMl08W11IYMQkN3izVdkFwnjFgnLaNBkpC5Eidm3lGS 8ADMoZOCR0my5JUaUPAMj7kOYLLEptKvNrUErxwa61YdlZH2DKNudY7dHYY+W3cq06PDk3MP2USy lSgRGf+CsvGUoxV3nMfJNXeXycm1goZ/cksx2JIt94xb2mNG/rwJjByFh+DTtaKrlfKkkXvQycmi 8Y05+bMoMPI0MbJoKQxXWdvMCx2wKiDp2WqpgprWpTDu5U/ySj365U9szsGrLBEVI1rjGQPLEcyy Hxjzv7Oyj4rZhzGMe9yjNLAxjoEN7xzuaCDWS7Z4MVtDoGdduJh/KKFIMc653NLqP5Rmh81rxer4 +Dol1q9hNW1paWRpaaTsK2dpnUVqV4a1keEhhk5PT+SVkONIZmkh5MqyELIhm8loj0uKwHyzotbM RDLXnKh7I7YIQ8yO5psanaTnmBu1e5Arx8xoizneLzxsW7bGcGy+CEd6tyQRVZYbv9ZONXsi9MH2 1ivOYzB3ZlqOaywLTwZibWh1RJ11XrTVytoJPCtqKeXy7DqY+aZLJV/8HsRS2fwU/nKw/2B/zGwH xt17WLaxDek7ODE2K7ZSz0Fd/gWM2boNK+Kq0uA1EWYb5BO57drSqtKlvqq0kGH+0tpS99B1aW2p XlpbavXySmtLs3TAwkbRG302stX4KW9gIpw+XwfF84Snc6Jn7ZmIcArsnHh6JtZfxfuO+96E4xjZ 9uxs2iJWBOOuc6ZcpyaZ0QiZKLCt4mIa907lL+oATLvlYdx7HMPlMeo9y5LDzVKR+/bSG8uBcFYT sUjWao5BPpX/hc46uDPEb+6aj9Q11daOx4iUreji7U+q0jPCpLaWLapzHK2DYuxWwa7bl52VN76I rHAWXM7o51CbFdlYWwppKllnxbLOXJa1Y6VVhYcQS6ijSUI7dsvGnFODiF6F9fR63KoXHkhoFbE4 RmGYWqratMpRTyk4+UmrZHqD8cdD2i655i1dsSl8TihfhFwhLUmElv2kT+6qyElbocnIptiuOXU7 dct+rmf5p04301aa4Mk9wZNrH9wk0bNpMwYwJaW/vkmTxORCdUd73yxxgF218PfX1j6rY25HX0fX 3F59xoxt9Jntszvmiq91dHZ39Sj/hvLq7GqbN6e9uqOtfW5fR9/uTs3bNXPH9ta+6r7du9vFH6ur satlKmPDcqbCvGZ29PU6L81LCEfQRrSh3vmbiP+gkXL/yTwKIuRPzY3On/piw0ZfrH//tCusEdMu d/7kPwTLc83q6eqUOxcW1Ff3dnY4Qbfv1jevZU51a9fcXUTCu+Y6AdJrCHykJ7lQGeKu2KVGM0O7 iD6HN8ZSXLRT3r/y9vBIzuj1OVa7mfWze7rmdVdN8ouqtauzew49ntb2nOGRtFn2A2b3rMpRJnnf ldoDKz88mI5ZQpFcUjQylv9M2qiqsB+yBDS3va+6pa2tp7231xskvTbVn8vyov27eO17kyapQ0U6 Y/P9Wmu/P6elt696XndbS197m7jfvL62toH/439qa/fYXGhxZyRFoa2v0sVPTpb3zG6Z27FHi1AF +aIoTXpHd2vbXH3XZGp/YQjJbv3mjsZ2ze1rQUwdc2d1eRKwufWPtgjder0nMpAZ9eUNNRTV3Qwx LRcZo/Js9Ryuaj4UyBV5NTTWitdSY/qs5CK9TZyqWaX3jsYyBimqD3+nK5OJLIzoXViCqVhQ3vJq jSQi0YgvmkPJBDaavnWd3lzXoDdNr9frapvqxRFjNfX1vo+1Vw9HYnFh0ZHqmpRM9fYZlcCafpoS 55rkfTNbXnufMgdgdNF0jMriPkOPjfRHE9vHjMxATTI16H2+1zpjdYY+lMmMzJgyZeHChTXWs1NE ZIcjiSlxceBMYiA5RYblDaIFVSF/Z+gD8n3+67wv/iFTXB1RT4UF0Jqs7h+KxFLiIFLaCnEg9q6i VRur0nvUP7aXrbKYTauJZDIin8LFw7WjEUlUz6K6609iD2GrIPj9BmqG+cf20kdvPDI/LUJwdLSt vbe1p6NbaLVXRd2WrWgv5ElPhvKfpGaq62tqdeeEWPt4XOdyzlSt7JnlOj0psDI1eHKpvHJ7f7aO L61xEtPTvktHryifvlKdP7X0bmgZW/Wo0Ep9QfMMX9nqlA6cDbm90l1odXlUVlSMxsmjdKRP3ip9 fjIWN1Ij8YCTHR5Xo4N6enRQTACqIJVqi2NW5DGkNXqL8LJtnSPkyxaPJ14x/JcUywrUAW5VYtjJ iKqpRnmsc0qcjSfi6Q0kbYj9asIwM0/rEzGLLZICFXHXF0ZSCcqZv6/my6im8WQUUbOn7kedo7J8 IViHkNkp8s9Gi9PuI/bL1uPeQJzs0PuHM64ZbTm8Fk9mrJUb6oAp+zlfTju+m+aPZQz/O82NYsLd OvVRHYW3SFYWvoqmoV4+qFqn3tjgzmqk1YmksGIpG2iGkqYRFac7xiK+wYlIdL/RdEaOyeYWS+OM wqUipK5iZh/Etav0NSUOsPOpL+XWLvL9anhSOZyW4u0XJ4AnZWFormnsHDrQlljEt0mgqaauXu9U LqSmpI1+U+FV+oQN7Ki4yFW/VDyRNcc/RUFMmyc89Gf0lGWP+cqfrEaS8eTgWO4cbBhHDgq9ThgL CXyRcpqeTMihEr+5qVI1X7Rejj66jiiX8c1d9l1l3VMPVAkxEjvZa9D9q4dtxXPOWm1Xh0qqt6zY KLV0BOz7ti3t3FlXP86s63eOYM1YOuDTe8oHpSw2MBasDNxHg4utr6oC9b7vVa70GFbOIhmoncv+ SjV3ZZk7/XU50t+yILZAn52knZDfD2SHqwh5AzGdz4s2tyW6ICJdyXcPjTmZF5On+jhzzP4KP4ZR kKJfJoK2T7m2nbtLBWlflFFO6T0vuqMvTBTTPrEKXEf3gubqgVTMSERdx37Ly54Bseo5XwrbR1NJ ZUtUBRt/nrXKsohh7+7Y0ruJymCBsFBH7VBDm/+66dOn106rm15o898hOsqU3F1UVV6lj4zOx+wT BwqSlUK29c1Ta3NkTGdsf+KY2TE5lLAr1ZFUkuKEnWIeBKce9aWSpA1g/YkRl7QzQaPO3aMJoB/f NaAW+IjBj2TG1a+Sl5JcjzprtMdIq4WQzuGKHYm0OE49mbB6nXIsxBtGcn46GZdDlOLdlIHdYp5U kMyIQVv3SeAyfuJwEG8QznnpFGN1DsJwMuU5ssIUoUteYtjhh57uuV5XP1U/2Bv0pEmT6JT1mXVr q123pidN6uNfQ9GZw7vIoIJddkfwHb3dc1p2r96hY26fvnm0us6JRG9fS9+8XvPGnDvLrzDSOpbD vHJFrD1RmdZHnNlXc3xdrebE6Iv7C4ixaEQd3igaVpEOy+WFeEWc2iDSp1wIyJ+/58t0cVihdcoW Tap8Ri0/ne+Kk1LipjpXzpulSV328IudoStHdubMzPxZuUQZqaprszrJk52eLNMDuebKNHlPZaVO I1d9M9/R42oM0omhJ4JcSKx9dnuP/kN3+qMytnW1emXd5KqQH+r0yvqwH+p5o2Gy9feDrWTvnFwu KbfOfhddIPOQYqknyyLxgTRayyjkYoPlIF//+m1dfHicKbVmkiprvQnNRIcjgdRH1F99ck/3y782 BANoSURb1CuNuXPLtNeXVp654zGOrNN7TWvbUw+IUfz0UEQsubfXmKsgxdoa8VpMne4jpxmr6Gb7 rWQ5E2U9aR0Y7j0LyDwWVu/eYXd5UlQRpegSlDN2ap4Fb40y62oMdVYHEVEttjPKWseb6m5mJG1Y L+Z9z3rQeb112P5q4a/Xu163j7Av/PUGkezqamFdzGzpbdflaLr4g/lHoQzOWbz2KfDuU36p4eRx YULb3KNVYjxLBGGt+8o9kmUNZKnZZOtD4n3UNqr2pViLu1o7a2QUzYQ767tM5VZdONfUjC13t3L1 tu88r31ua7veNUv2LEICkh1E++XOlt2qW1pb23spk+h/tTpMPeae8XcX2fE1/CrFZu/YLLuRTIab UVGU5YIt9zI257L3CVUO2GONYqQ07R0VnNXe0+6fDdm8DXOjuot2s1pJp9dsQ+wJEL3XKrbS3JyR e4gzy2t6b7eYcltAx626o6u+ura+trluqs+IV0Jrrq6rlxpj3zYEjOVgYRNlKJsyqIWL+ZShqArQ kpDHb465ljjqYsBd2mmODgj1j4jqdtC/xsTlIz98t4r9hZi5TkCpm/94cWuZp7nswhuGuagwmcNF viOpjrlt7bshK2vFo9OfccswS8mtsxrNrOIUgdjl19MyuEI23+hwr2OUcQtOtYa+6Oj1OF9UQ4eu q9AXO52BMPNF1fjleU0Wu7gh9hqO57Vu2a1wXXZXMs+LLfzHvYjV+p79lqc0OmLIVwjtbKJdr6mp b2qy22ZP0RMNQrXlVVUFsnjVboFtkj120R/cGWiNVgRPOJCFyCpuI5FUJiY8SqaCC09d2yk6VGD2 X0RTK0JW50ebQ55qt5l/THdInLhJlWGtfJXrfO0QQ6LX0ab7l6KYVlWVirP3c9Q89tLh2ixVcpbC WheqD67SNT69qKu1Lkc95s3t6LMs5c2HjFTmQCeGAdVZmIpllrjJNvR+Q86DBBXAaYYj6XSyPyan ZoQ2+EUWc/b6KbPHzHL35lkRtiXTzGjC70rK/pYUdUTt1LWbkY5Z5m5dj0i9Ibg/VluFDsTFcKV8 XB0+KmcqxfrIVNLaAu2LQ0wsr3ZlQM8sd7zMIzYNV25433dNppgZoFo63wSIWtVoBRwzAiUgktGH I2NitEJIOGMkdOs0VhXsxDOH0npjdV2VsIIax1fk6kOLnNkujbO4Na8Ihc05/SVp7gMIOVOGitw/ a+I7nVaOgxmLRtRMhmtHecRVbQe26/LJZr1zhwP1yrk8O6S3DBspZCln66egqtPUj2Iof8SY7Gi8 NxRXZVCgxgeCUEXAE9OAa+CJafSPU78bQvXbZT7l1fGwUQWrAfQPIKgpAP8Agn5AZLi50T8MJP5a 39TsGgBy2b7LqnS4JlDlsIuv3fEXGF/1a5WeXNaH0zgZMZEZ3iAsG0E2Vo7Ha2UwKCOqKmCiBFRb PcuTZjfftjccsRRUttTeM1/hkjktfozGzJrAP9kWjw3HzGqixm6z7AUtMhBrDCutlvL6IuGSAi3w QEzU36L+MafHpLrIvq1SkS9EQW0M7ws4HZblUVAzkZH0tI5EvzoYvK45UGbFA3XN9hPTKL3BBxrq 7QcaK5tCHmhutB+or2wO+0S9KxaVU0OfiNkPTK2ctjzrkFnJ1EKx8k6u6NZb1bSzUI/KWe2t5sI1 ITK5ciPtt+HsRiikWfY+KRcDq4Y4KlZnqwklNcaY9q0aCBHcDF1thjAj11QzfUpjTZ2IUb9PZbNc YqWUKA019fVTauqa9GHeDH7Vpw2+r9bVT5lWU784H22cNqWmoSHLR30a5vtofeOUuubF+eZ0vtk8 Lcs3fUrr+2bj1CnEdvzfrJ9SV9OYLWt9pWCG54vTm6Y0L04qG6fU12RLo79Ueb9YN21KXeNifLG2 prFhSm0NZnLwq1muQGT8Y+nZXB76LncbJxt4ZxVJQe9TIY+KL+pbtUQjI+LDnR0zq6POZgm9uqBw pEsoawGR2Zpk3eHluzq722dXWwsXY+m0qBSqC37bSbAuF/XKSaRhPa1WxW4VWGOS5cq0JofnROar rTrpIblHRU410IkMVnJZLmW7u2Ikdt75tvM413isrOxjPQVbWW7DyhtMDivL+2Cf+ymrhVVb002/ RzFXmmSz7g2AR9V0nVgSI2YOrYo/psY3IvOTWAJixNv35eDIQU7zzvuy19YrxLwTf6GxCwQjc1pp tzVBY58xkzYycj+o1S2dyJ2wbFMtWWy7plDbTo0q5zPr7KFm+1fPqIL4ZdkOKrQ4nu3M0VWXqwBr K5paeWP7rmvt9OWcUiFry7OzSsenxsUr8rlLfG1NYSXMG0q23lSeEhYMhJyTzjWi9qI709Ofe73T xCxJTeMrSc2hJUlNsyyPDpL43KKWQLdI/nlmoDMk/9xa2VRQ72TpzNPYKusuMDHPQheP2vrWLsvS 5xkJFGN/aoum2LeTMgZVwVe2RJo/RsW+W185Vtmkz9CVZFrU2uGOvnnVO05rsNa6hL0z035nZsHv tNrvtIa/41sc3aI+ZK24ce1R8o2B5i9QlnWYzTgsyOwLs+9EpHJbbt4wFtTV1NZV2VZald4ZGRM7 EmurKOVmr6imflxFbaqz4EUo1njWtnQ6S1moeMUSFNFptloGZTdGMplI/5CzdCotVv8akZRl6siv 1OjWiyIM8a5rTl7aVdaKF3Mtu1ruotLl88W5uGtdfMG0r0grXexMdPt3dS4rawtYGOKaBwlLcIHL QoqSV3NyLwAJ+icVOuXNKBH7mNovITRWbrLKtw7EG0LYqpCwhSC+HPIGYnqL9fxN6L8ZvboaqrjO KTKGakOIO9reSPur9bAU5I6zN4RAApzWX52SMd4VLaGl07WeJVQL865msfd5BdayqMtZX6Lnejuw oMX/dq6XA4taxvOyMzPTrUbG1VNhjhBC3u6NJzO9YjOn9yrw7b5FfRimicGugQE6a+N929xVMjPS v39yYKA3E1FOHQpLtvfl9oQpvcJe7lvk/+jivGx/dBwv94qlsS39wvtaa1KsI1BXodISb8v3uo2U EN24Pz1L7GbzCHw8n94hOTJCpvc6vtoKVRSfzzzzUtWRe/V2zlBa48mEMUsYbJ7LrlhcLiVyhjNP 7aj2X2EONULedjvEc10hHjpCXu5OGe0HtCdk3eW6nE/bL7taV6eGWgGXecmFLJ5VXNa6nUAzGm5U hNbbdSHpd+rY5byqSTrRX+rLmrxLikMnlj1BhB265FnbZE0V11qDhvYXvOHE1Ml5apyQVt3s0Nbo nXRDxOGkI2K5nnQWFG4lOjEnqKYq0WkQxyLvcKA0EuwlVUb/kLkVWg43esMYx9ijazDEG4Z/ZGTi jWc0VtePp1TUh5QKZTyMr0Q0N64Q5SG48iiPinuzMKDvziigCjWbonuDCWp9SDj1jo6bSYz7d/iP c0R9JdZqsdNgPGrd4NoglMOuzafjji2ybFXXWfEvmz3hjNf0lKaSQMxVPyYWspJFPSI2FDkJVLkm V1m6++6xdJZ5/j7XT0I5B0ZTcnw7lhDDaxmle+IvhvRgrHwWBLyGJAeUootN26PpyKDQSGGRKqdy meSgIQMdGBW7yqx4BRNkxcNZopO7VSo0O1QWR5OG2hEne6G6vxue/XUiII/wqCk1PeGFdFp13fTx FNLGkLbH7j2uMEVzZCQeU2OfFMm+ts4WKakW+S9LU8U6vrQcBAyZjXWcLDZjP+vDsf5UMm0INdAz whWgKNRyGCTcNBL+f6qFA6Aa0wVmWvqxtloo+xQbu12qslolX+GUw5r9kbQcDIog2FZXEpbXXO5E 0mpr1HpaTV1NfU22tXShqt0Uotq+oY2loeBL3uFyJkup1YeNSHo0ZZ/4Y5ndKem0NJOKjcgDwXxq NV+5YnZcs6TUOAqhyHRWxkxXJb6/b+0Nx/ery3GUfzQyMBk8HFkkzS0RbZnDZiAkaTjJnXnctzcU cWqZ5Z1hivS2avpMMFeLWgVDeOKW7vto2XxaJjzDjPKCCL9St5K5tTD7YslorF+f7I2Pv5RYi/bM iMhIyBjYA6OmIIhrjeUrMD7m09KMPJ/DFJ3MMLlcbySZjmWkI0WxjsOsLNxP+dIifFSIQxrkK07F 4p/FS5sHxM0zp618cbGSK+ZfbMvb7S9F+poxElLN0mOJ/qFUMkF1H/XHJhXj+2n3kXY+LfB5ykgN y8mISn8Vm57S3DixttZatQ4pqambNp5Kpzmk0gkbER3vlpIcIz5Lq9/mqiOiVCPzVXTpLHG70HLc tHDIEN7zSGrA8jSTSQuJBNLivOF227WKdLKlVimgIfU1uutcjbpmn+K5jlB0z1iLekJXjoEM8hAT WMy2igMvZHy8gQwbou6IpYelN8qktTwt3/oNf72aczX8hDUVnUa1YXxN6tS82i1Gz1dA3VY77kqa bV0lzfZp9rRQY3Flr7I9VkFJq91hrRRaPT2XVq+UVXVJo/WVWqPrasMGrALT73n02unXo9f6QXpz I8pdPy1Uu/Mo9+IMYglxekZ+sg9ezbUHriIyfWo01zcMFegDzk0mqkM+UMMPGXNIOk5HM+5bvLRA 7TSTowhmluid83r7hO4mCBK9HzYmpJ7JjpwYQaobl7KFzVcHV2sUXIlKXauvqWmoX8b16OLpmneg 1HxJlidxVo8zBup9a5wDomoM1BuEPSCqxnZ5wjO0+0XSuLC5YN8Sn8IHLWWjvYIqm3pMpkqdOxAT h5aJ8aSkcF0sYmeO+Mm5LL/PRTUZpfQs5asLRV1lhm9OMk7MxlGq0LimXOsasqmPe43XeBpHoT9T m6eugC1jXZM8HiEtUmQv4BfVlT6k0spPUhh2N8k8/CFX/WVqT2jjOWFVqHGcdVDYnKBc6lfI4m/v wr9lW/PIw8rMBfHWVz1C84l6NgaUZ2JBPlRlOiy3/uZaP94fSQROX+sfMvr3N9VN1T/SyYzwKWz2 G8QEjajF1Fy3TGjM7wVNGO/qCJiJq1fjUqqw2Thn5WchJpSMc9j5YstEt8QX5UY7IWe70xnRM4bY BBWRi+tNk9yZZInM9zuaTNFrFcs6ZIyi9qbZkdHUSFIZPfT6YiNykQNVlqx3vCG4jqoQb4uzvNVn CbrGe6RfzuMo/K2CWu8asf3++9fRBjoVUfq8sXjano6iI9xvREdTvvWK/epg2HRwus/aCOCa1TJ0 fx6KDFs4JPImd16IWSfVq7aO6PBPUcYzQ8nRwSHP3NnCiCMLceBCpF+cgiGSm+trrpnQKj2mnKZF xOkgZp/eKvjULtFkaivftJ44QRITJab2fLmal7Dww9YEmXEfHk3buet2Lmg3XCorvQG48zXb/p/w Ahs2k2WqRt69ysF1z8ukjM4zPWVbpyDJylcMAA2YXWbr8BZffvsEZM+aO2Xbo45m6QrRVJ9+m0NF 9lb3rNWduedd9Li8Qdixj6VNq0Ut+kpJTRYLRuZ2duu97X0ieX0989otj33eYFzhO29Iv4UDFGFz j48+u33uvu09PV09emU6MTyyoC64+7m1q7Ozo2/fWS0dc9rbPA/X909Z0DDZ6vBZOe1rLXxqvsDx ZJOQh2kNj1DtiSZNxkhNt4u2eGUsyi2m8GYr4bmTEokvjIyl7X7MrJY5ve3jKqtTw5ZamjV8vsLa EzjzahkN7XpWMAxaKylkD082tM4YqdVMejPQMqTUSEGudlgU2tAgXM2uklNMHUzu63O4mhm5TMsb SMjXgp1T6ebA3qxvN5Uk3eexqW6y3iqzV266Szhte2ipH00HRrx1M2eMlkR010gsU9k0WS4NUZv4 PC3uaCYdi4Ys9uRyO3OQR7hZ7bPaZuzT5frJWIKZ3HXcQMyIR62604xI4LNhpoDPAnBLw3R4EAgm a6GjhmqRv7mkHKiPZKbKBxLGwkDYIYomJO59rnGybraNvoTQEtgOT0IWu+vZdjGJdY5U76Zp5a2+ YwPBSLrq4GC2ZalwA6FkrYCbJutthjjsyddMjk9N29rntPe1+937iLLibCpPGZSqmLkkKzIyEh/z +aQNFp9CbCQlkUqeDpi1uu6Sl9+BAYreFyr/tPoUFZbVBhVYNAP6KdIvt66PWMeLqyP9ZG00aI6L iowe34f0ypgUekfC7C5W1k+ebE5FRUUmJ8cqm/3R0aU40j4Rm2lNGHRBSXG/OE1Q5USwFLRYsZeW TEw1laI6MLNOiMCJgU4U9JDz3YWy2hs3anTRysUM8yix8FYusLSPSx4cZ8ldlIF4cjCmjlOJxxL7 qyYnoo8MjaXFnwPvx6xOZ5WMkJUnsfiY2/DoFzWeq7SFZqmr0y2OaduzZ1Zr/bTmhr0pyy3R4VjC SoVyqBVy4Lt1KEwmsr+s2e3hDjMbUJMBEhVwnjVBTafxGD/Twowf947MFaW74lk0awnUUHEkS8gh +U9xMKThPqzWP3YkArGtD8tmcZ83JrsfMds/htw/IvZc+VTDWXbsW16astY168rL0IA4yDKkQ28W dWqoQJwjaU+MTGcePXNnV/f0do9LvHINg3mcn6epyO8WQ7Zn/XF1RqIIwDzxq0aVScOsVryuHURF YftgcpZUi9dVNM361KyUVFhj5k4WucogbQidzhh2/iPdqBylUafzREf7Dfk/iajwpRNTc/8y28QR dO6PyE0dNbb7FUemXq8rlLycXlf61N8TYqxcynWY9lG2kVYeWANTMrdU7pmZpeJs5we6JSZpssTS LIY7J9PmzMvieltxQmhfLs5D2rKp0YC1DtzSI1uJwpV4ZsRxpuKajfGlp0A/KitULtiOVAI5EXTY 6FHOtLsKtaoC10Ei3rf7AqeKVHm6fuGl1m9E9KvjF+LOYIxlC/qaJZnPYquZk9fdIgbmCqLCkibK VJUdM1GDWM3r/EjAKaYs5p4i39NOtdi+s3SDOYwgI4OGCNh0kydqIG8IrrwT59k7dyGZ533T69lK eQ6XUfTHyliEASd9/gc/L3Kzb1ZfN51G1Z6LbZyeaPg+4zOJOgIa4Il32hS60wqZGesNRdXTw0mR RbEBigHmHfZyyltZZZO2t+byNYzhPn+UEZzMqNM91YcXDom0xzIB/fPWmG4vQlYc3DEwc88bhMyZ ydIyCI12Vsl7g1FqMLnARJoWqJlM1QWRP8iU+pTJNBbypTR3bncMeMuxXXQio5mk0EZpscv9MCnD 7XLWG4yYCLAqKBUDu+ZuteqrXqv57xyNZ2Ij/vRY5ddzYnHg7ZCOtV/09sCPq42wvCF5moNcjpH8 bajLJ5K/McnrDsnzOd9lr06qyv5idyqWTIkZzvG+2BlZNG9kpu0QoPAXZ49GUoE3C/yicGTnfbPA F/sWzRwVp2o7l/OirmMHtQmTVg7xZw9HGACiJ9Yttk9ZnqNyO6Ex3wx1QZPTAY0r6qYDVicBdtTt 9/zGiFKHcSwBrhNLgBumNYQvKFq6fu+EoeAMXcoli6OJ2AGjhnMYqmxrzfrGVzOpFia0IGWx2/xl qi6QXU4hGN+q6fDFM0uxW6lLp5FidGXEiiJVllzDYw+emaaanMX25hW1a7JfzT7bnjtq9D3kaj57 7TNdLkMcN2+G7wtBuAI3xNIK54Wh2OCQ+42ACUD9SVnK2GadHXUiGzVEXKvT5vIE37tyRercrj6n gbLaYZlSc8bdHKCaSIsrWkZGaDVii/TWmjr+z70uuq191i4tc1DW2rythVLf+oD6+qrixXS2tBw2 AFhbie0hDlstq0TBni+6n2JBqtpc6stDoc0LzRmkiKP19pk+1l9kH8anWHs4K1jlTI2wKV3j0UJL g3H6Aivn4mtnsGPsb+9XTPW0nAoNEtsIMTCiy19LS9WfeeVSsMaw6s9rF674FaDrZKAVqAoMi1Wp ElwMHW0K01GrC7I0XULm0MtosENTkGo620TsbSHmBjnzQNGU2ioddupV0CGze9Oef9WMb53bsBFR Swtt9ZRb4JZEAb2vumeThyJpQjASrmwyZ0RG4hFzwMP7ds5uWZWcbEN7IuRaejiS6Q8emynndpRb jYR1bIVajyELMGVxRMTMXFbRFnKCUacposAMoRUXXWlYq/uYFm8QvWrFwoQqmkuh0WgOFMhAX35F mUrssDtadOhEadCtqOpWXFFjNbdoLafyD1EuAyPDzvKBSDxtFJjtUwPZvgKuXHMqhVja3IasZv/V pIYYpFULZOR6iex+12u8NUxYPruWS3hDsQRgWPnvHXqVUzaJMWf8Nezg0Wjo6HPSHJF3zhINf8s/ AG2/19frdvCTS9rTQls9z+jVOL2eNjU1LGbrt1hWmdP0zR+zt4X7Wz2zofMVuFzNXs6WzhuOu92T O3pnuHfD2b4VY4n++GhU6YQ3AGvFix6PjImkUIEPkVWljsb42wyXh4Xe2GAiEt9ZLILIjC3uvLcn kPblMunrWgfiXUzRvcPuelrGRz9ARchr/3tz1VyIkq7xOocrIEhvOP6VLf4A3TNyEbHuQmq5Ly5J 1CNhTq+iKHIDaf75+sYswmwfx5T9iiZAclFO5KZi6Yw8h3lAj/gr9+C58AWJ0BuMS0UiiaCXeF8R zHusStihJL5qMHiqinOEUaVw5yADck+W+2IxK+k6U6Uu64S0mkF1naviDWVpnaRiHqCSNYryeJfi RtHqSqgDaoKTm7mPegmpIF2TmiElLu+8Ju/s3KGauXSrU+bzTLeJt+YlDHFssxF1zbe1Ck+S2WYJ xUvmGc/je2lewvQyKRKcLvAllRlzk7G0c6CEeQJktlc6hcNFc62eaEDFrznnPcVL7a41e6KFFr92 tfa191ET9XTMnZ31vUWZQA6aiWpuzPFSIAcLeSmQg/ZL9jvuejtMI5ZGv23JHb1mUqNyLXLMXPJg OhhSsQ1ttEJ6EsIFjEy+bwkUlbbaRiT7XuLAWVn7dU7MjevTMcvqwlvskIqizqsALtXMJ3i7JC5L uQtvMQuTqahrUVfSFJ21fFfUxMnRjC4jHjYkZauJ8HTbbwVYZff/5Zpq2Wr76n7lV1c4sKOlHBBL V9Jy+b1yGJy0TqE3fGsaJ9Ze9GzHh4boSr1XV1w10kTSFd1VJXqzRWpQumY8WhOoYsZKWuPTmgZ/ DeNpkiaU5owmSrqzXHXH26302HZ57RJl89m/+c78dqKwDPRJxXOKiqicJhDrnUeMlLUu2ZJkli5e tl6pJ1xzyiPPoEKNnqtHGkE5xEEn7oC9wVgTK/5O6URSvj5V1TRW18mpocbqLMf4hihgk1cBAz2F JZhs9Clk/zLVyL5kJhJXnuXd0VcVlfIWVu3sh0qP8KNPETwKbNWOMUsqVZZzfrlhidTo842438uD UCRzCCvs6Hr36H5MDcRG0unRYTVdoLb4Sycu89PJ+GjG8K9jjvT3j8rNQ3I0V50cYC56HhRL/MRe ULGfz1xqF5i7k1OyvgwKtAd2in2R75BxHh2xt23bex2kj5mRVHKB2EDu2igQyF47/iKrzR2tX5Ry 1uwtZ4HOdb5y5u5565W9HXu0ywLXVFc/eZme+Oiqqi0fFOLes6EvKhIQ6lQh7/ihO0yzrvaGkPVD IWc2W+7a/KOB8lgoXaxUEfVAwA2l43vSs7glXzwiCyKxuNRIOcMnXVlO0P50Q002V4IhmjzVp8me 4Z4CrV3X8MwXuk8d9mFVGJobpQtDFEVMAVoj2f4xjC+CiTwtoG/j75evEPq2QvXLF0/znJz/Imje 9JCabnH69iuG9q1YffvFrfnc+f9F0EHl1N7c5a/W9Om7OFkjO8gyR11b7NuSYlJQzF63RkYi82Px rDuT9OA0dSxtBu9+KLfa6rk1V8+uvOKyFqy5UmSms9+JvSepfm8V4nL3rYZjUp91d264csJ22xAI pE2+QDkniPk1mzufmQALVyjoi/TZLsXSsy9maHLpVGvLzDntemdXW3unPruna163VCR+2EJd9oN9 0miXG9FlP8ilcK3DnZH+xV3WIl9uXy6rIbL6MEiaDkHM9Dm9fl89uUj4o7M8grn3xDudAald5iR6 lmLeOmwJwjU55WRDgatJlmO+2UsyTPdZjsuytDXeJv7kyVBfzoncFVkrw6nKkZOxhJ17fg1fJutC yES51K2yrn7q+NctuDTftV7BJcu86xRah8XayZZoVBxG4/qVEMw/hk1/85ZVocUM12szO+hVhz5v HlTWY6RH+mLDhuj8cIl/9olTbnO+5HrBeknWVXSirb85r7s02p2yfErtpDdUnZeSsdThbA+2BiF0 uUozJpbzx2PGAnPtrvIRohQNvfWqUTQpnOTUBNwkST986shsPZ0cTfULz3sq+UFXGSS+tYqwu6vk YJJyNM6nqtXKS8vZR43ygmAdOeRbqG2OXjgDKbW11d7/n5BG0jSMpGxDEq7C5ak+PQUin7aJcuIr jpHMcKsRj6crayd7Y4UuiPX0ajlVpcsTrlMlLHtN7XenzrSGZFPlcafizU3pdM0zpOs65Gck0r+/ 8NPpWmgc0C7T+Wx6dGQkmZLu9vrE+Bh1rWE53ZBDZXralLSw3L1BmG45lT+zReIwh1hGenZVmxTM foptnPnqfCe6UmBWmyN8a6BrSeE/dTiZzshBd6lpiUwwCgOxVDpTI5fLGYsiIr+qxFCf6GTUifjL o4idMcGkWoHjDcO1wJ8Hk3SBM9aA4laNtVvtkF9X602bK3wXUVIM+Rshm4gc32KB2lhWU7I3JCOV GZMnWwjvoK76GZEbC0UgXkVxdKhjpjWHIDzZh39Kvp9IZ+RC8EnR7C1K3jlLq7nJXnK8B5a7i46V R/nLjvBzKfNCnLaglts753SquR9T/yfogG1dTXPYyvT6bEvTXXrY4K4zfRpViPgsxVocCRZc+X0R BFglU5fS+xoWV5Ry8YDZi+u0navKBX+5fQIq/42W8VLj6cmpbVOL35lT7y+ffokrhZbXQuFk0dmG Y3mhVO2GVxiiorWXSwZWg+frudW7i5ErzQV33pZnPrWINi6YH8EssPffBkxeZZRa/kJ16ULZlWET o6/m1m1Pd80twAJ6bOpxuSZY914dc/vaZ7f3hPem1GtivNb3Vt511XbUF3XLY0rdl7kOaHiXXC9S axoZd/dSz7PS3HpxDuZV71ii3/1uQS92JOTZR52REefV8bw4rz+6eC+6zBLRTqTH+7oxiJKqrc9O GAWF0FdnNqSuzCrsxfrFfbFhcV9sXMwXzdxtmS87BOnCXxRFLZbuGjFSnXYBUH/bOWkNOed6n7fk SUjJhKwWXO+7DxXL7g/NLuR5tjXYrx48yV/BqwKfd0WUqgJ8VYfs3tN59EaNSr4Hk2mssj74gyh1 Q6lkInagEa1s8P0+MjTm+b3R9/toutt2RdjSr7pglU2+h1JKlq1JYRpkjMpm3++xEfunqb6fMslo e1pU6rH0ECFP8/2cNmibxByG65np/iSICPaZh9rYH6rz975TrvLoPOXPSNcZFTQOvh9VM9pmJGJE o65hOXXgW9WDnn1Z/clEQtiAC2JyQQod4CqxGMrsPvs9YliesWdlMzpr1A+2szTZtHrDkB+xTrOo q66rVy5o40YkhQ1IBRCX03Pmp5QR6w3B3kkuF5kl1Lo3f3ufVh+yA3IdNyab+7ADLqzClUl7ClhV QF7uc7Z9szZyUEz0ooUzcdFLcGmLblZS1lCatXINi3cidhrkibHen8YdS+/rXVahSeu9aojH3CyY LQBfxLqru3p7A7F3zXSKA7yzD+O5ja66oDkt7aTFXBZX17xsV8WpGKojRe2ZbXdBj6StJWFmifDl PPnmL8pifi3tCpe6Ii3MZe+bYgut7Wzb2r9rr/ikfyzn8vXBVHJ0JF2lK5f4/opFOOPVMwuT1cqj Q8owqqOxwVjG6jm5gsvYsfIGYR8273xDBRslUcORZbF+erkor5pHbStIaUP6gJaBXuDi/eFd7F99 q6WHd1m2y6XFKKbrXKeM5QBoREbfWmMZyWTopxmOKzufEkzAtfKeY0qnFSTnhqCczf7UCrG5Z649 3CEGlKyJLbHKXXT6RWk2jzgWo/CBkW1ncqCQrGgMZoXTQ1yRcyMupwlsk1npS/CkK2m7BBctT8w5 tOzLer1CbQrp67i77yu2lptr3mIqwmJC1Zk7nahyayxIbs3BwugePJlQYpvX2jbxxdZQkNimZhVb YOhqQonQHE7Qw7dXTXjhNhck3GnZhRs6sDixJOxKgjejLJlPfDEXZhJODzH9ndHfFVKo5kSP3lcn FmLEUs5gzQQbEJklXJMa+vTqAocWakNkVT9BZFX/BZNVyDiQa45jxZZVwxdMVmHDH40TRFaNXzBZ hQ1h+GbyVlhLxLIrR8RJ6em0PKI2omLtzRTT0a082nJiLgsqtAtRFzIO05b0TLAWsg7FPfe6DKXq 2eJjbSNTs0Qyy4fkWYnCtDREiVRnrtfV1HoDCZ62lkxJ34w7O94lzV980yRiOcpowvUFsVpKrXm0 16HKgLp6Q53zmiJQOTYz4tlWZa8ZVb+KcKYg7Bq+6Qskfwxq9VYrBksSgVp/8rPvjWod9mlNlr1R 6ml7Y9QEKlvBfVE5SlVTsFT5lh2EbqILFqvgkgTn6Tx76XLupMtbwqgyh+0YiyXBzpySCis+pvyT q7rSX8I6a/TemJjqzbhUJm1letx7vprw9srH/Juk1JTRUCTlmjawd6LKGMXSvlPcJ+z8QY3rkI9c ihUyUjdhPIB0+8/vdnnhELOenXpkQNhU/cnEAuG2JmYOrPuPvxBvWZVd4NRv77OOI49x+O7wBpFx 7U4o0HeHmIH1BqI+ZFbU8+VU73AkY57u653f1e3Dx31JsRR6IpqX06rrC7RHpuoHezeKuubCrXQE d42av6gFmYu32liF0L5cltHm3T5qV3dpM8mIYtSnU0m5crYza7aGHBDuTWbhK4xXlLxx+/y2z4Wy z5B3B6MybPEWE9vFpc33vtDHkVRsOCKDEOuDY2nl2VqtFi7U03WBq4+rdJ/UOqLZFyS7C4B3RbJb 4oUsSba/5b1ELZDVzbP9mnN0wbhe61vUK0536hgWLszElW8lqOe1NsOKbKGv0S6kXNtdC32tfVG/ YUSt1aoFvtZzwGJ9reeAxfoaprU3M83Xwp1fh7xmZqb9mvNWsBpBSfIuYk3Ybv2W38m+ri2PEW8V Kkt5yAGbwSbbW/PI6sIbUiRlW6fzjcxCsfkuYAgLmyYRdQYTTN8Hfb3WibhGOiQ23jD8p+uqr8+P pOX+G7kv0pD1l9njMj8aaCzET/1Wz9cKjNtkf0waUs7hfaruzNpcuyuUuhCtcNUB49CO2pzasRRX K5k1t3V0vO/kZrcbApFj5okTvtx0ZaCjJqF5KdzYxPrpR/mX06r35absRNL9rt1EhcbPG4pquqo8 vSxrA3fEe9ZPYfKsD5Gnpz5ZIQb3hBidvVl2AXIdE7hwKEZLPhRZYKhtseZRWr6SZa1Vk6Z8d9s8 6e0+JtIpRKFXOt7yJ8sOqnJs5A3E9nIk98JlhpJpQwUldxuLSmIkZdi+OUWMfPVMKiWnRs1ddOKM JIMqozJWY9RUmeGp1Ei3SM7WZ18w/aIHEzeig3RAJgsnm4EzmlAM9x5t0f+gT+RfFppyZ6PVw+8x K5kJOhqaYxWMW/nDLGVXq7jyqz7GhtmrFtpu6aAYJRfz8qNx37p7uYR4NMEr6YxcQq7PFicWT165 taQxVEssG28FVBKroEtLIih3xxWPN2Mcw0KMI9vVi9j5q+q2aCwq6xelGrr/FBHvKyu3TjSF6oRj wK+AWuEogKdVGIjE4qNIVI+OGoFaw1gk7fMFqi0R6m65P/0iCbs5RNhOJ2+iVADO+IlV0L3ZopqR QBn/Qkl6qnc9c7BjvgIK21NtO0JW4hSlm9a9VLazSXxaSNn2D6kUKPRl66y11AUqdYGWgf5Pz6n/ 4+gFTWDtL/WCrL/mGvhT7oRtr0F9vR6nr46fV37oDPX0mkkvka9X+Xr7ijFdZ6cyZonAl73j9vfq fb2TZjySSZLtsi8Wj6svqlVP2V0MZdKh7mGdnCt4BnA5ZvbiuIiVUvBl2croItZVZDxzfC6JFjDD l3F8WHtcvuZy+ppJi52ZsoZx+WoVV54Jvkx6Xn807L38L3ZGFplVTof7MNz8L3Yk0kZKCNj3XcdH LTdUUF2mH0A9azgLYjQD1vpWqxdVaASCqQ51e+fuYvhEk694rhTOR63K01d6PF4mC/FA6n3f5460 AA+kvu8H3JHKnlUOD6S+76/k7khdVY6vcfFUFOObHq6vrc1y6ltnLB6PpQ3hLCLtRCmgsEvBY6Sa IjSjb03sKvfObpUSU4Cj/VaXmST59NfavhaiuRPTLsy+fsulCvVeVXBX/ePWhImpCt7ss5bv6tah 9m2mO6Ok45fbMSdy+sZYeRSpAD1q8NurbksgjyZ5FSn7moKcLdy4dGQ4sig2PDrsdhdqZXSbOQgy HBlDg7xZkualeCaSMJKjaeFGVbjzyr7swpU7prvWJXAAHTBRaNIGYovoyJoZafqAHkkl0ZvhGj2n 82di4fP+LNNstS2Wv+dcBlq+2mE5+XsW0owMixEMa+eQbOzjkZG0YdcAsqzOTyUjUdHl98nUtFek F1mMLentTAwH1OgzrTfCHvKGIt9Q5oA5biHXCy3UE8ZCjApRlIeld1nxy37JMMdQCSKbTO1fo+9h pJK2jWINyekL6BElU9W2fROJDybJvyFf3RMzx79MGaqxDhRFxInMqaFnqlTfm2neQOzl+da+qrSn 9ogJH7hmfT6hqjS1I2RmISW2yVufZelYjHO1VG19Y47FUkup/QvWbe7ZpOHI/oYuO9IkSGW4N49E 2+a4czBHUPUW79IkcSKueXRnWnre8pUpVa+Y35Un3BKiXMpnoAgruM74di94tujJKtpWI+uR/OrU 7FcnT11eSF0a6IUuK/0p1abOVapNl05t6tojYg8+m5vTbKf1nh6p2lK+BEPNri0qoSVmaQ6AzjJd 5okRTDlaaC7vlJ4Yw93TB0tNFt/sBQwV+7pw7s05hY8WL7/8sjxoquFav+t5lYETZXDXrae+8V23 GAoa4lUvuNxBGT3GAfYoap69BNbrYT66x/G646/I/e2CX58lFysE3h7n10UV5wmgwNf7moKOzT2v 22+HlJdAvq8gC0Wc/qKsEcRggnLIJLdPtu/sDEq4joD1av5KMAYhvDOJk1PzFMTw0c3QgrGiitcy vR2bXRgsuVdRmL6uJ7oPjNye1rwyDm3zfLXXCl+C2xezBOt96tjCKuHVNBNZVCWcucuVZLKXJb3r S/f/vowW7WQqlZTDV07fbqKqytQCVaUhTFW8LdWKqinm4j+37z27YhAHAMglUr59Y6LTlLtgVOmR USqKRMbK+cDes8CmM2uN8UqvLI056hXbLlnRKxa5Nsos33bt4s2bwHnxYfZBroxqCssolwW2ouZR xrMOzecarMmbSZafsFx5tFL4C/OKttnprOu+w+X0StG3iqk5tcnjOmoOo0Q83pGxlgmlxcCI6wPh a6xsH23qfc/CC8vz3BIME7S6fVmEquIyOYzN6um7UldlDxSQdVaX1itJt2cN8zgZNThmemPx2H3Z Rgt8zaEnA8YxXrB8M643qCKegQNXzize0IErAO/71gnRvvy2zmS21F2tVbOCDxlLCOZ4vrEFr3r7 Rhe8YitsCZnnu97LnqfI1sO2Xu60j+p2nurMc1y569Mj3pft+yq5uqvNGKFdivid+wXDaUsuTJjz 8x3mGI1TRcr7rpQY980Xn3kj/lAWL5ye8Z/N55JvbBjt6RoYEHWDec1LiHVERjS/QAK+pPRCjhT0 nbuke6+cJxm6ci8hD5xxDzPlH6qxXm5NplKyPC3Oy/MS5unHomikx/lyLzkbic9NxtJOuk1h5dX+ WL9I8EBcWZbyywUXnfZFmUCO2UvvC3g5kGPjeTmQYwW/LOqcWJqug3N2X4GH97nyzXeAn3q/0MP7 3FWXkTFrDPskQN/fxhGE/ZTrb/bboY2kqiTGuS6qrnFq47SG5sapy8GLioyfmqmlmRpNxLAfHc99 Y9KrWrA19DWZYjpD+ERKRGMLYlGqF3frWGWZws6X1GyvNwyxhUcsgxqkMzoqFyfK9nJ0RE6bZbdS vO1aXbgYXI1QPlk4j4Zm/lLqZ4h5i4gZI2t9jdskES5DpM3gMuCGIr4umVhaFBsxZ0HM0AzLU4i5 3NP9IccBiTcc05OJ9bWJPvBbn+MkG7++1GcptiOFqov95GJoSzRovWQvqN2Loy+UKm8uuYJBG6TF UKWbk5Gu32K2u0SlTd5Asjuhqa1R/zc+9XU+bGTxc+ONnjeYoEueoCJ73whdU+cII7CozvNy/jYm MDiW85UquV4iISPc0b2g2UpkwFeD5TpylCwpvELM0nkLsYcLaaT8Zu6yrCKteJlbCIIHbVmdWE9n y5tnmaStiiHv+7U89ODR8bpa8gugMVwAgY7ECp79Qee848n8wNvLJeubwrO+ZwIdu2iOuponLUbk CJg5DuvxcicHcMXuQp8I/O2ErzVQ0vF+JItoLGn4Kt+solnxLQY1TNJcXVdXsEY1h2uUp0OeT62c nvqyVJ4WseAyLYZxzQJsvqmn6MZF9UwqNqJW67l8M/u0Y17a1LKMTJ4IiPJuq5x7f0RaNWLie94w 0q5zx5UPgEg87RniJT9iGbVyT7RwRmo4eIhtc019kz4sutLmqrcplc2N361vap5cY7t/lotM3T6f vaE4Wj0hrdo8B5D69XRquJ4Ghn7y6Wqx3Ii353Ih7sjc5/LbJ/Fc/r/FT6Euv71hyE+H+v+egPM5 OR10+zVoWrgGqcG/vLaKGg70DSwnRZ5X1vn2rJrLVyrrw/9uLr+pbAj/uTUpxtMzRmWj7/fYiP1T k/9V1+S4/VCz7yHPsfJTfT+6DkOunLacdtm2mvV3yJRObEFMlgE6L9KHhbla2G+PWV70Z2VTJqtg UVWnpbT977t21afNGtyai4vIDqX0/+JaVeRTRNGxci+sdjnC140FpM5/brelMt6/6mKSxkyweoSw qAvmG4Tla8Qc9QqE0WfNyagjZUyzinA61BnIurkCzHILEwjAnCh3e+Wtsn0BW8uyrIOIZFUTDGPM ENObSgnDo+6UgNwpSAvtiNiRlq/ZUbSnoMK/4SpG4/qI9V7e73iKY6GS0Nt2aO2WPfEx+wOBzrUu N6AsjKTEhupYJntKw0t9Ycl1L6fp8Z1eGfA4o+vhMfBVKeP/sqkJ1oeDX82S9CzVlXXRC5gZSRtx 2jW9W1hoNDextDkmEbWPdxfKnXFFMRCOpcbRkOCsU8XNesb9yUA4rjiIQWEzHlWimRbmo8iYkCwP k29g3MeMvVxnkDDExIjYaWQIdwGqOkkLFYqJI8PiQcFGCbJ/YjpHo49T+KDo9CxDFs5c1AqxVqeV NnBhMhV1VRmWOzsZUate9nWBJ6r531T4JEhtuABd84ErsgB118SjkmTaEaU3f75gcs0yu+Wbql2h ZTuaKEk3i3SzzEW5Vx8UOGRp/+YbsFymw5UqnlNURGU7vKzGKz1f+mINV6b1xuo62cdozLk606da WWaBAqtTxrc7vb7JZcv7VK1/2Q6NJzP0z4b90VcuQEXHJJaotqYaUqa97tMEt2oGlutWWaOn8sQ2 UqP6ln5lNaTzJmISp/cazzHLaJqyVg9ZGp1CPUVvMyI8V4xmjKCrU7JD9HClylbp87FrzG3yg2K0 PiKGcgeHrA51YOwKHQ9kUI5F3L6SJuM8OmL1KZxVuinxJzq1C2JRj6O9QPba8RdZnVSLVSZ4gSu4 vGWZ9PMu6CqwnV62XlZLRnQ2GWaZPfSuq1uRZViyo7OJNss0XnDV4wot3pIpnVXAWea/2pLulalh wtW98lUvhJx7rueTtJ5b2Hp2eXNtrmc5A721s9Dzz7kW/wh0Pfcx4P4MtQ8DDwYjIq1eWxnPAw/o XZZZs4l/LrgZiPdAcN0+AtwneHc/LG3lerYDwZUdLQ9Z9AcTev53jjVFvvdz9QtXgpUr06rrprui nU83s4zq+lcvFlAr+l5ZXpWiGL7PmB5ZZL+FaLgWxQYqn5xptdWoX+blcHAfl26uuXN/RQ42WAtn RX3qUrGws0F13dGyjLc/aL5ZWev2I6PnXa8sh3b1fPsUwoWYRYauJ/KJL7f0cgkvkJV5VzEHctK9 qjkomuByZvOJQDjhi5yNrJIKk6p72UnWxdfOAuc8Ucm57NmX0GAYWdc/y1MtxHx/Z0vr5NBl/Xpe fZNDzr6zHqyaT1ZDAUdc6scl8sSlgmhfLhtFcx38EH5Ee2BZhDij3SX6PtFUJczaXPo6zGFAWJts /W4EXFkwHp9cK0rO2fts85187MlZnx0qkiFMhZCNuEvJhZdarmGHZUbGG4aMmV5pN/dtk3VzS7uM VGcWD2ThkRfLHPvJD09plX8Q2uJvxFwbqpzPpy3ry/6yuWFhOLkgsLNHtEoR18uiPjOfdCll1kPp bY3KcSy9r8j7nZq5FbmgXcfOF72XPfacbcOe+aLTHrr256oXC9szbIbTEqUUq6DMCOTe5Gq+5joZ 23yt0HhLtRDuMMwnxD/5/vBInhc7El3Cp3/afiK/9zPrxW55qoL9ZqEvzjUWenPZTqP9XlhtVjpK Pt9R8q5WxD5TPnfL4g3AbqJzHT1v+3/IUd3Nj+Q5et5/2nx4rb4YR8/7qgy/a7awMj6+WavmpqaG pnClyj1gN57tet3JmDVX4t5BGzSzVKVpbbcNLGL2a4Aa7pHZaFXqO8vsFDaoZW9mVSrLQW54GF4r 2B8Pj0kse8x+1XOeWIJNdVlqmCrHe/1wLD0cyfg9nSTdq72VVzOpcWL2T0SJ18O6TATtDce3AbtQ NfV7lws2IYu3Ztpc/BZYNR2NpdUP/mXTUQprKjkm14vmWpC8FFw/t4ilu+4qU9UFys3KSCSVifWP xiMp1bcWAggcjjA6MiK7P3TaKlNG9WR7qZ9caG+ecBDPJAflCGihsvC7bwu0y+OrL3I0Qktxo5fa Hm9XEU5sVQXhOhVNqPkBagg3UATsetdpjUKrYEc6ofW2rE0SSfe74dEyPB0NeSk/OeMdc8sp0PC+ kctecgs0VKK2KbWsxWinLz2WnjciI7dQjQzFLP/FC6kczS5AoRngd53ms/tWEM9pYpR4WI4aL3B7 TFM2pjo1M6kibM1j+fQ34W2UOtqknaWcremBc14D1lM6dqC9281s9OghyZNmUwVmdHOWjLbs5ImT 0yNmjAvO6gJzaGpoDgU6BONcSJTH48lSyjjLKKtcEItkswYm+0w2b74VYL/5TTZvAAXZbwGTrbAw co5ieoMYT+07zTsC6OzYUSMa5lKgdHA+xjWHNKIajbR06Bc+MtIvN/CI37EErEmmZELOWg4nU8H5 HnHGSCL41YWxeFyEIo8FjoREQvxoj/jYuaUST5bL8Vb+PE9ssRBT72qA06Xzrtm8JRjkdEJZ3qN1 YZkSMBNcOe/TvoAY8g9u+tovX9LHMb65gmXagPJ7ZKmMLnVGF0rjzTPxXG5V9j6ff+zQHAJUO3uS KeHaV+6w8VVXxkCEOkVWZiI8dUKZHUgkY57F49uf4w1EHVsyN+kejbS8UcpCJi17Z9OhiHUyRZvr CyZpfrcwl1LO6ZnpJEaU9cFoUtoA8rtt7bN2aZmTVisjo2GHzvdH4sLIlfarygp1VIbY+iPD8cTb dDuV8q/ztIZng2Mt9g7ilOh1xdRSFWtgZMjcI0flImsZW5y+fJGyXTgk9In3Yil3UUzJDhafCRwc F/QSKesu3+htWH2W4+BhX8XmP3/YV2wLGs21YqWHXHlHRsOib7+cezSWV1uTRDPpPZBYXj3Jharx zvGy7S3Of+X/brco2uTfHOx+76sFpLctNjBgiMqJ4tgujokVKiSuvtRoZkhuv87x9qz21naxVsdc oSjUsfBP87K11IyoD9IIjOPl3v6UTHSqV5Qt11XIy52RRTNHU+lMr7Dgx/vy7NFIKio7eL6387vE 5O05kXTGSnXvkNhfmVDxLyi/7VTrvqugt2eOZdQhXXGDqivVZoyYeV5QzH1vz4wn+/eXWVDQ25aS BvQ8v3739Q/7lKxLqVmBWRYdjrji3ZsxRgqPtny7dyQlO3XtymvWOL/dOzp/QBx3IKRuzXwU9G3T YVOwZhBVpHe5lh2I3+4prHfkmwbJ1z1amiaPvnlLwh6MsjYUm6a10wCYrVZKDO+KncqBcWvsJXWW Fa1fiHkkThSIx8OWLviCSSMoy0rKYWj6m6a6kIz3tyP5hRA6ImtOiAT9WKi/i853YFDWNK/MXfMB XxYYcTEq+n7rd78vi7Sol2TAflcW8WRiUP4QcF8RXdA9NNZrvzg99Pc51ut1/pPkRwfTlXV5D5Bf qp7OC1c7jKX+oSo5sOZVF6lydg9GjBlnUb6B0bh/u404sC8iml1hocY9vde0GEhRw9pi543T6fSG EFTTibOSsL52HKWrPlC6LFMrX5myLa9QdZLDPKqTsGS6ZEYnbU46yf1P5tmjajKGWkma1t4eSOE5 4D+72rIXl6ZjnANG0vsHapIDIsN1zYEKhL9OC9Qa/LGhPlBj8NfmxkB1IYKtn+Z2SpFj6mhpSEiM JLlKmFzWOZp2bUyzCpPl68mrtlaOWU6e/EGJXpkRkxWA90WRqVUqF+X/TKtS+VSlMkb00FVe+Dt7 IlT1i1w3aLlG621t62yxu/HSsYTvTexhGUXUUNj1/ZbHNSNkQMG/smx4JB5Tnf2o1S3wJ3ViHbAT unBZ9eMpb0I4OZYZ+QthY6AQunte45zka2pozjH2vLRUfsSMoB5XHSzbq1lQF0TdND+W8Q8NtZlD OrZbM6lJGBjyAGf6Xs7gkPccd28wLg98tj6qti0Yk4mvYfk0KTg+GdoNz7v73u6DLFtNMnOF3ou1 NwgJiuGsqCvWumFF26yvfDWor55deWqRgUg8bYyjGmkOCD9kFGW8SwaWQ13izPsFtgHKOkBM/ldm JlvHUXuz0HSZZe7x7XcS2i9mPHTPVHattcXc3z4lku43xQQ3NY5Ye6ICcEVwyOjfX0XJVw2NjBiJ qLTYMbnn01IuFDolNVN+fyXSy9px6OTUMJ30Dc6Nbymlx1fDctBJ6eDDVML9J+uW83K32nkzz6eD IqE5VpjF1FoApdsDep7i6w3HWr+28qhWQ/04dGtaQLe8Y7fjq+oa6qc255q1X1qaVdckrCG64sRQ 1UyW2ZK2x2BHkvGxRHKYxu8LWm1MD4jWM7K+BN5dll0nMLJIma52zSGM2ep0PJkxTzJWCwMsd9OZ gJt5c9rObc1sldbni1Sbc5chLqK9QaiHTZucYOYLH9mOIW0uphby7GzpFr6NLJej3mDU0jrTaPb+ FDDba3VjUb8xojay2AN8clBLzCrKGm7axFfjvAO1tQGV9c7n5NPZ5eNN3du2pceG5yfj1eooUDkY qQ+Pyj1JYmmMVBlDrJAPW0Pt09Ca3B068QlvILm6eLm6k18AVQoO+odP7q0o3Thnt705ihUnujrW i20ASXVIjSb6fYtFJ3qbRprG00Pze8ZzmywrrjQdu8TdM/ri9rP9Tug6c0yAL41af2kItaVPDO+K aOqueOoqopUdqck1nl6Jtc69zpuPA3J4JqGr0Oy1kCuPKtSNRw2Cw7ZZVzKs4GogI6qWnVfO9OmC N/tSbgs0XB30lUgdpo1HH4KDr2FrUxZztl5MKdSGTq3VuY8EWMazXVaC1OSUkH9bV2tvR69OJis7 ML1yzeKMp9Pq98bWmWWF0YrS0PeljHicci4XkTiJ0Sv7Wjsn612JKV0DA2ZVYO5GDJvBVK2nVRX0 VreupE3DuK2E4NBn1hVjhTcPemWtfpBeJ4arlvGYhiVKdzuRJsKymQhTC9UmeLN05dULeQW1ZFwG RNgAZpZVgStKnWEJMm3GMVQRwqoEn17YiuAbNhAvdcxr1RuUp1rR4+iaNatK/t0XhFjbZC6Nmtdq HXfRNfcLMD4QHB3Nth50MSqWuvppy6lmSY/Or5YRLlUp8lqsSqQ+OO6YdXlvIduTsiz/XSaK4PW7 5Brqs49mtaxM31igNzMNkREr06ASZXk8GuAbLnS2tncLLyvmsZb5ZD9TOL33djmUiGeOdUYSkUE5 OFsZWF07EvU/4u+i2KHITaAF9lWWglMH93BGWknISDveN/VhIzOUjMoVlGpflH/lt+HsXVOZ6/MZ 4JsYaQ3LLdEkiaNUYwN2cOYskLl1zRuG2hDbO7ezu0afF5a1rvBk1meNtBOSeMXlc7Q1qzjklS++ jj+drB7zya+e9tnVPe07y23r5hlfLp/P0gGPe2ewLyc73Mfzmat7nNlyeeRVZGQkToETQcR8kxOh shIvOp7/o7p0PWzXYr7vdwmjYmEsbVT5vx0WhN8vqG6u1VUNWCC7fd9qV2s7w5UnmfK/7z9AUM7W iL1/yEy6ZxAFR04iJt1x933U2ZIoS721JVFsz5NrrUTpSBKwsA1kxZbIiDlrbyADMTnrM0tsQF4U ERlTJdRGzG3Xm2oUso/bG4bHNaXyqWC6otS3qq/daoccRpG1I9ff54709yVbh5doP7MKQlauoTXU 0twsIGupmNiVq1Y9uY6kiOgHjMb69zdP2/PtKQjTeRF5z27+GmdrJyLqF06PxebdVHJhrh2c9pZy +zkj+wc6fIV/0EgYqUhcSX7Y1ma5XF2UZ/Pcj9G0uTZKfTJYhkjloHAVqo+Yrg6shGeLil4p5y+9 ocilOOLQFHU+nlooulVaeBKN2c23qKRMl6TKjaI3DDPG0mFHxpDngFQaNYM1+mwjM9dYJJafyuNL JrsSVIDe+kcHXEo3nm3ky1NXW8I1wl3kfBVNS+gGadOzjqNoWZ1MyDqK18zjYY2oI0XqLbs2tldN +DNf7S3WPQJoHSbCfvMqSwXi3zfsFlKOTcPi8n9QXPyv6am4Kufz3Rm1DVOYmDmcEaqA8ymL89Hl UJnJQ3nTovZylSp7gZO9cyAqHa5XtotiFKjMnJKZTJjCVoognLGJ1FveT+fY3k91/yGe4iB25TI1 V7/aLc7AiXRCCONcmbh8nL9QqFQ5tNuDrLXzrsIkoL+SChyh7LhsVSPT5q6xfqu5VlVcRFWXnhrS G47bwbPP81ewig6poe2Nl+YaKfSiQIHJqfSgLxcRCbkUl0bHNC+EPebaoKnqILOVFQFYvifSputd TFbRAY2lpa83Q2RIJKP2vsSTkeiU0UzMPtI9OSBCmJ8Up5hYvjDE96LJhQnzdmRoLI0NFXe5e1Gt vsuAJgzTpYW9Iac/MhLpF6dbjMR5TSRNHTrdL130cBOJE25aOf7lZRkPw+UQjdZ+yIiPDIzGhUxk ekVX0PTkMBQbtJzG7NzVW2P6xZnnSpq0Gky3dvIYLGtfo3uzrNIh2zuFCEOeRpbIiE2K3pySz9q5 RBJdmWQffZDQRRhqPCCdkZ0GYT4IA1OJN6N2QVbG0G93+NYvk6Vrnh5R1VithasoYbYa8agVGZei qu/Py7hyQOqGUiEhkKgxILe/it60yHMr1eLjUSMTiQnvJ546xArTDrHDiv34FjBOa26src1yQF3a 6BfmjVNolk1f2pAruJzsj4nNpPLLelLMDKjFY1IZVKq9xdwrKFlNpF1qU6O3xOO2akxx9MIbir07 TZmPhtxU7X2kkNz3GSm9RkZqss+nn+WZMu2JvDpiWfjK9wZib53Ll1SVXRHhAjRYJydIuezbjtl9 OE85WOK0dtBNlOas6HUaA8KFj6gzUqOyTuGDImcjfE3o9QKDKkSu6FyM7+a3gOXsR87iolqNxezG BYNbPlZyj9QQr9bI3k+aetncfZ3JYPaiC+4mw5/HOdqP/HnrPyIlPC/G0dEoVm7Oy5GLAc/8nibF m5/+TKxx+iZmb8TbRbH6Jt5QfC76La/8hvBiGjxk3TJV2+w4OWPGlZ5pFnnJ2JuvWGPwnhemTw52 bUJd3dvC6pDxqwrGy/9cLqf42cqlr3OUTccKcq7ki7H9REfL3JZYSCLC0+C+7Ba0Ss/3plvH9Py9 Ll9U86/nsdMQWloKKS7ja6lVwxyR3W7XmJHdP9adFZ6ifRHx86m5rXVyAibc8a6/QHmD6BKjtPlL QFjFl7sIyFFKGphYLp+z2XTR38lz6c54PNnk2lOyVMVpWl4GFkfB4hRDI95AnMPKUs5kWkB+489N /zHfYeVpnNlal83O1Tc3uxXhhm6evvX4yo/LWJNnF1jr1kNMOys7vRlu523uzk6V52RhzE5vKP4+ UGHmnjcMqxDZLmjcspHtxgzvC31DQaeO4Satt2/oi7urD2huhFL7oFRIhn3ogl8LA6MLg5FUNG6o U7bMnVBiUEdOO0iHldIfkd4ZEXVWIhI4wU8cMJk0j8VyomENSPUnxRBixjAfC3qopSIVo1kpW/hq l6Y9BGnPaUWy+dJRkbbP2bE/JSfBIokxMbrlywxfFCyDRaaZCGVEYU6KSbadpX7yv1PaWvpazJCl x3JfMrwpj1hb0OTUsJ4cEQbraEKMNTjxDMtG5biz8CzxhuGc3+HPEncMgvmSpWzZ+SJVwV4LZGeC FblsOSHSkhlKpqV/Cqf7KtMwSP4EJmc9x46IGBLhfrHRpbejLZs++8ujqbZ2VrhaWmuE0/adHE8O BrUh4HBVt48akKMrYSU14g1ioREbHBLVWXp0WBQr3zsxmi67gITGwe6HyNpCBecM5odGIShGTwVh p8olHvPcl6gVF3/BtGZ2RE/ZjGYWW6RdTU/O8NVRHQP61KZvy4rFlmzM/WGz/y0nOnPmhCyG9YRl vqEMsCr75BtXlnjfd2e3zDyhlM21au1brW4e+SE74iGlOltz5KrB/fqo+5uqSr72Xb22ZmrTZH1r vbJR3dVzt43e1GSOVA7EBkeJmPdNOQVvpENGKUKH5Wp0X1FwbMJxNU4hY4bhSu9SMW8oZsNlDV6m xIv2SUZqo78chBUJM7fqSicA3lAWGKn0qLK4MskMOezsqlRhuLb56lbVH/E55HUUzxyQ7Oxun+3q oqadcfrw1iWQdFUNuCwYaz2dPczuDaAg0QXqMOGyf0ZWcQblsY3vq5XYeShapcu3whSRO+rfkydn faHSfkiv1tOZ0YEBw/QQMtkbgvd1X1SdgVx/Iuz4zBC3c3OIVMxFiafDWkvfVZDh5l/l6L3UwV79 cpTBFZ7IdDPM1kxqXsA3ju+aKVMxbETSoylrJDJn/eS7sihEr1sOM1y5NhCLi12DYZmX8zuJZKK6 0MzNNQCRZRC0R6iJVfJm6H2hxTeyIBKLW0NBOWNgJ0zUKFG599053UP8LcRdjO+yJ33UGR9qfkHZ M0JI4q9habAVVVflwq5NvrvE+uhfp+S7CtJHmbHLRyE3dxqXQnuvDeHzh57ZwbR/bjCWGBlVrYFo /1LJkZQYF7EOYrBnhIQi5GynsOa77JDFzB8aYM175R15k6dK8baYPhRvxNCShQnhNERMkclZK//0 llsw6mQXNYZnLf0SPu2HIqlIP79gNJtRiYVO0Y2K5XzK9qPXLtZ79asg3QvJRAjm+TZR96Km+ZH+ /aXjHNH1IknzY3Gr3yFXKy6oM1cNpdJVIgxlmPfzZYqUuRKquTHsqzXusYhs6V28qYRgaMtn8LvP GY/2Lz50eb0TskP0ga2aIaLzjaBnLWauqc1CZhv8vi+y5Nc4phuKleP2pIBdAUT0uDilV5SoVGRg INZv6Z13EiJf1i/ewqjxHgnsGGFydDUwXWDPFuQY7s9WdHzD/dlkXNBwv3o5IRoJ/+m4zrh9/ndl A6PaEHnlPfXV9a4wllyvut51v5o/nPZFGU80zHCaGwuIA+96omG/637TiUNIGbOycGk6RFo6TmZc a/r0vsBpr3qlqLom2yPT/SGVkN2IBaox96nVruMZO1tafSXEGl2xD7Z3xltiaRmy6i95vR54A7F7 SGbyTXd+Vogh0ZOHU3sDGU3snzC/Zi/KttdOuRYe5HJena3E1WVVDJdi5lOQ5XLeW4vTalXl6Dmb veXuyJhYbuXNSLn6IilXE8m+snWenVwO5DW75e/KoPYpVspaVbyvXA00WZnwImjDdEhkaodXsN5Q qPf7rYWonkOHrOVdanDANJHEcIGKt7+lyFenVIXZUd5AhFFVgEG1GLpVn1W3nIprYqiW6afAGXHw lfKCNMAldH9N49eALC4kRbBi+EGNIAQ6tzmGkszIUTjMpIyo8pEWg6ajIZWWy82X6KAXFJbPTFkK imzrSVH1uCGrHnvb7wJ1ubmxVE0u3WrS7NONS7vcdaQYMJGud9VhaN63nd6BUL0l16bGXNo07oqx yMpUqhiXsGJcHNV11Yo+zdVDurLyWiqaK10ULcthr1xrB1Ra1VLqjOwSmMNVUi2t3rU9DKXGKdyz g2aY6ZrlO3g2byTX0Jl/IIUQrOQpnbczW84jDiRHU6ItFVkhjukwQ/GOA4hpQKQcFUkckwHsYiSi VnL7h5Ji2hqFsIeEZIxTxnAkptb3j4gvu463zCTlynxzEM4nXVHqUu7xv4jVdvhzXuayKSgaaR5O pPONBIY2+4QznpHALMOAMpiwkUDdXT2Hi2/xRgL9Ya1g44CWgHMe6+QeBXSVZlWUg6XWF8Y4RwZ9 ndPQ/BvHuGBx8n+ObwQw70Lk8EE/sfhDJAUZCndpQmiy/g8bCvS+mWdc0BkKDDY9nrWUZubplfW1 Tf4ZHlfs6moWFSN2+RY7FzJ6GV7YfWOX4VpY0MileDV03NJ95V97bAcjbdhOteTFf7mHJPOFM0+s RJqtli35g8s7LOqNTWsikwiJUeGhCOMmSyDjCMXqmOUIJfsgqzuUrFkzrlCyZs344pItawoPpRVL Zclz105Oj3HA4uuLlZyQQMYRipWiJQvFnSKxjsMd1GKlyB/I4qVoCUKxUyRWucoVrk5A409RSCCL kaIlC4USkFV9F680+nVmsUpjQPHGFUpW9V3sFHl0ZnFT5FW8xU3REoSSVX0XK0UBxVusFGUPxQ7E uynR3d6vgJNscljNM4dmdV8Dtmh2Yz3cHKrLlhPuVnmFGPtvNSfm+sXHqkz3UsEBxyqRNfJAXGuR sScYe/jJ3iJjZ6F/ebEa/pGf8wZhdnXlImLllVJ083s72rCkDXEmoVpw7l9i7A1k7rw5c+SactW3 EF0FXwTM7rDoCyYicn2wipIvMlnG7fMbW95wpNuBtNONF9HKPVLvfd8ertJ7R+VCfyeHHf9PzmjH ePW0Ppuehth9E05dzS0G3gw1dye4Fsubuw+yKay3hsyxq2aeuaMh+IXAzphsWyciaeVRNOt2CW8w rr0T4aVsvLNPuS3/Kr82e4PJr9rh2uzPmqWk2g05q2CXFTXh9NrZxuSrK2yFG2dt7A1GRsFbG7tU 2dJQoZf6/FQyEpVK7xej3Ijj3+BTgJJ6Qyms3nVkaWloaMNSSOXraKivpC2Lyrcxa+Xr7eiuhArq 38qYXT9nBU+ItAIPblfLuUPNX8+Yda7pwyk+Frof0azhXRvrvMHkjf8Sq7hXGSaWhjdl03Df+NQK MdlbsoRzWcKBidqsgy6monpDyT5RGzY3uxxUszmHai6+8bviaGjJ+M2muL7iWkjfZ4mWyCwHZZ6a r54dvzWx4mjyymnuKrX0hlJA5eq3BIROegNZUSpYv4ey7DbNyqiSX0wDd/xKHWbdWvWsN5wVQaen Z9Np38TMSthjS4/K/FNVodgyF1NHY2TRD59Ku5Q9VL8JIm2YKm1ks6xd5xYQB3Vgni5df9i6LhaP iUhW8bNMuXI+7i9gvgKxFEbLvAoQGCkLjnMtzkiZVGRf8XSOdjCXrdmba5yfRJOQVsGIrPE7Y/A4 7oylza01Ri4fYVlmPWrzjrk583wrTRmRh9pQhY7DHslSOpz+YDZ7RIRIh9A3SZDdSslpmOSKxZKU haCwl+LIccG1fO7y4A3GXTiWZnnIOg0YnDxfiYuD1xZa8uLgakA8JcMbjCgmhTQZdmvgT4aylZbG TIpf2MWYSCm4efBVLUuzOGSdbQyuAlmJi0NOS8pVOrzhZLG785WLoGYVWi48ppSvhNqHuixLU+oL X1zyz2B61xitdGVG7plZjmZVvTeAFdiscqRejAmhFcG0yjt5+sUqG0tkYxVkXYUVkHFYV45B5Q0j Z7Hw+XXLa16VikXWGdfwZakre7HIY2t5w8g3xhleSrxhBItMAaXEp+XhY1j5bS1vMEtkeJUKUtb5 4awrs1easmQ+qg87fsELscK8gRRQhgJlpcHXvKyg9pdP8CErHVx9lQJKiK8GKWTFr7+EeIPIPvK7 NEtI1knnbLsOviAFJKspNu4CUnCHvmHZD3SNyxQrlRBZQrJOgWfbUfMFKSHZrTJvKKEdmRwFxlfz 5+jI5Cgw/ijknlkMs8rU5Q1nyctWFp35opatrFPxwW2SE3B5iVkkClDofOszvEHMGt/8u6uU+IrF +Obf87Q9S7pgL2zyfTEX6+VQe5+WFz7d7lV7X0W5BGWgPut0e/gm35VmmdXKPOM+fu3PNt2+lEtA QG8XpwR4A1niVqA+6wR76Ab1lbgArERz7IuxYDt8gv2L0ARknVIP9a2wEheAiTar7g1iXCO9419l m2VKfTEXj0+kJYn1WSfRs7sNWelKyUo7j75kxpJ/kuOL0F5knTbP6v9mZS8NE2jmXLzpDWep2U1f xLKQa3fyEk2XT9iy8MWZLveGsfhDTt6i4ysq49rzbBUdbxgr5ux4fa7d00s6Qb7ilB7zTz6VHd+s +NKyqZbb3Hhwo3/ewjCOmfHxl4fgqMO4ysNyWapbn2sD9hJOh0/I4rB8jCp/mVihjKovbFnItfF7 CSe+V3zDKlaa+F6ahSnbpPeS7BOfUBMcappbnDkizmvgs46v0sFUcnREhC7SMTCaEafMG4uQvMhc ce6FVQjnut9SJU3vaGuf29cxq6O9JxCbzth85RdSfbNnViv23tRaymCCLw1LlY46p4CLx8xkuB4o 8DtidM56eRi9FO+mC3nZ/a06O5DZIkvSZg6PLxAzxXq/HQ95UoE8KyJt5eTMSDrW78RU7+xqmzen vbq1q7N7TkfL3FZX5bW4XmnDvi8lHDUWxETmyAbNPsbCq2+drXN7p5iH71gBZfSeSDSW1GfJPl+i f0y3jwoQh1BMUmnQddJuy0XmxGiCiiQaU2WAYm67TVCal57U2TK3raWvq2f36tk9XfO6e11+/13Z JWVi/2Blco6AJ8nQ7KLhfT/3MR92kXAf8yEaBmpL96GaaeuUcW/25T52U+bWOCOfSS+L6Lsj502B GVMreZ40i+ibZcKMn+ugI1s77PB27enoa682G2GXd+amxlp51dRMa1b/qnW5au6Ym6NVzpr6HvHo wlQsY+RIqZW473mTbH8mkF7R+BiqZqaVnJ9cYASdUfnPcInoqmkciYuSMyrOJuFvNBnzq3spThmr EfaGIp7mcx32gWDIUFbFUaupXyBO2MmIM+mFv6x0oKUwg5UhpfVK0bwN2AXWdPQmatvJ2Vss2RzO F+etRqnu+TDNYDIljqmLj+WU/a7C11ZeuTcvJVl3yAa036p6MyJ/3EcxOfZsJO2E61vH1OEvzj47 OBJfGBnzlqOIb/jKCVrpiVIQ1Y7H0sHDfYKLoKSOEMfRhDw3ahRpp3R9bl9vq145N6JqCBQ4TsUd XMzVmxEVRyoqPLoPD8cyGcOYLGp89cccyuQTejK1v1rNp7TLCkGvNGoGa/T2URJhRBJOyJOrQoby zIxbbA1CCua5RlnUaG5f+2waYO/BMCHXAZFhjMTKhslVBTxZ39SsVzZOzv2kc9rNClU35cpN2T7H jcgCY3FyMxMZSU/rSPSnpOLXNWfNTPFgXbP95DSyMvuDDfX2g42VTTkebG60H6yvbM716XpXLCun ZhHjBBRfd3Kh6zTQFTvadq9jHO2/1fw31q/QrX+p7c9ac9tSL6zlrzcF3lC/oss7exvuDcVu0L/o bbitCU4L3p1KDsRcps4EqcB648lMb+zAJY53X6ghmT1G3phbxq3V9S7ItvUGkT+3cuRCTyQxiKhn Rvr3Tw4MoJ+u+cQJIkhvEtoT0YmWgL5FEzn77dhPnJzfOZkWlVZ3KpbkW2NLGusJWQOYedAZWTRv ZGbE9J/9Rc6J2aORVCkrLKUQ3ZNSXqi8oIYTk15f5FyYGUkb8VjCoMpcEHH1+b6AWUEjnRlNfyFz QExP9BopMa3UEuXxpZMVi5WYLJEbS/TLwbAFrgUjxY/WvP7oChirjkTaSGVWyIgtwAKMmnZ9C73k 4ZHMiqRmZk1Ap7dbFJu0XJNR7Pg50aNEiyPg7eDHObJ+wEh6f72yPseI+gGR4bpmMeie9QnXMGzW BHfK9RUyeWLiWtQ8w5ExNX2ZNjJ6XfPOLZ1ifeLO3b07ieEJc7zBFy+xyEQOg6T14djgkFwcNZI0 V3PMp92Sa8rUZLj3TTGlFBscTclQRU7aP3vn/IftdQZy96h/qtpaiyQncu0g1B97Q4+2dw/d+1ZW ZZ9nzfOcHJnL80xnljzMMaGQ50E5dB32jN09DE9gcBg551NZE5d9OCrn09bYT86H+hb1xWjkBrsG BlDHnI+GjKKM43k6znkiUnDA7s542IO+nm+OR7wdwxwP+vpNuYP0dCtyP2pa3Tke8hmlOZ5UhkrY A72xwZ07zIVxrfYyuGxPzksYqVQyZUSzhtWqFrnleGJewlwIJ6yvrE9BIhKfm4ylQ5VUPNIZ6xdx GYgTlmiAsj3XfsCovRRRbD2wH3Pq6MVafKQqv+SA2S55J88xL+dTK3uMWLEGzxNEARao9aS7RjYX bdWZa4PEOP5AMh5PLhQD8rrMV30hreSwNaItJ1VknuuJiCjSoupfoEStNqkTjLmMrqFeXxBJxaRw auxFqYtZ0bcOi/a4JRpNGelQ+fBAZCQifezEhDIQj5BnzOqix0iPUCUZydHQUmE/l/MZVRR2ETMe uR5oRSa5fu9blLXqtx4huoZ/GbP3iTnJdEaY7DkfwhpEfaOdkZFCHsPUzpqNngddeVpAsK6nUZns kvK+ZAzG0hllXhT6Hd8r5seyv9dXZ0o791P1BT3VUNBTjYU8ZRnv8+WC12yPqr6kY07nfKxvkWi2 0x3Dw/7l6OEPtuV9rMfIpHIUO/u59kX9hhHNG5z1WO7U9hxQ2Gd7DrDCyx2a/VX7sWVcr/vG1q33 Qmroesdctlc2Lk4lmkl7a8nwZ9yd/2zPuHri2R7B9DDztiN7VWL1nimm+cIL781mf9rdKc+aVH/d ZPQYB2TPmMJLpD9oYzB/wLMilNzCHjWDFVZI/of7mnJXNGiFWdl0RvpztrHOkx0jBT7o7gwNdCSi xqJ8bzg9nsKe78nVgjqP5euDuJ/1W3r5ns9hBbjSldPmdT+Z2/b1hpnPBnY/nccW9mhCATax1DBV wp3WN4fAgiOeeZ7M1545n08ZkYwhtDzPgx2JLvI1e0GwH+um95fjOXNkKMfPog+USmavHJPRbiI9 jNjmGKHdJPOpttjAgCHam1gk3o60xXqSHI/Pam9tF1pmqlCWLpjzsDBPFyZTUSIxGN6RNJ/t7U/J 2KZ6jWztt3yOWl92N7ONCpiPic5uVAgsz3NzIumMFcfeIVHjJnJ+3o5mtmdChxyzl4bujLOgcPmZ A3m3GeQ2F5TnnWp/jy6mdk8lDLFHK5IaU1u5InKs1NryMCrHSyMLkrGoCKC3s6OVNxdGUmKRlthx ZH6pa346GTcyRogpwjPiciwR8w/mZeVuWF8s/MkQG8H15MGuf7vlkjRj6PrZLRrvp4LCsV4XO8ec Z0Myu9HMbPGU2LG1iCvXjq3grqtd6se7ZcrZvKUiIUKQ1/iCaVyMnVd8qrT3qsC9V7s4vmcWc/eV K4TcM6Ar6v6rpZ6Aou7Aapzq7MAqyhpsb0NV8DR3i54SfRtRvzU1du5woKjjpzXXin/FghtuIlm3 3NhLs+fSEg/pLcNGKtYfSQQXaqu12d4QRDlPj1C5pkaHzfgM0fjMN4yEbiwaiVjLtsWy2eHhZDSw djiix4WhrxtRlZTGqSIBohGTp2qPuH5CPPzmfV0kLZ0cNpxlvZ7l3/6VAeNZVZ59fXrBq8qt5cPe IIaX6Y4y/SB92kq+t8z2rtCsZ9H2bLruX5q+tFame2I1zYyVT9HDohgeq/a+3g7vy+5vzUpamqr8 jRNv++fSbrQVoZ4u7Ubz70bL9WTMfnBq5bQVYt/aUhH08t+3tvjRXpJ9a81NS9Nm6peDPsvHaDJt psb6iWYy+Q2jZpmUCWAKed9f1hvsmhtXaMXMs03eG0xpi51fFzqXyRa7pS/m0h673LmwrPbYLU9J LptNdsszBctgl11Roj8R8763PzocaenPxBYYYlZkue+eEA2RNxWJ0eH5wggYoC4W0aJ6EK7xFg5h ovS2tnW2yDE9zJA01fZoOqPMGG8Y0t8f/T3qE3oDysWcfFZ4lNMTyUR1dyo2bLZ9vjqJGn1BTLQA qgJSRpKwLBamTTdz7imQAUQ1mjL8/W2+1+9aGDHD+zNX3WRdGummLztZ4ZGo3mqZwvSIyDEjRZ6R lsiwP3x1VcpWMKI36NGZ5ivBLkz9ZL1FTL7IoXDp7TBq6LWBxxom67PixiK5NHvY9DSop2kg0qqt lTM7/EPO55ADIvf9zg/UpT6QR+OkrnUbKdEMTcwyM0uIZWm0oMWJ/g7JkRH0V8y9Lu8in6Mmde+N mCjZ2RpPJoxZVDgTLubzRjz9u4kS7e6U0X5Ae8LTPV7B417a1l7a1h7IidK29tK29pC8KG3oLm3o 9uy2ogeSHo5lvrieDsKXei5pVpQ2txcnVqXN7SvH5nYrhCw7snepD9+Tzd9Vykq7srM808J/Qpe8 l3ZuF/78cty5nXUsNf/D7mGw/E/bQ075H3UN7+ROW5Y9B8HRjZxPqZGE3NHKuj8jrGMf9txE2SG/ NDa/ZzH/wh79Au6Tz/rcokz+9Mmji/IlUYaUL5Vt/DeWFuK2N0E6De7E3sLvbb3ttePLYZ992BP+ 3fPV1TmeyrsXP+8OO2vP3ETeZ5/3seC++fyvfLG2wGfUblNRxrtGjFRnHn1wrKXsG/l6x7EZdIXZ gp/zqXHvrM/5VGGhiYNJC02u8ywpdjotK8pGfKrUsK34i1fTljbj+54KVHilzfilPfalPfZOjuWz l30PF57Eguxnr8aJdpbSkb2ZdaWzgKbW5VkiYWRMvR/n41kL3srjd8B8bq6x0El/juLbWXJTkOW5 Fd1NAc/MHMsYzkhlqs0YyZly3+Mz48n+/fPE2hJtHh3p6x/2Casrl7jkiJYrJr0ZYyRPROQrveYq uuxDSp6nR+fLpXZZh+4sBc89ciaeGr9LiKw/muNr8gzuSCF2lP2G651sz6pmXp7OGz6k7HtIHg4v 1CJrYlwPi8OzC31WWOnjCds8ij3n48IiyZM0+xH58bDDvUOenddP0Zydighbv8BXZPDi7ONCP2Ge O17g41buFf74YqTB+sj44jXOlFhnRI83X7GSx5m1hb9hxanwN9zREobo+KM2jrdc0RvHW3YUcx5t nyOS430v2+nfBejQOJXCraiFy8ylq+N6afza4YvfOITmjeP4Xlw8NXHHdTEkt7jK4oqv71X7zYni OmmXetN5UvvcNnH4e1ONrrf0759ILowb0UHlF0e8Kf8jV+fw9qjaDpDWI/pIir6ONJFEbMXK+7ak 6Cnp9TW1eldvr75rMrW/2IggP6fW63SY76bMbXiOr/WeWa3i/PcqfXO/M5vKnllq74Dt1UZ3eYHv UF4YZDTEfIfcCBF0kDNLhhCz/eJsru9pfnHvmklmCg1LSLoRjWUIZmEsPST88STFBlTR69IHxRBz ZjRqiD/2xPqHxJ6MaCRRpbcsiC2Q4cymy8r97JQxqM+N7B9JEEisSj28a3I0ER2r0tujwtZOIkv+ m4ioXSAt0ZjeOxSJm+GYGzpiKbUVJKpHoqI7JB9NjsQSwnDLHnW5giqd1LFJx2SsjYHRuNrHGsdU HRw19JZENPWqPsfYzxhNGPYnhZwzdALiymWWyLF4PDYognZFIILhmM6I1RREYVIzmtNjSXQHfkim xsRf62r03v7kiGEObkod6uyYKbQ449Ene6Nv1FhgxHkjfKevKVahX5avJBEZlUtpqfKevS1qL6n8 onhSBTIqJ4Sl/JQCqF0kQn8jUcvlD1HsT6ZGkmpGQei32Lyp9FsFI7YqxwZi/XosY05xqSJAFPft mLVv+259+nBsfo0u8qG+Rm8Xe0blxlP1+q5id/MCQx8WFQgY6nURV6vckyfSnZYq9sLdlohtjfAc IvYzq3CwlsiFhLFQfM1+VQYtM1StIFcbZPRYVHRa+62lTQOjiX6V3FhmTB6JMCifTslM7Bd/rIwZ ekO9yKzmRn1+LJOeLL9PVNNmBNIUh4ga0lEzfyIZyVRsMCaykXd5y0mSmUsivipAFYj1u7URylXl iRycin7NVaWcdPUYsveN9GVeinJcV9fUtLfek0wbVXpnjfzMTjV6Z39rPDk4lIrx1817Mykqq9GU 0t8OmROIL6TuRNhZ6hdRPvpau6d0dFerekvWSAkjk97c23BQ87fpdc1VUmoickQrMqbXTZ9eW+OO 9NS9qQJEpHesqdJnGdFkSsS/ilIzlBwYoIDF43aCdqzR2yILYgmRFpk/3i+6okyVlElSzjevUvFo suMxNTQe9XX1eTKvNZnoj6WVerY5Lt5ypppQxddSVHt8r87zPZewCL1FuJAzPaur6lt+gpajLxUZ UVvbxKYuocPeDwpd6p3b2b25/c2mLN+cXlvnzmt36nbi3pP63hp910g8On80nfYPWuibd4gxJKvd o1yIDeOj5MeYqRIiOgvqrQjxWV8AO0YSo8IfIfFr9sSvaenEzxK+LiYGVcGUGbiLkZLVc73VWCsl 0ucaGbFtPa8y6ZUqZZOdpJHXWVPTvHRSI5eYUA1niJJcNrTMEtOcLTH1tfUkZmYqEk0QP6Jbpdz4 WWXf5TyA4IW7Sb3abg29MWngczNbu/Xp6qsi5Cq9qz+TFLtKfV+tq5vu/+pOxphwMRB1SoRqF6SF 0pGIitrM0L2fxKgejSk/MjT1NK5pMw51jWYk+JCrzEx1RaEJ48gtRWW79PDP7khKNFpVeluNsl1m 0tJnjIWB9WrB8mKJrsESnZWP1WkzH70BmCJ1S1EuNhN/NKUnIooBNpKKxUUSpnuSQLHfIZJKoTqZ pBnhbky50aGESIoV+V1j+yWE1bZ5S0JvISto1GVj4Y2LqpvS/anYfFE7CR0KjVfaiVidGTFvQIFY 1rsz2omvO7rB2PpyulN4Oh00LC2Unlh4vi2WHolkSJLYEmxuEl6s4jLZSVV91uxu2FuoWUxldKcx JpS3u8avIzRhIu9aRjDPTa8o/rbE/FJD1i81Ujzi0nzEZq7S5wVlSR8vZdXKBvaxMGhEvynuKyOV 83o7J8u8WeBXTm9GufLGG4KvXmlwZVVj1gRQ4VtRnRmilf42eJeYsdBMjffjLf2y0jFnN8wUVu7S 0momKiQd45d4U9ZkTNs7UL93G6Ljl1ZKIGwZI7EwYsSjQhmEgtuq7hN59mbBbb957DNvCG5jzWkj Kns7O1RdLwyUpml2oqYVVjinL58U9hmLMKXjLmNIHTPjCUEmJZiS6dnEM612+UTe7WpXTNZJ4eSI v4r3tFonJaHxb24m83szOyaHRHz5tviUHABpkx3AXCMBIXW36j+22sMC/lWK7j94Xw9ZpahSIaJI 5EcHRdfFF/tpog13Z5NsxnuM4WTGVackE6LHLqrnQtRapMySv2VHTFNN+JguXDy5v9/c4Je+TOWs Gn2nCGlIDCXjB7rNGTk0osZrfFUEhr9y7uURIB9AUUYThu/LDY11S1A9L4/aWeRfc71KhogthcHo N6R7D5JS70nKYlfUS1pPj6Oa9qWnyUmPNxBX4rCMrPEoYdNtbi0O183V4aHjbVZouYbdwsuX9aav mGUvWQ210xosy5RoW705TKXNxThxdRf6UK1CMpcKuGLcaw7PKONiRljBzuo02/uy3ttd3TOro7qj trm6tq52Wv10x1RRCbaLv4hllT6UyYzMmDJl4cKFNf3iq8PiozX9yWEzAQ2LnwDruyrnxpeABXU1 dSRierUVSG09GVxLXgdTUZ8/FY2LlQoZZSsCBce8vqa2uqOrvpoYN9dN9We/HA+0KiFLuZsWK3pO n9n6RO/oiOx+Ks3MFdGu3t5xxlTXVVzpXlKgI/vHaOJES6fPFsWxLTYYy0hzQA4w9FuDbA2pqN6u ximd8Dv7Z6ciC6t3iIkBo7nGQn13qg/3v2iZqBM6emfO1Wura6dW1zbVTa1vrm5WMZi6t9nVNlcE WAVRlmqZZtPhkcrIoBs9M2uJntwips/cXBgQdWIISPXvIua4qni135MiK4h5YkTb1ROdZkpympCk NVBs1ZP9YuWmnfvW8KxZ/XSabXlnX68zoWP3O2tEL9x5XIy7zU/Jfr/Zhsmv0nBv3hKNjIixUxq/ atfBBmoAXO+PR1JOFETEOrvbZ1enjLgYcLU+S36OGiofXVGUJUqXRcoct07rlM/aOqKWQeBzIvOd mNsNO+oyaVqNq+4NHwyVkxpuoynLnErO+l1dobV8liMIZrlnV8I6c3J2J9RQosEqYKRhPAMN4lGz d6k2v+Q0Su0hCGsoJ9dog4is79t+02HS9BrdsWlo8NOxqF2xiFftmRClLXIAJ2LNYCwcElNF0v3j iHT4haYYpG0kSUIiCX1kdD7pEsHErCGoiDQtxPxdWk+P9g9ViRF04WxSOvGKjZhLEi27yRxuF0Gk DDGxJUfa9fljalpGREwcqizsnLj0/RU1EjEKL6+nzTpURpgSoNybOY7RjES0epSHpNPMhD2jUhUW D/GmNcUaXI3omn0N+dGcSRBBGHFTroSq3nEe7JMFTTzshNbpLNFUxTAit0ZJP2o8aifB3G+cEp5I zSkmM/Epc4eJOGc6GpM+yeTAtOn1c3S+HCIyUlulA6/UmPI3xERESrp8s/PO5W/NmhBxTQDZohHH g4hA5CRPRO9s2c3aXE2VpJyfqe3QykFyMqXu1EyQUEwURMbWmnRB1POFLzulpnwtLaaqZPUirO7R eALlFTkVUzNPesIxT43EglgqmZACMB2+p80mU9QVve19etIZiCYA5eMuLQqH4QvA9uJmqi7/k1Fr 8HThRdhMb8IYVFWfMTAgNn+rRsiMkutjKqelxV8nVDuWwbwdEDOB4swMSpuMgvv7xL+dnrceGzAn qexUOu+ab1WKxBmLItJaJ3DVN+roptBPrtINEQpBJIR7VyFpNWmYELOvyviPyCK/cCgppr7Fx8xw rWTI6VtxAoQ1ESp6DhG1jW52e98Uka+VQqxT+ofE5oEpSrpT6FIYGWOyu5S7dUfliZqET8l22HRk K06cEe84E2+ptK0RTgTNXYSWZ0GRDLOKMmsPNR2zoEG5BhRJEQpnmUrx+FiVVWpNRRWvZB+ns8bQ 6Kxg9ptlXpcdLBGGeie0X2UNW/EmpqA3ue5cEFISjTmNEpqdmiILvllYY2bTIeb/E2khHjufRCqV 9mbEE4OxBXK4VcVESAwtSqgJcpVKlf9V4pNKu5UDBOs0eSXnQaHWTiBuIUoXKPJvSTJuJBVL9MdG InGpV5Wywp2sYidLSdzAdowNi+mAlDjeXgYXI+18Z7YokrJkynez6o8w9CfVYXXorfKRtHJdaRoY MgvnjaQzYlktmr0QBRmJpCJqkQpf22pkaCwtZO4yC7aSItyKrrI1Cd2vloSmt6rBcPRlmWHW2dZX rNWtsioyFsXSqgWTJTFCi2mFawW6lZr+72iZ20KRFoti5bP+x9JbyRKepvFuyvJGaFJShpi7pwxg zdSbxkyX8keh4u33myAaQ9tptPNIMHE1utsXjjmXnrFaAVl6nNUI9kIEs9ZTfYq5oh8vZtntmXfz 23nytUbvUmtBomqaQ55GZdge04XjcxELFK5Gn5UcTck2zF4KoVyEiteFKmC0SDugbyhlqMZuNG0n Qi1MMG2BiC62VCVTGOFSFgmztzFq6VdK6JeKu+mG1PmA1X7ZBoYyvrdKDgyI0YytZJKszLQXmtj5 YcgV2FOisbTVwcYgqjZcG3asKtqOjZkbZlZ7ZJ5lc3zIdz32j99g4XcMs3hEnqhGfPql+FUaAm85 x96bijMQW2TIRVbSP6zcREMDKjOfSjpNK6sMAPkV06e4qMrnizXLshDSsEiDxPS2mrasFiFIZ+0G tdeoailCtEvtDdp5VC4usVIlq0zpPV3pgLXMRBiOokCLiJhLRqyw1adb5GdFfW9J0ipAwX3u/syW 9rQIZDgmskJptHfti6u+iQ20L8q4FtO4C6v4lvOdKs/5ADHl58C1Bs6faTmKor2nzC6DoraW87my jpOZZS7wGrbNV1kcVZVF65wkU7OmUATiqVRFIkNy0t5NLHINkalO7phyOazMTmQTET0rw26jWrt6 p+zc1Sv7s7qlZvJTcoxexZAmkH4V+SCjYrr5stKoe8pbNJKJ6GZD29ppZuPCZKGa52wBtsqSkpOd kQVrXa805PLKzrUn0Kq+zRpPBOKLMQYQSSEcPTayoNlZrjam+jRJt+jNHJC665W6XQmLrFUtkUiF ma8uNZAtZDZdD1EDd2qUSnRau95CNWIc6qCaFakRquJ0quUs2eqXIxWbt1pTrYXstFmCVCFW6aYx ZK8rtGpR9e12YRUVIllfZ7HG1AnlXzojlsHZTaXe0kfLNMVsoKwm02morDIlPiB7it521iXhSCbD 30aFBsgVkHLhBNazXwvSTkY6STHNZKvWUXscneRZQwpidMxu0kQoqpNs2SN2/EedvTqyYJr5R6/V UNaeXJ2qRrh8FUqIDypnZaJqCpxjXaz6M+K2bUwn6AV+0ZSX/BrPzBOrIcSWKflREUbgLBnroyKj nIrb/MB4vyvtRWflpfUds6Ut4FOOizLX0aSuENXK1ahqt+VOWq8GJ6xv2RoZYiY6XTxz4NLsy9kD E+bbI6rH7lqH7iqXITvMpf44jaXzmGdzuXtlqho/tUpkr919SNlDmqonkbAHO8UnYs7gp+yg1IkO Cr2oeIzs6DHSyfioTJdc8OpUcnS+nAS6/+q2ryNpNf7DvWHIGVnVOxIjBp7FopXtrXMnW5WFmcF1 NXU+W1zV6LIXnZb224Aql04LKJaKieZAqFRrp180VntgDXqLIitrfDW3rcp4cMmvs3TZ6ovJ7qdQ FWsG1Rl/65ml+qXiW04QYnn3oBh3clUrMXPJrLTp7bx0jhsYMRe/2XWurPoz5jJuFDs9ZBoFqio2 szLQHBGdGTL4usl6q7l62cxicj2tVybT6frqhJhiqWuewo3576lmBzilVrzJsuCIZooobN78lQ2W NVgl4iASa53S5Moilc/+9jJtdWRUDiolrp+srLGIOG5KRNYusmYS5fyJWrog1raq8byko/JmqxIW lWzxULJzGjgrCFFM5FiGVZpUFBv8UXR1MAKCUK/MsmWsGjyUeUQeqWjWU7ILNzAQiWFyxNSBEpHJ 7mLROa+3z85pkTSVZ8G0yE0i873vtuxuv+oYOmYAQqjuV/uzvmrmhq/ou16NTnZXy54Yi5bXFWv3 W0bwrbldfQV+dZI+qa6+Rk0/xEV1Llb/dMvRISx2q4R1tPfNohXfXyzzp/lOpuWAOnkxGEmZZ4HI 00JiUWndpfS02HIhZZIwu9Ou4EfM4MWD5mmZ5gCRKDvD0iyaL6282LBhDVaINyKxhFXh+aopcy2q paVG/1AiGU8OjtnNkKiFlFa693yYlZq0zaVvTzXvQaR16nJDDK+rQ7zEhIYZSxGKiiNvq3+IwVxx dMoCmhlRuL6HqGIyYdGkaEEyzhSHbhqsIhRRSw1HhL3B94yBAVkHJK1Kbkz+2fXhGu9cWNIeiBHS 2SqtKr+oHBOVDY8YQRSVpijbKn9jrmO/qjOpSP/+VoPt/NmcO7TzKGKPfc8X5XlUNn9i9W612eyN xOQ5dFL1hcRke21+UKXOyhbZiKiZI6dxEYmkqh9NSbeoZm1sZr6sHeWwijuYKkts5tyQ1DJhrwqX OPJZKegkSi41JqIPGmL2IG7LVETD3nluN22mAqXNqYkRedqbkRGzsmZyxAi+e3BaaV0qbQ+vetpe mSMq31RMjKgavsxYJarX6E+JD8QimRpvWYtJdz9pmTtywM+QrTfmiRoLni8tA6EswujKmF4NrdJG 4RtTUa7ilYyamEqZ/1RdJds8sMugK70iDE+RjIzp6uxBV8myf5lv2O2dMu7FyJnVjIhMMXULbenG AE/LPU5yJ5ssyC6VNsu2zIH2RUb/qLCwZBsaE44Qkilyqa5BTDGOZoaSYmrL9EQiM0/sTInqPZGB jPJ+3YfMx5Jis2IiEo3oczJRXV2yCWqsFQ8g21nJRXpbig9V6b2jYrKqvlaeod6VyUQWRujYCAHJ KkgFJP7VPYRNNEPXt67Tm+sa9Kbp9XpdbVO9qEj0+nr5ens17UR8Bv0VYlWTkrHaPqOiJJaw6M5F ohrF4cGjcbHSwhSdM1ls2uXW3ytbVevprP1P9iO2MXm4YsNkkTuE06PEJ1zspRZY9q13A6Xso4kR wnjEtrNjtkj7RcGOyocGRlNidtGuiqW+2G2+WKglLWO56lyphZrmEPNitn4tFHt36I/ERZFU9R8/ qT18uvxT2l+pmzGh5kTvjWiVGacqVYeICIlQZCyE4z3ZW+VXAls4lIzLYs6/R+Rib2taTxSkVMze MWoWmP1jCRGsNY1kT7GoIyDt4iRtcHP3oVRt0V0YxIaSFYYYXTZ7WHI3qWiyZfXdr+rIsOxCWjsk F9KdTzmnMNoCMmf8RDaYLcywdQ6jHHAY0xdGxqrUN+TQqTBOkmIWSJW9kJgn3caYXd78mmTJTDYu 1o/J1GAkYfbC02Lcsd8YkW6vE9InnV2Njoxi+NvHX5mbKeXMpBWS3dgoUYkWV2whVG87jZi5RMKp zLwz0aG7X6wOgLmJT7yvegdCMaS+eeoqS/0NofiymxKnrzUaETNN5jGrQ2rPZntiUKicU03HY8Mx WSU7LkzEHle5iEGpjdAHfh0xpNEjpC/XUyhRyirWWJDc37BHKsPEIEoF8hVpSqoGR3WL0lkLtK9K FZO9qukRk8CinLmmS2WLIcLZvKVX7+jdXAxux5Si9u3QLs+77pnb3qf3drVSJ++ut8xt8/7QPnd2 x9z29p6OubNldFp6d9JndfW0tuttHb2tc1o6Onv1ljlz9F1benpa5vZ1tPdW6e27dfeIhQJdPXpH Z/ecjva2KgJsnTOvzQxl5jxlwM7p6Ozoa+eLXXx4dyuM3YlBS5+Mxrzedr1rlhkjPtvZYu1k36G9 p71jrr5rB98WQfGziGO7DKinY/YOffL74s6MgyuKhCnC6Gzvad2Bv7TM7JjTwWd5flZH31wR9Vni Xb27paevo3XenJYevXteT3dXb7vZVcFGcm90EdPA7WpHtDUKKn3Kq7H0+Jh/+tpT6kxdEMMMk+w/ tonmZA1z+RM9Atciqo6Za9irVRt4RzWHa7QvGomJMtVLmbWXCTWssWe32KyzHkkhb75WV1e7/t7i Q9Zb/t/NXydppat0la4v/LWKpm0Km8FMaIUxOBAuhyvgSviACuPPa2vaDd/XtIdBO1/TGuAr12ja XDimqkxbs7pM+86UMu0SOLquTPtyfZm2dWOZthf8Z5sy7Vvblmnz2sq0W+Gtncq0XeeUad+dW6Zd Dhd1l2nb7Fym3bNnmdawV5nWlSjTDoC1bivTdoEN/limReCVu8q0irvLtOY/l2k7w7mrlmsbrlau 7XtYufYbOHrVCu3q1Su0L1dVaIfD7t+v0Kq2rdBe369CmxWv0P51UoVWd3KFtsmtFdqOkLizQjsf LoB74T54CP4Cj8D/3lP/9/JTDyzW//1Pu/e2e2+7ngxbr3XHr2n77FihDe+grZKA0dXLvlqxn5CB +GXe6mXix9Wtp7RNundcRRvYQSsb3mGttQ64f02e+5yL/0nzh/WtXz2/bCTeDv3lK+KXLsLdGWT4 q4i/zBby/5pLB2pcepBw6cIP4WA4BE6BU+E0uAw+duvTv903VxzvuvE8dq7nsaeyPeYN7SvZHjvV 89hQtse8ofVleyz7tcZGWsWWZRtsWdYxUMZtZMuySeIv5esccc3n9l/34SayZbk2U9P429etP5ef EtdWf6xWK9e0wzao3EJb9bANPvdd2qoXr+X/29c+4OVvPLa6db+x889vOv/cxPln42OramVrVsS1 yAf8R8a43BXj8lU30uxb7StC/qIMfCR0/X+50l66Vq5rlVW0srLyy3z1/FVwNbwDVV/StGpogZnw U/gd/B4+he1X1bTD4Tj4BfwV1llN0953f+Ya983V7psrV+YbeZWtA+tqK0ZNsOZG2jpHaJqrmuI/ XxPyaodj4Hy4AJ6BtVbXtEmwM4zCAvgJHA1/hv+Dv8FjsOEamrY3XAi/hxtAo+3ZAY6DP8MT8CRs /GVNmw+eqqZ0s/xunEto5yZCFhfDbXA7/Aueh63X0rQRuBrugXvhPngSnoItsAf3g9/CR7AdtuFR 8MDaQqk0bU84D16FWtrthfAH+NJXNW3OV0uiKNqNc0n5C1mcCE/At6iqhuAq+AC2WU/TjoA/w7pf 07Td4Vx4GWrWp16AW+ATaNmAugEegrW+rmm9cDo8BxtvqGn9cCn8B6ZtVBJF0W6cS8pfyOJQuBsm fUPT+uAM+BdM3pg6AH4PN8CNcBO8Aq9C7TdpF+B4+CU8Al/fRNP2gkEYgqvgfZixqab9CE6DX21a EkXRbpxLyl/I4nS4CC6G16F2M9po6IcEJOF38Bl8VacuAB2+BVG4DF6Hmm/xLFwLH8MnsP3m1Atw P3x1C/QLFm1REkXRbpxLyl/IYgx+CSfA3+Cf8BysvSX2PMyFE+EvsOa3Na0eGmAmtMLhcC78Gp4D /TvoBjRAI+wD+8J+sD9c8Z2SKIp241xS/kIW78LUrWiXoR1mwRFwF/wNHoOX4RXYolLTtoRGaIKD 4Gg4Bs6AM+EKuBJugpuhbDI2AUyCTWGzySVRFO3GuaT8hSz2ggvgBdjiu8gXdoYeOA5+AbfCH6Bs a/QDfg63wK1wD9wLT8HT8B94B7aoog2Bc+BcuBp+C29UlURRtBvnkvIXsngT3oL/wqfQUk1fHx6A r9RoWhcsgjE4CU6G2+GPsPoU+nPQCcfCb+AieB3Wr9W0DWAfuABehbo6+oJ1JVEU7ca5pPyFLP4A L8HLUFavaeXQBj+FU+E0+Ads2kCbDo0wBhfDJfA2bNZIuw8GXAAXwq3wByhrQqdgJhwO9zWVRFG0 G+eS8heyWLMZuUIjLIJbQJuqaVtBJcyEVjgSToST4O+w/jTeg0ZYBLfCO/Au1E2nbwAGXASvwmtQ PQMbcEZJFEW7cS4pfyGLOFwL70HZ9yj/0AG/hIvhEngLGr+vaTvBHOiEBbAQrof/wcxtqDPgdDgD roFr4RPYbltN2x1OhT9sWxJF0W6cS8pfyOI2KN+Osgk10A/nw/OwxfbYh3AWPAObtWjaD+AceB62 mkl5hqvgavgtfAzbtWraj+DHcD/8GSraNG0V2K6tJIqi3TiXlL+QxZFwH0xqx9aDX8IjsP4s7Df4 OsyFLjgSbob/wFazNW1vOBHug8+haQf0AX4Nf4dJHbQd0AY/gQdhvR1LoijajXNJ+QtZ7AmnwEVw MbwO6+yE7Q+T4bswAsfCz+Bc+DW8AhvN0bRvQCM0wTBcC9fBn+AuWLNT07phBA6AszpLoijajXNJ +QtZnA2PwkZzKc9wPrwKH8MnMLWL8g9dMAxXwvuwUTeyhz1hLzgbXoRv76xpMRiGq+BtaOrBXoAT 4aSekiiKduNcUv5CFn+EO2CVXk37EsyBTvg5PATr99EOwDTYATpgfzgEDoVfww1wIzwJ78C7sP48 3oNpMB32hL3g3HklURTtxrmk/IUsXoStd0G20AHHw9/gI/gY1tkV+cGP4BL4D7wDq++mad+CGPwS Hocn4Bu7a9o8+CEcBDfBa/A6rL0H4e1REkXRbpxLyl/IohPmQhyugPdgwz2p32EP2BPOgufgW3vR p4cBuBj+DbV7a1oGRuE8OB9ehJegeh/6FJCA38Gn8L99SqIo2o1zSfkLWWy7r6YdAXfBS/AybP0D bDU4EU6CS+GPsGqE9gEWwEL4OVwAr0LVfPr4sAecDXdCRT/tCsyCY+BqeK2/JIqi3TiXlL+QxetQ H9W0MTgQzoQr4Er4C7wAL8J/YT0DWw6aYQ5E4Sj4CVwCl8L/wQPwOWgD9B9ga0jCL+GugZIoinbj XFL+QhZrDlL/wynwBLwGr0P9EOUWZoMBv4HXYZ0YfUPohp3hV/AYbLIfz8Hx8Et4HDbYnz4FXAiv wYZx2pV4SRRFu3EuKX8hi1kwG46Bv8LXh6nH4Wx4Bj6DDRPIDX4AF8NbUJtE/tADvXAiPArfGNG0 feEMOBMuhX/Ddw7AxoArDiiJomg3zqXWfyCLB+Eh+Cd8O4Xs4EK4B+6FZ+B9mJrWtIPhTngd3oCy DLoBe8C58BKsPqppa0AXnAI3w3/hU2hbQFuxoCSKot04l5S/kMWV8Aq8CrULsevgBDgRroe74R54 FT6B/8JXF2naZNgJ5sB8OBDOhLPgNrgd/gXPw2ZjmqbDtnDoWEkURbtxLil/IYs/wSvwKkw+EHsN 4nAJPAlPwaY/pB8Iv4QT4ES4Hf4IFQdh48NOMAd+Bg/AegejT1AHvdAPUTjq4JIoinbjXFL+Qha/ gtPhFngEHoUPYNIhmrY21EId9EIfLICFcDNoh2I/QBQMuBz+A187TNPWh62hFY6Fa+G/8OlhJVEU 7ca5pPyFLNb9EWUeUnA6/Auehy1+rGn7wBFwJNwJ78J78PXDafdhe2iBI+FyuAKehS2P0LQhuBre h/IjqSdgB9jryJIoinbjXFL+QhZ7ww/hFvgctjgK+cH+EIfL4VXY6CfY9rAHnAp/hv+DB+AT+C9s czRtPBwJR8HdsNYx9BGgF06CJ44piaJoN84l5S9ksfFPNe37sA38CO6BV+E10I6lrMNecB48DI/A q6D9TNPa4Wi4Hn4Hn8BmP6cPAT+A8+BFWOs42gmYDccdVxJF0W6cS8pfyOJv8Bh8BGv8QtPWhCrY HlpgV0jCL+EEuBhuh3/B8/Cl4zVtVaiEydAJc+EUeAw2+aWmTYcZsBv86pclURTtxrnU/i9k8RRo J/AH2B5aoB+icDFcAq/DG7D1iZq2M/RABkbhVDgNnoHNT6L9gEG4DC6HO+Bx2PRk+olw6MklURTt xrlU/w9ZHAanwBXwDjSfQlsNfXAa3Ar/g89g+1M17XC4FN6A9U/TtA1gbzgPXoPXofZXmrYIxuCP sMbp1Cugw7TTS6Io2o1zqf2/yOJguAtehJfgZXgFPoMNzqDfD+fDnfAnWOVMTdsODBiAC+BR+Bus dpamrQ5rwEbwDZgJrdAJA/DDs0qiKNqNc0n5C1mcAVfBHfA3eAX+C2ufTV0OrbAvpOEoOB2uhjvg OfgQPoJ1z9G0BtgdRuE4OA/uhSdBO5ePwsbnlkRRtBvnkvIXsuiDn8CZ8Af4D3z715rWAQacAH+G /4N3YPPz+Dv8Bl6Brc+nPoAfwx3wEWx0gaZVQyecDI/Dphdq2i6w4MKSKIp241xS/kIWNwh5QOtv 6O7BI/AmrHURugFnwuOw/sWaNgXmwgnwN/jyJdiDsB8cA3+GL1+qaTvBfnAMPAjrXKZpO8CP4bbL SqIo2o1zSfkLWXwIG15Onw8icCG8BN+9QtOG4SK4Fx6Dv8M/4G34N3z1St6DDtgbzod/wbeuwlaE FvgB/BBOg8vhnatKoijajXNJ+QtZVF9NWYVj4KdwFTwIa/2W32AW7AsL4TD4EVwC98Ia16An0Ap7 QhQM+AVcCe/C165FR6AFdoXha0uiKNqNc0n5C1kcAyfAiXAn/Aveh6brkDncCE/AO7Da9bwE9fA9 +D5sA6NwHbwrfvsddiA0QxvMhh1gJzgOHvxdSRRFu3EuKX8hi5fhNXgd3oD1f69pPTAKv4QL4QVY +wb672DAZfAofAQfw+Y3alovLIAT4DfwMqx+k6bNgUPgNLgH7r2pJIqi3TiXlL+QxXtQfTN9czgH HoNJt1Dvw0FwFPwELoIH4Q1Y/VZN+ybMhwvgVaj5g6YNwilwKtwGb8Iat2laJbTBbnDmbSVRFO3G uaT8hSyegy1up1zDhfA6bPJHbH3IwE3wBKxxh6atCTWwByyAk+G3cBeU3YnOwM/gIaj4E3UJ7AHn wk3wKrz2p5IoinbjXGr9N7JY9y5Nq4UdYB/IwE/hJLgWHoLnYcu7Kd9wKbwCVfdgy8Hl8AeouJd+ APTDCXAi3AyPw39gtfuoB6DjvpIoinbjXFL+Qhb7wbFwBTwI/4APYb37NW0riMGJcBt8Ck1/1rQD 4FJ4ETb9P03bHY6HP0P5A9iEsAhuB+1BdAuOgDtgjYdKoijajXNJ+QtZzIUT4ET4G3zzL5rWDkfB bfAptP5V046G0+FZ+PbDmrYdJCAJJ8DV8Gd4DVZ9RNO+AfvCUXAvrP2opvXBrx4tiaJoN86l5n+R xcPwAkz+G7KEY+AGuBGegk9g3ceou2E72AXisABOgqvhT7Da39El+DH8Dl6HLf5BfQE/hNvgPdji 8ZIoinbjXFL+QhZbwlawH1wJj8Hj8ASUPUEfH/aFH8Iv4G/wJnz1SfQCpsMQHAsXwc3wGWz/lKYd Cb+CZ0B/WtO6Yb+nS6Io2o1zSfkLWZwKp8EdoD1D2w0Hwg3wATQ+S3sPV8LrUPlP+opwPjwHmz1H 3wGugNeh8l/cQxJG4Di4Hh6Bt6Hi+ZIoinbjXFL+QhYzIQkjcDLcCc/C57DxC/QDIQU3wX9huxc1 7XA4D66Dj2G7l+jbw5FwFFwEj8DbsM7LmrY1bAc/hvteLomiaDfOJeUvZPHVV7DfYRH8FB6C9V9F 7rAX7A37wLFwKdwPL8EnMPU12gX4I6z+Ov1/OBJugs9gkzcIBzJwEzwKZW+WRFG0G+eS8heyKIfv QDsY8CM4GR6BDd5C9nAs3Avvwpfe1rQd4Xi4Cp6Cp2G1fxMOtMEPIAPXw/9gq/9o2jBcDW/9pySK ot04l5S/kEXzO5p2ENwBa76radUQgx/C7bDqe9iIsDP0wI/gIrgHnocP4Xvv0ybAvTDpA/r7sAec Ay9C+YfUA1ALe39YEkXRbpxLyl/I4nA4H26DR2D9j5ARnAcvw+YfYwPCGNwGT8Ean6Ar0Ah7wIFw ClwKb0HDf2lP4Fb4CNb8VNO64GS45tOSKIp241xS/kIWz8I/YXUerIG5sB8cArfDlz6jvodfwP3w FHzrc00bhCPgGrgW/glraWXa1jAL9oDj4W74H9SXlWltcExZWUkUxbpxLil/IYuH4D+wWXmZpkMn LIBT4Bq4Gz6F+ooybRQugN/Bf6FllTKtH34JJ8At8DxUfInwoAFicAm8DB/DtquW5F+0G+eS8hey OALOg7/AX4Vs4DurlWnt8APIwKXwDnx39TLt+/AjuAdehvXXKNM2gGbYGw6GX8EV8DRsvmaZNgQ/ hpPg8TVL8i/ajXNJ+QtZbPZlZAr7wf5wPNwIj8P7sMZaZVo3nABPwMaTyrS94Gy4H9Zau0zrhV/A X+BN2HidMu2bsC3sDQfDr+AKeG+dkvyLduNcUv5CFt//Spl2KNwNa32V+h9Ohr/DpuvSjsOv4B64 F+6D12GN9cq0ydAOu8MZ8Axs8TXafzgAroH34Tvrl2lxuBYeWr8k/6LdOJeUv5DFOhuUaVMhCdfB J7DB15EpHAApuBregXU2RD8gCb+Dz2Cbjcq0w+E+WOMbZdrOcDI8BH+BdTcmLDgF/gR3bVySf9Fu nEvKX8jibngT1vpmmVYFO8BecAG8DtWbYPfB+XABXAi/gYvgFdhqU8o2nA+/gX+CvlmZ1gFzoBOS cCHcCy9sVpJ/0W6cS8pfyOIjmKGXafvAvvAjuAwehNfgM2j9Fn03+DHcC/+GTTfHdoB+uBCehS23 KNOicCk8AxVblmmrwA5wLDwMr2xZkn/RbpxLyl/I4lWo+jZ1PaTgRvgUWr+DTsDhcBlcDn+FNbfi NzgIroe3oLmyTBuBS+A5eB3egC9PLtMaYVdIw0/g7skl+Rftxrmk/IUs3oFvfBebHbaFfjgczoFr 4R1o3LpMG4Tz4Vn4DzRXoQNwJvwWHocnoLy6TJsCXbA/HAq3w6ewfQ3v1JTkX7Qb55LyF7I4Dh6B jaaUadNhBnTBQlgEv4YH4S1Ys5Z6HwbgPHgG/g1NdWXaD+EMuBr+AY9DRX2ZVgvdEIfD4M76kvyL duNcUv5CFp9DewPtPpwI/4BNG6kLYDvog4PgYPg13AuvwGpN1BmwLxwPd0NZM+/AwXAHfGlqmfZN qIE03Ah/mVqSf9FunEvKX8jiRZg0rUxbG6bBrrAQToSL4HVYbTptPuwFR8CRcCHcCc/D57DejDJt FzgT/gkbfK9M2xFSkIaz4G546Xsl+Rftxrmk/IUsyr+PrGAvuABehC9vU6bNht3hbHgBVtmWNgJa YCYMwrlwJzwL78KM7egjwN3wGqy9fZm2DjRCBI6Ac7cvyb9oN84l5S9kcR28CzNakClcBm9Cw8wy bT84Hh6DSa1l2vdgHhwGP4JL4Fn4Whv9fTgEfgsvwabtZVovHA23wN1wD/y7vST/ot04l5S/kMU6 s8q0auiAveFceB7ehxmzkTWcCffAvfAqrLZDmfZtaIF5cBI8DGt3lGk6GHAZ3Avvwnuw/o7oFOy8 Y0n+RbtxLil/IYth+BHcARU7lWltsAucAc/BZzB5Tpn2XeiCYTgWLoKb4TPYrhM9gRPg77DJXHQH DBiAo+ECuBWenFuSf9FunEvKX8jiQ/hyF7Ya/AIeg//BOt3Y/nA63Awvwcuw9s7096ALhuEYOAue hc17qBPgR/BH+Ay27UUPYCHcAuV9JfkX7ca5pPyFLLaAudAFC+AiuAueg/ehYV6ZNgo3wv+gYRf6 i/BT+Au8CRvuim0I28CeMAYnwyXwCnxnN+w/OB+u360k/6LdOJeUv5DFJ7D97rT9cDQcA1fAn+FV +NIeyBb2gDPgSdhkzzJtCmTgJvg7lO9F+wFbQwcMwuFwKjwBG++NbsCv9y7Jv2g3ziXlL2RxLXwE 2+6DfOAncDQcAz+Dy+EquBr+Af+DTfelrEMf/AqeAe0HZdq6sCucBdfBk/AUPA3/hPfhox+U5F+0 G+eS8hey+BhWiVDOYVVYAzYBHb4F20ISToAr4Q4on1+mzYQoGPBjuAjuh5fgE/h+f5l2KNwJ78Kk aJlWC3XRkvyLduNcUv5CFjvDT+D38AZsbZRpzTAVdoUFcBJcDX+CNQewFeAkuBv+AZsMlmn9cBic DxfAXfBP+Bg2GEKfYFvYY6gk/6LdOJeUv5BFAn4L70BTrExLww3wKVTth6yhG3aGw+FeWH3/Mu1r sD58H/aAMTgFLoUX4AP4Xpy+AJwN18Hf4R/xkvyLduNcUv5CFv+Fbw4jK9gV9ocL4ffwKcxMlGkx OBTOg/PhN3ATvAyvwevw5WSZth3Mh0PgBHgIPoVNR8q0zWA7GBwpyb9oN84l5S9k8VP4Ddwk5AJb H0B7D+fAjfAs/BMqUmXaDFgAV8Er8K00ZR9OhIfha5kyrROOgtvgI6gbLdMOgBvhPfhstCT/ot04 l5S/kMXnoC2gfYZtoQ+G4edwBTwM78CkhbQH0A0L4Sy4Cf4Oz8HnsPEi+oVwAFwPH8LGY7wDJ8ET 8MZYSf5Fu3EuKX8hi7oDkSecAH+Fr/ywTJsNw5CAn8Ot8CR8CF8+qEzbCY6E+2HSwfQFoQuOgwfg U9j8kDJtC2iHfjgEzoQbDinJv2g3ziXlL2Txf7DuoWXaZPgeHAZ3wwuw5mHIG6pgRxiCI+A0eAze hvV/hH0PM2A3WAAnwG/gBVjzx9gXEIGL4E8/Lsm/aDfOJeUvZPEavA5vwLqH00eHubAfHAJ3wKOw 0RFl2r5wEJwH58N98DJ86UhsAWiCMTgW/gIbHFWmNcDusAf8DC49qiT/ot04l5S/kMW98AJ8BNv+ pEzbBYbgCngXvnJ0mdYMUyEBP4NL4W54Ar55DPU/dMFJ8AR8CJv8FLsfWiECh8IZcNVPS/Iv2o1z SfkLWbwu5AEzjy3Tjobz4D64H96GST+jTwCzYU84FS6Bt6Dx59QVMAoL4Ay4Ef4O78JqxyF/mAen wz/hk+NK8i/ajXNJ+QtZfOsX2GowGww4HM6Ba+FtKDu+TJsFP4PfwAPwIHwEG/wSHYBuiMKv4RZ4 ENY7gXofFsBZcDbcA2+cUJJ/0W6cS9n/yGLNE8u078AMOBRuhI9h25PKtAPhBvgENjy5TPsuJOF6 +D94F96DTU6hTwD7wU/gTHgOtjq1TIvBD+F2WPU0+gSnleRftBvnkvIXstgS5kAnLIJL4B54Hj6E bX+FXOEKeAeaTqfOhx/AhfA6rHpGmVYNNTAF6qEXdoFdYQyuhL/Cm2eU5F+0G+eS8heyKDuT+h32 hkPhMPg13A9vwhpnUb4hCovgBvhQ/O1s+oRwAKTgFHgAVjmHfiSk4BL4J3z9XHQGjoSbzy3Jv2g3 ziXlL2RxN9wDL8Lavy7T6qATInAhvAY155VpabgenoKnoeL8Mq0KdoQBOBD+CKtcwN/gSLgcroC/ wbvw1QupJy4syb9oN84l5S9k0QJHwwMw6TdlWh+cCffDU/Cti8q0QfgxXAKXwl/gLVjr4jKtEr4P h8O98G8ovwR7En4OF8ND8Bd4H9a7tCT/ot04l5S/kEUddEIEfgMvwSqXYdvDnvBruAWehxfgy5eX aZNhNvTDQrgR/gMVV5RpO8BxcAn8Bf4KH8DXrsQugLlXluRftBvnkvIXspgPF8KT8KaQ0VW083Ai 3AQ3wy3wPJRdXaZtBt+DLjgZHoBnYcvfYifCkXA5XAH/gA/ga9eUabXQBsdeU5J/0W6cS8pfyOIv 8JVrsdPhHHgAnoUtr0OecCRcDlfAY/AerHs9NgHMhGPgQfgAVv8ddQmcCFfCY/B3+Ac8Dk/Ba78r yb9oN84l5S9k8Sa8Bf+B1X5fpq0JX4bvwt5wGJwJV8M7UHdDmbYvHA5HwPlwP7wJa9xIvwCicB68 BBvcRNmHebALLLqpJP+i3TiXlL+QxeXwImx6M3UAnAP/gPVuQZawKWwGM2FvWAAnwllwM/wdXoct b0XucAG8AOV/wEaAY+Fm+Cc8B6vcVpJ/0W6cS8pfyGJrmAvDcAycBS/A2reXaToYcBncDa/DG7D2 H8u0ZtgdFsFJcDG8BjV3oEcQgyvhPVj7zjKtARphtztL8i/ajXNJ+QtZHAZnwQ3wf7Dan+jXw87Q A0fAXbDKXfwddoQYHAWnw5Pwrbsp+3ApvA3fvYc+IfwI7oFnoOJewoC6e0vyL9qNc6n138hid1gE J8HF8DpMua9M2wdG4Hr4FKrvRx+gFxbBr+AGeBRegcl/LtOScA18BNv8H8/BT+EhWP8B9Ad2fqAk /6LdOJfa/4sseqAXdoHdIQkpSMPJ8Gd4C9Z8EFsA9oWfwpVwFfwV/it+e6hMmwFz4VC4E96FSX8p 05qgGfaE0/9Skn/RbpxLyl/I4nHY8K+02XAKPArPwLOw1sPU5bADRGER3ApPwptQ/wh/g5PhFPgD 3AavwxqPlmlbQSvsCmfB7fDwoyX5F+3GuaT8hSy+/jfsejgQzoPz4UF4A9Z8rEz7DsyAQ+FueB3+ BzP/XqYdDRfCA/AgfAQb/AM7D7ohCpfB27Dh4+gSJB8vyb9oN84l5S9kcT08DJ/Af2GrJ8q0duiH Q+FE+Cv8F7Z4kn4e7AQx+AmcD7+HD2Czp7DvYAHcAo/BZ/A5aE9jA8K3ny7Jv2g3ziXlL2TRByfB qXAa3ALvwdefoc8Gs+EouAGegqeh7FnsQeiGOBwGN8EnsN0/0Q04EU6Cm+EjaH6uTDsE7n6uJP+i 3TiXlL+Qxdr/ojzDMXAfrPJ8mdYCh8DN8AE0vEBfAK6A16DmRco43AgfQtlLZVo5fAf6YCGcCBfB m1D3Mv0JOBqOebkk/6LdOJeUv5DFNfBXeBu+/Ap1OEThcngUXoKtXy3TDoDj4Aa4EZ6Dz2GT1+jr QzecCk/BFq+XafvBmfA4rPUG/QxIwq/eKMm/aDfOJeUvZHE6/Bneg3XfpGzDTDgK7oN/wzfeKtM2 hh0hDb+EK+CPUPF2mdYG+8PJcArcAk/A+7Dev8u0KdAKR8GF/y7Jv2g3ziXlL2TxMqz6H+xz2BvO h1vhZXgF1nuHfh50QxwOgzthtXfRBzgeLoVboOw97AUw4BdwPNwG/4a138f+h23fL8m/aDfOJeUv ZPFjuBvehrIPyrRZ8DO4CP4KD8MH8LUPkR/MhAj8CM6EP8Iz8DFUfFSmfQu2gZ3hRHgE1v+YcGEv OPrjkvyLduNcUv5CFufCc/DtT6ijYT5cBPfAOv9F5hCDX8Lv4L+w3qdlWi0cAD+Di+HfMO1/ZVoC ToJH4TX4FFo+o68I58MDn5XkX7Qb55LyF7J4ED6E9T/Hzocu6IdL4GbQtHJtFvTDcfALuAEeg/fg K2Xl2pYwAD+CE+EfsGl5ufY9GIBBOAmugb9ASRQrhvyFLN4AraJca4N94QD4HXwKG63C36EdknAs XAB3wDPwDjR/qVybB6fA9XAPrLVqudYDGTgHzoWH4AP4ymol+Rftxrmk/IUsamBH2AfOheehfPVy bSb8GG6Dz+E7a5Rr0+BguBNegHXWRJ7wfdgDFsFJcDG8BdqX0R04Fi6GR+DRL5fkX7Qb55LyF7LQ 1qKuhu/DbhCHK+E+eBL0SdThcDhcCVfBs/A/2Hjtcm0q7AS/gEvhFihbp1ybDVH4BRwPt8AL8KWv lORftBvnkvIXstgSvgeHwi1Q8dVyrRJmwKFwFzwFq61brq0OTdAPP4Zz4Dr4FFrXQ0fgdngYvv61 cm1vWAjnwwXwMHz8tZL8i3bjXFL+QhbfWL9cmw7dcBjcAatugE5ADPaDU+FGeBw+hElf53k4DZ6C LTbExoPL4HF4Ap6Gj+C/8ClstlG5tguMbVSSf9FunEvKX8jiZLgEXoNNvlGutcBMMOB4uBYegueh cmPsQTgK7oeyb9K+w1FwDTwHa25Srn0Z6mA/uAZehc03Ldf2hJM2Lcm/aDfOJeUvZPEAfGkzbDn4 CtTC7nAQnAaXw7+hSS/XFsCN8BnUfovnYA84Eq6E/4PX4XOYvXm59lN4CP4DNVuUayNwwxYl+Rft xrmk/IUs/g7alpRl+C7sAD+AMTgJroWH4HnY8tu0/fAz+DlcD8/Ap7Dhd8q1KkjD7+BjaNwKGwD2 gaPgJ3DhViX5F+3GudT4P7K4E56Fd6GpElnBvnAknA9/hKfhP9AwGfnC2XAP3Atvw6Tvlmtbw2zY E86G2+FVeA023LpcmwVROGzrkvyLduNcUv5CFifBY/D1KmQHZ8M18CQ8Bc/Ct6tp5+FYuBgeh6fg aXgGVqkp17aFCBwMv4TH4RPYdAq2H7RDGk6ZUpJ/0W6cS8pfyOIauBsm1ZZr28CRcD98ta5c2x6O hD/Dv2ByPXYhXAJ/g8fgc/h+A/08uA7ehqpGbD+4CF6AbzVRr8CZ8ERTSf5Fu3EuKX8hiw2b6ZfB SfAQTJparu0Ex8A9sNa0cm0D+Do0gwHHwIVwI3wOs6ZjF8Av4Hi4GZ6Ad2DtGeVaNXTCIBw2oyT/ ot04l6r/kcW5cDs8Cs9A2ffoB0IdjMJv4V1Y8/vl2jchAhfBH+FNeAvW2QYZQyfE4GC4E96Gf8M6 2/I7tMJu25bkX7Qb51L7v5BFAg6HX8FVcBc8BG/Dl7ej7YZ94FR4CNbYvlxrgzE4Fv4CG7TQH4Qd IAOjcDrcAf+Cz2DdmcgezplZkn/RbpxLyl/I4kl4E+pby7VFcAL8AW6DN2GtNtpz2AH2gnPhNvgr bNDO32AB/AJuhlvgFVh7Fn1+2BH2gXPgBfjO7JL8i3bjXFL+Qha7QgyuhPdg7R3KtS2gC7rhh3Ae 3AHPwDtQ11Gu9cIZcA38CdbYkXcgBofCZXA5PAKfwjd3KtemwZydSvIv2o1zSfkLWRwH58KLsPUc +mmwBxwFP4Er4FF4D77SWa5tCfvBFfAerDO3XJsHg3A5vANrdZVr02EGROAwOBtugge7SvIv2o1z SfkLWazXTbsM58I18CFsszP1AhwBR8J18Ai8C+v0UD/AfMjAjfA5bNRLvQD7wL7wY/g1/BGehv/A Vn3oRV9J/kW7cS4pfyGLQ+BP8Ax8CFvOK9e+DbvCAjgFroG7Ya1dsBOgDY6Bh+BV+Ay23hU7AfaB g+EsuBEegLV3K9daoBdO260k/6LdOJeUv5DFM/ARrL17ufY9+D7E4Gg4G66FW+Fp+Bgm7VGubQc7 wynwFHwA6+zJu7AN7A8/hUvhbngC9L3oH8K+e5XkX7Qb55LyF7K4AF6DVfam3w87wk5wMFwM98IL 8BFss0+5ZsBCuAXK98Wug+/CdhCHYTgH/gDPwCew9g+wEeA0uP0HJfkX7ca5pPyFLB6Gr0fKtb1h IVwAF8JjUD6/XNsctoUeOB5ugPthnX5kCkk4An4L18AL8OUo7QHMhj3hPPg93AdrGyX5F+3GuaT8 hSz6IAFHwbVwHfwT/gubDtBuw74Qg6PhArgBPobKQco8XAlvQd1QuZaCq+EdqI9hD8BZ8AhsuF+5 ttd+JfkX7ca5pPyFLH4GV8Nv4VH48v7lWg3sCPvABfC6+FscexBuAW0YGxCGIAY/g9/DE/ABrJnA FoCD4I/wIkxKUvahMVmSf9FunEvKX8giCifAmXAW3Aj/gP/C10eox+EAuB4ego/gY1j/gHKtFSJw MPwSHoNNU+gNHAaXwKVwGbwBNWnqh3RJ/kW7cS4pfyGL38F78CF8L1OuHQq3w+qj3MP3YRtIwKlw PTwK/4ZVFpRr7XAsXAnPwXcWlmv7wenwAKy7qFybBfvB/hBfVJJ/0W6cS8pfyOIMeBq0MWx5qIUF cB7cDffA+7D1geXaXNgPDoG7Ya0flmvTIQZnwl/hA/juQTwPe8Ep8BdY/WB0AdY7uCT/ot04l5S/ kMV02B0OhtPhSngXmg/BtodL4Gl4BrRDsflgDsTgYLgDPoStDyvXqmBXOBTOhlvhCXgLGn5Uro3B LT8qyb9oN84l5S9kcSu8BU0/xl6DP8D/YLvDacPhT/ClI8q1DvgFPAhrHIkOQCccB3+FdY8q13aB U+AOeBy++RPqADgdnoENj0Y/ji7Jv2g3ziXlL2SxGxwLf4WvH4O84Cx4Br7603JtK+iDI+FP8DC8 AQ3H0k7ALfApbP4zbEk4Hh6GdX9ers2DU+BOWPU49AV+flxJ/kW7cS4pfyGL6+B6eBVeg9eh7hfl 2kL4A5QfT18Pjobfww3wElT+slzbCQbhh3AjvAdfOYG6BJohCqfDrfA4vAmNJ5bkX7Qb51L9P2Qx D34Ff4YXYaOTyrVvwE7wE7gTvnxyuTYbfgG/gtPhD/AiVJxSrm0GDTAGN4N2Kv0COASugWvhWfgf bHxaSf5Fu3EuKX8hi6mwExwHD8OGv6L/DufDE7D26eXaOjADdoMFcAL8Bl6Cb59Rrg3D9fApbHUm /Tw4Dx6Dv8OqZ5VrW8JM2OeskvyLduNcUv5CFim4Hj6G7c6mnYc74d+w5TnIF3rhAPgFXAa3weew 7bnl2lHwIKz/63JtezgaLoVn4Fn4JzwH/4LK89CV80ryL9qNc0n5C1lcB/+Fbc4v17rgePgbfOOC cm0+XAJ/hDvhT/BvqL0QnYAkHA73w9q/od8PXdANB8HV8Ai8DRUXlWs7whEXleRftBvnkvIXsrgZ XoHNLy7Xdodj4Hz4GzwGX7qEvh6cBE+Afmm5NgCXwzsw7TLaefgTrHk5sodT4CnY/IpybQiuhPdg xpX0Ka8syb9oN86l1v8ji7thravKtR44DZ6BLa8u1/aDq+F9+By035ZrZbAF7AhDcAScBn+HNa5B /vBlaIY+SMFxcB68ClXX0o5cW5J/0W6cS8pfyOJGKLuuXGuBQ+G3cA1cCy9CxfXl2rdgG9gZToCH 4eu/w5aDC+ENqP99ubYH/Ax+DsfBrfAkfAzr31CuTYbhG0ryL9qNc6n2H1lcBx/Ddjdi+8G98CnU 3FSuTYFa2AcOgtPhd3A/rH0zNgCcDs/B5reUa4NwKTwDX7m1XPsqrAvbwz5wEJx2a0n+RbtxLrX+ D1lcDu9C8x/KtR/CnbDGbfTfYQwug8vhCvgXaLeXa5vCDJgLv4CH4Gt/LNf2hPPgJVj3jnJtFiyC MTgQLof77yjJv2g3ziXlL2TxCqxyJ/1+2AvOh1eg5k/lWhp+A0/AWneVa5NgbdgO9oYfwqlwGbwN jXfzN7gDKu4p13aCA+FK+Cc8B/+6pyT/ot04l5S/kMVX7kXWMAeG4CC4HVa7r1zrhJPhEfjG/eVa BC6AB0D7M3YDlEMj9MAI/AzOhRfg2/9HXwEug2fhOw+Uaz94oCT/ot04l5S/kMVF8DR85UHaa1gX WiECh8IZcBW8C40PUb7hJngbmv7CPfwR3oDN/kr/EL4FPTACx8Gl8Acof5i+w8Ml+Rftxrmk/IUs fgGPwaaPlGtRuBT+DRs/SvsOXdANR8EFcAc8A+9A89+oL+BWKH+Me1gEN0P538u1abA/xGEYzoPb /16Sf9FunEut/0YWz8AnsPY/KLNwGjwDmz+O/OEX8DBs9AS6AD+Gw+EIuBH+Du/DV5+kvocYXAH/ gcanqB/gVPgHbPx0uTb/6ZL8i3bjXFL+QhanwZ/h/+AB+NIz5doW0AJ7wwFwPXwC2zyL/OF38C40 /LNcWwA3wZvwFrwN33muXGuD+XAInACPwcb/ov3/V0n+RbtxLtX+I4vz4XFY//lybR6cBk/BOi9g E8BXYQcYgCPgXLgOPoJtX6T+hz/CGi9hD8AB8Ft4D6a9TP0PcRiGs+GWl0vyL9qNc6n1X8jiCfgA 1nwFex+Oh3/AZq+Wa71wIjwB33qtXPs+JGEEDoDfwJ/gX/AZrPt6ubYLnAr/gE3eKNd2hpPhcdj0 TXTmzZL8i3bjXFL+QhYHQArScBHcBc/D57DeW+XarnAaPAubvo1OwCnwNGz573JtO0hBGjJwMdwN L4D2n3Lta7AbnAsvQuU7JfkX7ca5pPyFLGJwNbwHU9+lfYYT4SQ4GR6EN2DN92jXYQYcAn+CL71P fw4Ogbth0gflWh8k4Tw4Hy6Ap+AT2PBDbMIPS/Iv2o1zqfVfyGIH+Bk8DBt+hPzhWHgYNvqYe/gh XAlXwdXwCqz6CeUftoc+OA2eAv2/5Vo/XAR3w/+g5dNy7TD4Hbz6aUn+RbtxLil/IYvX4HX4zv+w 2WE+HAInwCOw4Wfl2u5wNjwCkz7HToQz4G74GD6B/0KTVqH1wgHwc/g1/Au2KqvQhuF6+CeURLFi yF/IYqPyCi0CF8HD8KWKCm1VWA1aYF84GH4FV8B/YOoqFdoo3ATlX6rQqiENN8HnsNmqFVoP9EIf zINdYHc4etWS/It241xS/kIWx8LP4D64Hx6A/8B7ULdahbYAboZb4G/wGHwG31i9QquBJFwFV8Nd cDe8Bv+DDdao0HT4FsyEXWC/NUryL9qNc0n5C1lcCU/DM/A5rL9mhTYZRuBMOAtuh/dhvS9Tl0M/ /BpehslrVWhxOA1+BTfAc/A5rDepQtsNzoCn4RtrU9esXZJ/0W6cS8pfyOIieAKehM9h03UqtB0g Bb+Eq+BO+Bwqv4K8oRPicDL8AV6Gr3y1QpsO3ZCAH8Mf4GV4BVZbt0L7NkxftyT/ot04l5S/kMUo nA3nwO3wLnx1PWQFETgLnhf3X6vQhuAkOBmugeehbH3qDNgZToVn4NsbVGj7w9lwDtwLL8En0Pz1 kvyLduNcUv5CFvvCD+AwOBuugX9Dw4YVmgED8Eu4Cu6Ez6FyI+oB6IEROAJuh1fhNfjKN7ANYCYc AhfBxfB/8No3SvIv2o1zSfkLWXwGMzamTYco/BjOhevgHWj6ZoU2CEPwM7gU/gCfwnab0NeDFJwK 18N9sNqmFdqOcBAcDOfDH+FvsN5mJfkX7ca5pPyFLHaBo+EYuATugSdhI71C2wuOg1/AdfAwvARb fgudgF/B6fA7eBRege9sXqHF4Aw4E/4Iz8K7MG0L2v8tSvIv2o1zqfYfWewGC+Cn8BD8Bd6Ctbak 7wYGDMBP4EK4ET6Dz6Hy2xXaLNgDzoFz4V54CT6B7b5ToW0Pu8MiOB1u+U5J/kW7cS41/4cs/g6v Q/1W2PRwDPwUjoWr4Gp4EP4JZZW0+9AJC+AcuBP+BatPrtC+C7vBwXAx/ANW/W6FVgd7wMHwm++W 5F+0G+eS8hey+Av8F/StabNhfzgZfg+Pw+eweRW/wQHwQzgVLoO3YJPqCu37sA0cAWfC7+E+eA3W qsHmhz3gh3BGTUn+RbtxLil/IYs/wD/hS1MqtCrohcPhd/A6bFFboXVAEk6Gm+ElmFSHXGFvOBwu h0fhE9i8nnegF5JwONwGz8Cz9SX5F+3GuaT8hSw+hbUbqP9hFxiDs+E++BA2aazQdoJFcAE8BJ/C lk0V2lxYCJfA46A1o0OwF/wILoO/QcVU+oOwD/x0akn+RbtxLil/IYvr4GlYdVqFVg3zIAOnwC3w Omw4vUJrgzicCDfD67DODOp+2A3mwyFwAvwd3oJJ30O3YB3ohn74yfdK8i/ajXNJ+QtZnAZ3wBvw EXz9++gB7A4Hwg/hIDgUzoffwEXwFjRtQxsAXdANB8IpcCm8DltvS30ALTATBmBs25L8i3bjXFL+ QhYnwdlwDtwOj8FrULMdbTvsA4fCqXAZvAObbl+hbQYzYSGcDJfAizCpBV2AE+ARWHcmfUA4HO6G 12aW5F+0G+dS43/I4nVYsxX7HfaEJFwHH8L322j34Rb4GJraK7QhiMHP4XJ4DLRZ6ANsAzvDz+F3 8Ht4Ej6BLWZXaHNgdHZJ/kW7cS4pfyGLs+Fe+A+svkOF9h2YAQvgHDgXboOn4T9Q3YGdCLvCIrgM 7oOn4Rs7UifA4XAXrLoTtiMcBw/C+/DBTiX5F+3GuaT8hSzWm4NtB/NhAVwLn0BLZ4V2NDwIZXMr tHLYGjpgbzgd7oQ/wQvi964KbQPog1PhPrgf3of1uiu0rSAKP+8uyb9oN84l5S9kcRz8Hv4Gr8J3 dsaeg25YACfBxfAirN2DLQ8NsDMYcB78Gf4P3oN1ewkDhuByeAWq+qgH4GdwXV9J/kW7cS4pfyGL J2HzebTdsC0MwpHwK3gMPgdtF2QKbbAbnAx/gNvgZfjSrhXaRrAb7A6jcCJcBC/ApN3QHZgCnbuV 5F+0G+eS8heyiMDZcA/cCy/BKrvT54d5cAgcCufB7fAofHUPbAT4HuwOC+FYuA/W2hM9gu2gH34E J8MjsMFeFdoOe5XkX7Qb55LyF7LogAT8DM6FZ+Bbe1dovdAHB8JpcDm8BtX7VGj7wg/gSDgffg/v w7R9K7T9YH/4CVwIN8KHMOMHFVochn9Qkn/RbpxLyl/I4kT4LdwFFZEKbRYsgjE4G26Bv8D68ym/ 0AS9MAiXwxXwZ3gV/gcz+yu0VojCj+EUeBKegi9F6QdGS/Iv2o1zSfkLWUyFg+BguBDuhL/DN40K bRNohTaIwgI4FW6D52GtAfQBdoeD4Uy4A16AdQcJG+bDCXA7vA5fGyrJv2g3ziXlL2TRAkk4He6B V2DtWIVWB31wEJwD98I7sMl+FdpsGIIT4VZ4Fsr2p48HO0IKTofb4AWYFK/QGmFb2CNekn/RbpxL yl/IIgG/hX9C2TD9eNgM6qAHMnAa3AHPQ0WCvgDsAMNwEtwMb4m/Jyu0OZCC0+AP8CqsN0L/AmJw /EhJ/kW7cS4pfyGLG+GfsOoBFVoN9MFBcDH8FR6Gp+AjWCuF3CEG+8ExcAbcBs/DqukKbWvYBY6A S+Ef8KUM+gR7wTGZkvyLduNcUv5CFr+FJ2HSKGUUonA83A4vwjoLKrTpMAgnwB3wNnxzIX15OBAu hr9D+aIKrQrmwSFwITwAn8LGY4QP/WMl+Rftxrmk/IUsToDb4HVY70D6aTAfToDfwYuw4Q/pz0MC fg0Pwaew+UEVWhfE4Wy4H96Gbx5MPQGL4CK4Hz6AyYdgKx5Skn/RbpxLyl/I4mj4PbwJ+qG0+fAj uA5egg0PQ8ZwJNwM70HVj6gn4BT4Pyj7cYXWDCNwCfwLNj0cWcOJcBbcCA/AukeU5F+0G+eS8hey mAw7wk4wB7phZ+iBXhiEOFwL/4b6I6n3YS6cAs/A6kdVaGvAznAs/Ax+DufB+XAlXAX/hqaflORf tBvnkvIXsjgILoXL4Ca4GSqOpr6HI+A+eAPehFWPqdBWg7lwAtwMt8AqP63QWqENjoZr4Tr4GLY6 tkKrhP3hcrjn2JL8i3bjXFL+Qhb3wpd/RtmFk+EUeBw2/Tl2APTDxfAPeBw2Pq5C2xP2gjPgKdj0 F/QZYQh+C3+Cu+BLx1NXwM/hOHgUPjy+JP+i3TiXlL+QxUew3S9p8+EGuBE+g+1OqNAOhcPgHljj RMo9RGA+XAKvw6YnIXsYgMvgGXgWtjwZ3YEz4Sz4J3zzlAptk1NK8i/ajXNJ+QtZzIdT4FR4GjY7 FRnDfPgNvARbn1ahbQvbwRhcC+/DB/D9X6En8Dv4PXwI3z+ddgUOhlvhM9j4DOQPkTNK8i/ajXNJ +QtZXAz3wL2w+pkVWgfsCEfDn+FFeAm+e1aFtgfsCXvBr+EF+AA+hI9gvbMrtK/B7vBruAvuhlXO qdC2h8PgzHNK8i/ajXNJ+QtZnAVnw01wM5SfW6G1w7FwF6z+a/p/cALcBDeDdh7yhCPhbph0PvU9 fBv2h9/CRzDtggptOhwIf4DyC6lHLizJv2g3ziXlL2SxHRwBf4I1foPswYABGIQfwY/hT7DaRdhz cAKcCLfCp7DxxdTtsDecCY/DppdUaLvBUfATuAv+Cy2XluRftBvnkvIXshiBA+D38Dq8AXWXVWj7 wYXwG3gdai+v0BbCzfAGvAmNV9Cew3y4CN6EyVcSJlwHt8HtsNpVFdr34Pvw46tK8i/ajXNJ+QtZ 3AWrX03Zhy74IRwE/8/efUBLVT34gt5VBQhIEkRBlCCKGUUBFSWaECUpKiKgCEiQJCqCSM6CiOQM EiQHCUoGyQaCiEjOIDlnEOa7aHe/nn7z3lu9ZqZn1jv1Xx/31q/qnLPPzmetbu9ijnKMR781J/Ae E1jLr9w6LRFepQL9WMVqUkzX5qQkPwVoznzCjKj9/8ve/NvrevsntcVztKYNy9nBTnLP9DxPT3qx kWzfaUsKUps6DGYjmb73fEh7lrKMFexmD/fOMqfw7ayo/f/L3vzb63r7J7XFeQrPtpdjJenmGM8M ZAs552pXytKXzeSYZ2/AR3xMV7oxmNls4SjnuW2+ZwpKUZs686P2/y9782+v6+2f1BaTmMxZCi9I hHasIM1C/YBB7CbXokSozkgOcpZzFP4hEVrSihWkW+w4+rGFTEs8E1KR+jRYErX/f9mbf3tdb/+k tmhII0YwklFs4A82sonNnOEs5zjPBS7+J9vy8n/75uJ/4s1/5gT/7ph/9+Z8+N/jldTmsUwk/Z4x hAy/ab/1/00bH+AgxznBSU790+b/0t7nToaT506e+9PPrf/TK0av/0demcuVShbeKxliH/yU2ttr Xn5keqbUzaFqKdNsyZCsAR+njKX8lyzclKibdGjS+9dSxq5HaR4OqR+J5SkXC/l61I7lmLr24ZxT 3ymYa+ra+J1TWyfL3WNn7K4eIdw9NYRbyTL1f1yo6PX/u9fNIUdIbTqoE9KHxL+mT4RQ7OS1uJ9p QopQJjQMjUP9UC3U81mcLDpRlvB2yViyan7WL5kq2Yd8xCvOFfOdVxyZKpQMNR1Vw9kbhFohZ8jn 2Aw+T3FXLNOoE+HmUU+HYnlC9lAgZZtnSuUML5XMGcqWiofyVE7Zpqof1cT/59fToXixU9e+9jNN uCU86xrvucrHSveRa5Tze2NqXf+3Uagte94dNPDpvz9LpWKxcOr6WVI7qp5vJ5UzZ6jgjE2vfzuu Vm6+PmDKGi3lSRo11bwvFd5Mus9YKUenUYaGoboS1Hdkg+ulKH392kak+33o2Zyx0suvD9MQWidd O43zJXe+5M6XPBQMV8uOCDfFCipDilBcyZPqO+lMIWQNJe5P9XcB/q6XpEppVPv6eQqFHO7gzlih 6630L3Vd07FJ180Y0i5PGeJTM71zTyyesUaGpPkh5b/eR6GQ07GP/nNsUv00VO5/OTbT//DYItfL WzxWJLzs6JrXe0YdZf/QGZr5WVM7P+mIW8J/LPiAx94LecNrxUaE8rG8//SRZmoq6cr1rtf/+9fr p8j9sRL3x5Nu9Jrrve771VwvTbjpelnr+V/D8ImjavyPjk/TqHZrFZU/vKWtGsfyyzOE58JD/1ri nOFVP2s5qpqyf3y91pNa/Vb/lglX098U2sbKOOpG/fn58Izv//sendSbs4S/KyjTKKNpVNJdX+/N Wa5XV9IsnVRlVVK2KaTWYqHn9RpP+a/n+7e+lkFbp28/Nfb32ar67d9q/F4t8lUs7mdafbVCKHv9 2HzhwX9+z3e91Lf5N4/+mvTNPL6Z/F+/+ahPUodszn/CmU9c/17m/873Hrv+vdt9b2esKknfu0/d /xrLc70Wyl0fVzV9s8z13v7uPz0mhBFq66vY7tgIZ7v5/6K2cqr5nNdnk5z/XDGEN4z+tMtLWVpi 7yQyJF+UolHKnKnX3tg67SPpd2bokbHYzScyD7+1XNaQbert72TPkHNRrka5c969Ns+H94T//it1 +vZJlee39Co/xX+7EF7//KLnmBtC+Ci5nvfPoqm8QSmCmTDomyGUIKlsSeOvGZ/SnBa0pC/96M8E JjKJyUwhaZU8xYMu+RDFKcHnfMf3XKGYqbQd3fmSX0lvEk76z2l0YSSj2J60UCcLIS3l+ZgmdKIz P/MLv7OBLMlDqMJovmcWBnkoSXd+ZjNbyKYy3mUsC1nEbvbwQMoQGjGVFazkR7awldypQqjLt1yg qCmuI6u4+cYQ3mIEB3kkTQifsIDkaUN4mV5sJle6EGozhXMUtkltz89kzBDCmwznT/Le5P6ZxyWK 28R2Zg1pbGxfZSC7yKZhqzOekzyROYRWLCftLSFUYBC7uc+Qb8T3zGI2czjAQR7Jos7pwVf8xq1Z Q6hMLWozhbMUMhDb0J8BDGQMYznMI9nUOdVpQEO+4yo33e6eyUkuajCBw+S9w3eZzkUuUUzH7cxP 3KQDV6ApzfiKnvzOTnaRLqc+Rhl6sZbUuUJ4lMcowTO0Yzhfs4ucdyoPj5GfqrxNXd5nEqd5PLd6 5jmepz3L+J0N/MkBct8Vwl3kpwCf0ZkuDGIwk5jMHOYSu1sbk5bs5KAyo9hL7jzOSXleoTtfMp8F xEwaz/MF85jPClaylW2c5BS579U+DGM4U/mWIxzlGJe5QvH7jEVWkeH+EMrSlGb0pg+L+IGUD+j7 lKYr3zCGw2R+0OpBVUZxkHwPGTcsYD9/YuEMcZ7lc/rRn41kf1gbkZ9mjGUcx8nxiHakJqMYzXwW ELOEFKcE7fiR1JaNx8hPU+YlLSOWiHu4lxI8Qwd60Zs/yJzf18hPU+ZzitPkK6BPU5MxHOQQDxXU j6jHdM4Qe9x98iJfMZZxHCO/LepLvExpmvAJM/mLEjYgnzOQQUxjOpcoWsicQj8WsJD4U8pAXqoz kj3kflofYwjbyVE4hHcYxh7uKaLcTGEq33KRokXNAbTlJ34mUSyEZBSlAz+Strj+wlf8RmaLzy3c ShnK0oG5nOQeC1MVevEj1yjwrDLwNX+Q9jntwrN0YjWZnjcf05cxjOUw6V/QZ7mP+2lEV7oxnK85 QNaSIdxGfgpgXQ3TmcFSlpH6xRDK0YgPGMJQ1pO1lHIzkoNc5BKPv+Q+KUt9JnOWrC+7Hm9RmaHs 4+7SIdShPlM4ToEy2p9e9OYHFpOsrLWGlynNF6wpm/TsrI55gpK8yPu0pBVfM4vZbOEUp8lc3nE8 wZO8RWWGs48HXnE+XqQHv3OBi6R/1TG0YRwnOUXKCuZV6vAVm9jMba+F8BrN+Yw5HOIw6V53PkpT hnpM4gxZ3lB3VOIthrCLXBWNOd5jLCd45E0bIT5mBCPZx34eqmQs0IDvuMJfFHnLnM4y9vMnD1TW 3vSiN+P5gRRV1D1N+IQvGMVBHqxqDFKJoSwh8bY243m6MJVDHObRd8xnfMpgJjGZtexlH5fJVE1/ oCAvU4OOdGIc4/mFVVzDFjbczwM05CuWkbq6uqUvmznEYR6toXy8QE2+4TDpPThkoBzlGcAG7njP 9+jBV2zillrGAqM5RBZPOVl5nhfowq/cWkcdMZTtXCVLXd/lHcZyjEc88pTnFV6lF+u5zeP62wxi MOM5QZ76+gyTWM0adnK3De/bjGYFK9nOWR5vaP/LEg5zhJgH3CxUYjj7SflBCKkoS1/mcpkrPOtR oROTOcBBHvlQ36AnvZjJclZwkEtc5iaPSPfxEi/zLp8ymCEsZBG72UOOj611FKEVSznAQe5ros2p xzi2sJXsnxgzfEVPerGIH0g01Td5iZfpxioyeUB4hHy8SnVq0JEBDGQev7Gec6T1QJGOR8jHq1Sg CZ8w958HjuepQU0mcpKbPzMP8QDP0JXpXOYKGT2k3E9jBrKbPeT24FKV9nRgCac5w62ttCPFKE4H JjKJHdzV2v6WqZwl3kZ9UJLKVKE587hG7raO4X3qMZGDZG2nT1KJfvzML6ziEpcp3F6b0YGOLCdN B32bV+nNZrJ1DOFpCtOGFRzkEKGTe6IyI1jHbxwkdLY3pTMz+Y5L5Oii7/MOI9hHms+1AS/Qnd/Z wAVSdTVH8CDFKM4bNOQrejKWRexmD8m7mRO5l/soTRn6sqFb0n+MyxpBISoygK2E7sYaxShOdWow lnEc5ggPfGke4BU+4mP60Z/t3NlD21CLCUxkMZvI/pUxRSta05dJnKJgT3VPBfozn7+4SrFe9ouM 5wiZe5vfqMIIDnGYR/rYC9KMH0jlITo1OXmCFixjH/v5kwNc5RYP228xkiUsJZmH76LU5D1GsZ7f uWGAeYhUZOU2SvAMpXmP5gxiCov5nQNcJt1A9cQzvM2HdGQgU1nMLs5zgYyD7Hd5k4/pzghWsoUw WPuRjQp0YjALOMndQ+wZqElPfuYXTnHnUDnfcIAHhrlv2rKYC2Qdbr2mNH3YRPavQ3idJsziL54Z Yb7gN46SZqTyMJhNZB4VwsOUoSe/c+NofYq6dOFnbvzGPEhdurCa9GPMB7RlIefJMtb4oBqj2c/9 4+zdGMNKNvAHGznOCW4a7zhepAoj2U2uCfobxXmH5vRnIqd4aKIy0YXPmcJq0kzyGc/zNp/QmjaM YyWpJisbz/AWNajJl0zmNDdPUS6K8wb16UJPerGE3ZylwFTXYTabOcUN3yb9H1zYQ/AUT1OYj5nB 6aTPpulLFORZXqAkL9Gd1fzJIQ5zhMzTjXk+5itGs5d0M4wvajKB9VzgInfONKZpQk++4U9Sfmd9 oyX9WcFKzvDQ98YOw9hA2lnqlM/oSCfGsJojpJwdwu28yygOkneO+Ye+9GMhR0k117zIs1RkMLvI PU/5Gc1h7pivj/IRc9hMqgXmEvJSiSb04VuWEVuonHRjDYlF6oxKDGcOBzlExh/MVZSkKh/xOb2Z zhr2cNdi98F4DvDgEv2BiSwgsVT/pTo96cVcNnGSG5a5X16kLl2ZxGo2cp5Myz3vUYdeLOQKBVbY bzOefWRfae6hBz8T/1G/oimLCD+5H9qzmFQ/G+P0pBe/c/sv1kU6spArPLPKOslAdnD3anMPDWhI T6byM4dIscZcy9t0ZCXp1ppjGMA69nLfr46nC7OYzVYukXGdeqEor1OPJvRmKku54Tflpy3fcZjc 69ULzVnIGXL/rp24h7pMZgOb2ExsgzHI2zTnS37nKDf9oSw8SW26Moa5XKXYRnsUBrCdnJvs/alL P/qzmLBZW/ApszhH/i3aj8kc5t6txhUj2UWObfo8kzjMvdu9pyGN6M5MfuM4iR3WNxrSiD4sYQfX yLbTmKExc7hM0V3WbUYwg4sU3W3s0YGOjOE3jpN+j7WHorTlR27aq9/RlM9ZQ+Z9rkVlqlCVrozn J/Zzicf3q3N+IOWfxicdmMNV7jjgPHzEHNYTO6hvk4fnqEkb+vAbtxxyPbqyktMkPxxCKXowha1s 44YjzsOzvMNHzOQv7jlqLDOVYxQ8Zo5jMamPmwepQ3MWkeKEfkZ5XqENY1jBHs7z1En1zUrSnjIe qcQw9hE/7X55hCq0YyQL+Y3MZ+SM4E/uPKsf0YyFbCXVOeUjP5X4lL6M5xiPnddWzOcCqS94TqMP 09jBTlJeNJdShrq0ZBHJL6lLvuQntpLrsnmQ9kxjOjtJc0V/4Xkq0YPl/MWjf6l3urCGk+S4agxR mib0ZRrLucKj16xvjOI7LlM8xEJ1vqIn89hDIhYLOXiMOozjTy5SJB4L7RnBWn7lL/IkYuE53uEj xnOK+5PFwtO0YQV/kjl5LNxCQarQggFMYht3poiF2rSlN5vIcYPzUJf36cFsNnGWVCljoRw92Uy2 VLFQmaH8RJrUsfAqX7KWo2S7MRZupwhVaMEAJnGGp9PEQiuWkyZtLJSmD3+QPV0sVGIAK1jJjxwm VfpYuI/neJNBbCd3hlh4ng+Yxlny3BQL9ZjOGtJnjIXHacgMLnFLJufhAxozlVOkv1mZaMh3XKVw 5lhox4+kuiUWytOHNawl463ORV+WsozlHCVNllh4kJJUZhSHeShrLHzMSEYxmm8YwwHuuc09MJJv 2EnObLHwIi9TmoaMZiV7uUCh22OhKm/Thgms5hBXeeaOWHiWtqzkBNmz6wtUZzQ7uCtHLNRgPNtJ 5IyFZJSkK+s4wEEezKUeacxsrvDMncpBOyYwkV9JndtnfMZMjlHwrlhoxDh2cZgj3Hh3LOTnDT6k E8s5xW159DWKUJ12DGM6p8h/TyzUYiQ7OEnBe12XwXzLJjYTvy8WHqYs79OKRVyh2P2OoTu/kfWB WHiSQpTlE5ryNas5RuoH1SnvMYLtnKDAQ7HQnEFMZSObSOSNhUcoRz1as4RrPPewdqQXG8n+iHum KBX4jBZ8zUoOcEM+dcPb9GA5sUcdQwsWk/wx45S8fMhs1rKPtPljIR1P8Aaf0IsxHOaGAtqQyrSn A6NZwh6ukalgLLzOYHZyy+OxUIrGfMgQlrOf+BM+pzKj2MeNT8bCC7zJUPaSrJD6pzglqMVwlrCD 0xR6St9mOYdI97QxTX6q0Z7hzOA0hQo7DxM4ymNFzIf0YANpi8bCU7xGa9owjh3cXMx4pCXfsp/s xc2JdGYey1nBCdKXMO55kSoMZw9nKfSM8zOYFazkIDc8Gwt3U5zX6M060j1nPqAmE1jJac6Q+Xn3 QXnq04bFJF4w9nmdQeziKveVtKZQlvp0ZQxzuUrRF5WNnvzBHaWUl5q8R2dGMZ8tnOfGl7Q3X7KB v0j/sj7LQOaynz9JV9rYoCz16cIQdnBnGfdOG37gKkXKujafMI94OesAZShLE8awjF2c5bHy5ltm 8xePvWJs8TlrOUqWV/UvCvMWzejDOA6Qp4I+xEhmcolir2lLOtOFSfzMQZK/7nxUYhBbuOMNcw0f MYc/iFfUNjzAi9SiHf3YTLY3lYevmc4FilSS0YnOdKEbE5nCVDbyF9nfck9UYADbCZWtW7zBEGaw ha1sYydnucBFklVxP6QgFXeQk1wUoSE9mcxi4lWNUWpQk7aM4Sf2c4mn3zbXsoTTpH3HPEg+ytOJ 7znCA9XM3zzOGzShN1NZSup3tT29Wc5G7qhubaA1IxnFMnZykVtquAeKUIkGfMspCtQ0TzGLKzz4 nvNTjvK0YyUpa5kHyMzTVKIZfRnPXs7xVG19mKHM4A82cpnb6/icN3if0XzPFUrUtV+kFSMYyTfM 4U8OcZgb3zdOeZeW9GQNV8hez/pOUWrxOd8wh794oL72Yxiz2cFOEg2Mc5owhQPkauge6cU6bm5k L0JHFnKBfB/YDzCbM1zlGqGx+qYIFajPF0xiHadI+6G6phyfMIQ5/MEurpHtI2OID5jJebJ97Bh6 s5kj5GviHPTkVzJ8Yk2hPg34gvls4Tw3No2Fl+jAT6RtZtxQlu6s4gp3fmq+4Tmq05LBzOIXMjY3 p/IUrVnOXlJ/5ho8SClq057+bOA4mVvolxSiIk3oyTfsJXVL/YVqjGEphzjMETK2MoYoQ11aspj1 ZG1tT8BnjGAkP/InydtoWwrQjK6s5Za25krepBLdGM9K9nKBIu2sKdRmEqfJ0N545XEa0I3xLGcz t3dQt5SlN5s5zx0d9VeeoRqtGMQUDvMXJTqZ8xjBj/zEcdJ21pd5gbfoxziOkb+LOuFjmjCI2fzB aW743DV5jYHs5BK5umpvXqAm7RjGdI4T6+b5g258wypWc4FbvnBdylGDr5nHajJ1V6c0YQhDWcER Un9praEQrZjNRYr0iIVPmcUlsnxl3aYhM/mF05zhjp76MnXpxGB2cU8v8wnNWUSK3voyd/EypWnK OFawh/MU6eNcTOIUBfqqT95hNIdJ0c/+hrw8zKO8yuu8QTMm8ytHifVXd1ShFa35mp84SqoB7oMa NGUW55OygcYPH9CYvqwi2SBjjsaMYye3DlZOOjCX5axgH+mGmCMoTTVGc4i8Q839zGQr20gMM24p xXt8yg8kGy6jAxOZxO+c5qav1QfF6cwq0o4w9zGYn9hKrpHmZdoyjvGs5RhpRsXCvTxNO1Zygvho fZIvGMsa1nKWTN+4L0pTjW/YT7Ix+iRv8TXz2MNebhxrzuIFqvMJszlJYpznProzjrX8yjluHq+d KcO7jGYLR5PyCdqNXsxhLvPYQ2yiNYmnKEsfVrGDuybpa3RgIpPYyDlunmx+41m6spYMU/QvhrGK Hdw11TnowEQmsYEzZPxWG1OCLqzmHCmnqTN6MZkN/MFGNrGVQxzlGCe5Ybrxyo3cTxVaM5ipnCLf DPMu7WjPSH7iKKlm6s/UYAT7ueU798hrvE5TJrKP7N+7V4axkUyzHE92clCCKjShF0OYyx8c5q7Z rsUo9hKfo83pylx2sotkc82llKE+XRjCXtLNs45Tkwks5zBHSDffvM+bNKU3YzlE3gXKTh0mc4Z0 C60v5KcirRnCLH7hhkXGHeV5hfYsI9kPckpRh44MZAu5FrtHxnOc+5cYP7RhBdtJLHUO8vEmTenN WA7z8LJYqEojZnKFh5YrA6/SlAHMYj0HuG+FuZhpXKDwSt/jc9aQ+Udlpjyv8Cqv8yYNacyH9OFn jpH6J23L23zOZKbwK5eTPvvZOkEZWrGE06T9xRxNQd5iIJvIskob0Jf1bGcHaVarJ0pSg6bMZwtH eXSNjD70ZQELOUyqtdYVnuENhrCIddz6q/7Ip4xgJKs5Qup11jkK0YrlHOYvSvxmzmQ0q1jNBW5Z r69QjhpM4DhZfld+GjKTdVziMvdssFejOq3oxa9cJvcfxgQvUYdOjOR7zpFjoz5CE+axgatcI2zS j7ibCvSmH/2Zxxlu3ax/8wIdmcVWthHbok9Rjnq0Zg6XKLpVeehFb+ZygYLb7OlYTrrtyk0XfiTZ DmsNLZnLOR7bqQ8ziUPk3eVemM15YrvNAeShAp/QizEcJd8e44DOdGEav3KcG/eqH2owkfXs54F9 1ma6M4vZ7OIad+w3FilHP7aS+09zNYPZRJoDxgcNGcBAfuYMGQ+6B0rQkR85wW2HPANQig/5ikn8 QOKw9YL36UNf5rGZs2Q6YrzzDB0ZzZ+kOKpfUYWRzOdPDpDpmDFBOerRmiXccFwZ6MF45hE7of2p yZf0YCEnSHdSv6UIbVnOcWKn7I3oxhh+ZR3nuPm0YyhBNdowmB/YzkUSZ8yDFKY8vfiNzGedl8p0 Zji7uPuc++ddxrCC9Oddhzp8xXdcJtMF6xMf0I2xnOCJi/b69GY9h7hC8UvGFSNZxWrOk/my/klZ qjOOuST9P6I8T3W68yWz2MAZMvxlzPIebejFRrJftZ/gPWrRm2ms5Qjhmn7A23zAd1wha4iHZ3mO hnRlFIvZzikKxuLhNfoykxWkicfDK3zEMIazhnNkSMRDXkpRleHsIZ4sHkrQloVcI0/yeHiCFixh L+lTOAdPU4mm9GYsxwg3KC9dGctvrCekjIfsPE1F6jGZH9lCzlTx8B7tmMwUdvAX2VLHw+O8xJeM Zx6xG+PhBWrwJT2Yx16Sp4mHu3iKVswjkTYe7qUQrVjGVm5IFw8pKUB12jKMGVzhmfTKxSLWcWuG eKjCJ4xkFOu4yG03xcOTlKM1i0mRUTmoQ136MZtNnCdtJt+nP1vJfXM81GICm9jMNi5wmSvkyBwP r9OMPozjEHfcEg/FKUFNejCdNezh3lv1KTryE7Es2ouOTGMXqbPGw43koy7TOMidt8XDW/RmFcmz 6Q9k4BHe5DP6M5ETFLg9Hpowm6s8cofvUYkOTOYXDnONF7LHw+es4SR5c8RDI2bxByGnMnM/JXmH ZvRmOmvYw125tCXd+IKZbOcKWe6Mhwf5kO+4SP7c2pSqdKQTo1nCDk5T4C6f8zYdGMkPbOMkj93t nAxlBSs5Tto88fAAL/AWQ1nEQQ6R5Z54eJ4atKY3G7j1Xt9nKNPYwlZ2cPd92o2ujGUTW9nGdpLd Hw9FqEYLvmITl8j+gP7Dc3xIX6axnLQPxkNhOvATNz0UD8XowM/s5r68+hbj+J0NXOPph40JZnCc Bx/RfxjDXnLlU38MZjNZHtWH6c0a0j5mjNOFFaTJHw+3cCsFqUkXRjObazxfQDvzJT2Yy2ZOka5g PDxEaWrRmuEsYj3biT1uzJCPj/mW06R+Ih5upxpj+IGjHCP9k85LaerQgiUc5wTpC/mcZ6hIA9ox gCksYw3HufEpbUFV+rGGVE8bozSjK2u5pbCxQ0k+4mMGspjdXCVjEddjGFs4yqNFzdH0ZAELOUqa YtqHklRmOAv5lVuKy2jCl8xlHgdIV8KYpBRVGcZe8jwTD29Qh8mcId2z5jLKUo7mjGAx2zlFvufi 4VUGMY2lpHreMdShFROYyG9c4fYXrEu8THeGs48HSurTVKIjnZjEes6Q4UXzAnWZxBnSl7J+UouJ nCLNS+ZwClGN1gxlDqvJ9LJ6ZjjTOE/h0u6f9nRgBr9xmvRl1APv8hGzuUbWsu6fqrxNW77mB7Zx knvKKQstWcp2znNXeXMAb9CEvkxjOWle0e48SxfWcJCrPPCqdqcqLRjCbFaRroK1g1fpz3YukO41 6xdPU4fODGU689nGRdK+Hg9FKU9ftnKO9G84lsK8z+eMZzmbyVnRWOJtRnGIZG8al5TiJVowlpXs 5QKFK5kT+IR5xN/SN7ifotSjPsNYwHYuka6yNqc/i1jHrVXM/3zCKEazgXhV6x5FeIUezOIn0r/t PDSkPd8yjb3c+I665gXeYgTf8yPpqsVDBRrQkenMYCeXyf6uduBt6tCZUcziIvdWd29M5hj5asRD Y6Zyikdral+G8BtZ3jOe6cZUvmU9N9YylilFVUZxOCmrrU8xj1BHP6I2dejG92zmHKnrals+4wf2 kfZ990h+atCTwQxhNhu5zK311BEfMJM1XOAimeubP6lGC75iA9kbKCutGcd4JnCEvA3VA99xhvM8 1cgcwiJSfuA9T1OYBvRjJus5QbLG5hC6Mpld5PnQnMFAVpHxI+sOdXmfegxiG+FjfZBHaMIIlrOC szzQJB7KUJeWLCfNJ8Y4dRjMr5zj/qa+T2X6spaUzVyfTDzJm7RgIJM5TcFP9UnGsY3thOb6DS9T hxYs5jwPfGZO4A1aMZT5bOYYj7WwFjGP+RyjQEttzgL+omgrbcJSkreOhxf5ktWkauO6lKY7v5Kx rbWfvixmE7e3c68MZDtZ2isTFenKr9zawXcYwnZu6miOpAIdWMo6jvBYJ23APK5wZ2f9kR6sI2MX 45e+LCHF58rIF8xgJgc5xGHydTU/sIB4N+OCznzPLPZz7xfmK2rRnNmcIUN3dUZBajCQ+WziKPm/ VBYG8DP7yNrD8wQv0Ykl3PiVOYUvGcBAFrCPRE97CR6jGXMJvfRnWjKN6ezgL7L19lzFS3RnHVn6 GF+MZDPp+prnKERFmtCTb9jP3f3MsczkCvf0NyYYwQb+IMUA6xUlqEpjZnKRogO1G0s4wV2DnJNX +YAvmcBCrlFksDmT1WQeYm9KZ8aznR3sZBe7uXeo8jGDyxQeZm9BD37ntuHWZcbxA0tYygke+Vo5 aEg7fiLdCOOSspTjM6byG8dJjDSf0p65HODOUcYpXRjJ72wg+Wjjgt5sJuc3noGZyCmeGKPdWErq sa5HX7Zy5zhzMpM5Q6Hxxh/LSTPBWkV/tnPXRPMNUznLNcIke19yU4ratKc/f5BqsmtyIwWpQGO6 M4KDPDhFGzGb2FRrFq34lmlMZx+Jb+39KUx5erKOW6fpD4zmCI9Ot3ejG1/Qnfls4SKZZ3j2oD4z uEjRmfoPK7lC3u/i4WEeoSqfMZDv+Il032tTBrKLO2cZq4xnOxlmm1PISDGq8hn9mchpCs4xtllC qrnGF82YwEQmsZswz3pFIcrwJWu4eb49ASPYT8YF1hOa0oxPmchPHCDZQuOSyozkAHkXeXbjGzaT 5gfrLukoShWa048JHCf/YhmLSSwx7vmUyexkF7vJsNT5eZnafMYiblhmfqQPv3Hbcuszo1hFWKEf ECc/r9CIbgxnL3ev1MeZwA7y/OgZnjFsI8NP6p+MPEM1WjGIKZwm/8/ugzkcp8Av3vMDR8ixylgi F6/QiO6MZwHx1fo8X7KB7GvMyYznBNnWai/KUo6OjGIx2zlFwV/VC/OJr/Oepswl/puxy/vUoz4j WMR2LpFuvbLRn+3c+btr8iXryLrB9WlLO9ozmz84y01/qEvqMImT5N+oHujHRrJtMrfRn5/5hVUk 32zcU5wqfMBMLlF4i2vyHad5bKs5nzkc5RjHybPN+se7tKQnG8i2XXsykk1k3mFdoz9bSb9TG3MT JXmP9gxnBhcoskvd8gOpdmtfPuBbzvDEHnVLPeozlHls5hyp9+qn9GAjOfYZ8/RiM7n22wPSkEZ8 wDcsZTdXyfin/Qn92MgdB8xd9GET2Q8qJx/QmA8ZwzL2cI1Mh+xf6M8Osh9WDvqyjbuOGKs05kM+ YizL2Us4aq6gIsPZx73HtDlTOcPjx9U3vehNH1ZzhNQntBOFaMlSkp/U92nJctKeMrfTkBGMZBRb uUSW0/oVJenGOrKccU26so6sZ72nOZOZwlQOkOKc+6QYFejPVnKej4fqjGE5f1H8gjWM7zjIIQ6T 56K+xru0pCe/keWSdZWh/Ebay/oag1jORS5xmQJX1D0f8AVfs5t7/tKHmMlOsl415zCGdSS/5h64 geK8TQsGMImk//Lf4yERPmYO8VgiPMSHzOEaOeKJ8AqvUoHXeJ036UxXuvEjP7GKk5whXyIRmjCX efzOBq5yW7JEyEtDpjCVZSznEH9xS/JEyEkuSvA6dZnMNrZzjcwpEuE+GjGYISziLJluSIR7qM7X /Ml9KROhHv0ZwCx2cY1MqRKhIoPYxm2pE6EaY9jMFq6R/cZEKEljvmIKS7jGvWlcg9LUow8L+JMM aRPhScrRgLYs4E8OcEO6RLibJ/mYoQxjEae5Kb3PqcYQ9iS9z5AItelNH6axh9hN6oby9GM7d2dM hPcZyjBWsp9LFMyUCG/zDq0ZyjRO8NjNiVCT9/iKKSzhGvdmdr+8QiPas4iDHCLDLdqaErRkDGP5 hUNcpdCt2ogatGU4MzhFgSyJUIvadGM8C7hC0ayJ8AGN6cdMfuSG2xKhFJ/RgpH8wO9kyqYv0Zku jGMFW8h6eyJUpjtfMoN17OeuO5SDAQzkO9ZzgDzZE6EOgxjMD+zgNE/k0J5UpAmfs4a1HCNNTv2c mrxHJ0Yzm6tc495cifA8lRjGcFayn0sUvTMRivEmTRnIPP7gMI/m1hfpwud0ZQpTWc1OYndpR0rT hGEsYTcp706E+6lIC8aykRR5jHMq0YJvWMtlct6jDXifPnzPJq5x570+4wOa048JHOOO+xLhaQrT nsF8z48cIs39+iqVaM4gFrCT5A8kwoO8Sju+4zC5H0yEF2lIH+ayn7QPORdVaMdE1nOJO/M6hldp SDsWsp0dXCHdw+qW12nGUH7kPHc8kggv0ZRRrOEKd+VLhDJ8wjg2ER5VbirThgn8TuIxY4eqfM4M tpEiv7ma1/iIvszjMFkKJMKz1KMXczlM+oLqlYq8S0t68gfHSPu4+yE95ahOJ/qzmCNc4NYnXJs3 +ZTmfEYrRvINYzhGgSfVL2Upx6f0ZTyHeaCQ+6Y4JXiPZvRmKMNYxAYOkfcpbUVVWtGPCZwi+9PW K0rwCX0Yxz7SFnZ9evIbGYsYL7RjOYc4TOqi+h1v0ZAZnOfpYtqReVykQHHzEXX4golsIJRQBgpT ni/4ju/ZwiVyP5MIL/MxQ1nJSVI+ax6hEE0YxnAWso2TPPScvsYbNGUCP7KN255377RjGSle0P/o zmrOco5MJfUP3qUJ07lE8RfNiawmVsp+gAd4Mek/bMpAlrCUvUmfv2SNpgL9+JGfOEuml6271OAL uvM9v3OQPKX1CcrRhN6MZR/pyuiDPEZ5ajKCn/mFM2Qs6xzUZiIHeLCc+6UbM9jCneW1BUWoRQcG sIFrhFech2epSB8WsJA/Sf6qNYGKvMnH9GIMe0lbQXl5mNJUYygrWMl+kr1mTPIaLWnFCBaxnpte 1+Y8xZt8Qld+JM0byk5RqtOGPvzGLRXtQXiRBnRjONvJ9aZ5iwp8Sn8mcoiHKlnneYcOjOR7zvLE W/ZYvE8nRjOb8xSqbE6hPr34lmUkqlibaEozhjKPtWSuqpwU4FVqMZFJ/MxB/qLE24nwDDVoS1+2 sJXk7xgzPM5ntGA0S/iD26uZa3mGZ6lBE/qxkD2keVcZeJMWDGYxe8lY3bl5l54s4jA31zAmaMhA VnCAdDWteVTgM4axklPc8V4ivEBtejGfHcRqGQ+UojEDWche0tZOhPwUoRIN+JadxOoYZ+QgH6/w Ef1ZzB4SdfVhSlKf3szlWFL+vrmGxvRnAQfJVM+4oA49mM1OUtQ3x1KBzxjLr6xjKxdI08C1qENd ujCIhewhRUPzBq/TnvFsJHkj90BluvAtW0j7gbJQgx4sYh/pG9s3UYueLOY4t39orPEpY/mD+EfG P6/RktGs4grZPnZ+qtOThRwmUxN9mnfpyXfsI8snxhsN+Jo1XOHOpuYs6jGUnzjO7c3UB00Zw0+c 475P9Tc68z1HydlcG9KGGewny2fOSwfmcoYHW6gP+vILsZbWURoxjt1kb+X89GIIs1lFxtauTSle 4mXKUZ5XeJVa1GM6J3i0jTqlDH3ZTsq2iZCK8nSlG18wgpFMZgonKNBOf2E8E5jDXBLt1SXt+ZEj HCVFB3v0Dn//bfmezGUeyToaxzxLZ6Yzg4vc08k+mPeZyApWcmNnZaQPfdlE9i7aleqMZSObyPa5 tZ3KDGIr2bsaX9TmW5ayjOTd1Alf0J31nOcCRb/QhsxiNlcp2t3cTmtWkOpL90c13mUch8new/V4 jwlsZwd3faW8DGYIO7m9pzmFd+lLP7aRo9e//X3mb9jPA73NIRSlGdM5yzme7qNsfMf3nOfpvtqM FsznKtn6uWa/v/8u8FhWsJKU/a0zlKIzP7OP/dw/wLzFW1Tma/ZybsDffyP4ApkGmk95k69ZxnKS DbIPozWDGcJQ5jCX+OBEeI6uLCPlEGOFnsxhLmGoc9Bh6N9/gzbtMHXJ3bzPt1zgieHmEz5lAfGv 1RdFac9SUo1wPWryHrVoQ1uWcsNIfYKe9GI+V8g2Sr1RhcFsIvto+wY60ollXKb4N8YxH/A9hzlC vjHmU0bzDYd5ZKz9AHM5wlHyj9M+vMsYjnLf+L//vuMMFrKIGybYU/A0bVlGyonukbI05zMWT/z7 bzwe49FJ7p33mMBafuXWyeYNKtCPVawmxZS//+ZjSvJTgObMJ0xVl7SmDcvZwU5yf2u80ZNebCTb NMdTkNrUYTAbyTTdWKI9S1nGCnazh3tnqDu+5TyFZ+oPrCTdd8rNQLaQ8/u//35dWfqymRyztDUf 8TFd6cZgZrOFo7P+/htqt802FihFbeowicmcpfAce3BWkGauazOI3eSaZ4wzkoOc5RyF51u3aMUK 0i1wHP3YQqaFxg8VqU8DGtKIEYxkFBv4g41s4hLjQghZHwl/v1on+Y/JgKTf/iff+c8dNeE/ddT/ myX8Xzmqv38y/ockfZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRE SZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRE SZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRE SZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZRESZT8VyTFotqI kiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJ kiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJ kiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJ kiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkiiJkv8tk2JRbURJ lERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJ lERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJ lERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJlERJ lERJlERJlERJlERJlERJlERJlERJlERJlPx/NxlYLISM//47/6kk6TzhP3wn0/8NSeqk3/4l+V96 FfxHvX90oVvSB8lC+G1JIlxkbyyE2fG/swmkvyGEd28M4eWbQngiawgDsofQNHcIk/KEkOO+EI48 GMIn+UL4sUAI7xcKYUGREIo+q6ylQhhSOoTer4Qw/DXnqRTCX1VDOFQ9hGXvhZBVASZ9EEKnJiG0 ahZCxxYhXGkdQuUOIWxWsO7dXesrn/Vx3YEhNB8SQrbhITQZHcLCCSGcmhJC/ekhrP4uhJVzQhi8 0LmXhvDijyGkWuPY9SHk3hRC3W0hJPYo358hxI6GcOxkCFXOhzDtivuPxUKRFLGwKXUsnEkfC2sy x8KybLGwN0csHLgrFpbfFwuf5Y2FJY/GwtrHY2H/U7EwvFgsnHguFsqXioUtZWIhXiEWZlaMha+r xMKFd2IhX41YqFQ7FjbWi4VajWLh6sexcKRZLMxqGQtL28bC+I6xMOXzWLjUXd4zFnL3j4Wjg2Jh 7vBYeGh0LGQaHwtlJsdC12mxcOi7WGg6JxaSLYyFikuce6XrroqFgWtjYd36WGi4KRbu3qacu2Kh y5+xMOBILIw+4Z7OxkLni7Gw6qpyx+Mhww3xsP7GeEieIR4u3hwPzbLGQ+/s8TArdzyMviceWj8Q D30fjofNBfxeKB4qFomHYSXiIc8L8fDyS/Gwumw8PFkhHvpXjIe3K8fDonfiIV3NeKhcNx7yN4yH xh/GQ72m8ZCpRTzMaxMPb3SOhy+6+6xXPGTrHw9Vh8RD/RHx0H6M80+Ohw+mez/L+ebHw0+L42H3 inh4Z1U8lFrn3H/Ew7vbvN/tXH/GQ5Gj8XDvKec6Hw8Hr8TDzlgidE6RCHVTJUK1dInwZMZEKHhr Ihy6LREy5fA+dyLMy5MI39yfCIPyJsKORxPh88cTodNTidCsiO+VSISPX0iEcy8lwhflEmFGhUQo XTERSlZOhPrvJELuGolwc+1EqFQvEXo0SoQuHyVC9WaJ8GbLRMjYPhEKdEqEFV0T4XyPRLijrzIM SoTBwxKhyOhEKD4+EdpOSYQwIxG+nZUIdeYnQoN/xtU+40oThQMc5BCH0WThKMc4juYLJznFac6g OcM5znMBTRsucZkr/IWmDtcIxm4MzR4SJCM5KdANQkpSkRpdIqQhLelIjy4SbiIjmdBdQmZu4Vay oPuE28jG7dyB7hRykJNc3InuFe7ibvKgq4V7uY/70e3CgzxEXnTB8Aj5eJTHyI9uGQryOE/wJLpp eIqnKYwuG4pSjOLovuEZnuU5nkd3DiV5kVLo2uFlSlMG3TyUozyv8Cq6fXiN13kDQyC8SSXewnAI VajK2xgaoRrvUp0aGCrhPWpRmzoYOuF96lGfBhhKoREf0BjDKnzExzThEwyz0IxPac5nGHahJa1o jSEY2tKO9nSgI50wNEMXPqcr3fgCwzV8SQ++oieGb+hNH/rSD8M5DGAggxiM4R2GMozhfI3hHkYy itF8g+EfxjKO8UxgIpMwLYQpTOVbpmGaCDOYyXd8j2nj+tp0wZjar79bVkI1avIpbWj3z7qWKdeM a31a//1vekPrieurYIoTWZKGScrrQyXE/htJ74uF7Ccz+DngsaTvXgutW7cOlosMIX2In+gZkn5L eSLlvxyUtECGxImkVTh9SHbi3ut5qhMZwn98xUPq68clFT75P98v4WfGf/Kkc4V0Ol248YQ1Npjz Xevn2PVi+DdlSJZI5feiidj1a990Itk/pUh6NeBDOtEDM2VIbib6wi6hD9ecOYM6eJ7X+IKhjFPU GSQVOWaJf5witKYTP7KWMhkdRy8Gso29vJNJt2Y0EznGWRrcrNvyqG3C0wzmG554wPCjNyOJ2T5k 5PhDCp1XmcnFIGby+MOGKBNZSm5VXZhJzOMHfuUJW5CiPEdFNnGCZY+GsIVHNGdxnqci/ZjI4/nd G+dIYwtTmzYcJWGv9AjFaUgPkj9uKmMiP7PsyRB+4R1bn3psLRrCbtIXMxVSiir04GvWs48sxZ2b SjRmMDPYzjke1jUKUpkGfEBber9gmDGW6dxZ0jTJ05RmHkto/qLvM5qJ/MEJLpLC1qwxTdjCTlK8 ZBkgw8umee4gN8WpwNu8RyNbuub0K2NoU66sfkHWcr7PU7zAy7xJA1rQll6M4nvmsYrtnOQc8fLO Q27epi4jmcrLtpGV6MVIrpDuVX2HPJzlhgqWNHKwjUO0svX8nGNcI9vr6oz0b1jSuJ07KcarVKUm dSqaemn6pumTfOaZgklzzVuWTopTmkOcJ29l/ZJ+jGUSi/i0immWHoykii1wHW542wimxTumZIYx kW9ZyG/s4QCXuEpG89yTvERZqvM5/ZjELNayi9TvOj+vUoNOdKc/w1jJLg5xnuq25bVZxa+c5yop zKtpyURWHqckFXiL3rbyw0hZW92Tnlu4nft4/X3f43Xb/bcYxrikrT+zWVc/hB3s4RQ/m8i2sosz HG+ozhuZNLmVNB4ZsnCNVI0tSya9r5nFMn5iI0e4yFUyfGQbw72UpRo1acZwJrGE1RznHDs+DmE/ RzhFBo8puXiI/OzgEH0/0a6UbapOyO9Rpgiv8y61+Igu9GcIk1nIOv7gABdJY/26iTvITxE+pQML +JnazY1bprCQLJ/ZSpGXElzjJo9SmbmP/Zymc0tjh/OkbKXPcx+1aMUIxjGDuezmMslaOx8taEt6 6+st3NZWfXAPD/ES1WlIE+6wBt/LWrbRpb3+x+se796hWEfjh/b04ihXSVjAbmEDf3KEa8zurH2p 7tGwPps+t/5wmZRd9VGy8TBFeZbXqUQD+jCGCSxkP6dJZZ9wM49RiNeozGf04Wsmc/4L5SOZx9LU 3MuTPMtL1OIjXvvS/dGUFgxiNLs4Sh6L82PUpRlTWMQyNtLOI2/vr/5+9J3IG7Yc1Yn1Mr441ltf 4TGPxcX4jM9ZynrS9jX/kZvHOcxfxPrpE6xgPXX6Ky8bOciJAc5LwqN2GmrxQdJjN+0ZwWRm8QPP DrKO0oJu9OVr1rKZE1wiNlh98SRP8zwvUfofP/N/sG8n0DbWex/A/852Iip1r1I00FxXV6LMUWaS uZMhocwZChkzZ0iEDJF5nlKZKdJNKNLkllBvUt4kFIko3s9ZZ1t71+EtxdttvZb1sc7ae59n+E/P 8+zf92Qab21jZ5E0ocntacJAChVNE2p5bK5NW/etOdy3Jrpnnc9XBxPCTi75wePgoYSQ8bDHW/Zx mOvd/Oz6KSFkOeJ9jpLuqEdICnp8fJCbEiJu/SNu3yNhWE6PdHzOXjLeFAmXkJc7qUUTujOYmSzm PT7lIOk9aubgn5ThLT5KfvxkN1lzRcLN3E416tOOxxnNbFbzb/YTuTkSsnEDZUniUXoxkRd4i80c 4ubczoeatKUn01jAh3zBEc7xOHwj+alJY7oygBks4n0y5YmEnBSkNk3py3DmsoLN7CBtXo/G/IMC VKUej9CNoUxkKWvYwQEuujUSruZOKtGU9gxmHEtYzQ4OcO5t2oSClCGJH0nv8b4qNWhIB6aygnfY SYX8kXAPTWhLb56gP8MZwUQ2soMrCmhTClCcEtzNQIaxiKW8xOus4m02sJktfMpWviJtQcdPZi4j H8W4rnAk3MFQKt8ZCa+wiSOltWmZSMhQTn+xjm28Vz4SvmP4XZGwkHsrOB+y3B0Jt7CBfZSqrC1I XyUSrmE126lXNRLacFE1Y5Wy99ovzaldQ9tRp6Y5cr/5QNq6xiiT6VHPuTOJZaxlKxfXj4Q8NKAT /RjFej7jG85/IBIu51aKU5cWDGIsy1nHDg7wtwcjITtFqUBzOvEMU3md99nOd5zTwBwjF0WoQl/G MItVbOAbjpCtoblFSarSkHG8xBt8zE6Ocm4jbUgeynAPrZjKMtbyGd+QsbG1gzwUaWJcU4dH6MZw prKCPaRpaq5xNR0YwniWsKW5OdzCPljLVvaQtqX24QYKUI369GAQ01nIB3xOpFUkXEAuilCTxvRh GR/x32R82LFTiLLUpxUDGc1y1rGNnW31Exc8aq6Qn1LUpQWDGMt8/sU2vuWids6VIpTnIToyjud4 i80cIn17Y4B/UoFaNKU9o5nJGj5gF4fJ2iESrqcU1XiUXkxhHmt4I+oDviOho3nIrSTRgN4MZQGv sZMfuLyT/qQrA5jLCj5nLxd1dn5UoBY9GcwSVrOX8Jg5TX7q04qhTORNNnKUc7u4BnEnLejMNBbw Kbu5tKttkUQDhjCqu/ZkIS/zPh/wIR+Troe1j8a9tCdXP66NeZ+NfMIO9nOIer0joRlF+xgX3E8T /osdHOXsvvqPRbzFh7Tq5xrHdnbR5QlrCYX7WwOoSHV2spefiDwZCYkDzAmykYNVrOM9PuIL9jBg oHWbmSzic3bT8ilziScZySreIeegSLiNstxDTwbwNfs4TBhsTpKOmcznxiH6gWKUYzJzWMoKWj5t DaYTPRjIM5Qa6prM2yO0PzlGGZt8yR7WjDan2cYRsoxxjOSmHMPG6Uu+mKiNyTXJGKUejRjDPFaw hSKTjQPWTNHPPDvV+6SZpi2pTh3WsJleM3yGKjONLzbzLXVm6TdGz9aunPec46I3I2g9x5hmFIuY 96I2pu8C5864xSlff9+yxPrE0wyl+Sv2EzWC0YxhAvN4mTVs4Ev2coBDpAtpoy4944zfIdufvP8z /rOkjeOe6gR+27Z+6+fOOLHf34bxv/nX74lTewantz0y/+lX5DN3BCcnftWLX/+OvZLyL7kQmrqm mJhchWQAg9KkVCWTy/PJZfbksvoGNvE3t9HZcCsf3I6H/mlDWEDdxBCaM53ZRM4K4SwGM5z1bOTy dCHcTgMaMYs5tE4fQjvmsYrrzw7hZr7nIIcpmiGEO+lNP9YyJWMI22l2nv3S4W8h9OK9aA1z0N/t nxdZwuNZHDcdLg6hEx+whayXhHAVc9lCr6whjGA337EkWwjLSXOpc6MRLdjNAXJfFkJBHqELC3mJ 4pdrP95iA0lXaCs28gmVs4dQneE8y/t8zLk5HBO96U++K0O4jwY04QWW8j0HKXuV86EPg1jD2+zk yqtD6EpvlvMp918TwiSqX+tceZVdpL3OOKAc5RnEUPZz5fUhzGcn79zgfKhyo35jJa9T6R/OKa4G PJNZ7CNzzhCmMTNnSrRsD3lvCuEOOtKZV1l/U+qacWkqM4BBcTXkzWxL/kwuYyZX6pryXn6Iqy03 puXNqWvMaXNr87gac28GsI71ye/dEsKF5KM8nehOJE8I6fKkrkH3ZXBcLXoTn3FxXu2YN1ab7kQ3 VvB6XK06L0XjatYzmf+/1K4XspQDHI2rZd9FJYYyMq62/S37yZc/hMIs5r3kDEWBEBIYwBB+Ik1B 846SjGIaiYVCyEQVqjG/sHMg4XbtwY8c5c6i2ov1/DtaO89RLKV2XqdYSu18YrGU2vn2Yim189zR 2nnraO18QbR2foApdxr7bGY7FxQP4VJKU4XH6Ms8lrOD77iiRAg3Up269Gc4r7KOAySUDOEm8nNR qRCyU4cHGMkUdnNeacfGY6VjNfud7Iqr2beia1zN/tyytklVksrGavjHavd1y4XQkKk8z9fsjavd V6EGL7KYDHcZJ3G1/GM1/EP8SMEKIZSoEKvpp73b5ynH3fRn8N2xWv/rvEf6iuZpxVjtfyJTT0MG oDAVjpMFOMQRilUxl6qkzgZ8xe7jZASG80zV1FmBLnSLywzkqq5/aEqr6rEMwdtsOk6WoDL38gKL ODvJtuOyBccyBd9zkNvudez3xjIGiTUcDyWpWCOWOZjKPHawv0Ysg9CT/pxsFiHbfcYC9WhwX+ps whFCHdujeJ1YVmEei+IyC7Wox1jGs5uj/0dZhgY8wqP1YxmGyg+YL4xkIh+z7YFYhqHcgz7DDF4g OSuWEJdpOJZlmMNibmlozaMjPRvGMg67OcgjjVzPWMprnNs4hCxxmYdyJLGdneRsYkzRgvbMYzH7 +JFLm7ousYx/EWlmTlOSis1iGYrpzGMHe8j1UAi30oZ2x8lWJDY3VylEieapsxYF3eAVoQ2PtUid vbirpbZhCM+yka9aps5ktKQdC1jeKpbReJDGzOL5uMxGDe5nNGP5mp8o6WazLE8yqPXpy3Zc1dY6 Tw/68RGb28ayHscyHstZEZf1aNVO37eLZT5W8i7p2htL7WMZkAnM5jO+5PoO5mSHU58NSUrOg3RM nRG5sJNxTS3qdUqdGTmrsznVOXV2ZDwTO6fOkPShX1yWJH8XazOt6dAlli3ZyLYTZEy60Zcn47Il zbqF8DDzeImDJOc3j2VM6tKIV1hF5h5e7xHLnBzLmhwhOfN5Wc+UzMls5vSMZU+OkLGXdY0KvWJZ lM1si8ukzGDub8imPExrFvFSn9RZlZp9Q6jNGMb1jWVXMvUzTvrFMiyLWMYhfqTcE/rsidOXbRnJ aD5iK9kHmAsUoQSjmcS37IvLuvwy4zKbJezhMMWeMnef+uPZlzyDrWe047HBqbMw6YY4J8pTeUgs G/McLw6JZWSqU4tnGEWaodqRS7iRRbw89OSzNEMYzia2HSdb04o2LObVEbGszSXPGJtUo+YzsezN ElbGZXByjnRNpBs9uGiUOUShZ83P35ClWT76j2VpKlE7OVPDTq45lBBy0pAWzGIuK1h1KJa9ycpl 1Kch05nBet6Jy+TcTzP2cIi8PyWEQnSkF+vZ8FMsu3MtN9CCR5jPAjaxJS7T04x2HCExREIJytCD J1nNm2RLEwk5OJYB6kYPVvMG5yREwvlcxw1UjWaDJrDkJDJCvU6QETp8088zQqt54yQyQuP+YEYo fe5IuDL3qc8KbSVNnr9OZuh7Dt4Wywr1ZRgjo5mh16KZoV0c4AfS54+Ei8lJDTrQmS50jWaHJjGF aexiN3kLRMJtBVKyQ5XoQI8CKRmiscxgYTQjdJAbC0Y8Q+t/uvM0E3meeoUioQVXRDNDTXmInjzF Xr4na5GULNEoxrIomik6r3gkXE4+SlOXVvRjJHN5jS3sInOJSMhOT/ownuWs5UMKljRWSaId45jA Il7julL6l0EM4++lI+FCnmU8m/k4+U+xolmnAhSiErVZwUrSlY2EDNxNc4Yxks1sJSGakcpHcaYx i5XRzNQ3/Mjk8pEwlTejGao0dxkfPExbBkYzVa/xNnkq2CaVKqRkrHowkL18T6Zo5qoo5XmeeayL ZrBCRXOItnRiCcsoUCkSCjOeydxa2WvcXjkls9WarmzjvwnRDNct3M5EpvJKNNO1j6PUiGa7ujOA b9nPedGsVyFKMyua+0rOfHWkN/+sYV2gWo2UDFhvhlCwpmOlLr0YzBhK1rItmtGbpxnH67VSsmOt 6MyWaIbsAi7jsbopWbIXWcY19YwTSnBPvRNnzPaQoX4sa3YHScfJnE1nxX9A9qwuHRucfAatDYNP kEULjVKyaNdGs2hlo1m0h+nCyEYpmbTljVIyadsapWTSzonLpBXmdr7kKxKa6JsmJ86qjYxm1daz 9TiZtVsoRTWaHSfDtpqvOZT8+WY+TznubZaSb6vUQnvRlE4tfj3vlrPlH8u7DeP5Vr8v9/b/OfOW k0p/gexb7m7GObd1j4RifMYXcZm3/Vzb07pGMbrTj/S97JMSVKYfT7Oef1Pr8Ui4j7OSs2607a9P +GxQJFw12H7JS8shxlhyNmyoMUbx4a7bdKQTiSP0F8+zkukjI2EOG551XiSOdhyUoSoDGTo6lhXL OMZ1lCokJWfEGEVkrHOkOOXoy1DeYAPnj4uELLSgDfNZyGHyjbcu8zivspLECdZb+jCA1bzLuRPN RcpSkdW8Q4ZJ3qMSVSbFMml1J7svZhwz2MLnXDlF31GLOlNimbUjXDhVP1CKpawg7zTzk+b0ZDff kme6MUxHOrOcleSboY/5hkPknOkaS2vas4hlZJhlfeRxnmAN71JldiRU53Xe4tbn/D5zeIGsc4y/ uAzcuyQ+71hZTeQFY4o3WEuzF411NvMJl8/1LMA/5jtWmtOG+SzmEEcptkCfspYNXLBQP5JEDcYw jk/YwVWLjG9GMomP2caVi72+OJbNu2xJLJ9XhoeWxHJ6yYZzkCMUW2oe0pt+vMl6Mr1kLJDE/Yxl Ale/bP2iIa2YyhyKLXPPwCfL/d4rx88DTnjlZPOAeU6hxF84lds+4/Q4009nnHHGGX9dvzWL+2cf Z7z/tOP5M/3yvunX/Nr2zrTtz0VO8tOn70hOtVM1Yn7N6WqT09vWmU/5E87JOpn9n7kTPz2S+yDR /yntmzwmfs9Wfn6V/fW097Vnh9CEprzAixw4OyVp/WiGELJkDKFmxpR09Zfs4GuuPi+ERhTLFEJP etGHT/4ewudMyxzCc5x9UQjnU4kkPiNnlhAeojXzWMru60PYS978IVQg0z0pybtQPyUZtjOa9Cr9 YAiN2RZN+mRvG8IdXBxNokSiyZIboomIE1XRT7aCfuzb1WPfMJ7orx9rneAbj8nH+bZjI5vivvXY f9xvPk72qvtH/XL8/FaJP/s5bartJoSjRw2IcE4oEeqFR0OT8GDIHqr4uWFoE9oalfeE4qFgqP0/ 7d0JfNTEHsDxye72orUthbYURFflUmy5BIugFkQE5KgCoohAT1qgB6UgN+VQC14IKIgIKCjgwSXe ioCICir1QA5Rq6KiAqKiHAp9v3+y3S41S3d9PN/z8zJ8vs1mJ5nMpNkkk/1P4f08lcZ8Nvqp5ipB NWVawHJOlcO7qUzTVQZlZKihLJvPuxkc2YUsNVK1IjcembwnSzZn7aZ8NqTcAtfW4iklg2mm/iqf raWzfrx7y/H61oxtSYkDWC9XXz+D2hhLWe34p7Sj7z+iHQPUYP1V1e1J/p9tj1V3q+5W3f9ZdY9T 48rKyo4v2zusLKLyP02NJ6/fhvWjzPImkBd+796XzfImkvd9yryxZnlFknd4fz2zvEnkrX8hbIBZ 3mTyvtm2drVZ3hTyNr0wZqpZXjF5UfXH5JnlTSMvtaNjh1ne6B5f2fs6S9r8OS9SzR/9nGNm2dGO Znm1r02NKB478CWzvHsi8qNWLfnNZHuRqlVkj9ptiwvbmuV1qZVbO3DwvCNmeXt7z2q3aOWe6WZ5 C3pqXYqKdtc1y2tXf0OX/IOHtpvlzc6ZkVxNdY0zy9vfs31qv6j2x8zyegcfTj00L3+DWd6+xtPS n/rxeH+zvLzmiwd5K7Mkcea4Ne8FLjbL0/RejfHzlFSLe/ypwUHVp849Gb05QGnBQYH9mR/IvPSE EqpYc1GAe81FAay5KMDXNRMd7jUTHayZ6PB1zRKbe80SG2uW2E5dM/bP66nQ07SzRxfjD9jnNWL1 5w+dvgjzBvtVhHnL/SrCfBeYFOF9L2Zp7iKyNIrI0nzdi+ZrmtU/smLVLM2zCJ/rHzvDWxHefhF2 irAbReSp0xeRH+wuIj+YIvKDjSKCKCLIKGJpFbVICnUXkRRKEUmhfjckMtxdRGQ4RUSG+92Q0kh3 EaWRFFEa6XdDVtVwF7GqBkWsquF3Q4pi3EUUxVBEUYzfDUmOcxeRHEcRyXFeGqIiK47r8iJ8Ozs4 Znhb09u5THOtaZvpbU05kLqWnXogdS2z0Zd3ncu8btP8+LEpe5W1NT9sbMpRZW3laHHV1n20dNVH C1RVW/ODxKYCq6yt+bFhU0FV1lYOCVdt3YeE1Da4/DxlnWSsk8x/5iRjHVrWofW3H1q+3115rYW3 G0w/GuLtTtmP38jOEHcRO0MoYmeI3w1ZFuYuYlkYRSwL87shoyLcRYyKoIhREX43pFOUu4hOURTR KcrvhtSKdhdRK5oiakX73ZB9se4i9sVSxL5YLw3xfmtU1S2/98u3t85a1bdGciC5Lt/uA8m3WyPz 48eXWyPzw8aXWyM5Wly1dR8tvt0amR8kvtwamR8bvtwaySHhqq37kPC8NbJukq2b5Kpukq3LTUUR 1uWmoogzcLmp8iTjdU3rJPNPPMlYlxvrSPh3jwSrv2z1l63+snUD88+4gbEuW9ZXCdbzXuv6VfX1 yzrJWCeZBBXHQhIRpTySRPt4zktEkee8RB95zksUk+e8RP14zksElOe8RAx5zktUkue8RFp5zktk kue8RGl5zkuklOe8RGN5zks0mOe8RI55zk+pND+50vykSvNFleaLK81PrDQ/odL8+Erz4yrNl/0t KU79leR9vSiOwhCHHQHw9jpKRfAzDnXg7bWvZZ3JpXyr15ms/ZncYoRPW/z7f0O+lCVHj4wvOQfn Kv2/DFDtcZUyRj2NxhiMxXhMwAOYg7l4Ek/hacgIHEk2zbBA++uvH0BZklakqRsm23UlCXUCNGXM S+rtmtrKb9OOsfl8xZk1ST4qchYOUr1pxBDkqVv5Ke8Gq4pkLCVTpQ+0qfxalr0mRq4KNlugPcAR YLM77hijnLxdVF6OqwjVS2XrwcfDye7O9FYlIc15vJei78iWlMNFKkCzaUGBtoAg1+oe95iqSH70 ZJfnqFTWHMpcnwZsPdAWGuiwSfK69XaqgO2n6Ot00AOis1UaU6fqSEkSEO1UzVRT3ssnR/5rBL1V QfYQmy3A5vBa7lWsPUIvO4Of5S1jr1SfoRVVU+5kLB4UXNEcY+BcN9rj5Gc2dUhTWUr+OnZ8WYsy pwrPrMuFqGUDfVnax+516O07T51SD6PkXrQty7U3lWrDvpwUZLMHsmFJK21q1e/jdmQ3da210PVb bs/Shfr+l2velfxj3UD996AqpT/9HvrodR6k0l1TGf53PrcnzUKLlTpUYtvrMC709aKGByahJuQ/ UlNqy3Sl6sTa2Sf3s4RD2SPnUNH4rkolrpED+DOWWeC6KJ5nV4c8N20lf1KJrVRbq9aqSZOimsqv ME7JvZNcJIu32lXGSa2qAk6bbO5XYc2nXCe/J89zh1kqKyu/d+qoOuufOvnU5OoDDJx8LssHHTjP 0L+2fB5T9LOOk8+GDIoo5FMic8n6lofrn/0rXHUK5CyRy/KDWCblNIMvrPTfTCe58gR4HHvlSUPp bQt/PtYjK/LJ+4JV44bP7JLz3Vua3P4Z+XJBljUXQU4wh5Scf5T6Qyn9jBemyVFAz0STayPnLs24 xiUyDWGa7CqrH1M5uY9iGsp0qiYDUI2e1VlM5zMNZ7qMqfQGVmnGCfQFpjWYrteMeux1GDcW16Bz bmFGQW5GobNDQUpmodOH1LZ7Sk6GMy/TWZiV4UzOKBiel3uFUZ60VVGevJZ2tMtNGZTFqb4iL2VQ 5dfSju55BTkpQxPS87goyHvSlg4pI7PTnddTpxHDFfWS96Xul6qR2fJa2tMtO60gb3ge1e6TV5Du bJ3QVDmTpOzUuW/IftZfqyY560o3avrrgWnL15e/PrTavonXdld9ZCpXCJnKVeKU3pGVrGQlK1nJ SlaykpWsZCUrWen/Jp2u/2/b/u72+Ql1ImfNof9/8bEV0v/v4OqTS36+Mvrjo5TR7y9WRr9fvrCW fr88H6iujOcDMqB7mTL6xauUq/+uXP13xOAtZZRdooz+/wWV+vVSdrfs3AylCo1+7KEAfSrPO2Uq zz9lKk/jZHogPETfnnJt12x6TqTRljP4zCAs0qi2VFl2Q6/swqEZqrxDbiUrWclKVrKSlaxkJStZ yUpWstJ/Ien9fGX0m6UPL31s6bTK99zyXb18Ty/fzUt/Wfrk0j+X7+Kl3y99eOnfy3f40o+XwL5o ZfTlpb9fSxnRMRKhK5FKZ6Ouqgj+c+I8JXFO9PVRD/UhQVoN0QgX4iI0xsWIV0bQYBPI84hmaI4W uAQt0UrJ9+lKJaI1LkMbtMXlkAgVic1KUhLJVhGA2AFXK4mmMZ4HdEJnSMTxteiqJMJMqe7oAYmU vg7XK4mjk6gxpXpD/iJ6H9yIm9AXN6MfbkF/DMBApCj9r6erNEg0UQYyIRFkWZDoucEYAom2y1FG oKREtsnzl2EoUMafiy/ECIyERM3JcxnPgEqJ1C4PqpyojMCzSZiMKZiK23C7Mv70vDzPmYbpuBN3 4W7cg3uV8ZznPszELMzG/erUgM0HMQ8PYT4exgIlMXPGc6FH8CgWYwkew+NYqoznRcvxhDo18HMF VirjOdJqrMEzWItn8RyeV8bzpRfxEl7GK3gV6/CaMp47bcBGvI5NeAOb8aYynke9jS3YinfwLt7D NmU8p3ofH+BDfITt+Bg7sBO7sBufYA8+hUTkfY5SfIEv8RX24mt8g2+xD9/he/yA/TiAg/hRGfE2 P+Fn/ILD+BW/4QiO4hiO43dlxOWcwEnoAaeaBDQaAbB2OBCAQAQhGCGohlDNiOc5C+GI0IxRJdUR hRqoiWjEIFYz4n7iUBt1cDbq4hycCyfOw/ma8axP4oPqowEaohEuxEVojIsRjwQ0QVM0Q3O0wCVo iVa4VDPijFrjMrRBW1yOK3AlktAO7XGVZjzbvBodcQ06oTO64Fp0RTd0Rw/NiF+6DtejJ3qhN25A H9yIm9AXN2tGnNMt6I8BGIgUpCIN6chAJgZpxtCObAzGEAxFDnKRh3wMQwGGoxAjMBK3akY81WiM wViMw3hMwEQUYRImY4pmxF3dhttxB4oxDdNxJ+7C3bgH92pGfNZ9kNEoszBbM57BSjD1HMzFg5iH hzQjjuthzQi8XohFeASPYjGW4DE8jqWaEe+1HE/gSTyFp7ECKzUjDmw11uAZrMWzeA7Pa0Z82It4 CS/jFbyKdXhNM+LGNmAjXscmvIHNeFMzYt3exhZsxTt4F+9hG0rwPj7Ah/gI2/ExdmAndmE3PsEe fIrP8DlK8QW+xFfYi6/xDb7FPnyH7/ED9uMADuJHyNiun/AzfsFh/IrfcARHcQzH8Tv+wAlIoKoe cc2FX7NJtDmffzgQgEAEIRghqIZQhOEshCMCkaiOKNRATUQjBrGohTjURh2cjbo4B+fCifNwPi5A PdRHAzREI1yIi9AYFyMeCWiCpmiG5miBS9ASrXApEtEal6EN2uJyXIErkYR2aI+r0AFXoyOuQSd0 Rhdci67ohu7ogWRch+vRE73QGzegD27ETeiLm9EPt6A/BmAgUpCKNKQjA5kYhCxkYzCGYChykIs8 5GMYCjAchRiBkbgVozAaYzAW4zAeEzARRZiEyZiCqbgNt+MOFGMapuNO3IW7cQ/uxQzch5mYhdm4 Hw9gDubiQczDQ5iPh7EAC7EIj+BRLMYSPIbHsRTLsBxP4Ek8haexAiuxCquxBs9gLZ7Fc3geL+BF vGST77nKyl5h+irW4TWsxwZsxOvYhDewGW/iLbyNLdiKd/Au3sM2m8SD8/nHB/gQH2E7PsYO7MQu 7MYn2INP8Rk+Rym+wJf4CnvxNb7Bt9iH7/A9fsB+HMBB/IhD+Ak/4xccxq/4DUdwFMdwHL/jD5yA jO8sg9z0S6CoDXY4EIBABCEYIaiGUIThLIQjApGojijUQE1EIwaxqIU41EYdnI26OAfnwmnXRySo 83EB6qE+GqAhGuFCXITGuBjxSEATNEUzNEcLXIKWaIVLkYjWuAxt0BaX4wpciSS0Q3tchQ64Gh1x DTqhM7rgWnRFN3RHDyTjOlyPnuiF3rgBfXAjbkJf3Ix+uAX9MQADkYJUpCEdGcjEIGQhG4MxBEOR g1zkIR/DUIDhKMQIjMStGIXRGIOxcP2f72oCJqIIkyAjm6ZgKm7D7bgDxZiG6bgTd+Fu3IN7MQP3 YSZmYTbuxwOYg7l4EPPwEObjYbsxGmUhFuERPIrFWILH8DiWYhmW4wk8iafwNFZgJVZhNdbgGazF s3gOz+MFvIiX8DJewatYBxk7th4bsBGvYxMkwHoz3sRbeBtbsBXv4F28h20owfv4AB/iI2zHx9iB ndiF3fgEe/ApPsPnKMUX+BIybHUvvsY3+Bb78B2+xw/YjwM4iB9xCD/hZ/yCw/gVv+EIjuIYjuN3 /IETOIkySIdfgw12OBCAQAQhGDJkT86doUzDcBbCEYFIVHfl12BaE9GIQSxqIc6Vf8IH9VzLlrPS fz7JmME8fYzQ1foIogL9iYHvKYYeY3lZckgFyg2jMvrWyniU4k4Dx8+OlrEJDRyuQW9Knt/IWLtU NVR/8uF/CtdHT1akqtfgXEAVH5hv1LMPrS9Q6aqDkv9mZYT7P3TxNdWm9yzPzPzZvqRmhcaYwADV U9+qjDSUfS/juDL1OuXoowmz9TFV3lMjti8tYZcqX7dfTRZ2DQMM+FPL/atPItv3d/9HeWxf08d8 5qh81YOjYPBp1zNLUWxfujLyzNKf/V++JWOrGeyBQpWsfxaGnna9yimGFlTV/vLjvnxqtsy/k/zd /55JKmOda/9/k8Zv317NOIYqn7vl+X2lsWgd8tJG5GTkFurfCXTrKe/xlv5hltcJ5fkJiepw6zXD zI85K/3vpH8BUEsDBBQAAAAIABhIYi5xnNyx2ZkAAJvXAwAhAAAAZHJhZnQtaWV0Zi1pcGNkbi1k b2NzLXJmbWlidjYudHh07b17c9vKkTj69y9V+Q5TvnXrSBuJFqmH5bN3q1amKB8m1uOI1Mlmt1Jb EAlKWJMADwDqkZv9wPdb3H7MCzMACMqyLNlidhOZnOmZ6enu6df09M+6hyfir0n6OYqvxMc0Wcz/ +IfDljgPJvki++Mf+nEepnGYi8MUvvnjH4ZhGtwnsegGcTAOxKd83IL2yWgxC+P8ZzHGVptRmE82 o/loHG+Ok1G2mU5m0eVNZ3Nr749/OA7S0bXobG1t//EPf/yD+OMfenfzKA2zn8UgnOfh7DJM9a+n l1kyDXP88fyo29l7t4Xf8n8Ef86DcZSIozT8fRHGo3uxdn60LmjSk2AUimOY5lWIc4MvJ0k6C/II Zv8hyEINwv5AE3F42h30B6LT2hKjZDafRgH0Pj8SkYKa4fiDPAAEiWQi8usoE8fhLJHTGuK/xxIl Av4OYqHQuElohG/G+EMUi8liOoVheG4xzPg2yq+FIEAB/DRPk5sogznTUINwRPNvb+G/ECdbnb2W HLc4BgybAjS5sWo6csKhbix68VUUh2EKrXj2QfZZHCUpTGWt3xserW+IiIEF2QZPHP6p4F4hwWQt IU6SPATAQU5AEhgilT+KWXAPS8kSMY6yPI0uF3nZvILMLIBg8CrqFkfEZoG4CabRmLYwgEHvotli hsvNojsCMUvi/DqjJeCULkOxmI+DPBxviDScT2Fj4S/onEiqG4vLe14Jdbemiht4L/JoFsLK+zlv ZTCHvZqnUYCISMRCUpg38QxGm4RpiJsN5AiYD6Y4LPQZRYTEcCYRCPiMmRIy8QZRhhQDo1wBv2St N5reQjEF1OJaR4s0ZWIvjjoCGoQFByOg3gxWJvfpOs/nP799e3t720KebSXp1Vv84207Gm8Gl7Bd wQj2IL/LS8ZyaHpwHYyTW3EIzDzKkzQKVxo1o96t63w2pS3vJvP7NLq6zpGyolEoxzdfr3XXaTaa kAfJCKCBBEDpsd4SB8A959g0E+dhFqY34ZggH8hl2dw6A+4lTpU0lYbMdIpbshyoJkjHmcCun5Hz NlEctQjE2RR4AxqFoXijOPS96MLmXQESJmkyU+LrjaTOcZiN0mieyyEkeY6jSTQiAQUcVZQi0AvZ LlsQKuFftxEsT1Gqng8Bur0OY8I5iNNxy1vmOJwAw+Na50maW4uskZVi7bj/YZ0A4QKAtllOAd6J LGemK5BnnoySKUm3gqQBYTpbxFF+35KMIeYBTGC0mAYpChlrZpdBFo0AoURnDHwMq/0fQG5GMxic HJ+xmICm4dieAPSQEtyS3iWnBPU2Mt1HFNEDLGe8GOVabNJxWZB+hAlea4HhbclqSdUWEvFMChIQ YrCDEfL9mARTdp0spmNeGDDOeJwy54BwwOELA/+EojWa4r+JJUEs0Zn774qpWHTE47coXaB3sMiv kzST/BXfwBzoYFngCLQCi+Qshv8c3uPIQP1vji8Gwzcb/L/i5JT+Pu/9etE/7x3i34NfDj590n/I FgQIvjm9+CQb4V+me/f0+Lh3ckgQAPTB397wQfPm9GzYPz05+PQGZ0dQClMk/AFmAFO0j/OUpDYI S+avS17Wh+6ZaO/IaQCniE67/V78F7Ik/PH3FusTw+ByGuI2A2Zy3B2JgDahAOnNZpCjNJiFRPqt ZR+xTXA64uM0ybIgvV/epfSj4LTaonsw/O2BUCw4HRJRcTh9GCgNZ1t0jx88G4CzI+HsAJzh4OHr UnB2YQvHuDnjB8HScPbEYZAH4gwEPnDz8o7OR8N5J8YfZl+wXwrOvpJry/uUfTSc9+IwuY3hEAyD 2QNgaTighP4SBuPNMH4QosWugtMWxwfdh+NZw+mI4+7JgwnIwNkWx1EcbWbT5AHTseDsiF/PBn/5 8vnsil8PHs5hBs4eWjHLO1R8DJx3YnA/u0ymm6gBZ6tCNHD2xcX8wWSo4GyL0xtQ7qLw9qF8IeGA XB3kKZz1izTUKlH/Q2OoYk/BAUho9vYnqDqdSq1lOQD5seB0JJzubGUo9rpAQis4ebb6fN5JOB3Q o6esnl5Hc6WSaFs7W4ItAwfw8ym4Z8XoGET1ageQBacjfovSfAH2UzdKR4toJQSJ9xrOtogmwzDL WQdY3rXwseDsAJzz0c0Bq20rQrPg7AKcXpw/TFWw4QCmFSTybBi5bxTfqjGKcBpBitAvhIvGXZ1R d/oMw3QGBjKZE4P7LA9nzTfKmUZn5WnwUKLdtuAUoWgptBwpAGfbhgNoWQrqK2DFncXy9ZThBOHs WnC2y6GMWEusm5xo79lwHGLRkLoK0ldByZ6w5rBTmAHJctAxSOwsgSja+wRnRxyiPRqxjVTfp+wj OmyO74qD0ec4uZ2G4ys2+5b3tT5AuAwHTm/llTg07oMV8CPhvBMnbNvfhABReqJW4EcFZ994CR4C CeAwDb9Hr+YijfJ7NL2yaBymwQor03BAHS1zuayAHwmnjfOYgFWeo+MomS6IHMnfwcdo7y6vPuug P/MUqKN4Nk6ncNziEXWWJvMwzRvLdA1nWxyQ4Q72vjxZVlID2pI3QR09QmezcaGhC5vN2eVgJBz+ T7tVcL1tDqR7rNRClnb0kXR85UE0RWeOUtqkpmW8q+hE1gY8/aacmgSn2aAbYs5OOfK1oq6SScfc OwbD7nOxvQNkg64A/OPvygd07Hic0M+gnZg3UQALuZGKR2R5yrI8SUPpZ4BJztBvs8SvBkgBSmoJ oid7OAJyFcbADNPpvRk9v06TxdU1AR5EM1ilOJFOOGucM+mEIyhr6LxYV2tT+p/0zuG45Esn39tY LDLUyvCXWYiCP8pmmf5R9iE4BV25Yolrg+P+esv2qWXzcBRNInLyMaph/FkyXkw5eoBON+O2kyom QLnpbIjb62h0jQ0K3h2ezPBQ7O5vsHdn990+e3fgj79vuL+9V7+9/zs5mdTPBIfb7G/JNvtbyjvU gVUo/43lGcNdzjzXmURoCnJxLMKIXPkkkmLEzFSM8OgjGBmdcYB0wB7FHqhZkR+CLEtGGFUYswzC X8kxgXYPQeGjdIAMNbIUcjFgZLNLGT2ZSEMtXk4b/ZAHw98UVYBEgIMXSe1NV/lpxQF6wuIAjuWp PHrebMAibtljCLujuSuI7wnOiL1oqbi+v0wxGBNhPA/xzL/oBXN/0P0BSSlw0zgE4oiuYAoZ8w/A LHiMcdK4C1KHkPM+UBQ1AtQp7y4sI5GLJowFMRq+wI7RYrahSRDDOzxn6QW7jcbQGDbzFxDT/xBr o/vRFAgVhDYKjyQer9NCLu/FKEQcmxHZof1X7QcWFwO1KazEbIiFp00hkWgGJwBy3jAzTQa7mzud 41/+IVI82JADpkgatyhrPGiuyCiBtrX5bnfLwBuH8zAeI8Mnxn89CubBZTQFvSfU0cIr2KVYbl5L kv79HChrKi7TJBiPgixXcyEgGpcSG8AdezAu9HXVSm6a2ZHXG2AyJa7w2Ogt8OiEXbRpqBSn2JM2 KFmg7kfHFIFZzHEbQQMjceV2tChGwQCZGsKSO7sC0QXUuMenMfyLndO4sGlya0EdG2OkCi6BULB3 3hFsBLb/rkUDtepRq9FKcBgtiNp93TVgXWMe4EEINMpkhoHBBHSzNKaTkPFHMIACpsk9UgBCk/jP QfLHyTS5Uny3jXx3rCUNKe0tzYHwSzDiyGYg3mTT4CZ8gxEzYkAggcCPx/BGjkGKWWJQDrZDgw0H xeFKTAMzAyJ6EAEojmGUG3YtBHIYFERXJJT433CAIvfizKj/tXRitmgtMLBaDZ2CgH4UAHXLsSQf LsnwCYeGEUwSA0cqIHTQ5cCC2SzK5T5o2lExdtyxPMU4GvbPRtchHJLEqoZ+WVIyoIyTBID4o+Kh 0T1WMn+XYk/sGte4A9LCaCigLMsBhZLhge1uUbfqpSngrZukqVSfcCKzkAQ4y6xLQDd1kSI2EFM0 stTmDDAoisfVJh5Xm42OKkz3wIAdCwAt1qsOtsHZ5vkRaAitrc3+aWdzq7O11373RmASBa56D1Zt OfKt03se3E+Bw7w4qHZGS7y9Awjowtc4m4FqKTUfWDUfW+ImmeZwjIsAqSJfjEPUWBLQ8eYkJeAE BQaOFNvlRM6cY0A6bnEbQLMLx5gPgkT5jzCFo/KDGojgERggLkBOdBNMQ9aWdvZb73Y53CAb69kw 6cKvp9ezIsPtI4KIpOUC32j1oplq8aaFSMEVUXdSCogDlYtweLE5FH8Gi6YDKkUc3okPOqJOcp95 Z6Z9AVJCif9693c5x/c4R80j1h6OI0WZ+pRT/AzD33LMHhlocclKY6oUoC0AqeIXFsCENSFWmZII M3himFqWF08fnRmg4bISw/NnRUaNhLqWISpNRVKMnB1eqIao32AIQ+3D8WKKLnZkKt4IpeqzAES8 f9TnvcphwfmSQqn0Gx5HjYGyXIc35ED9WOkNKH3YbXSDWSkTSnIxmrfRKZhsqTfJTNLXWE2A84B9 LiDl4G8kAinriAZjc/zqzWt9W1mxoWRFGw8fCtrA/yyCcRqQhXN2jbba4Dqa5OIvIR6X5uwxOQxs xwS2mEzigvLZoiX+156i6jZKZIztFEY70Cx7rAE2H88aTFxkCyKN8G7OeQQEg3ViES8o1y4CBRCR I62+LPqHjn5Y8OEwytCXQf8iKGth64qcbjD/db0wMmIwOYoTmC6T5DNOagw8laPlwwq93DqCg6c1 TpoTY+hMxYwWmPI0kGwoc+wU0lCgnx9JhDiZHaoNimw7SLXkuEOkucj8xjQpF7Jvqcz1Ys+SRLbg 09oN9v7jH5D9VcBMw4s4dkO5hmOyzWXqjfJI4BpgxLF2phbybQgKyq23nqJna3Br3WO2oCrUOsY3 G4hrKFTWi1mX0vDICsgjdwBb2hEnFBEYjRVbE4ahTXZSwYng7rDc+ka7XLbD3L/BLrd4T/CEKAs+ ujsE/5OpZmNWUVMgUE60/Fm2ToQQtkfGdlGhBxLUDtYWLoFJi1EBtUUEhz71KnimNmrNC3hqh1Pj 6RRmggqzmcWaEwf9IuAezdFHLYg09TUvXqpHpKheppK+wgAORt6vTO2DTAvT6WqLmDiVJPGmQLFJ gEDiT9HJkkwUpW3ohJyilAJTF9UH0qstztsgMGE+QnmY3GZiBEKCEqAWeYI4GNGQLKilmjkOiaSD 0QhsAFbRCApJCpAZt2guYjpydLVgN/w65+8C7xjXAiUfXoOdh4m20Z0kWgJU6MspbTJRWqLDZMvN 1LxJU8CBQa+W1hRndakFyclbQkeZUgUnCogpTDAe5eRcKpnOWorCkKGuqxlpFkQm9MhY7jp/bzRQ uVEc4t1kBs3ZApRyhaUvbCLIJgnCdQ9k8tBjo1P6FECuhyTO/PYs2WSXVmFm6oh4wLx8L0rJrJQL Xje2rU7GtCTd8vn9mmRnaTKJpuHSqXEWt+GOgiyeM5BMH0S+2V0Yd0CauARWMnSUaV/kLImjPEmN RUdgfpfzcDgSuVbvlK3uW7QyyqIMKamrHGr3Qg3OpGePLtWwUGvV19EVyJRc2o0mqRXOKIoBKu+G 5GhMtc4WczRlNUF3NEFrwVmYYnd2HIyaIQVRLScAoohg6INZuncp1XskI3gohUA63uVhTLOVlqCM ybacafBdipKZzAIYBf4/M/oqYIIlCst/FTLBKaDTDw96x6SkZGqYEif0om4CW4m/5vqoR38MTA9J fsPKlSnMTAUgzJyyaBaBHi4FjRpcaR7EP2xBwpxR3/KWzUS9lCM002XcQRJmuEBV7SaAOWAfWgNA ANYTdQuWiyUg7oLljGiT1HqLc5FTkMOzRNK6lr1YpcXgEJoity2K1Eerg5U8s6jysCi1cnl/hPiP zl7CskeSLqZhZVUk5iu9wdVVGl7hwVPcWUZHmkynm3C8g5gi/APhhTcmcJmMQFTa7vRFDOwwJRcr aOibfsJ5BblVsuR1Mh3beg4T8GWyyAWmGcApF7XCFnn4YVC823IVoQ8Tb7fIZPA53m9IFhkcmaDu gI60zuEvm2nkGlTERu67PIuJzOS+FtFcSdIGzxTKlBJBbptR2lJMMeOFumQvac4f1JjJJeOiywJ1 I/amsrmpBrZsvsLBAkeACax44bfKxSPdJt1Z9SQm6MuX6wdCMBiwaYC7c5QZ1T55CUCsaYZaryN0 qQFc5HDi/KMKKXozSI/KSFUkOOQPZe8Rnal0mud5gO5nsyFI9JZ6Mr++zzQEhTh/Zqg9ydl1madW mZk/nRKFCijcuoUVIJbnwBfYDVfGDEmrA7AjufclU72YP+ZEPQ3rC6aJchTP9eWpmLbtqJIfRnBc cfidVU0LRqIuMoKZaVFmESbHxff3tv+OHp8bVLv5ZiCHmFIFkTMm1O0VyeQ05iRBVpDSUE5LWfaU zjDj2Gokr8ml4bhmOjriDtDBoOFYNElc8i/TiNI8IJ4x7oqcDDaae0thFQ2AYmKqxOEB+kQR4oiM c5VZFt7BvrPEoLMIxEZZQuIGtiA4qpWfoLdhoOgfp8kVhQGVUajscns8bRe25GajjgWnyOgzk6ze L0E3di5tJLPeOYY/ownb2jZBgOQD5a/q0BoWtjK8CygTBczCBUw+yOk4VUezpSmSBE1izyCivbq1 RL4/Ys3nn+L/+bd/w8Wo62iEEdPrT5veR2xulnxb+PzJAPhn6bAS/ZWffxZmUDJc5QzkD38qLLxk EuXzEmpoBZ//90/0y5/sr+R3pT8QhH9aBN2Ww/3TOCTbhSlYP3TwXxKC/fmn9d/F70p/KKzCnvGf 7C//ZK/C+aGadOyxCuMWfijtT2PwfxX+rvqhFMg/MZVls01/8d8d/rbih3Igawdvh4fHB+vYdm2w 2ZV/V/1QvZxNa9ab9nL8H/gYgo4H+oZvhvkM0g4AyS3lwQbJX8kmRghAA2JQEEBSe82TuTIXHKFQ IhBM+oUlSeURUzqEAg9T1bL1U1G24gkkF9WPS9YASiDY+Op6Kdjq4Z0yAEZ4YZMua2ZSImpHbDTp U0v+RJPh/Twswb+w83mNtMNdJ5WEXJegW9KK1tqdd+tWV7oKqFObVd/tQl/Dw9B73/SmvmUnlgKz UwCjkAdA3ntT8I80BWT3MYDslQKRu7fW2dpd94HoTDEG8e7LQex/OYj3XwLCEAeev6RvZfOEM7jk sS+ARunu/S3RZY53wS/Dn51D9J+iz81/QS9Tymnx/1QwPmGCgfyu4gjaKvuyY76r6GZaWF9um+9W 6bZjvlul2675rqKbAWx9uWe+W6XbO/NdRTczH+vLffPdKt3em+8quhlcl25mVTez+pW6mdWv1M2s fqVuZvVV3agjsk4WzELruJjRJTQ8y6hOyWWor8Rj5uv8OsGAdor/GHFY4TzMF6lKiMwo/WWOQRBq UfxVrNmhJzgkbsMp6PLsOquPrq1LJo6TnKMt6jTcEJdgLuoQmW0IE0Btg5uwlvQNo6SgsF9hpsqy 4N5+QAAxgzUf6CikhC/GGKrzyYIjNnb5Cm0l2INcOGDXsnUyE+Ff46kJ8liWMcEAMw+O/GwB9g4g 7+zsjHLmCWP4kzbe0Ch2bwPaJjAnRQCuQDYiQiVCdCL/SN0gZO0ioszJADWJOOEVwsymEaOILFI2 lvUE0LdpXSO0qM2+XIjO/zmHA+UNNgwTgK30lswlbZ2xHUYbTXAiOWsVU8ZwVxRPphh4NsjDPIbo Uk9ph6bk3EgsTMy9rVg/PZ5JyRQfNr3dlr48V+asGOsUeIrJknYYTfQ1I+12lskJ1JSgmAzvyCpB or0GLc7qIHctOhEoXJBMFzOssTSLcuX4Nbn49nWryxBUPGsJbbMIibGSK4kFnC9pqygzM/7Riczy su5WUKUurQlHE84t42+TibNqxUgtiWEk7lgA586lGLGDOSYUQuCxCBW5pxi1HMzVPvFNUnL/Bf6X YsIpszomLBbHYgeXllglw+nB5LTKRjpd5GooAmMPZ+9Ioz0RJZcQfRmstg54mNqaj6riQj//W+Ej vG9qP3IA21jAT0/6eHiSZWtgLxnmdpE/p3Aums/lPe1AMfTmWyNInP2DkwM2bAQltJcbEAbGYB4C l5mPFPW4oxn9pLyKvq+2VTHbIXE0goHuPJVIuiuDW3EJVKLvFlyCuH6bVcBRIxtXuaZHmh4lh4lU HTP+Z4bJlyDxQ+vejYlB4th8NYQA8WokVlCptjHzpFipWk14FTC+mmGmAgziqyFmKiBofElknV3f Z+paI360SiLC2TzHpPnUyreMJgdj4FBZfA8/iJkAv8PicgHdRVUZJ946NZBTmJ8Fg80pmeKAtzQD eQQuh3ScLwrLI+3SyqGcBukVhvEnmIYmQ4jsNKnCD80hdgbcKB5qySgPKXOlFATOQdJIPJouxtLd Pw3jq1xlK5HPAHMDTao+SqBTAqwAnRfkKzX5pasaWb0u8JLK2ec8q+ulG1kdKcFZd67oWGhkdf6g rsfUdS40sjofRtmIciRLpqwb0e2HCmyYxccUdqUrl+40FLkt8gJicYPyBBNiDdvwlupU6Vy6rq7l jQFcTRGMx75qr3Fn56QOZK694X8oWiVby6sntTRTAcalJJhqgSiGBRFxEdN+6lkuWbQF6fEXXZiz Q2pmCkVC9T4V41iC3yxegypbfgUgTx5Us/5ypFQv32EWoZdfZLVVVmvusD271RZEQClLLvJLUD/H GiqJ74q53GLCzZhBhuOWOEuyLELFDY73DA0HMCd/ruh7uUCzBov/pXiFqDDLggwqslFhWtIRjVZY 5dli89l4QWZsSOCt4xiMHljEIllgWkWoNnUSTLOwoGN3HqBjvyrT316ZfgGatJI8T6JGl+LDaMvP DCev2nLxo3NwTfDxG+vMNbqdnqyr4xRhVOo49km2XMmxjsNlil0NBH+5RWW/XrGrWbEN5vFXbE+4 qLtZU/C1Pf/TUIVTC60SF55GU7/QCjBKpalYaImWVmoElcIuXegHT3t7zIVWwLB0t4qFFo23Mo7T hKe1TvT2YhClYtBLzGAw6luNlJiXKXbVKpxrRRYZJoqLGiZNE3NVA7wcXjEL1tkoixeTt/jm5oxF 4GVIZfW5rgq7+0thYCIxxX45UaJSLpaqsbQvR90Bz6TaGC6ulYR6pkuyLLipXDoWvajR82WyHg3c CI46uhzLu9RLoBtVmq9V3XyfRmMjsp4NPf9BM9NsRaAFPqpqVCDf0ka+zSCrAqEwcWIvxoRwDQg/ +UNhlXR3GRWhs1xp7PJYxi2vyjCZLTL56ABfV3OTJliPZ2GJ5LqsjuJTBWdMwMRab1lshsMlBGRJ yKQ6OmNFgnhN/ojFWNCSOBABKQ/OdLzgTBmWi2Zj+YVN/DyzGI2/lKcyKvXIRPWNbEr1Qoq6uCcr y+HurqEXQVZHqTo/dOt1izVlnLeB48aMb40bZTrhPTR3zUdVj/XQUxdpWcJCYN1iDfkiG44GlkYF ILNhZjqNLNFXLFqfUiyiUZCrC5uRvvsYpFVQ1tpv22Jrawv/f138C6aqIe6/lRFcOkcSnmk4weKe fAaRAmrAoKgktCtkVgCiywqezjxIYNoofLGIJQpmDagCzDUV31IXcXDXYplFUQSNDStAmD4tcRDf 85MXg97Q1+mNjC+BEmCiUEAdsSaMiwaz3mU0VIV6/Dyma6J0AHt/s0Yb/JL2F9EnEfjoHpmSWI6Z XtElUwFBOmoau2SqUMaei4JfznoVTO0fo0DeCvI/NQRcoCKJThMcFcr4tu2PoSaktWwxW693EQWV TIYTctPpVmKt5+1YspBnW2EGeY0cTks21D/uvgH+7OU/lpvKRZHnrKoA4ZDeMyAyLniyzNFlYWpF P5eLKc/b9WIw9Sg+MnXhv7GXrMH6KwVYs0P4Ubxt7rq/f5+bu+Jaj1nVZNGPtornrQ7OU/nj/G4/ kjNOvwaysofl1YPyEA9KMQq98KZeJ9ecKHRUksxZeWyIykTOJh6Lbzbr2hRUyyR5jXEXP8/NovKM HfV7qVR+TRd9TRf1Pso2rzzgccnfTb5oBdTSiPuLzw5dZbGvyaHfZXLodpX+aXylBNCJ66oQSlIX 1bVvyhMQDPAuDe5SS8RP/QN3301w90AGJbB4u1JVZtElAaLyp7CODVXQsXvMoR6kDl3oGd8JkTdk VR0ipSoyFHXF2N72ytBuV2H4pQd2FY0+sVEi8SeI7L/ENnmca2YVvX3LxAynzouV7ZKvPeMSq8Se tZJ8rzZJ4eMmdlYZJM8169b/vJTgCLWpV49fs2758xWybpuFJF5zb19zb19zb7+yr/+Hz72VD107 Orc6MWU9OII1dCyfQpuC1SMqLR4C1NDqKVg86lsCYKpAx6bOtq4XLhUZNcWp9XCa/fiXnEhJWMNS sr+twWDOCpQSoCA+kcFQKBO41FBw0rjLdVzcCZ14pIpR1+ia30z1rXM48l40D5QUMeOqz7JRe3dr azWVlE7gB94G2xA5aukqp5NfNFXvGZmTxBwHX1FjXHUuz1EZrF1DHRk9e73vcVb2quh9Y0XPUteN wrdRASKK+d2cCuvxK6mG7NEs0m/BqLIJsQJKqfB4mIZZRqQsbTcMsdIO0qCaW4tw3KmQ0lMXgy1M qHkYa+mcLFBfNqenCFMtEVJmhU3XUknoxZQBs8qniE99m1UKucLXoFSjoFT97cM//gFNpsNwAhop lXTErzAUstnvDY/wkcZNrAp52Dvqn/SH/dOTgfj5538TH3of+yc8aP/47PRcVsOkz/Hp4cWn3mb/ sHcy7A//Zsno0w9/7nWHm8O/nfXo281N0NVpydGMgivy86E/HFjdLmKsNx6OtzvWl7iWqzAtfCff Jyn7bm/H+m4YzcJhNPqc2fDmUtu3vvOedSt8js5Pj+leyE1nc3Dct8D3/mN4cfBps3t68hvi4PTE ggk2iT/QeXLL+r09yXSRX/+GNo0zc9pFON+crwHAbF4/y6FlEMi9+Hh+enG2IcmHPnL7uqfHZ5/A rur26mHCIo9MC2kJbhhSo3+fpv8JJkQFoP7RJj3Qor7sx2GuyrDCAbdR+ksVrJPecPPg8PC8Nxg4 UMFEZOOxqqtugB3/FVHCT+AcR5cuTRsQnw4Gw82Ls8ODYe8Q//2ms7W1Df+B/9na+s83SOLHQQrs 3dkQ+JO1AecfD076/3mA9EE9keFE/6x7eCL+mqSfUakij8Ibi5hPT4YHsGv9k6PT4jLeqD8OgxtQ fM6DSb5wkQQiDQTkzxhnDO5B4nYL7w/LRj526LO9s4X90ntxlNyJQ3xjdkMMFlEewrI6FZ1O8zy4 DcQp6JZpVLL99OkGcTAO3KleJzEofeJPbbHX3ha77zuivbXbwTf0Wp2OO15vcxZEU9QRYe2tlNb+ 7zmvsjWCQ8h8bEqnTxXWnWbSDyTw0FmQQPhZRPPROP73KMwnrSS9cjoM1APEP4vrPJ///Pbt7e1t SzV+ixOeBfHbKT6WFE+StwTMgXEAhAOI/llMCAD8twGAf9CyNwNuVQqhm2yOroMoxed54ZDBJ+b/ ikfi/YY45z/+nY51DA22gjxHbFXsE3z+HAbx5hEIxVEC2hVoPUAD/zNpzeCPf6dS0NPgMkMQFske 9gbd8/4ZUrlDsbbCjGcMPVwWcvksjsV3WlvCvJ5sXpE2H/Pa8Nr5kfUSmJfSW/KYL33qa46rF31b 1oLOe7/1B8izDqs3WTLYT3CkdsUYaVTc7P3sstsx1Q0P6darzcmCXoAbo3uQHoKios8b4jKJpmE6 n/qVlaA9eyxFtrjCaCbDZELHZ4HoWd6WOMAS7+ohLBc5hVLP6JFMMIOC3yncQO9XOObAKT2InuJT kDhTB0oW4r1BVPLk85Q4t+iOdhanL26DNAa+8wxCB1u7K2ELZqfzExbm+TcXhHphT6/KDbWLkB49 lb1VcweKwYkYzXIrXk+OvmmSq0wVfi5Nt3PxbUp3Xd7nodtpbwczCtSbp/zq4x3JD1f4bHeoJZ9f g+jqV3YAm2miUgycAhTCmxqO8WHTKHAdIsH4fxZZTr7iJbuz4yrHdZuD28+T02/L/ZWqjeE7jS4p AydrKTBidymXN6dtHsFPs4Q4Y6+1c3z9D71xgXsJY7fV7ohjLiL2NgtHkvp5jahSG3JH3HqbU5iv 9MciX2by9ZFRLlKlyLnsSKIlmSZX90vwuL0KHpHI4/AWwN9x2f4kJv+Mp67y0i7xdDO0ad57ZMfx EmlgcX9BMmzgdsL8yBQRXtq1JkLz9HCPX1Tlbmo+TKJmo93R9bYvQWBnVQSOzIvEuaIGlw2AX4Dt osm9Lx/wOdlZmJNVi9eSWbA6AIqElt2DRnRHUDWyXWG7RIguQUK7DgkHN9GN+JjAIUJT8HBisZQD RT6AgOfywfgmoNcMzq7vDQojepHKhM29wyAC3SEFWw+B6zfh9dMCRCq9u1w+jFDoaa8AdRmpyCgO 7J/d7G1O0iiMx7Jui/noOI2Sf84qe4s0YZVjo0RFgMaKvXGSg7+BDv4fKCBuUKtdaLDlSkL7/fv3 W/vt982VhD5a4sDMv7Gc3xDzxSWoifh2JmAUN7mz926rDj3H0WeYZ/7n5DrW4naeJsBfoNHINw65 qbtUWN8EtEV08WQmkMRvS8IB0QKdfsIpTehpSXLbOqMPb+E5P7d7HmacG2reEu3HWZgijSsrlhwv DpDkMkum5CjFzmkICo58NyPJ0X+sCEfXisQXbBwYk0U84rAYMDY/yzFL0sKLKnIr7X1D38b/W7D7 RbvzTvyvA5w9J2DbDaXg7WrBSw6UIfx9Pf4w+40A+v4Aiwz6g7NPB3/b/KV/MhRvxpttazKD4cHw YiD/IeN9TQiIFGtyPFPWsI60ZmJuYsjS8c+prqAoTj2uCe/m/GIpnsC4GFW8BPvgWyK4SK7+QD// q7sD+DKnejcOzl5qxOm5l9asmKx32/Y2SB7jj/b0WJj9jvBai9UGOP1SjLJMl8JmGV4LqBM+9izk 0b9BmI3RwSAz/qRdJzVY6Qq1plmYJXxg83ofe+fi/y2gYUwzbm+Jtfb6RtkvbbHWKf2lA3221/UP /2vW/2vyRCj4nVUgMqfkS95EN18JC2VrVakilEnxJBvupr4LHHrlFavo19qWs+B8PAt8NAT8tUsJ 2Yi+3i6BcRCPD7jTzlLESf3/8dBXmM0KaBQDqbwXRQWGGrLrAG8v6DR9hon5RNgv4leqKFK6AXa8 p3NTDE01pTfg8B5E4VEr+V6yOPvlb/QK2rfe0+KuWR7cU6kySL+3YE/uUR8mxGe+8fW2sTP/80OQ harn0o6qodW/O9PjNu/fsfvn2crjb/PiNzdJQ/lwMOgJ8vLzV/oHJBDzaDU/444OOetFbBCG9Dwe kqDtKENfGsFQGXD1XjTlROMQuRqJAAA1j/nqj0pz6x631EQVFky2m6R7NhWtaJIhBpvqBr1fL3on 3Z44PSLLpQRSj59bU72PD/5j86Db7Q2AZYE3NsFICDkMaI1gsfSqygOvXRrjkreDPId/LJDVKXet kNlnPvpa1tpE+zzRa5s5zsmj3nnPC9q8OQStZfMUzt1N3qqBPHp0mEYMFF+TEvvzEm9rRT8xOMOQ 4Q0YiJv9087mVmdrr/3OtRF4+/Y22x0iIP3PbV8T99mwzdRdQRmc1bmUMr45NRzE9DTtvZUCKjAU QHqfIQhkigBF85WXVWM92lBxKUiPEcl0CKY+chky6BCzNFUqrMwxcYDIfMuk5skGa9P6J4e9/4Bt Uwmhlt1k72cFQ7fNWVu5tQhG83XxKLGAyy59O8uT5lcSNC7taSh91Z7sx7Q+jXseG3+c7Mkn5rJ+ xIvTEC99rtTvjIwW66Ot1mU9D+C/7GxfNaLp5vCo2Y+lrKnRBSpBq9XZ3TVneoEh8eTY1DV6GcxD JXPDA0y7TkYldzSVs8R/foM4S/HgPEjzCKuRpiX5udZdlT5D09/g0Yyg+QV26YXlq36er/kaX6QF WaJShCkxWoMsmWD/UHi5N1Ix2+BpFwcEmaSTrbeqhHYFA3vy2+e4FWmkvaU+FqlcnPSHSu9+cx2m +T+saXp0dJtG+WMc8aEYhRSx8YnBnNpBliWjiMJISBne7kXmziVrTBL59sVmBK62N1/EXmkxPRpt e8D3qPVZ0z+Sd6kLu+uAsIfb2gB6mKILldrz47wUY8XE0TRR19TdWUSYlW4h4fzInpl8eDa0MOIA sMI+Egl8IjqRGk72VJCj0OeIIBez4B69JLjVeRgL9Wgxw32ZOlQmdjbbG6g67azIhZ0KLpSn16oc uPds+M88XJTI+xQl7yGBoPdCPM5DzuSOC+/mHHSx7v8Hllj3r1LDoHvi+Jd/iLUTaHwtDmZhCvtK mQdvgXT3+UcMOMzDdcMCDhhLRDRkAR8GM0Vhsl7d6ZdrOqxK8NsVBG8pXcuJvtSDoU5Kz1fBwQrP VyF+D2Z7O57/Cb/u7O7Znidbff6KLGPFgcnZ45xPLhe5IlrxVJ3GYg6xMEKkODCUWkGnmimxzjoG 614bnlrjkzs3hqbSlaB1FLNDzTiOL/s5LEcIxx/HkZQQXqRwGs0iKT9a+nDT+ToERbnPMk55dqdh 7QWc1pMIZTxKJhnYI9Iho5mp5cfh350qk8IYP0/Fv3kwz/b78Sil46K957Mytmjv6Sb7wNQlLbY7 usXO2m5Zi70d3aKztlc6Sseaydq78iaRbvFubf/JxctRkt5i3iElwosuR9KRYNaOel2ZsocbSLkp macC6hOr5Bx3mlKyNJ/cY0xo5zgY+zgzNyGiZBd/Fny1RM5vt/X+7U6rjZMauXRc8cHkMOSRVqfz ttXeFTPoWjKuQxvOuO3O2/1W50HD7uy/bW1vVw3rEJwzbGfnbXvvQaO+h1H39qtGdYjYGXXn3VuY 8ANG7bxtt3YqEeywxc+FMd/vvt170Ep33nZalet0+aw4Znv/bXvnIWNutXa23261QNMuGbfi403H dexX1sZ0PvZRSLqAyZRpBgDk9QLHFD8djIM5Dn3c/7A5NtdNxGYzQFQDTGVLyROn+had8zk+633c VKmbUZahlNhs3t0sWlCWM0W6ZiLjFOGf/DSaik/eTWafgku+/ZRd030fin2AWVoi+So+rP5bc8JL jt4NKfNZRS+r8Sg11stsTcyBU6OXOS2HdjN1DnPZAFndKrKWRee/AwHacmQRM38wzqmOhIi9J8Fl AjoD+tzdsX2vRK1K6PQuKohNVEL8Bo5CHw7hm0ldhYz0c0hZmNM1XGXlvnR7rjL2U6EP7lbog+zU XqoKale3+bngscCfvr7D4sAUOZR+XauYg7rsx8lFuoph99jFIVOUunxuMpFcuv6GgmCJHNhqNWM6 B0yVVbaE6UqgAPqoIspYpxzKwo92YtfLZa7dFZlrr4K5OO7zVHYWDnl34FtX9P0H36ai77truw0t nEeLHWkyttkoKuTvFEjZTe0mpix4H9HfyDdi8d5TGl6xRGDlI4Mvx3jv2eVvxpf4WfA2HXBedX94 sfnn/W2VwlPa6YPu9KF5p67u1C3v5CaPH/BQKpfIuufl+F6b8JnSK6vUymb6YpliiPOq1/gcIDft 1lZ7Q2t3G+I4uMe7nlsbwP7Stmp1VuPAd4UcHqSyVVJ1jk1iDohmyqdBM1ydH6x0BnkejK5NeliG qdFhkCoFiYZpCdWRgGBnK5WA9DGVwCOz/nX2Dq/Pqdn64MwdB07vueXtaGwW6gKbj0JykxSXQnCm bOFNE1y+GdI+1aey+PVskcocjOESIr5rglRMt9aWJbQ4IMryW8oyWhw8OVBUmeHCl8gVcobtFojA 47c0Sb5QY8+8OG9P9Jeton7aDghvEUZl4LdbVk/PKeXZQnJOKVEuT83Rl+e8xBz+mFQZUdvdy85x u9f29jJ0VuptAkZn7KDnVqU1Kkq6D6ZJPsArs8VP0+7DuyHotvHV6WQCFuDK3eW9nA/B6HMymQzy gGtuNFx6sXcvlpvYsPfwzh32Qb31sKv0HmB+8MEIy+11E8yA4E/jTcPu1PEsTHEHVx/8CC8JFjZ+ pcF/SeZzQP3AlOZrTDFOuUT5YRllJ7TXg+lOkzg8Sgu1FIQoLfNRD+iCb7G7n9JqJyXd7TKI1qes gEpJ77M07P3ei0mgWR8zuOldOIKN2Hqu+WuUkVNIT1M5SN5ZW6GBlMr0dikejPx9+lQterDha+Rq FdOqS6PgRRhlr4UVErZUWHtLOSv1EA6giN+HZP8kKADSUm6JY7Bn8IXeOaYkUtmnCvXSTB5g7W6g 8YFvhv/yD1IodKZYOLqWl9DJzekAWcHpaXlcHCCu/+VlOk12Njsr8UmnlE9Y01iRR/Z2ng+H+NlU S2jeQabHAcb5yGCrKN+B4/NBCaCOIXq5zKlXbGFF3/73TuZ4B2MlOt8uXqyq0YqXUr1RYL4+LZur EHREYu1mWRKP1wHTZ4soKkvK4TZ4F8ssk/FHiaW2WyDKqpIThtZvSK2TRUqO9ihGh17OtIjfhFT4 mstI+JVdkgmTPt6cX2TBFZIoKrRcQzBPrkKCOlng9Tw1s5I1qZmYhKP6s6sxShjP4yTk24Vk1grP uK/uD1OgR2RarwdUHefub7bfr8S5O6UnlDZHnxe7zufTiB2vwKbDw+MD2rUD+ktRLuYqZuR6LAse myqbe6CEi1k0SpMsRKIQOVZ+RE4nP0uFQoWFmzaxclNLFkPNqAq6Osf020r69NpQZ5fLsORQHQUZ uZwC2OSutYqniz2/NDJXrvP9VrvVaVWmC5bS+m4prTu+k8eh+Eex4ExoFwT/LAyyRaofo1K6e0qV bPM0mtNDdi6VXXL5blNLJ2VnDYCh1a5FsqqM8/2fHEDOz1b9L88F6kWvZ8EdaWk4c8K0hAKrmiXw L3zDzz9K8ME9VTLjLVXhlWUsZIasYhWs407lGeH8c2kOi/ksoAeOsCbUUv+E+mKUjKORWC/OyOMb lZQop0LToDlof6zcDphtSxWDnN6XhOKBz+UOEtYoG3GeZFFOFTMxGUWKELuVuxwsHoKPgVAfI2/c GGMmHzi8kPE0dzZqyRgR0oq7XdyGqgOFMdFbdh+PrtMkhtPAzUQK0jSCGWT2q4wuNThFTNIZhUXW XOmbvd3beXk3lpUwgtW02vsryaK9UllU5ohd+dJNnWfpEY1AS3KMsdw/zxnsLvjnrSq/dXsdYnVE WLGvs8rFwkEKe5Hh09s9XQKHSqZxlgWQS6clrHdc2nsuHVqPgtoBdhQegss6hYBKUJ8xKoxvq9CM HCizECVKlM2o+Giisu+W5aB4Erf2ZsCLVjHN2bu94sn7rgG1owf/udI631h8pXT780rpZZS+X6Fj /hgivaBEvFL5d0vl7+up/DsW5a8ULj/fOYW3t8odY17GwDI6N+4CoHPxT7G3A8Te2S+n9mXE/jBn GW5twb1U4yQ70Q6ygFbJfmTH2+XblCdJvFkyRAt+yKU/fAqW69RNxbrhu3nknpCYEccXgyHScgww gRFm4YslO7IL0U/VXo32ysPrfrpJcxlLpNdptbY7TyBmH0h6Rf+s7EVMhk9FGc+r021FPyx7Xh0Y 2g/LXmVoUnAq/3AEWB63djKWVvCU0hH/nGmP29Ha+OmKCF/VQ9dVgoWtcYbSx0gxNq+sJgfJmOxS R1SiIJMDyCjoyz1IiaBWiw23t6uJyc5fW+kgRWp6t/fuuZ6i7V16aCPDdelbDSjLxDWvGH6ibdE2 l3xJpFa4SVoqPWhfNEHtrCqfyqOWlNPYKAe+mOL49aUSPaQnLwiokQsb6O77R1C9CmEOarUhC92r 76w8+lEQ+w8Ejq7D0WdJfSybqPoP1pmWFgjGjFDEcXieVht5JezQCuBXhl42ma1GY+XRQpPw2kj5 oomXvnX3tUgNR6ULi7jp2poNRB7izbGArhtI1d7EfoJLr5BoCvYwpqbQrMb6RvJ8kc4TVpbAmIzm lKQB8oxkkgPCegIFu+Nr9jwwwG4Vn6Csf+XEPTo42TfQL0i4WcS+fTIGczqaZjpUBjb2KBwvUic1 c8TvHWcl8Uh1OcIKuYXCRSQi7fYa8bMEHxgQY4tdvf7ihVGn+XWyuLouhPZuA7Mj+IBHMMLXVXDJ teNZ8doNEXHNuwCfnpEeAyUNQOaMk/QnN+6Iz5+CUhPxXTnrCCoboDTBSU5/tsg0ju1ikfp0Y3w6 EGzsVl6UKufh8iibpJLlt8FL8r+/FtteyDrq6vktEs7oa5pIa1w9EuRg3t0rHeg3/F6gTslvJYTr 0rt0S+nSApWCUNYYQPvNgaEXEGVSz+FstpQIG5NeTo7PxKA3xBUOzy96qvyiA8cawXShQpQT4Gp5 F0p87J38d+/8/PRcrGXxbH7TLrlf3j09Pu4P//vooP+pd1ho3Rm9vdleVwakQrd7nDhkf2NKC8X0 mttsDuIQTz2aE2cI4JH9vXL3gdzDj7yH9mqC6W1wn2lr6Ojg06C3Gve+q8gqlfJ/Kf+e+6+ufT3P ciH/4kplgpDFSMex8c+qs9RBpVK+2A9Rd1wjH5fDsE5n3jO6GHwdOoaLdRBR8pkDpWS8EnuXqkvo 8gj6QIXluzW12uuiS2imC4uxUQJKRcEi873uQqInPIjHfw2ifG13ndJb+AZk4WBe5Fk0LktthY9d R4OeFFTnON/gdom7sw76Y14v/CZROB0rqSqn4g9cpjQ4uoK9KbLOhA+nmhFBdB3Qj9Z2e3KKUEsN 4tCV9/ApoTnceqfhzrqQB6izGDgndPmZsqx/UXXpC5M5QfhLVawo2yNXFxSiIKB95FUIYx9MtXTe XReHIb405pykK5LsYe9Tb9hreaWXkHfMvf00BDaLZJpZMJ9P750ixCXs1ESp4p1Zg9a+OiyEtXFe xQig+2EpKWQ8GMgxdUw1ZVafWhEJVCAABBbdLpevTZKQupLeWET4ikOJtYj2vx9Lw3Ots74uA2Rj RHVyv7bnTUjQrmTOZsv1xiFYs7DqEb50ydgoYYoDtQDSeiI+UFFESPzhTpg5CJiE8BQdQVfuzX2W lsCjMArlm3bl56CfuAgfespQEQCyxDS5ivh1nmkUf+YDKRDz6/sMv/YBRMp63aApKbxE03tbRxmh ILS4rxyvlg2Pjwb+1/lRt7O/t/134O6D8SyK1UK49pnnxoCPemYoDz6T0NdOFIkKIJcJrKukztmL 1bRWUpX2K1Ql+2brs7J3ClnCandDnijgBlBFf+L7paH90rLnnEIoWlNRCo795h2ZL5GuTUL3avB6 mksnJtnaSaZNVUK34BpQE3xytcxFIPkfJJc37SArzEnWUjk/+bh5Pjhbbavfq63+4x8qq8DUlSSh Y2805Yc8CYJ8cK7FvBpKiVOspoEiRJfKMvnk1J9nK8WtFFgM7F5e9KHkiCxEOs9DvROw0WNyAck3 n8aLUUj/E4+xwFHEGQuEP3wS0R6Fbru0rEo4ZoOLBXCAI+sL4Az5hxhd9bTJMzhH6SxViFCuL8IZ 41BiTM5bYwVIDUNGlTNV7PlrkslI0IML3xgQvScr33JYRVUTlQ2vyEqTVAVlfwhMWZtCeMhZVtOK Ns8OG7qkjYcR74DqT4oEm9lyVkkK6yEap/vQe5Zmo2BKlrOzp3mM+MGOqfH3KEXSPcQI4XhFzyD9 DOcgU6Karg95bUPPDsWLOpAvA7/oKYmAgjg474Hs7P1KZU5nsKfBVYiQZb1DlE8OCAuFmVirf9nH 6VosRMaV5GmW7rzCO1D+6GmIkgkgUodHwzMwQ1kHwPuwhYk447jKVN+jhcLUM7n75ryS2HXAsCif JYinaAJsAbohaNxpUZJVbrsj19xjtLwYE+vRSc4P0vLYt9eIgCj3ibEoUu36Tmoa9iQkDh0YhJ91 0iVKp15JAg4cJoj1xiuVSqxcKxsz9AMt1yUsqWAsW+4yrPcnRebWvBQs8gRpkzR/ujOUhnaNYQcO xiOU5OJJaNHeVYJsoLSF48U0j+bemhRLF17h9rqXWOweEWjvkn2MqGJVhfOitm6Ve9oWSla5B87y alWFIZ2PzrcqrTcje56lUZJiDHblnsfB3cX8gy6+sELPj4sg9bo2HROLERa7Nu05vPuwwGfjzcf0 FAKUp0NUiinMUAMItQU07s7wupmq7rWkMpDsWloXqL4qkDV7WWrXrEHP3nT0lRemjFXyn9uY/7y9 v12RH/XopQtRrTAuU8rOXMTR74vQvN1Lh7KURK7Q4mOolLmqFD6XzdoleDN8sWLueEUa0OPaq4Lq gaIjZ67mCRKNMpK0v07qeBRyd5AG8jcZcahcV09pif+knEWdAA42XAiUpgZwQWB5+BDzQkyP6+jq 2u7iqwwgYYHFcq0P6tnDfMchTnczk3kVbmdKxD05HZqDTB3atFqZISAdYi8tM+RgPoezJboT3VYb /lPIDj/sHf128AmId2v5mcL03CmhZ0daP7Qm1hPdi1C3tLUvRZPpBnL8JRq2mIfL93VdbCJ538rQ VmD4QL8Tpb4hc8ils/80mbsUP0KV1PKKI9X6s/rhifVLyLXM5nZVhGdMr6ru0xVMOYBZhONvQbav 4rExve2Ui8eiYvlCBKT14NSzEpFl83oVkl9AtLvlRKtsmsct+VlHqOMSI6kZrZrrNPr6jLxmKJ+9 TflGeunzan5Zbvvyo0taB0463ywMOI9S0ytdJPwiinT62lHw6yADEGFsIUuGa+bTQHpWnO615t4G xQWBmAJAXTYL8lHJm64Ue+ICJ7F69oTzSoitgUHnODeZHXJY9kDWsdwpL6CpZiOY2rr2uz8OjAFn Xbw4hn2Uo2WvhEs9h8GzCn32tfUGdiIyiFDzFWrCQNccC1XJYp6L9KtoJhr7k2CahU134F3JDjzX FD0jMKJMXvfmPAaOtqC3mBN/KPujpjB/qyh+yjBuJX84YNRehGorih5giifF98YNXPo67rjUFZ7I GIF577aim+sN1x2Hg0Ihprqd3684IQt+s1Xr3O7ubj/4pHygSmeOyct7fRHfPSHlmejyYd0RWXso OoDsM5JuTf9s3ynUhTOjeDRdjJk+HAgql0dMg3tcDUj5a0DYq9kiP6ufLYUyF4PoKg6mv2JSR37/ 4Lh9AUrvyYLVVnZLMTfk7Je/iYzmJH7nSRVtCQe/MsEmaxXL/DWA6QByU3ZciHbsMMA0EiJ7dzYJ 0EosI8JANXQzt0HKwU7lvvZWyTp4jnsJ6KQIdBplOT0nPhGBdwJ4LyY3200HjkUvQey/J+By5tJX esret3GFpP9Ij3kpaw3LahAkO9TvzuMosV7oaVcG0znsa73S44B5tHd55HM81bOk94K+9SyVVcKP HpWEY5e8HVQiPAth2BImXB6JhU6/9vk8zLpGFCwLDWK3izjEd8fDsRUb7GKt0MqgJvaSr5Sv2Osi loVEcdlZ016MkZMkysybJPJ50so+x1hQUyYo4lGLv9aHarFXz0pUxMMcfz3tDntDEFDn/ZOP1R3v cg+PcmF7O3W9PDw26uXhUfcynYpyvYw6HscUfJT6vnm6oPTsSGZvyHJQPOXSw63MIsESPYQHJ8cL hDrfwCJjDt9JJtF4/HJrBbwHfa5dcbyXCJC2Sw0WsS6lAs2gX5sIsKDPbZKOreS1RG6jymZGaZ0s ckGzL3WCaaLBSscjBXFDOxgo25yOePeE4MrKWJQQDtUJpuRkdEWBq0ZL34MMFL/o2/+Vj92WUE7H pRxLYL04yhGW1HTwQwSVtVahIV/83L/SUBkNbfvSp3B8vTw6WsSvlPQtKMm1Vguq4XJ1hnVG86Pz oL01j69DXjzbtzxdil9gDvg8TFWqttrWKsOxytwtAJbRmGWOi5aoM3UDoBR8O8eG7MBRUR/X2n1p xDhkKbSz2abY1c5m1UvUJQS56xKkZ3d8UWzUIdDRV6fQYZIHU36NwF4EizEu+7ZpbpZlc/jRJYsC RSvpGakN2lCvOtDNL1iSuAynXsUNpCvpNpuGNxVPRZnoBSp0QZYtZhzB4DoLVGTnMkumizz0sruD 0WhBF7DIp8yvTshc8CtMbMT7tnhTUqYX+oFGiiM7WPLODL1qd/59mvZirm/L61shVAZoniY3eHPf uk/hI1kvAREuLw7/ULy35/KeZ70v5T3bthdrg/5/9ogJd9ud9a/+KKklzFVhEPx34a7kGFdRXt9i qevSBiqluQOicqiS18dV9T3PD0lPkQlMv0Hp4NUcNYVGCxk7S2cS3ATRlOiTApFUuPQFW+vbrcpK kSWU/c6j7IJ7qam+bHuDXi320qGZPfZ2qEYlUA3GKpVP3fWU/DBa9n4J+T3A7H825PfMzP4HEqLZ gR+GEN2gc4nr++UR43PzHTxYLtr78MOQpHoMQddb4FRG8ZvBERnfhNtiqYPDBIOYGHzvBvPgMppW X/ASfow9yuQQhVZLSFksoWZRQ9D4UQl61srkekdmCYUle8VE8GOba7OIaFzYOLHwYappeFAOqQeI AIBx2XpjDfQy8nFABNyJjzatieq8jF2HzLoHHz71xPHpYe9YfDw/vThTtAW//V/8KbQfkh1AJQGG LGhsUuzOjoPRgxN3qHfvyZI8KqtLJLKCi1yn8TG4UvUOCw+qem92kQJjZRDdyZyAKnHQnandKcTT DDqaZss8MQJ1voksjWbK0mXK64dfFTDrohDxjEgmQBs1KI1ijUaPAb5O2gvgktL81tqddw9JyLCY oZCIYe3r8gSM7gzzSA/GY3wDyfoVQMgvS+P50E3Jvii0+n3ogwlf3kG+oHceZvNhNAvRtoIP/jnE Z5vre1k9VC8SamCxq++s/gUit9e3lM7Nsssp/PHUrr65pK18H4KSViO8BTGNwhuZ1sxVXZjygJId uhonWOyo5dW+ovKL/D68yJJFOsJ6i4yEkromgILuBkA/2yB3Fpeoh8E2OQ9VFWdpcZUK9eqVm9Au vSbGhbO1tVn8vxerbu2DulXpCbEYzhGwBSZZSnzIPC6XBvmsG06n2drWujM3IAy8gsBpZGt2pWRL XjwJ7Y7sVUqtig62Qi0cB7NUZ6/ga7YempoHo89YttXKxPbJTVYnzhbzeZJSpcUhOupAIIeqTAr5 7EQm9x2NAgeGLNPKpevu8KGQKKeSv3y/Q5pBWs1zjwYzY9o7dThhNRSgvQSr6s6SLKeYAFFenJdM YhKlWd6ihMHwLkCkbaDbEU2YNi6BHto2/smEc40cINadCGiZgMGdK+/mTztbP/3SgHg7Rncrv5iV YFgiLLmXZdWQ80Q2yTCyuGhm+T09noIFYy0hDpuP5WwBSpFoDD31P6hAB76IUD4WA4iznHPmDR+W nD3Lo67qZKrhJnptr5ydFK6a8BPWPSWk4FMefEfBvDfLwSrJEi/Yldxu7ZWm8ncqc/kt0twuylWH xBrtpSK1h23nCtLxR9nNDVphKobbD99XmRihjMVjXYCX0h+XFIbkgp5K8Wm5piLfSvsCa5EBPJ29 Y61UVbDEopvmapOqTsrHjLM3KJJ1GqmXQr/UNOwUOcxae3Pr8KkRdoBHo48YHxX6HrSvQLOGq2rK CirAbWHu5RiDNrk79qC9mU1MQm5PCdSi+OmfDHsfe+cVxhr3Q4ey0215Mrqe/90ZPcBrf2T+0+y3 2p4gW8PcNmHFshx91fMTqGiD+3hkd27Wsx/Ta1zHwdz0XannxWj8wJ6WSoMnSrZy//AKSJYvoxsg zUAM2/LktTDWsGfnwT23H9xz56E9JY4PLsm+yFboiZwXZafzMD3W3MDf/Zooh3gtAOhG73IlMYkK C4D97F1NDTzN9Uuuhpi+UvkvEwLLk8FYLrgChRwJYJs6M4Rj4Bz0rfu1TskvyInXaRJH/wjHa9tu g/n1faHBjttgkZ3pspQHI7bu1nbdVinvbDdBdSIP1/bcBtFc//bO/S1Pxr0M5X6UXQPwfff3LIQz DCMvVqP33kJwlkP5upIeq+2Z+anFp6aZh1LrXRQ4Qtxf+cw9DOMIptLefkpfQZebFu6/jZI4Rk3y JqIUHDC0NzAbTNrpXiUTVWr9qEp5bfEPukgeHcQOEBpGvaLS3mx3uGDxNAxS0CJBOkwpyijHYm3Y AaGv+FOuXcwZgJ6CkPFQGpT1Lh7pB6UPqyimy7MC4214O2c/Ne8Gm8grh8Y6lqhHq8MiHSGFmPLl qQw+0JtfqhFCryI7v608Uaf/qWKjTAzYryQvaFZBcOd2tnk6GHgrsMK2+Ip9jSfRVtXaZSo5aVcP TRBs7339/ECeJj+Vq2P2NvcHmUqMkyzi7gEg0OVvDAtmFmCQIBlq3E5XvMesy7ara9Q6GRYMcEpU EFdpsphnG4LfXPDkDVZwFvltssnlN9Iw3BxHV1GuLDELXq7n5cDA8mH0gIwZheGOYV2z4Otkmz8R MXNE+LAZEZfalUrLb3r1Yfab+dnJLZ/99vWTy9Ghar07lqu6TnNahEo+DfIcTL/QFDJ0SeKF3jMo PMC732zXt8t2XVpoz+fa1In2rKAnSwXi8IIAuhWQ0eXD3hgg8F3uJnTRCCc7ZTgxtuezR8uUIhla +WYKKnmXjZQeP8v75Yb+apKgizu8W25D2V6CF0D8Mgkw4lljVNgEgF/yJu4028S9Mja13TUvbwsv uoffxxZuN9vCdzVb6PnNXt52SueFqLjI9l3s9F6znd6v2+lSD+cL3G5rHQ7GFAV8H3veULd8X2pR GJf0891hGZMSwzYmm0SpcRK9QDfMEdayDcX7zabejK3Sfeu8pH3r/Ij7VuqGssIxL2Dftn/EfSv3 vOy8pH3b+RH3rdx34oQin7caozTUeZpg+IIeaw546g52ZK1kesz15WZDNbZM2qVOoMOkEC1ulG9j R5K/8hYXrlOpW3wc2iLkX9ODoKikhsiq9Mq7aLe2HCj+A4JJSgU8fzVVSOUvblgH024WsTUGZopx NqhO1SVIp4PyGs9yMxhxH4LCVTadVcu/IqC3sPEtGNSFsnwOW6Kr5vBFU9jyUFB9Ga07cwio6jIa N9c30V4Yu5VcRKthtN0yRnOyKsrvMPqc5qdcWM2XXWWsv8i4nOlApM70tDF92kTCGNr0nmvgsyj1 mO64JQYRBq1zi4Ayhf5p8b1ArBQMo3lX0TjQdR2kVnhDXw+mOUVczmaOpW3z/AUXvaAwB87e+r2G zkrdhS+rosuZ+9S9VVMFY7fHIpigOjZK4hssSxRJv7/3Ggt2U7JQq2znJx83zwdnrjwzhVlWKMXi wMitSx4NS7FgJNmBwkNJUX5JQetZkMuHrouRahnLhXm6q1EU/lLV0/3NTlMV5p25JmKu7FrxfbWc 0vu78kdOU31gWjaD6D1ZmvHSi7xaImZy6bAxC5fMEsosPq5GssrEdvV/a7krpGI/JyTZteX1w2YK WQ6aCHUPzLrWjHToAkAanafRLCAYmEcdZVw9nbOqG1dTb5qnvSGc/euPa1K3baZwc7ft7W+UvK3H K35QSlRXEdf9zAMaq/Ub3g3wabL+DIvZ4Wdpomyh32Go5tu4H5wgqXX5uHG/3t0oDMcqn7dpv/Pf Hzbe+e8PGw+09CJKZb+KAusl/SRKdT+rW5mAAYJZnuYb65qPT/vgtXXjNChKWeL+krdlSw76olAi OVIEhRmhUsm9DPNbvPLoa9SoDsVj47WQJSuGA/VAdJiVzMcB4j43zeNfBhlda6JrqSGJNmnJyVH9 IwV/Gym7WkGDfyajiJQw8zglC9bqI96WM67L1xMNq1DKVj2lPG6elhTusVyX87a5XTYCMSffP3HR amHSkEwpUrFYUTQC48xLN2YAdGM+TuzO+iArnaEDhk+4jYLtpm7XB8WXqRpuresVLpHez8e3iDtq rr9prrJewry9juDgvw5uQr6iLF+Dc9lNZeyRYXB2eEEPLUS4WtwUsWZealgn+5dLWTlQdGEruniY XydZyLDoBjgKj3ka6mquOCdXAKUpRXblnUV82isEUbIWtcLWhgTIC6JKWOZCugtnhDbRNBxfgUWz jlVZvcfFgEjsy/Noz4CV5eXLpjYulRfhXEqfF+yQrcv1sbmhXNe2DtAfhRdAP5FmO5K/Ikl022OS wWLqXligTOtFDH2ynLLuxUd8x3v9B6AZ14Xv6qPPlWSUDCDlwycCU2TJwZBRRtCrrUUPXsJmyTeO xiR7mFCE98BNsc8PQCGu79m3PJ4rjRhyKBwfkyCaLmB7xXgR+hIlvCM9/4ZPHWQBVTz3h9t51xvs 2o4vSjYYV40SAQ5++MDx2P/H23btEq0x/p/r1hfEu9ly3ltkfNAJXtle1O6/m4Za7sJpSgFfv+bv q131ald9VYZwc3TLfJM/Cju8mlaNycZUqbZqQg0HbuVgq1Iw/HhcVSs4z76sWjD17z2fMKNebaR2 xcX4yhWDnf7HcPwHeQI7QbbedMpjcp5XTRGpPKuoMGxQ2Dx0+cRof0iVYdoPF3ffa5Vhi42c2KS1 u00ik7kpmF4oGlxbNjjP8HosySGr2C9+lgUm8+xiNC7r2KDncXAnBVPffim6Qc9+nIUp7rUzsil0 DP8A8XUq60OKakA3ERwaKvFXGWiNp+CvvLwKomO5OJu0lGu/p6K1SsC6XFUoSdqkcq0DwKlj26By rTsDr44tmW01lWvdGfwAdWwtaeSdQgUZsmKYu7O1VfW04XE0nUZZiMU+MmteHgE/TmFRjm/KRagA NRcOtwkMw5eLkbLNYV0uPavLgiWU/JJT8JsQRsclDPuIWJ0uXjBhOIhUKc6iK5N6D2XZqsSUfzda SH2Fk++LrpqQ1bav9dr6wzLCKtJVTbJE/Wm4IsXMgrtotpjZ9WUVyg+l72UW3AM9ObjJoNc0D+Iw WWRYgBcLudUkllho0tV+v6S8uKffwAE4ie7AZpYYlRXG52kCZDRrifrS4jAPp7Y4rVwdQ7qYeJ2G t1RwPGEtcdzZYIaeE3UlizSEaTDPQi0biIkv0yQYo5PB3V+p51ANYlDVqOAdeiBa4oPqUtbIAUNd WIeQ3hJKkLoVcXgLqgiy+IxqE+Mv/5OUlgKLYb5J+rkl/jNME63bKMeguAErK0k3tV4UTK8SwOK1 K5ci6YOTu8keFqAZnBUgqAV2L7NCEXEOFH21QV1aywpyJcIaylLkvzh5x3drPjTi4l1X2FVYKqvm iG11dupSxB7vqPQFnx3+mgWfQ0GmOqyKUe8gC49BU4ND+nTFQTEdC9+Llq/YZlR0zeUyFjhyZHr+ GUBSOmMIRPH8Kci9/VG4DUkSXBOVatKAuPZ84ioI+0ai1jdyvyI1vQrbV2H79YStc9nGuMTlHUDz UIJj8PJt/y9xfluXfsoZ6ZEdsUeyjiI6UsllKdNeqVpn+YsIJcxU8QxAE9+1Zxza155WcF8/LeJU wVX2HruvHTAmX5Kz2aZcz99s70gzlzP3sIp/hefh79qlu+wyhupfVgl+lf6mJJU9evP+R5SH4XVf dXwUgwUITfsPd/0a+oX+pnspD3n4f07ZMMYUJWmBfguuvEVXV3u/GgeI9UKywwzfib8Dy3DRs8LL +LPKz1rKLc96s5Umb2wA1HeWJIrIYurfQ/WSJdX2ihtecUQ64u1lMHfvocwthvxO5wZWw82Duw18 PoBS6ciCo5cd6P0JF+V4rqZpQp4zYzm+ZMJ515RwPA9p2bn2rOlGpkLa1Ri1zMAHKCg/zL2hhwZZ PbNsiGABMiTO1R741/y8+30qHfvHIJ2dWpmjVZoXIXQoMUxyvpY8DpIsOVSjVtRhzPPQeUrcs0ZW XkjHc0rC7TrYUgXiapH13RSKK+7zXtE5IJz3E8UaGm4RhwLXWyu9pggKDbXv5yovKkOfjDVEeXaZ rtMnATipJaoK4Zf4Jbp2OZJy8vxa7wwqz4K1yg3tmQAcKsvZ2Vm7Oop8+4h9dLK+TlF7rHJPeEdo ARGrOCieHoMDn2YKngoLQw/0VVgQHADqVXUH8+oVc8UCnK6n4Jc5L3zML3VmFAnec2cUd7BhDl1h 7OJHR1QqzXnV+1g/dG9ame+Wdu/Pi731vzcoue0wnMMpFnjlHn1Ah8ltLFMO+tI3ZKQo/fs0RX/0 0hldzF0wDwR0/oAXKK2NjmZASKeTCUoM+bmIMW8qHDfYFq9wmGj0dqbzbJgofuof7bRQGNPzSLZ/ q4GDSPXuJmlK7PWg3hexfCQcGSVbtfcA8BtMT5IoM2uXe7acE6IRLnoyZd2Uxm7OR7273EObvrfQ pLeHtpV6e2hr3hulUJSBFWJeqGz6RKWFPOeZSgbQ+IlKW5qFuRQh+sFL57tVYOhW1neme8U5ynJj 1Syw9s67nf3tvZ13T1QJhybJoWY4xxZxBLqnKeJ4TwX1/PPSPVUx2IL1ruJxdBONQejYB+iGUqXN UByudoDgxSjM+boCI3dBKZp0pC7mFOirUWmK557nRSw5pJbuimlbvg2PZ7FgVCWQ01IpRLb+giVf SL2wtL7rwLXyMIcqmssgjQQXqkovMvvVHslUkHEAyWI0arzvwQfdqXtwyaUezyXp6yjLWXr+JbQz LtF2ahj47CHUA7zmoMuCA7RBCsaGkCFU67dIl9Bk2nKgVNcU2mrxf1YkZzN0WFG3qDhBB45fZckn bKdLaS6h2RM/mbDQe/lR5DvkavtsUApITHPun93sqYX6hTVUTdEF4GUFcVlpB5bo0o0OM1dF/toC VE1O3rrw34pTdnHBanOQlyeaMksAuFRf/uruypW03K3wXJOV1shL2Ai/sPNK2+B1f6JN8LydriW3 PGcsfCavjErXr3xYNCCXm3QGF8ockhsZL3K6u+GeJu6ZwTtVHKZim9TGuAK6eptehJbBnpi9zXa7 OYV5SYml1v5SMjN+gK9NSweYfZqhN1mytuwrUjAPxyJPozlnK1pFvl1aucgk1eW0SIQEokCToH2z JOMjDwd0gJjnQvEgxjINwTQreJkBK1HOmYt4HobprORR571WZ1fM0FCXOX9v1/Z2/qWzu7fe0oXE KenWrh7ugDFk/mI142Uv8Lp0+66Kbj0301La/Zb16Xt1tekNATiV5N3tr6srjz+VVpJ3gNDgpXXl X2iwqb7su0tP+1X0xF7H5ToOOyJd33aC2F9ru3eFZWLOWqfiB5letLZd8Xs3Qdd+Hq7tuA2iuf5t 1+tsxfd1qz23FTt0DsM4ggm8c3+1Hgtf23/KO85dKeZLAk7RTUSsASYRFR+R+dSeQqdebTiqoi/F cCDQM9p8D4BV7iCTgl4FDQMyVqmUj5U75RInWmx2/rn17oIIb2CB3lP3ioScrwWGj+SquQ1AAzlx GQI098Az9OZDGapwEb91JHUygNTnJ8KFTHlTNX58CDLYb1d03tCFpFUOmnoviwRRCZD7EMOxTJQV 0zdcsWQVGRJKoCdO/fQsdYSsYhSLt1YbRnVcPlKBSRvviDj8pXtG5v69HsI34AVd4rkNUrzZHuU1 yy2XBg3XbKcKnTtPtfrVg4SomIQjbB4wuCQKNXbJwFUIqBJl6gMWxYcgC6dwCIozVO/gYIoy6f+Q +qMk9tyapQ9IkfW4BB7zmDySW4UxfUDWLNA/LWeygcc6ap+InTLUl+2072mSK6BciTjEoA1e3Aqx jANLmQzJKcLX7qYlWzwGoKOXWxAPbKYVHLPvK50jJmD2fPKQunBY3ibp2BImqpwhzVYJbsfAfsmm xO4KIZqtqs204pfPfjOFFSzlXc3MtjqI+hE3uTIQ54SZn/9GL+LXra7d6sqomZ1K0dRxan503KZf 3WnKs33L06XD++t5TQtj/YBO00zsbLbJZNmpT1F1SK0yXuVl3qxYMaCzaxsGDumNvr7DPsnB8Ju5 i+BKsWjrRPGmCoWkUvt36cKmVS+DeUN5cen5QVgS260e9YZUlwvmMgXjeFoXHpU6sTLBSXdFekVL NsAiI4s8LKmKC0hBA5poeENcgkokqxdcYRQhQK/y1bWy2H2vGVC9h6WaJHeX+2jai7myUUzOcopf gcl8E40LVRZ9JOslIMITzsT5DpiwOQ9WBiqL+WtND/avX5L3VR2v3c/KmGcxo/DZ7+erRl6/z5WR Rz/38/nv9atSvmS3K+N1h4mdq1u606K42dzDZPIWGi7ZdrFk50XN5sPnjehrTUDcXofS7U5hAHbW oqctpKfEMSsKX7v3gAABqFuPaitB6LdbbfErv9ln/eJqDPixtZ5ZxKRWhVdCaoldgB+cN/cDjgNI ly+OGLnazMcVyLAyzOdke5fToU+Ffjq41XwZLdZTYjUdvunrANJMT5ufqpdgpvf6ZQbp+wYTzy+t VDDvMoX/qUm5xgLCZ7/8jQossZeb3xD14ODYUgPX5Y3qsqdcAHUG53eSl7O/2X5vT30ZqVb6mN0k ziYy0+nzlCITIwu5rKZDlhBMxUoT9gVT7Yo1UY0IqbOSS3FCZhza45BPQ+USo7i1CK70KVz4aKLL i2am7Lq2VSgDJJYmc0s/s1h2v6NiPyu2026ydCeXbGTtPno4XZri7aPUzvn2N8nP9ZYtfEDlKeBh 5Z6VbrCdUlOZnG6yv5dNpjYp3FlrCZDK7HB6VQWzFo4PuuvllyDEUuKT/m/3gRElF0lEtUpqrfHv X1ZsjWH0nuxGbt1rI/osUgUnfse3o/1EDzh0bEoY4qEWS5lPNS/rlA51rdkv72ChYqWya88Jhfpm 89KnwAs4dlVZXAzqFyV3nx+rTBtnoWhgcjoOEJqcWNMawuG6kLUFaFrHVYXmyuePyZ4jQEqBj+kL JB3vuLMuqZkJZEpv02PLix6z5Ma/I4XnV2D1RnEnm9o06pSp2xAeVfbHdde9C5LAL15nE3azy95m 1OJHO8IrL0XKnubstO5Ec8+GN7UloIMx8DbDklNYcqtY9rMejZf9Gk+dKARLlsgW+CfMYDZf1rMf n+K7EZlu0aDMnep5Rg946K6Ne56Et0Vc63WajuWCrt/gKTQr8FFfIf7Rr5saGycoiqpibE1LN3rL xGG/omgkQVAEhQKBjSZdNddXRuyjRiXOLTl+HAj6RMfauGwb+gvQdTnqJOFlkHHsQlXxsvP6aHYJ 51Gq2k0VQt9XaGBgPglqjs6CIPFr8JVx/oqhtb3d3e3dCgpb4ihc7TbkWRKpSI59cdlX0VimqlvO fn63Sw3sWiJ8KrH/K+EVdVilr1ZTmKqlXA6kqEd7Mylo1WSNe4RomnzJlcUK2bNh3kSYRdksyL2K NImdDc9l64j+ME6Jk4L+ZfYXwHYAOVfgG1OtX0jQP2Yemk8uU/78jPJxlPEvXkr5GHg4Te4pb7Y2 Tftx6oYfYDazLVFZTHBJnHmQ5tFoMQ1SttxxM/xHOBbzOdlTYAiupeHmus5zpEsJ8hmNaZ5ckf+1 8b74dfq8Y3xFUVJ3WD3u7TmuV6Clh5kyyw7rMT+k/d/Zj+wzhpbN5tQqFdNmn8qFO0maOLE7l08s LFos9OHyRiu7+mr3tsrSshStwt6W767Wwp5iS/VCs/vsYk5TvGVfVKQqXt+C/JTGRGNM+AXyHMXx OdXHQ4f1jBzYN3ZdPFZU+YHYhGetwm0uTcfFI6x/SEoa19QT3hPHvuaVRf/QNwnlGQlGFz2znDZF uRfJ9DTuF4bzuZx2c6Q3RZUXBqwyMVbNl1pWqubxMKjUurWbKKjSJNYdpc9BYAMV0FX6HAiNVEBP 6WsIpNaV6sBYSUrve05Ic/mJ3Scy5SnzY0ZWpGvOJ0xG/soKP8yIrkJRA1AhVDAsiSnWOktSPyqF 79zE/ri30XRKYOiF7KBkHvSrdjJptDEOAPnk+4WvL/B+CiYQaD+rzQhWAPJLnK0GzLdwFpahx9Mw rE1wCdLbkgZOVu/Ac1Cwip/1GWJvwtWsFBEJoiKBZOQgDxvW07fTYbkDU7oh+aJUkmIpaLqu5Iqz cBKAyCFphwD5aT0NJcjlM1HObScHCr+gc5LYPlFVlJR4j2wFc7kT552kcEy7cBI5csNyYeaB2CwB HUwNOU5Ic6CRD3tHvx18yjg/FH7ALx0oo2CK+jJpwowOfqQFb1IRoMLUZUmx1Mt4VZ7iEveOvsSd okEXcRqOcsVcyzuIIHdIAOlddZFDe3x7jZQFHaPU5s6UDDcYx3/30K8TSoLNcSSXCbsal7Ir8vwn uB1ObuZYVjMTJZ/lHtqyNejeS/zC0LebwEyT4pvc9DlPbvmor+ut6wO6nwYjnyGzAxo/gQ1R7Ntk zYfRZBKiyAL+7OG7yEhN+Bmmi/yaLsHXdT/qdXuYiSQTNJE0VxgceqvEOpj9FZwRq/QejFJaeDpA XrM+jXofB3cfFmmWD9AQWLn3x0WQjslsdLo3KIwK3T8FWa5WPrjGi6wxL6EZ1vXKhfNp1v3Dfc7v yU1DEGjpYTiXmG82eaf7h2ky+kxoaNZd0atH8w1ofTiaOeR2ygTXFG/jWWBNfZCH8xVmTt0H85SM xB6XQ1t19MHicoJvaeDuq4hMs9Fl9S1fVKDcLGakGSi+itTQzHLCM0vtrEfWjsSbg1g7v9RNbqmZ m9NBHmspepnxjrjvQgfdit9agwOyRJXCpyqm07IcDBdOBnumNKo67dQ9urxQRuk502A7yv3CMlZT UmmEf0Cz3ncNS31MFjDwq42A3hfBSTBSDbxqIxnKLILtFRuZJvEV/eIXGBnfnF3fD3TX9+UNPikA 7S23weIqW2vbFTEq3NqPXSu/OSmChjW63iCHnkNBRIbaFEIHdgVBThZT774SPjwZ4BmN2u20YBRn 6LBhLzteXTKWrAOihHZfVBJlZ2sVtvNiMZaKtpTZtMpWTl3kUmJT44tJS84pk+ExukwmX9jlgBHI LVLPi6bMCpjw33FX6uYj1zb6fZ599kXN78GsvedLGPh63xcr8O12xxcp8PXeji9PEHRnv1A9pC7M 9Ug7ht4ri/0ow3WRWbf+FKOpIl4OPSvsqepdLiy09cKI5IPTExG8wQil/9nfYIRtMILQAcAo8YxI hMs/UeKkqoI36B4eH2g3AVUAcbuCak2zBNJEK2GkyuuFJS4LL5luNp9G7E0YKyvDXe7Le++pPKmb PQXAiLhJdelULnt6ASzHols1Mrm7vVfnCX9EJpjLWYopm266gJ1PGSi9LqPc80QdSgeSrmBHhAXa CT1lDlad8UXpK7JlLiSr+KKmTz4M/bl8JwS3jK7KvKOltv7yggjauPn6dCXRA5aRumQFu4letLE1 dRGquUth5kpYRxB/ZxJmEkyzcBUR44Upj0v9NivnQDyRnDGhSu+qJYkHTGZYy9fVC+0OMmVNNHnD emSWO8KAjCgE5LfUfX/vKIsTuyvG6UEcYW4NQ7CmeB2OPvOkXBk1n4fxmAwAUOAv4Vi9RQojSqUZ fG90urUKjXrx4eMy7+CKOaXFYhpPQ6NUkEUS5ed1oerh21TooNGhSVxuXW5dxJkNTO0TsYSrHUAq d+87I7Xtziq05t0FPXZ9ySuKwu3Ou73a/INHpLT2LmpSYPXDNFlwKYUn007heTK9j5MZHJU/tEzx LlIeO17/L6rN81Xty+COVWAtVlAp3symSS7f8uY0B1WxPPcfMZCRRlsR+ikTl7h2GXEtKTLuwODW Ur0HOJdYad2o5DLjHPf2+OAMS1WpYrQOHE4tlOq385tnAmyJ8G4UzvkukPYzkksNI6EkAPe/E7pe 6jz2ShQeu6GnpTT8dBX6iwdhdj+7TKab/NQtuUXFbEFXvDDzhwgoxDsFpanmDsW26i1FHMOBUmc8 1lmqPwphlYUlyoOSz8o+NAUQpPdsCnMWoPZo1YloI13EIzd59ns4/mBhK1l+fklEW9V55ltr9Bnb 3vrRjXm/9OBxTUD/cU6HR9rhgyG6m3Guwpqs4Nmu9dP1VsHQUVcD2g5GJ+QSigWD0zmh3xlhtFci ijIvcmWaxksgCpotJ+mvfXAow0Fkauux5cQhvjfi2F+JOsp8wWVZOA/OQsCgx1Z5RLBdeHviCeJz amEcTUN6ODztDvoDARhnbTL7DkNOKxnGfgm+44rUqmelIQzTcDoFKUAZM2ZNYm3YPV4Xp/Hb08lE Cgp5CbQ0AMtHrhIUg83u93yMrK5flHliK/PmVjhKxNqW+Kdoo7fsCbwoal/tMyWDWdORUkYkfHw4 yP3OqYQ+JUSzmu5R7k6tyJR8VgJFbWsmJ1pKF2XiwiUTTReOnwJ79S+6YpurG6Mhc3p0tEHfuzAw rUumhV101ZMrpyc/ikOizFlblTD7EKnT7uw/odjJFpebNOtXefPFxk2nzAlamQzd6NJXVbb01yKL YlUty+uoXyVWuqrjlnTQGiJCvjunFjD5SvTg+S5N8YEzrJcj329dSgkf8HEFx5LhDf9wfxzEwRW5 jNf8LOT52G3jmT4aDt3BbWwDPU4pDtuLkvF+hZmpzypmYX6djCm3lO+deWnzobkiyGh26ju4UZxu GdrwAMNHhKOJhifDVvKGoAOEryUPTo7PWuKiDMcWQNqD6nkbUNjHqkzbrd4X+iybsqmSVP04AyDt vPdx87z3K9UUkA/UWZXDqa6SfUfbRWfffm9SZjOZ8D+91BbM51PgQoQRuSGU0i3DnuadibGgqtVa xLkzOEVN5DbKwg139DIYXuFYIfOZ+ajzkO6O1uN813IqSlIXgPcmJgWW8KIlbB3V0kA+ovBnYk/f HdbcACVRoG6A4k1ISjFDVkkAMioTJPPiHIPvDpRJRBGqI7wIfhcgdjaQfjBK35H0VHKx3gFSqFjK tS9kgVLxU2frp1/qdCl1Idq36oPRMOnOvuxeOcMg0VsuuB75sgUJrwgvRXOil/UeSiB+X0Sjz/Lx SOdORikP4AoKpRZa5kYtbNYIC2bj3ek0ua29OKtv+euGYfUIfVcgXIVxmAZTpoKZJm5K8UcWly/P LDKZDsZjljAVrPQKa8mKuaxFoRZfNRmxRpFXBwxlHOHjPfzWI6fO/pRhqdlIH/QoumTRWq6n6QCR k6YqK3lIL9Gsha2rlvgY5ifhHWbk0hs669aamlCx73+wKHClO/1PTbkH5dRhc6ErgQ5Kb6rLSkmG 6qrrgZD0gn7yReRwbDYUJJqW1ToVxNsGvuAtClvRncGcPZWsQq74l7ft/aq7uY0fd1D8wP/KGteu Jul0OMv5Aixqp/VlKRn4UuIxIz+RqKNHqTOUbRa76YwufeliTJX813rIXr6oMzybxHLvmS6wDB/i QBXI/aQL5Arvudooz2RZ3Vqz3d7bkqcVcUdWTdJ8ugo+wG3MofrcqJThf0UtAoyf1H9N3FT3ZU+5 vJw3Ugc8S8GARWpBijqA7DrhTp03X5CXyXF971UmhQGRNN07mRhQUo8HZ0KZynBASa0EdTnriizL KHkoEwRVKCST9ZpB50XLNsqo0F+IeAlyvkg0TYLx20UeqWIglAAEIC4TfE1HlS7BEcfJbSz/Ob++ z0D9mlole1hNsHVwACILkOgLTqNgHozwYZX5FPrh6vgZ9hEVXIJ/BFMAnHG5aOjMMwmtMnigH1yH 0/lkMcXNoTWjdSlLblxHV6rwz6+ng5aucHRhrY80DVnXkN5tU5dJ7VvLTE+6lAgBoVf04hxvhhbx RY01qmCZFqb0SxuxICDsb8hyMj5Q5UAFlbc557unaxGQuz2A+mWd1iPOUQipU8XiLdB7w+lYTcci W57BRW4hgYmEiQn3ZRxO6AoymumIerVyHH4c5kFERWsc4aLgaqh9tYQV8zj393a2tqpeWczCEepF Fh99NSM9pMQ1sxMRXual0UWC8QpOmiPK4LU77F/cNJIfmUVELXEwnWo6eWuIxAGj7/+x/hnSVXen TZNtcHWbQZgTaTulHVXF0qwwf35vHN9jcKDo+4nLlss4C7BGbInIjmH5ZDPfa7OwwBiPsN4+2J6k EqMtG06wFBOKknRBsgaGRPwGMB4S+k0IkoWyWx8ycgM1el8J+DqAfLQ81DT04T2drn1O9FKkITKn MhDc8j58noPuDIRhnyoetmvOmAZY9t/qKcfJKnbLt0TrRQ06vdcfCiePg1gXmy1j6kjjpmjxKFPH AeM8A6Eefgix0C2wVAnvkK57qKdlHNdrxQgQfWgFso+KCBR6vF8vsZVK31LQu9anKbq6XlnD2mcX qpjVM7eqKK5ZzSxn2rpF/+DkICpbSflC7I8+bDfE0q42vYlGhpwz3wYpS3ol5RzUiIVWPdj5HA/I sLecVNoAFybbFQ8inKNL+ZoMKTZUXq3ZZTIHxik6ipczRalcrOcK8pHCSRTV1ieuIk3fcLRIaaXK RLW3ch57Z6XOFoKe0nhn0Q3jQDFv7KUm5Odt5QPQ6iV7l7LZqvhtV+rK4o00USqU5WWW+6pMZel6 9FaGyvIv0QwVXh3UayzXW08bhce1QW91wLhGVUNt0YGiWEsXE7J3ic6Xn50ew2u/ume5Wly0ON35 W5alvFrGN8sYVKgf+nCJ0ndgXAXpeBrym3Dybhl6kCgYQsVLqc6UOA5QnMWB/xIlPpyayDfczESU A2yUoAMzD2WzklLGIGbRfZZqKuBbsdoDqmNuQWVhJJ63fvpJD0ZRuiC+R3eagxB3EkrHoXXDlHJk 8ATDgL8SqcL/vj08GB5I0FQD311JcfWButpHwWyRzFHdXcToyzAzLcUlF3JtjhYHiHk8xkWLPQcf N1WcpnFDJKFznDQi1PQqsYHLya+TjIqIGJOYlnEFOPLjyIVnb3CSMOcR3hMa9A+rSNtnT0nCGh/W gax8q7re9jS5KiELrxCv0A9akAenjHEDB8ZtGF1do4zLFjNkMqdTBIeb5pbyWWhzhsQHwzORhdJJ lGxnQWLohVm7JF8fGqvZeHyqQk5of8uZVuktPQ6j/uzKrf5EvNv9v0nW6C2O7LGlXU8R2Xp0EFt2 AJjswgrbhn6EycKLA8DGOqEQCXRvizP8toR8bYYM/DI2rzqrLMnu0qbwzrE1GO9fxFbr3e66+JNY 2+F/deBf/yZ2d6VzdBJdLWBqTlfKGwizEhdIqROwJTzGMHrkaidXiZeynAUsanPAyGNNOUxT7Klf 1+KiC+T7xcXJm9FUkMEBcxOm2YL1szzJAdHm1ioDsa5VC3UoBG7JZkOD0gd6fNb7aNm7mYkUVJw8 3vJZMFh6jkoZ1H5+B0KjLfQFGz4D4W6Rta3+tvybO/AaqIVAdGtWuYu3iCP+e329useabiU2RZYv JpNQVnFZL4Jw+rvTNS5kbyV6Tj/jP09qNhcDZNi69Dx1Po20PC+js/jhp+dG5LywACLuJdBunl74 JY2czwdayCwMskWqPJ/1Usv5VNHGwN6Pny3UTaIp3sQsw2D9SHESbzZGcZ1Xo8rteo4Uo1jxZzEs ZejgJoimytFUPwe9OJQyYyo9YF6Swe/Kivs4Hx2A4vdkOMjBig/uFX5bugxNs4K5REuYf/ly0vSS rpxPI9Ik7D4Vbb6xj56mRvB2ZWCzELbM3JhlFM8XfFjgEZkm8zSizF/5xIeOUCFR1B5kYAWcatAY kARi0KG4pf49eusMumNcE3tEQDG3MVZ0mVK2I8bR3IibvUX8nBC7ClU+Gz6McB2kwQh+AVVbTSYq DRwuMFeRdcXtDiWxjRimnR5HIOTbSmM7Q+syGH2mQkdoucGqLqOpMlkoG/OmLfOfUsztACCs0I9g bOAxmde1t1M2bqvo26ha9ANjGT64p3O6D40b3M2vtOoa4i4CFfj3X0s20XHdV7OeFXhtFO/wC5JU IG6VgMe3xL2OSmi5EIgpvkSNXJYGk0k0UoRYDIMs3QQvkNks1Wvlh6+N3kbOXD9eocMVdeGGKnby wg1V+90s3MC9YzxK3PefTdigQWc6h/ikoc/yJ42tzqhfWX2tznbXBoB6d3lhIhLQ3k6TWUDnwkR0 Z7unNYtSvlOYfNxKVo9WDcjKWxRD7yljsYaCbV37w0dlEkqfdp6Qsx9rt94XPT7oukyjPDf0SBpC M76cKCPQbHgVC084ULSpJXEgizYqkCUTpCfZHSiL+HMsx9Np6ToRzMqUqC12XsWDXlylnGOWEsuT PUp4YM63jRpzXJrgZ8E9Zo85GKW8kYTyosgAV08vUl5TUXOn31kld6ksVSnV/01pTetsBiDsUFaR kpRS3GMHDBwNI5V6W3jySuWrsdNBKlbohuCZe4fJMmGzUaZ9OVBQF2ughz2E0LxIU6l0fUF0JktE GG+Gy/yNqMHaf08EudRQUTMU4aJng30TvsFc46+S0wNmkauZM79k6KZdlIkzq1gb2v2NgLlqzWPQ tSaZb0zWXmmlyrO+KWnv7byK0K8iQqWNuBqp2fITPTJUiZnf6HO6GwsDCfERSMsr0FSlCb4gynoV mo8hNB9EyZbEdAhZlBnH9HkcQt5V/rWv62OrS3PgNXMeeU5WhXKNEZUqq127vNgRYsctJdCs9dSu uot5naPO89UACLVE5gGDcgpxTpJFiqcu4gMfgJFwih4GjE/Cjo9xmfcM4bcwHqs1j64TDK4DdWjP E006DWdBxBcd5ji29SorJl7iBQXp9HN2GRkxtT2OgTpcXPwzruV+wXkOreNsme+xXEXAexsr+B4r /I4Mp9T3KIriu3wjH+h8dIE9Q9ej2uv6x8Vsx6PF4czdPiO7QFZ1Rnr2bikiV3FFfrud+OQ4HZdm X1e4GTFtBdcD24kF73D/6JAocz46XZe4Io3zseSEKiSLShyKtc7Wrhd2sibYbt19mwkuzfFu5DMt lwGex7ScKJv5S7FvqbfU/jRIuNZwSAU+5pwd92P7QZcCusCMqo+cf+XCW+6NLc6nG+dxyZxWAIP6 UAWUVcAoI68GTI1z1wZTiZ7VwFSiZ8XZVKFnBTBd0GseAcV6Refh719AN2pFJVBWAaMW9YVg7EVh 9okN62GLcqE8cFFfAkYvCrN4KYPXQHrAokqgPGRRXwgGmKGSkB/Imi7tPIw1PQpcDUwlIT98UQXa efCiihT44EV9CZhKQn7YojwKfNiiqsEYKN4VTlsfeK4xP3LdFUJ6yg72dNcaJb9ca2rXoMQ+uZ9P 6KEro4UjHHBDlv7yvZsbiCN62VmlVBfhaAeXvjGkkekmU7N3icZzYEjLmTKmucooOg4G/UNQwEN8 LZPz7N18agfKycWnT5RKz3YJWhnOFKR1jRZlHFAuNE/KnU5F1GC5ZuYAoqIOmXEM4MTqwwQOAO0Q E4MF3XIwaDaFuYwPZWWy7dSQbYmm+DKpV96ycFArr2hYVwXkDYwq+nWEaM0lowt5rcMfwr8nVHWD JMi4UmzlpREHjnWFpJzvVg6F1VsNGy5xO3CWk3o5cXvoeSxS314moS3V62XSubnf5UoRTX8rCmsH Dk2iKKwt0lYEi2QqLtMkGBMTeFtKl5Pca08NaNYB00wsm01VBFt+9DSRzYZgXd77KrJ5p042F+3m 75Ze3Yuf1eR6VPJ8qQLvX+qrvcbniSApkmVZrel96eVNeQJYFxAdOEuX8OUkXySLF0fxuzUU73jA nk80+lWPXqZHe4HkSqeOpFsHTHUguSx0/CSUuldPqV+gOj8vgn1VnR+UEFFjQ31Zgs+TEPe7BmL4 AcrH86Ls71ZZZip1wDSQva7egCTqQHk+8rekiFy1HvT9UugPqx4/gMjLdGMlhh1Az4PG39fQuBMq +m7tv2xBmGRBibcMI35CpYJYXBK3qL+U3gFGFkoSDys1c+tFC5gFv9QoqNaKpn1MhsNpbsDPtHgu QO+xnMMhj+GaK5KC55Yr8ak9xC1HdO1yrHn4Qybi6UtH5ic8MzKGg+jxKl4UKrBGmbxyFNaWb6sI wWw18fCZOOR3xjT0JBJI2BX0lyp2MfZllf6CIMG+dMMV1WpNrSJTO48vYg5/2x/Tb938GKhnEAeO zS6PyiB1QUo/3P/d80dRe3oE/rCOmAKrOHCQcZocKvq48FbC6tWjBHbcbf82cZ3GB4grcB6VP+qi oX4ey3fPH7XKl8UuDqAKxX0Zo5TQWVNGKWhfLtPqx4C+qvb1yj/AP41CrMWcqe+Uiegq0VNqYh0H wrPWxMz+f5sQ1fPQxprEd39EZvkytayRQlbKMSsoZEYFc4DU8olbgm+pRvbKJ8gndVHh8kTcH4NP lqhnDpBlftVytnGA+EzUgG1cqi93lS1Xzxw4X6asvbIWslZdGLsyOf074y7ZVsxMKfgmmpsDpQFX ecyz7Z5Az1Znc0igLEHDsngasIwrV5qkObss48Codjk/KsvUBcerLmL8UBxTqb6tzjHN3QTbT+BP W019e2UZzTJ1wfqqS0c/FMtUa3IOmFJzqIaD3KOhxhyq4SBvEvVBzzJNjj8OoEfgtgry+ZG5rS5t wL9k+lJTYySPNCHwZYklDoyj1XIFLLZx+WS1XIFlx9MX5yKWJQo8NA+xhg1cqm+eGlBkA1eCfglT dOpSA8qvTH9nOWPfeXbAA9ihKjXgsVnCp+OHsIQD5cvPiU5dMkDp9f/vniO+r3yAh2SrlycD/CiH RF34v7SSxXfPES8vA8CBsZKL+QFJxRXh/4fmzr+wjMtOXcC/umjLd8o233PM/wv1Kzfa8qOcKHUh /spqRD8Ge7yoKD/2dAA9nqr1ozLHktveXxbaf9nM8UOF9h0gX+DZKjKTyzwr3SJXzOQAea6R/M6S C+lfHMx/Xvwkv3JJeLUI/qPpYU8Yx/dLKSznjlWi+KszSIk/YyUGeaLc5M6SS+1fGrp/ufzxRIqY xyTPTBH7oZljyXX6Lw3SvxBlLHoN0ovHZq+qAP0XXb9/aaEWHZLH/2xu0mMeMLwpQ3uVJos5DoIL mixgIHx/FcgA8dziPoo5T+yOzIGif9g7GfaP+r1zb1rH0aWq8ilHPj/qgr74bgu4M4bxZkTnY/Nq PTeUi7KaNByMfIKq9wyoFTtnTXrbg7UNlI+InExifDUoeuFipKdCD1jQYyKZQeqHIItGZrri+PTw 4lNvs3t6fPapf3DSteXbwysQl02Ctnwc3kSIJDr/9GMnDiEed08Gb+X7TQpSLs6DcZSIIzIk49G9 0C9I0Eslf/wDr0QIwIHeI4mTRQyyZhwxh4Ag0LUqmB4BPccHJ4cHw9Pzv21+PD+9OBvY70FYiKMd Mr8YnNdA/+MfCKRmHgfGkpdhNMPYL8PgSQKS1X7cFQQN8nnkyuj6918l6lZdQp59nUXYM3TWIeer VllYOi9CMoycpPV4liYZA/Kv5/1hb1Me4FaR7t2dLfq0Wvt7/NeWXbG7f1J3olcj4Rwb36ZRHtYs WC3xX52V65G8ZeOZFbI0h/P1MrkJS2qHuY8ABYIP1fkUmWqBb9rAd3DQXG4OgNNydX47YLA5DNjX b87BbpLgHis94QYfa4KTJ6UCZ5l/vkjABCoTa3guTjQ3y0p9KJbXa046Okgv8RngMZwNMDScn0mK 7yJO75eQwV+xPtpyEth7vG3v0/E7UmI6RzzZL3wZ/TjIDGQ3Tavv8rmjWAfT2+C+yFqB6zgzwJlm mFhYD4gy/6GokiQvoheY5iKmF8kWsPGpECfDQVesnQQsOYCcpyDgS/LVBjlKlHSMFf9nsyjPw3Ad jwb+soaw3P1P0s+cvcikpkCItbB11RK9BawjDGIDen2jzJEosfcF1ASbIR/KqiKpk2HvI5zazsNC JZ/fgxnom2vb667pU9q0s7sn1nbWlzT93+crterxSqf6NAxuwofhNQ/m2X4/HqXEC+29arRiy/ae broPSK1pud3RLXfWduta7u3olp21vdrRO9ZM195V7emL3cuz5NZ+o/YFTF6bNavoDEpl2Ok8e43h VV9YIuE1ATTUFjpy77c7L2Hrq499B4xWAl6PfZsozKF/liaTyNaRXpJwG0yTfBD94zFmPyzVRaun 5cxfacjKxm+kIDswlmOtFhnnQXwFO/8hGH1OJhMgWDsU+pJ2tbiQXjx+mcsY3r38rdBreGm78GuS oWQ7S6MEhrt/hLm/WAEhUXEc3F3MPwSyvPorQiYfF0H6ihGHRNDoeUVJASUgAzFm94oMjByE0ygO QareBLZF+cNiBI72fJH9yIjAGMogTDEYdjCGDo+GkQctqXKG9/GIHHI3dnLM85jbxWj8XKfWj7Mw zZ/v7G5AkxxLc+EAbPLZPH92pCclBdjYZ8hRGaWgPItJmjkCxw/v5w90VOPn93n2Wax16hz/vwez 9h4GB6qb2A7i6oUfU04JLRND8iifZsE9R2GzMBftvV8PjjFz89ezwV/QNSI9HWUXzcgJk4lZdHVN OWLzRKawXMJRR/l1HOd3umIkLLpapASXcWpaFDMbZjqdQt7edYPwKiWLAtMGCn87cJHuhxncPLPq qPGyhuQpXNbouAqfNQGQZS3JvV7aSBuiFcv03dz1zaqXWO0aq2+uXFD1rYZ3wwgOx6vTyQRItL5t iR9nlQ5gqS+bS3PQtv1f2tKxs+vaFA3QupaOZbYEaMFkWdJW6vJ1rRwlt64p6zqlLQbR1a99mTHY 1emBlU0v4jBNkzQcV0PrcvZfXZOLWKYIohpX3Qz+Pw6mJ0mUlVMttjmORjifyRSg4YFV2bD3+0Ln auJNDtPOEuYPTMBi+ZhM5ElWTA0AdfUSxHdBLcYUxSKMJiqtamoLbpnB1taZURh1mCTTaXKL0QNB KBa3cLbOlO+dYkGEfhEHyOx4TNzwxssaAgBHphlud8RNkEa0US2TxPvgE6E7w3P8YDxOw6x8s6BF MA+obFJExAGTKWkkhcl5mM1BZIXJopxZdMP6Rswhv2GcprZFF/antsHwrvqQUG1gzqGXBl5s8inJ crQF6luBYgk0PT4O5o3agQJfjc9CSwu5TQBbzYGEajat2Cu8irKcdZPGIzl91HDVHYdtufNLmnWa Ndtu1mynUTNlEVxSonBlW7ZajX5e3254h0d91p/NvNT+8paHy9udh3lax4y6Ye9uFIbj5QBVuyVr Pv+94cjnvyuIS+DpgZ9S/rtBANWxRJB3bOVb530+TNLmmSNJyxvZPofKRpbxX9kG9BaJ536NoFHW OnDwUojllnNNc9sNUL1gV3aF5+HvNfhZgVdd4OFVA9BHATB1w7YSMGowDVoPd5fIISARKYuOg1H9 qWya9udNW9pW1qQfj8O7pV2MJdWww3ntiWvaLTVs7Mautri0Q53qYC2uXn22my5Ro4tQl6rTdvNl anWBKpqo10RvzPjmuK7bOt8Pu6zp0sPPzCANgzxEsl/Wsh+fAn5rWEO3OwPbsq6hdEvV/Y62VZrU yM5kfAYzn8EOfgrL7S/Z7DCaTEI8maJg2oOdxyyauvZHvW4PiU4SVJV1Z1qjjnubpGOYx1WFoSob D0YpzTgdhJVHPjWEk4Hs2UoHhGyHBvUY925Zw09Blqt5Dq5RJMf1M9BTrWxU6v+sYZCz3Mq0fFId YvmljSVKhq6t5NmLEV9ei0O8Ixek93yXLiD/rbpFsiAfbnCTRGOCMDjud6HrbZBiwhrd8ZLDnV5m yTTMwzIdRioHlgqzgp3XWLOwm/6v/Q97lxI5Tfv3wkYVh/O3SgGgC3ymcQnmdwzm9YW5O/jUX5gr ufT2W2fVC2vW5TmeDIKgz2pwdh548Q2Ge736tvLVt9+sKkMPv/xmQ1kS233O19++wjK++QW4nXfm Aty3Smd3Trnm4fwDkaL5hLJwd+f4l3/gwbC/t4V/Rf4lp6D6mpNOcz+Bs/xaHMzCNBoFsZ/0zmnu DgiUAtkcRHG6mMkZXcOZdRmGsQjv5oFKgces49ksGfvp14GYohEhwjGvZucdrgEPP3pnfm79BNsE vzn9cXlZMgtNYnQhl95Lg1glSb8m379xkr7KwHZgzL72pT7xT7H/I1zv0xUz9kQF8VeSvpvq/2iZ /oV57ct5uXRfNsvyefWGg77T2x7tKFF0y2XtYer659cbgc9MjNfj9Ue+EVjbNNIt363tP5vLg4+1 7d/k8uAXTf6LLg/u7T6ytjUiz9NTqVtS29rpvEBly1Wp9mg1L0KHcgA8wUXHvZ1nT6ZLKhw4cF6v OpaSxfHXuur4FTa8bh2vdx2f5q7jE2/rV7vs+MTr+Dq3Hb/VIl7uPgxG41lwMMqjmxADOd/ibgoe W85a4sXsEpWHCYhtnBpIDyyleHsNys2ge3h8QC5F0F8ykPCLLGcFyAFCJSLBnAR5A+YF1yOkxlh9 UMRJvHmWRjN5VrpCC4T/TYTHBUsoVrBQJbnNZE1CO14zgT1bpKFn1sOIIyv342fnd/i01wUp/LL0 IclEWNhgk1aZzRFtYQqIg+UEM28E/qzRsRmIbTH+IPuUmEWddXGA0SJy0VOVzHEotvx22+viaBre UV77TNanFBkcJRkfzxSLgj8oAgVowE3waljwh4dYSn9EeWdhimfWS+ajI9yiRzp0v9kifknmc6Bp jCV/A2FQK24Ld05eFGa70yQOj0AgvdD5X8yLBuSLmvxZGvZ+78VFO/wlrOC1KkHJ/erXO/g2Ql6r EpSQyGtVgiJKXi/iuxjhdMdXRNAlNzBuslmU//BlK8pzYh8BI6+1Cb791F5rE3yXtQkUjIpb9L91 qu7Rwy+8wNeb9EsaHcB/lV8ieL1uP3je1+0r3bwNWttOuQbNte+rQVvLxbRkgVXXOXzHSn0z9l8s mVr1FZgyV0Jpw5dU3+BxKhdU6JGlbX/YKgfVDe/yBqukB7qWLpRgLV3rIfx3lOHe61up1hn9HRRh cI98nXv/RHUSypp4xQ++sJjC8suO6vbiy6+TsLRdSdmD5X1+xAIGOd8FRv4/nYfp8TLiMLpWzbXK wSoXdZ9VDYXaZg+ojFDbrCE8fMi38aJN40OM1Zm2z6mUAsjd8mIKDxXIr+UUypt5MvG1nMJK5RRe iyQ4i/tuiyRoxC1Vvp3WK6yzmTJepD88mIFfas5la7FNzmarVkgc5pIRVm1fzYzfWfkI2fAkvDVY qGPq49dyEy+/3AQ0+nCfh8Zlmh6G8/r1O+0/TJPR52UzV7u8jGCGo5mzbae1G0fuNGsygzycL5sL 9RnIzMIaX1ah+eKS8g+rnYeK4pc47rDZA0p8VP8q/Xv0xH3QSP3SXaxOlY1ZK6CHriuc3E6rYZIH UySR6hVZrfFt+saNUd9fCToeQksHQCVm2fp0GxpfPvC9tPHFCPj1Yxqg0dC0Dw2Az4k3HgQWuEp7 hcQV2j9kHWqYFae26mrU4+sroxfU7FUxvEIXNa0VutgzQy32AbNbpZs1w1W66Vm6r903nufKHdVM V+5ICutq5GFT7Qp7ZxHuar0eQCfOFFfZvOI0V+z5QIKxp/uQHXww2VhTdvqari+qXNZvHVMwq3dy yH/88Q+7LSEORp/j5HYajq9k7SOEwP9NyUgAZsE3KzIRiHkKthPpVjhxvMFwmKDpJTqtLXE6GIi/ JulnvNVB48r0pL7snMpLkKbi//lRt7P3bmtDvHGrFa2dH8lrGLpukbBeI+hz/QyaCMZj6F6JXwLp iEFEuvTRG/Ffcsy/t5TXjwow8baJcBzlAOk2yq6x6lKC14HRkBNX6O/OF+MQvzyPRtd4y2UcxBvi 4Ca6YUAfwRiGLz6m4ZU4CT4HMUCJNrj1X5NFPL7fEL0xKuwJbC78dxzwzZqDcSQG18FUAZKXZKKU 79eMRTBG64raJvMoRp2vbvqUOZYlApTae5p5OFlM+V7xFHTdq0UoDuJx+v+JT+H/hIs4NKPijudg TUy5bBoibjqNrhC2NYcA1M4sxySRFhPSHhDSudrdX+C3JL3n79stMRglePdA0icR1XH/A1J4XiAw fQV7HN6EU+hTcQdbbjNSnCqPhZNihGXEDoWbQ3y3l4bElhLKgqLatJtMEHxBB0k6GKuyTjDJUZLO Ew52IMnjVVomeQkH75FHk2gkolwG5JgtYJL/3T/6795/DMUsumwJRkenJXp4i5fvAksQf8Xr5zeh mKGcgf8PGQTOWIkGQA2VVGPJgCXXcMotLASD980lINC1ABlxeItD6r4EmxDLmfd8A0lEY7SIRzqf a7KIR7zqKL+nFzuuqHlKyBzhl2tRKLY7iLO9HXEZ5dk6zQAmm6kpZMAkAbuQOFyJK0nS6CpCdEJn 6GZWJZGFM2aIEopqoK6cWZKRMfkOCO6EJQAs7jwk+34UZhKnyOTt9u7u38V5koUb4rhFY/2lJY5H 3WlydZ1G8O2bQZ6CMFukTNV9QghsZZmYha2vED/INsPu2dv+2SbLNRJYcZhnb5yTBg6KQ9He26D9 w+nBxIJ70X7/fqtVnPi7v4OAwIn/ubUhjsJxkuIaNoCVrpPJBFhvOtWL+nNLHAY3UYzrITw5g1rT BpGVJyAD3mzwVHb1VN5VTKXT7izBYTeJR1HG1Hpoqv7Vrx3A4oApCEYYsu0MaW0bDHCAhQVlbX8W 8zQKnDHDNJjzjUK8RodE7YyJtDU4OT57o4fdrRz2/VbbRrq9xr/Avws4GLTEX4Pp+HKRZZ57RLzp o99KnZLAK3i1fwFouZf0gTO66ag5wbguhD8H8QILV8Ic95w57j7SHBUlCAxmMr8SIn8LU5LhHXW8 M0mJkzDHGgPLSUus8fLWzfoA5zUr2nukFVEGDUjqHGZFGVJfb0F71QvqbHVgQR/SYBzDHGHKG1zg UckEq+IDDIAVSsWmPjmdyWzDiB+6Z+I9D4ygN8TpKE/weq83cLv93h34L+E9VoYYGx7hs4MUm348 RkkXCmdU0NEXEZcIAvUADuJMTqO9I+cBI1lc9K4wi11QrOz9ZKXnHP48C1I82zbEYYuVng+gGeTh rZ+o53OQ2sRttYkKnZuZRKcDQe6uvZ+UY4dfyn3EqYLyNk+jKS7jvbMMEAa/BGkKdJQnctJnoAgu rmNcjlrAX6P/iVHle3MQiwNACOgAdJ4402GplY3S6BLlFhJU6dQyM7e2nJsDqWSmHRvhZs72lP0Z uxg/xlq5V6EiSqqtAx0Oo2we5LAuvKctb24/jIHWzdI6NWjf/jsSXcQIPw7vkZbPWi69wEmHKDyY g54vy9x4540cbLtmsB1gmCnpnqB7b4gLf1vBgkyV1A5ByUYlCA2yqcs1axeD43VC0Y1Lq0V8WRhy QDgCZ9vC2E7NIuBEUNP9UEKk7nH9WxTeyhU54x+MSBzJsItc5tpvB125sJK1PGDzd2uWsv937wA4 C9GczJgeUPsJ49sgnI6RLpDeNeW7u199cNhqX0Grc0DYOp45RdYGx30+DFCh2d3XC9tvzLDvn2iZ w/AOdPGppT7Jp5EKIGg9/nLeV+/T/tYTLcAu2YxBRdqlujXw3Pe3zGoq1rC3B5swyP+cXOOcYXgc jdwth2RR1rkaymQ7W6Rd7XhwczTtL5z+JTmavBKcJCxgcYU2kLeCfTzubWzRiX8ezpLckjVJjP4A lN6NyByXp0hBaR37fNrfCyzmVZzC3rZLCLTWo5b4SwALia+T6T9s/Yc8MOwZciUHGA9c0a2wlTAC EM0iDr3Bt3faXyC9n0Z4Ixr3OrwUnC8wRzgKqTgLLKfjLOfBcvyLxfgqUtxZ065ZkwOlsEJQppT/ C1XBNyp7Xsj0+VIfnwZY5+srZznd1WG9ambb3trfVkotTN2YhqBdvUGf9eYp0MYmw5LJDtasB9IJ xLrIz6XsXlmPvdhbDM42z4/6m/2tvc2t9tZ+572l2vCqtVTAmW6I6zyf//z27e3tbWuE485w2NYo melFbD98EXpoRuBqi7hpt9qwkPebGspWBxC9BTj3V9JpspKdB62EZq3n0Hj2ndbWZv+0swmT3mu/ 87aBPJBKOhli333QFI0drkcZLOZkzzKh1k32dDBYdbZCqPmCvQp8HnyO4CTEA1F8RBY9jK6inJQH cl6MlE9vOx2LHrtHrSGORx/T4Hbzlwj9UifhrfgbyBX7Lzi/QFb0Bx9OxNbm1rvNrd32u87e5p6a xLu/SwtepjQo7iRep5XLYlaMz5KCihLFMEW6cyc+vEF9o42OJrYWA+nSxb6jwqo0jAv0rFu27b7e 1H3cVOWoVmJ0hDmreh+Uc1gKpmN58B8PB1bESVuyLbTuTXv08l2m5FLQRx2PDMf8m4NxMEe/LRyT m9bLGuyLF6NpkJpp4OSOz3ofN9Nwis5ePTQgdhEyQq15Ep8JYjTpO88EsO1WG6aXw+Z/Ci6t6Ws9 QPAE91uWeK5yxFK0xda2KsI99acAf0rPgor3L47suE+peUihpwoNC063Bq6MlTwZ2FbarHx3qF6r 1U4O5TOqc2fgdN3RfXXjj3943xJGGQIlIYvGRvBQfx2gYQIiZ1Gg4iq31xjMogKhc6ryBrQTwhLn CawniMV8cQnLIziRcnkFpJFgqDET2WJ0vYHufCxISoXbornMxVQql/T9E4w0xOgb+f3F5T3Hi3Bq +Ag5KkhTKvg2DuMIGBv6Z1LO0pSBLWRdO1MSL4zHmwtoRbVVYx3p2SibCXVV0WE/C9MKHJf8KEMb BCOcyj0GuNzJtBwS/2FrA+7Y5KcydwZ8y4xK6EFbvQp52TvFqrUy/CURkMp7Ofg2+ziiSnTsHJf1 YReX5I0K058yr09LE0KIkZGUKv5pDFq19lSUxopM6R3CB2sICkWfAnF88B/qfjvIKy57x/fRucx2 kvK/OESFRAqUwjNWsSDY80usZsg0C+NlGEcjuYOq+2IaAyUjviIOionY0m/D+CZKk5j2QT4skMnz FUXIoDcUiXGFAwSucpghq4QuBF3CT5Ix/E/OGYcCi1DLJcfhFUvFcDLBC/jysJKzsoZTCCfToY2E HuWgIE8wXokPtwD30TTsKcAaemDVi2giI2hmqaaz7LaGKwzvAlL6ATpbWv0zkAPrGyJEMAAjxpLA uOMytBljuJiNiICEwO11gjF7HE4CVkuheDO+PqIitmiBBPJq4sfe8C2idw339+3oGm9XvOVtfgu2 SZiH6zbf21SkEMMJBCkd27ICMr6HhL1MZDDNNG2YOaoLmqrIJC5FCi4pUThCdLPNNSJxOUh8SsOa Tu83NB9LqsU+1Y5B5bIDqwdsBykGBJlrBIQ7lVppykUGXUGJLK64iArcLjz54eACQk/fkjCQ/BvJ swWTF+IMt0kjC1cqaTnHJlfRDXl6eTK4dUBQMUf2eaW8Dxs4JtO6LEqBD5hEV4uUd/wKqdxAsXeT qtbQdwlgb55G8SiaB1MmsTUSxes8QeKaaQhqZzTDuEQaXV3nBC8CBMBAH5FHiVW5cyUpzeRZ1wY9 RXSpVcYVTaU2InF5Mc9yzC0GUr8FcpkHacCpNzDmT/Pr+wwJwFIifqLt/AmMcB02H3E+bPZTC9RO B3ehFOlqGJXeSzIqvIsyecgRdwZwrCrICupPnLnQPzg5AD7HtGBq6zbLfmK2z+Cc363oUrqaNMSM A+AJ0H46Wvk55XIhPHe3lAWemKYAuWnjr7Al7FpGMgMgV6cEM5RJptBpFFIiKuvkBL0EmB6gUwbk +Evw2xKnMq1lzHEXekMt1OX4sag+zgQIsCWOkkVK55zO5eASstQfqQJUHFIZhtdpyCfiItMr4awK qTYEAi+kJWmQMp/AmtluWShaS5HWePqyUK0ZQZ1xWhmR6vtPyWSC/pKfaFkKpzpfRuMkpIT0t+Mo 06Y76E+boXXJSUlwPR+JEY3xwvZXFCgoGbqoL7n6DTQAVW4a0MuAMKURUQKvw++Gw/HtB0lEk+gu pAQyqiRMt47goKU9ABmewWksdQUaR9aqR1F/idnbxJZw9pD2ImvyZkbJwS01CSgg2RZ8mJRQGt+o +nVBKTJqZSxQqTQ/k4PKlkF1E7kc5yITXxRwNfoBjYxHgtpUxVJ+oQEX6aSKE5RZhBhhAi9m8Vhy KJr07nIrL6jAwDiaGWmj8BZFxEUnrEQ/H3c13Kmv5Wm2RHlOoWcWf4Qzmb8205ovcSgLMzjIE8Bt 5SoJSkHi4kpL8KkvbiPuYO/YcL7nQtVSXYVNCtBEC/VJ1j0dvP31dEA2slA0R2NRqIDnCCcl2GeA Cp6MLOCm1ikKHDgO8kDIE7l7rJF5mzQlQ3PVWjEX75dB5wokOCD9b+kmWvcrlXSXspCgOLMGnQmW A4BENL/ZM9l492wYJTYRSDwwJRf3X0toRDGfVrgSiV6LIPgcrSL9EoKwF8TEcaxvDpYSxwqEIY8d Ig4lVI3UrsCuu6Mg8ooCTx4nZP6pLWWQG0LqTzp9UklYNXwPVakme+xYni1JHbJCeY55fvpAFQdD OL3eykNMHazmMFNchiOQ1ekcx9ZeB3kO3y2QGCjZk5I+QPd26SGz8WmWI7VsJYz4zqhZonJUoCtO n3sEhs1upb3oNSzM3SZiVo1GsIJD1hEpL5edaY6gKakkZjIw5VlhXhhSwjWwdSFVVL/poHLnaEBo c4GZHHjZjMYlIN7LRmpcxJcR7HKE1YcmRdPkmaqR1JncaDRTec56itcCygm7Yz7j6aJykaJjPZym 0BL90hiM0l0qDUPL6SH7z9kVYOXnW9xacqWfqMk6VU27wm1+Ox2XHbeGTwfaBkm1I5XNkVi7WHGU yLhclanTRlMHjLJpBHg5D7NkuqD1UaqvEYJgzNkLtb+3dfQgYzcT/DsMKX7Mxha6I4oZsmu97sm6 EiQS1+1W29HnWeyTeZ6R5jdhfrVOS0yEw0MDSax77G6TOjWU6x15mY4FGY9n7vcznk3+tjLsyKZF wlGxXsvZd37E1i6OZmBgtvsV+rcsiRPJXGEyCyyMmmct5jK9T4tlOiFymdAOlJ5dSy2CpbVCqHdu wYx+liO010VXpnBLVAP2M7GWZFlnM8bIT3vvLfxD/v1OWtYpp/Qxf5g9eos8WMQznW3KL4bTwCWr p8RsTDG+3cM1UyYRI1KRdWed9bgAH0bDCWtWlguloA5nXmBOLzsQE8ME6vQpm07VVHgXzVmoYSDr kLdEcZia5rY7TctU8bZEdTrSG86nI5D3nB4LlVKMjMLJJIhAUYnkIybBus0pxxeDocY5LpCR56+o xaK82Pngb7qvUZAkBNzfQt9RZV+JFEcg2H3H67boLkwaT2pr4oVuod/t5HTYdFwAAbKt0+JgyBSF PmY0nZErKr+3GK/fGx7Byf8Z7z/AkZ9k5NcHnFwFqXyKhl6ricakHKYiw1sptDuxMtWtEeZyBGwp n4SV7ihkqBnpU5ekJEazUPtDsEsQxUocOjJM5uAqsg1H13EyTa7u9XmFEkqSqX0vRoo80vGpvisH YWDeAqR9iF5+fnYOgytyngSGpwnd+Q90JePzPTdwHCHD/StsWkRrGyd4zuQm3CKkyktgUILNAlRS YMRwMiHZkCgReE9fW0O3ilG6xLh7cI9+ylgyjskbS6cT+i1RpiLHM5Ij66W6zTwNRp/18W6+l/FN jadA+98vkckXdE5i5vKmPBznEb2jyJyAG0eHuxySF6hQQ+cMx7LM+YPrhLNgkQYc4GRhLbeAJCe5 bmw4G2rzZLCKyA3VXaxaRG15vxOgeaKcQFyFGMaY6q3Fieib/vr8k4SUqSDJnB4qDHMMIMsVYRjB do4z+aWZduwWjmjGCiOP5xKO2WeaK+4ahKMUR4iCvOVyXkRlmTLCEbkYQzrnQZ1hT/QlKRFINaiq 5bJ6peY94MV7nvYG9Mk5WJbKP9nu0pqE5khrzQSkwKHBveBHNC0+079chvpMZAMBnXT6mEHUSCoD ujkDFT6jO2F0D5D42iJvyeqEhN5dOFqgUsYHbYRVKJKUcNXexvjnIr9OMOImq8NIJOLtnbE4Dya5 LJg+BAK4T/ACaByMA/EpHwv+8DG1s4UtYKOPkjtxmMJ4G2KwwCBaZ6tDTU7zPLgNwErC3WLRxLDo z7Nr0KR+FuJPbbHX3ha77zuivbXbQQEjOh2G0NuEs2T6M5g/MLdWSnP795znhQk5wnxoeTv4fPZi ivkicidNbFvr9+qXtS6ftOZSRDKCfbynB0O31xFTAOmctxMrKKY3RkcuXkolyw9dk9NAq+uR3uQR 8vyYGk0WKcZAjawmGtJaAuahkXpNafhMKRx7wbidprlbvOkE1s0UeVWKR/iN70MK+i5zxb6cC0hW 4IZwvCFntcHyBadEYGgeWFeRDGH4GaDdXidTkgDw95wS31XgEfkrjfRFXMVHn6MYAasAlw788MOm mstIjZd3OYne0ey4As2LhQk6uKXJRrd08XwnAT9iGVqGMti0X5Lb8AZTUREkAdLbJEOSiAp5Cs3U 26Lk0rgXt8H9Bg9CbltUZhIMTkmeLJl8Yutwmg9dklI7xweQ+jVJr4JYmvgZujtH4ZwqpMdUaFCL 2fkCjAfzRJu8mErRUwVKH0i8YXgy4zVM7m5OOpXeYSRdMWxeekVI2RDyGiQBYAsDCYQIryDIFCeE yANk7UzBalsEGP+SjwlfywuwvfgKic8W5NNoFpHQNoVl8PIwJV8wASFhwK/zkHQkJAPKBOEtZRkc 3iSfQ+0iLdsOZBHYaFxYwscSG1hZDYc7Qhfj0nxCYcAa2c6K6tKxQoDeHAxEf/AG/esRU+3wlx69 /H5+0huKwWkXxPbfxMHJYfGH3snH/kmvd94/+cgTOhj8RRydnnd74rA/6H466B8PxMGnT+KvB+fn ByfDfm+wIXr/cXaO2Q2n56J/fPap3zvcAIjdTxeHCsyHC9Z9P/WP+8MejHkKQ/9NAfkbzOFgSBO5 GPTE6ZGcE4x7fKCrB/zSO+/1T8Rf+zA6woLfcZo9gnTe//jLkGaA/5KzsCYJQAnIce+8+wt8dfCh /6kPA0OHo/7wBGd/hJ3F2cH5sN+9+HRwLs4uzs9OBz1t7oBaZV8GwpB1jy+dK/crPUfA/vzpvRts L7KhpArpw/jjH/QPh3ji/B+Z0gVmhZUZ1v/wf3Sa7jZ346Pz//Tu5hGy2gB4Wec9bf+f/zrDi03t 9tbf1TC6h/pN//L/A1BLAQIUABQAAAAIABBIYi4r5i1Y1jQBAABQCAAhAAAAAAAAAAEAIAC2gQAA AABkcmFmdC1pZXRmLWlwY2RuLWRvY3MtcmZtaWJ2Ni5kb2NQSwECFAAUAAAACAAYSGIucZzcsdmZ AACb1wMAIQAAAAAAAAABACAAtoEVNQEAZHJhZnQtaWV0Zi1pcGNkbi1kb2NzLXJmbWlidjYudHh0 UEsFBgAAAAACAAIAngAAAC3PAQAAAA== ------_=_NextPart_000_01C2E0C5.FFFA2D40-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Mar 3 15:13:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11229 for ; Mon, 3 Mar 2003 15:13:24 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h23KNWC22527 for ipcdn-archive@odin.ietf.org; Mon, 3 Mar 2003 15:23:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23KNMp22518; Mon, 3 Mar 2003 15:23:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h23KMCp22458 for ; Mon, 3 Mar 2003 15:22:12 -0500 Received: from snowmass.tci.com (coral.tci.com [198.178.8.81]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11146 for ; Mon, 3 Mar 2003 15:11:33 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h23KChH2022106; Mon, 3 Mar 2003 13:13:03 -0700 (MST) Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Mon, 03 Mar 2003 13:12:19 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 3 Mar 2003 13:10:17 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0566375C@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Wijnen, Bert (Bert)'" , "IPCDN WG (E-mail)" cc: "Thomas Narten (E-mail)" , "Erik Nordmark (E-mail)" , "Randy Bush (E-mail)" , "Woundy, Richard" Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask Date: Mon, 3 Mar 2003 13:11:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 127D6891654087-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Just curious if anyone had a reaction to my email response below -- about the BPI+ MIB use of a netmask rather than a prefix for matching IPv6 multicast address... -- Rich -----Original Message----- From: Woundy, Richard Sent: Wednesday, February 19, 2003 10:04 AM To: 'Wijnen, Bert (Bert)'; IPCDN WG (E-mail) Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail) Subject: RE: [ipcdn] InetAddress or PrefixLength as a mask Bert, Since I am the person that most likely influenced the BPI+ MIB's use of a netmask rather than a prefix length, I suppose I should directly answer your question. (Of course, that makes your suggestion about putting the explanation in the DESCRIPTION clause all the wiser.) The IPv6 addressing architecture is currently defined in RFC 2373. Section 2.7 describes the format of the IPv6 multicast addresses: 8 bits of '11111111' for identification as multicast, 4 bits of 'flags', 4 bits of 'scope', and 112 bits of 'group ID'. Five scope values are defined for node-local, link-local, site-local, organization-local, and global scopes. Section 2.7.2 shows how new IPv6 multicast addresses can be assigned, making reference to RFC 2375. The draft draft-ietf-ipngwg-addr-arch-v3-11.txt, which updates RFC 2373, defines six scope values: interface-local, link-local, admin-local, site-local, organization-local, and global scopes. Some of the permanently assigned IPv6 multicast addresses appear in RFC 2375. This RFC includes all-scope addresses in section 3.0 -- these multicast address assignments apply for all IPv6 multicast scope contexts. Typically, these assignments are written as "FF0X:...". These assignments are referred to as "Variable Scope Multicast Addresses" by IANA, . As an operator, I would strongly prefer to use one row in the BPI+ MIB table to match each of these variable-scope permanently assigned addresses. I want to avoid creating five to six rows (one per defined multicast scope) or sixteen rows (one per potential multicast scope). Unfortunately, every prefix of an IPv6 multicast address that contains at least one bit of the 'group ID' MUST contain the entire 'flags' and 'scope' components. The only way to perform an address match based solely on 'group ID' while ignoring the 'scope' is to use a non-contiguous netmask. If there is a better way to accomplish this, I would love to learn about it. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Tuesday, February 18, 2003 7:13 AM To: Ipcdn (E-mail) Cc: Thomas Narten (E-mail); Erik Nordmark (E-mail); Randy Bush (E-mail) Subject: [ipcdn] InetAddress or PrefixLength as a mask During the IPCDN WG interim meeting last week I question why in docsBpi2CmtsIpMulticastMask OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "This object represents the IP multicast address mask for this row. An IP multicast address matches this row if the logical AND of the address with docsBpi2CmtsIpMulticastMask is identical to the logical AND of docsBpi2CmtsIpMulticastAddr with docsBpi2CmtsIpMulticastMask." ::= { docsBpi2CmtsIpMulticastMapEntry 5 } You specify the mask as an InetAddress and not as an InetAddressPrefixLength. I was given some explanations, but I am not 100% sure I understood and I am not 100% sure they are valid. Could the authors pls respond with an explanation (which I think should also be inclued in the DESCRIPTION clause if it is accepted). There may be other occurences of this in one ore more of your MIB documents. Thanks, Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Mar 4 11:16:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28997 for ; Tue, 4 Mar 2003 11:16:47 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h24GRKZ17405 for ipcdn-archive@odin.ietf.org; Tue, 4 Mar 2003 11:27:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GRIp17384; Tue, 4 Mar 2003 11:27:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h24GM3p17160 for ; Tue, 4 Mar 2003 11:22:03 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28826 for ; Tue, 4 Mar 2003 11:10:59 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h24GCOH2016732; Tue, 4 Mar 2003 09:12:55 -0700 (MST) Received: from 147.191.89.203 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 04 Mar 2003 09:12:52 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 4 Mar 2003 09:13:39 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC05663769@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" cc: "Jean-Francois Mule (E-mail)" , "Woundy, Richard" Date: Tue, 4 Mar 2003 09:12:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 127A0F0E64450-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] IPCDN draft updates Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I uploaded all of the recently-updated drafts of which I am aware, to . Updates include the Cable Device MIB (-05), the RFI MIB (-06), the QoS MIB (-08), the Subscriber Management MIB (-10), and the six CableHome MIBs (m-02, except for -01 of the CableHome QoS MIB). Since no PacketCable MIB updates were submitted, we may have to reconsider the meeting agenda for the IETF face-to-face discussion in San Francisco. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 5 06:36:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26905 for ; Wed, 5 Mar 2003 06:36:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25BlQI17717 for ipcdn-archive@odin.ietf.org; Wed, 5 Mar 2003 06:47:26 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BlB517700; Wed, 5 Mar 2003 06:47:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25BgM517299 for ; Wed, 5 Mar 2003 06:42:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26129; Wed, 5 Mar 2003 06:30:54 -0500 (EST) Message-Id: <200303051130.GAA26129@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, 05 Mar 2003 06:30:53 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-subscriber-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 Data Over Cable Service Interface Specification (DOCSIS) Cable Modem Termination Systems for Subscriber Management Author(s) : W. Sawyer Filename : draft-ietf-ipcdn-subscriber-mib-10.txt Pages : 28 Date : 2003-3-4 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a set of managed objects for SNMP-based management of Data-over-Cable Service Interface Specification (DOCSIS)-compliant Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. 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 author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-subscriber-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-subscriber-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-subscriber-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-3-4174227.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-subscriber-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-subscriber-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-4174227.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 5 09:32:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01442 for ; Wed, 5 Mar 2003 09:32:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25EhOf30711 for ipcdn-archive@odin.ietf.org; Wed, 5 Mar 2003 09:43:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Eh9530704; Wed, 5 Mar 2003 09:43:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Egh530676 for ; Wed, 5 Mar 2003 09:42:43 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01421 for ; Wed, 5 Mar 2003 09:31:13 -0500 (EST) From: Wilson.Sawyer@arrisi.com To: ipcdn@ietf.org X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Wed, 5 Mar 2003 09:08:05 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 03/05/2003 09:32:55 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [ipcdn] subscriber management draft -10 Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , The latest draft of the subscriber management MIB was published on the IETF lists today. This is the same version that Rich has already posted to the web site. The only changes from -09 to -10 were to change the 8-bit TosValue/TosMask to a 6-bit Dscp/Mask. The only change from -08 to -09 was to change the module name to prevent namespace conflicts between the to-be-published-someday RFC version and the already-deployed (-02?) draft. A copyright date was also fixed. The -08 draft was discussed at the interim meeting, and the summary of changes in that draft are on the www.ipcdn.org site, under [Meeting materials] for the February 13 meeting. - Wilson Sawyer _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 5 11:52:17 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12195 for ; Wed, 5 Mar 2003 11:52:17 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25H3KV13583 for ipcdn-archive@odin.ietf.org; Wed, 5 Mar 2003 12:03:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H37513540; Wed, 5 Mar 2003 12:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25Gke512742 for ; Wed, 5 Mar 2003 11:46:40 -0500 Received: from ihemail1.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11255; Wed, 5 Mar 2003 11:35:03 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h25Gb5O04011; Wed, 5 Mar 2003 11:37:05 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Mar 2003 17:37:03 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501063C22@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Wilson.Sawyer@arrisi.com, ipcdn@ietf.org Cc: bwijnen@lucent.com, "Erik Nordmark (E-mail)" , ipcdn-admin@ietf.org, "Thomas Narten (E-mail)" Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs Date: Wed, 5 Mar 2003 17:36:59 +0100 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: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: woensdag 26 februari 2003 14:28 > To: ipcdn@ietf.org > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); ipcdn-admin@ietf.org; > Thomas Narten (E-mail) > Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs > > Colleagues: > > Page 3 of RFC 3260 seems to consign the last remnants of "TOS byte" to the > dustbin of history. Consequently, per Erik & Bert's point, I'm proposing to > change docsSubMgtPktFilterTosValue and docsSubMgtPktFilterTosMask from type > OCTET STRING (SIZE(1)) to be: > > docsSubMgtPktFilterDscpValue > SYNTAX Dscp -- 0..63 RFC 3289: DIFFSERV-DSCP-TC > docsSubMgtPktFilterDscpMask > SYNTAX Dscp > So... you DO understand that this is a change on the wire, right? For MIB modules that are new (or get rerooted) that is fine. For modules that recycle or advance, that is a nono. > That is, these are now 6-bit fields instead of 8 bits. The Mask is a slight > misuse of the 'Dscp' Textual Convention, but I think it's intuitive enough. > I still do not undertstand why you need the mask for DSCP. Maybe you explained during the interim,... I either forgot or I missed it. Are you also aware of the DscpOrAny TC? > For consistency across IPCDN, there are several other MIBs > which may want to consider similar changes: > > Docsis device MIB: > docsDevFilterIpTos/Mask, docsDevFilterTosTable, ... > So this is in a MIB module where you would have to deprecate the objects and define new ones. Bert > QoS MIB > docsQosPktClassIpTosLow > docsQosPktClassIpTosHigh > docsQosPktClassIpTosMask > > PacketCable event management MTA MIB > (introduced in glossary; doesn't appear to be used) > > PacketCable Signaling MIB > pktcSigDefCallSigTos > pktcSigDefMediaStreamTos > > (I didn't look at the cablehome mibs) > > Comments? Suggestions? > > - Wilson > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 5 12:08:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13470 for ; Wed, 5 Mar 2003 12:08:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h25HJPc16450 for ipcdn-archive@odin.ietf.org; Wed, 5 Mar 2003 12:19:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25HJ9516270; Wed, 5 Mar 2003 12:19:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h25H70514329 for ; Wed, 5 Mar 2003 12:07:00 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12512; Wed, 5 Mar 2003 11:55:26 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs To: "Wijnen, Bert (Bert)" Cc: bwijnen@lucent.com, "Erik Nordmark (E-mail)" , ipcdn@ietf.org, ipcdn-admin@ietf.org, "Thomas Narten (E-mail)" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Wed, 5 Mar 2003 11:31:31 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 03/05/2003 11:57:09 AM 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: , >wilson> inline "Wijnen, Bert (Bert)" To: Wilson.Sawyer@arrisi.com, ipcdn@ietf.org , ipcdn-admin@ietf.org, "Thomas Narten (E-mail)" 03/05/03 11:36 AM Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs Inline > -----Original Message----- > From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > Sent: woensdag 26 februari 2003 14:28 > To: ipcdn@ietf.org > Cc: bwijnen@lucent.com; Erik Nordmark (E-mail); ipcdn-admin@ietf.org; > Thomas Narten (E-mail) > Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs > > Colleagues: > > Page 3 of RFC 3260 seems to consign the last remnants of "TOS byte" to the > dustbin of history. Consequently, per Erik & Bert's point, I'm proposing to > change docsSubMgtPktFilterTosValue and docsSubMgtPktFilterTosMask from type > OCTET STRING (SIZE(1)) to be: > > docsSubMgtPktFilterDscpValue > SYNTAX Dscp -- 0..63 RFC 3289: DIFFSERV-DSCP-TC > docsSubMgtPktFilterDscpMask > SYNTAX Dscp > So... you DO understand that this is a change on the wire, right? For MIB modules that are new (or get rerooted) that is fine. For modules that recycle or advance, that is a nono. >wilson> yes, submgt(-10) is unrooted at present anyway. Other mibs will have to consider this. > That is, these are now 6-bit fields instead of 8 bits. The Mask is a slight > misuse of the 'Dscp' Textual Convention, but I think it's intuitive enough. > I still do not undertstand why you need the mask for DSCP. Maybe you explained during the interim,... I either forgot or I missed it. Are you also aware of the DscpOrAny TC? >wilson> The mask could be used to select various AF classes, for example. It is also likely that some deployments are still using a non-diffserv meaning for this byte (Cisco's NetFlow?). Restricting such ad-hoc use to 6 bits doesn't seem onerous to me in order to match IETF direction, but removing the mask would be removing significant flexibility. Using DscpOrAny *with* the Mask sounds like sure confusion. > For consistency across IPCDN, there are several other MIBs > which may want to consider similar changes: > > Docsis device MIB: > docsDevFilterIpTos/Mask, docsDevFilterTosTable, ... > So this is in a MIB module where you would have to deprecate the objects and define new ones. Bert > QoS MIB > docsQosPktClassIpTosLow > docsQosPktClassIpTosHigh > docsQosPktClassIpTosMask > > PacketCable event management MTA MIB > (introduced in glossary; doesn't appear to be used) > > PacketCable Signaling MIB > pktcSigDefCallSigTos > pktcSigDefMediaStreamTos > > (I didn't look at the cablehome mibs) > > Comments? Suggestions? > > - Wilson > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Mar 6 06:33:51 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04035 for ; Thu, 6 Mar 2003 06:33:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26BipW27149 for ipcdn-archive@odin.ietf.org; Thu, 6 Mar 2003 06:44:51 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BiaO27103; Thu, 6 Mar 2003 06:44:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BcYO26439 for ; Thu, 6 Mar 2003 06:38:34 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02837; Thu, 6 Mar 2003 06:27:04 -0500 (EST) Message-Id: <200303061127.GAA02837@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, 06 Mar 2003 06:27:03 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-qos-mib-08.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 : Data Over Cable System Interface Specification Quality of Service Management Information Base (DOCSIS-QOS MIB) Author(s) : M. Patrick, W. Murwin Filename : draft-ietf-ipcdn-qos-mib-08.txt Pages : 82 Date : 2003-3-5 This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-08.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-qos-mib-08.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-qos-mib-08.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-3-5140730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-qos-mib-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-qos-mib-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140730.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Mar 6 06:34:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04073 for ; Thu, 6 Mar 2003 06:34:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h26Bj1U27198 for ipcdn-archive@odin.ietf.org; Thu, 6 Mar 2003 06:45:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BipO27156; Thu, 6 Mar 2003 06:44:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h26BccO26444 for ; Thu, 6 Mar 2003 06:38:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02856; Thu, 6 Mar 2003 06:27:08 -0500 (EST) Message-Id: <200303061127.GAA02856@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, 06 Mar 2003 06:27:08 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-docs-rfmibv2-06.txt Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP over Cable Data Network Working Group of the IETF. Title : Radio Frequency (RF) Interface Management Information Base for DOCSIS 2.0 compliant RF interfaces Author(s) : D. Raftus Filename : draft-ietf-ipcdn-docs-rfmibv2-06.txt Pages : 110 Date : 2003-3-5 This memo is a draft revision of the standards track RFC-2670. Please see 'Section 9 Changes from RFC2670' for a description of modifications. This document or its successor will obsolete RFC-2670 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS compliant Radio Frequency (RF) interfaces. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@ietf.org and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.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-docs-rfmibv2-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.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-3-5140739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-docs-rfmibv2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-docs-rfmibv2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-5140739.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 05:58:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18699 for ; Fri, 7 Mar 2003 05:58:35 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27BA3g11748 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 06:10:03 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27B9rO11703; Fri, 7 Mar 2003 06:09:53 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27B7EO10978 for ; Fri, 7 Mar 2003 06:07:14 -0500 Received: from hoemail2.firewall.lucent.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18609 for ; Fri, 7 Mar 2003 05:55:15 -0500 (EST) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h27AvI226931 for ; Fri, 7 Mar 2003 05:57:18 -0500 (EST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Mar 2003 11:57:17 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15501156B39@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Cc: bwijnen@lucent.com, "Thomas Narten (E-mail)" Date: Fri, 7 Mar 2003 11:57:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs 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 one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Good catch, Bert. The idea of a mask for the DSCP was killed some time ago in Policy Framework based on its incompatibility with the following explicit prohibition in the definition of the Differentiated Services Field: RFC 2474 Section 3, page 7 Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. John At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote: >Do Diffservers think that the following is wise and makes sense? > > docsSubMgtPktFilterDscpValue OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > matches all DSCP values. A packet matches this filter if the > following is true: > AND (FilterDscpValue, FilterDscpMask) == > AND (Packet DSCP Value, FilterDscpMask)." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 10 } > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like >to hear comments from Diffserv experts. > >Thanks, >Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 08:04:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28860 for ; Fri, 7 Mar 2003 08:04:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27DGN423394 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 08:16:23 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DG4O23360; Fri, 7 Mar 2003 08:16:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DDqO23262 for ; Fri, 7 Mar 2003 08:13:52 -0500 Received: from puffin.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28546; Fri, 7 Mar 2003 08:01:50 -0500 (EST) Received: from pcp802197pcs.nrockv01.md.comcast.net ([68.48.86.43] helo=STJOHNS-LAPTOP.mindspring.com) by puffin.mail.pas.earthlink.net with asmtp (SSLv3:DES-CBC3-SHA:168) (Exim 3.33 #1) id 18rHVw-0002ln-00; Fri, 07 Mar 2003 05:03:52 -0800 Message-Id: <5.1.0.14.2.20030307080157.02f98008@pop.mindspring.com> X-Sender: mstjohns@mindspring.com@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 07 Mar 2003 08:03:49 -0500 To: "Wijnen, Bert (Bert)" , Wilson.Sawyer@arrisi.com, ipcdn@ietf.org From: Michael StJohns Subject: RE: [ipcdn] RE: Tos field - SubMgt and other IPCDN MIBs Cc: bwijnen@lucent.com, "Erik Nordmark (E-mail)" , ipcdn-admin@ietf.org, "Thomas Narten (E-mail)" In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15501063C22@nl0006exch001u.nl .lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-ELNK-Trace: 9f6ded143da542dc9c7f779228e2f6aeda0071232e20db4d118ccc7604bea458ee6970146f5ee956350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c 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: , At 05:36 PM 3/5/2003 +0100, Wijnen, Bert (Bert) wrote: >Inline Given the long history of mucking with the TOS field, it makes little if any sense to try and define that field in terms of the current fad. Leave the field/mask as it is/was rather than trying to make it work specifically for the flavor of the day. Mike _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 08:31:29 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00952 for ; Fri, 7 Mar 2003 08:31:29 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Dh0325685 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 08:43:00 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DgKO25646; Fri, 7 Mar 2003 08:42:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27DdsO25471 for ; Fri, 7 Mar 2003 08:39:54 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00694; Fri, 7 Mar 2003 08:27:51 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs To: "Wijnen, Bert (Bert)" Cc: bwijnen@lucent.com, "Ipcdn (E-mail)" , ipcdn-admin@ietf.org, "Thomas Narten (E-mail)" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Fri, 7 Mar 2003 08:12:07 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 03/07/2003 08:29:36 AM 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: , Keep in mind we're talking about a *filter* here, not a PHB selector. And we'e not inferring bit-structure in the implementation, merely allowing the network operator to take advantage of any structure that exists. Do we really want to require the operator to install three separate filters to catch one AF class? I don't find anything in the cited paragraph that contraindicates this sort of usage. The fact that today's PHB selector set is likely to change is all the more reason to give a filter-installer some options for concise representation. - Wilson "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Sent by: Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs ipcdn-admin@ietf. org 03/07/03 05:57 AM This is one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Good catch, Bert. The idea of a mask for the DSCP was killed some time ago in Policy Framework based on its incompatibility with the following explicit prohibition in the definition of the Differentiated Services Field: RFC 2474 Section 3, page 7 Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. John At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote: >Do Diffservers think that the following is wise and makes sense? > > docsSubMgtPktFilterDscpValue OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > matches all DSCP values. A packet matches this filter if the > following is true: > AND (FilterDscpValue, FilterDscpMask) == > AND (Packet DSCP Value, FilterDscpMask)." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 10 } > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like >to hear comments from Diffserv experts. > >Thanks, >Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 09:27:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04478 for ; Fri, 7 Mar 2003 09:27:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27EdUU30930 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 09:39:30 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EdEO30918; Fri, 7 Mar 2003 09:39:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27EcYO30829 for ; Fri, 7 Mar 2003 09:38:34 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04377 for ; Fri, 7 Mar 2003 09:26:29 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h27ES3JD025610; Fri, 7 Mar 2003 07:28:03 -0700 (MST) Received: from 147.191.89.203 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 07:27:56 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 07:28:46 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC05663795@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Wilson.Sawyer@arrisi.com'" , "Wijnen, Bert (Bert)" cc: bwijnen@lucent.com, "Ipcdn (E-mail)" , "Thomas Narten (E-mail)" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 07:27:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 127673E6262523-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I think there are two issues here: are Dscp mask objects legal, and are they worthwhile? Note: in my latest DOCSIS Cable Device MIB submission (e.g. ), the new object docsDevFilterInetDscp is defined with SYNTAX DscpOrAny, with no mask object. I can't really say whether Wilson or I are correct on this topic. I agree with Wilson when he emphasizes that these Dscp objects in the various DOCSIS MIB are access filters, not PHB selectors. In fact, such objects enable the DOCSIS equipment to act precisely as "re-marking boundary nodes", which are also described in RFC 2474 Section 3, pages 8-9: The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service. Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors. On the other hand, I see the definite lack of structure in the DiffServ codepoints, and I am debating with myself whether a "Dscp mask" is worth the trouble or not. In particular, I am looking at the current codepoint assignments in , and wondering how I could optimize matching on Assured Forwarding class 1 (AF1x) using a Dscp value/mask pair. If I use Dscp value 001000 / mask 111000, I accidentally include Class Selector 1 (CS1) in the matched set. If I specifically add an "ignore" Dscp value 001000 / mask 111111 filter for CS1, then I need two Dscp value/mask filters to capture AF1x traffic -- instead of three Dscp value-only filters for AF1x traffic. This is a small savings. On the other hand, if I desire to optimize matching any of the non-default Class Selectors CS1-7, I could use an "ignore" Dscp value 000000 / mask 111111 filter for CS0, and a second Dscp value 000000 / mask 000111 filter for CS1-7. This is a significant savings compared to the seven Dscp value-only filters for CS1-7. A really tricky case is if I desire to optimize matching any Assured Forwarding or Expedited Forwarding codepoints. I might choose to use an "ignore" Dscp value 000000 / mask 000111 filter for CS0-7, and a second Dscp value 000000 / mask 000000 filter for AFxy and EF PHB. While this represents a huge savings over the thirteen Dscp value-only filters, it may capture traffic with Dscp codepoints that are not yet defined by the IETF/IANA, which represents some risk. -- Rich -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Friday, March 07, 2003 8:12 AM To: Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); ipcdn-admin@ietf.org; Thomas Narten (E-mail) Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Keep in mind we're talking about a *filter* here, not a PHB selector. And we'e not inferring bit-structure in the implementation, merely allowing the network operator to take advantage of any structure that exists. Do we really want to require the operator to install three separate filters to catch one AF class? I don't find anything in the cited paragraph that contraindicates this sort of usage. The fact that today's PHB selector set is likely to change is all the more reason to give a filter-installer some options for concise representation. - Wilson "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Sent by: Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs ipcdn-admin@ietf. org 03/07/03 05:57 AM This is one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Good catch, Bert. The idea of a mask for the DSCP was killed some time ago in Policy Framework based on its incompatibility with the following explicit prohibition in the definition of the Differentiated Services Field: RFC 2474 Section 3, page 7 Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. John At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote: >Do Diffservers think that the following is wise and makes sense? > > docsSubMgtPktFilterDscpValue OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > matches all DSCP values. A packet matches this filter if the > following is true: > AND (FilterDscpValue, FilterDscpMask) == > AND (Packet DSCP Value, FilterDscpMask)." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 10 } > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like >to hear comments from Diffserv experts. > >Thanks, >Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 10:05:46 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08414 for ; Fri, 7 Mar 2003 10:05:46 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27FHKH02471 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 10:17:20 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FH6O02445; Fri, 7 Mar 2003 10:17:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27FGeO02291 for ; Fri, 7 Mar 2003 10:16:40 -0500 Received: from titan.arrisi.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08176 for ; Fri, 7 Mar 2003 10:04:34 -0500 (EST) From: Wilson.Sawyer@arrisi.com Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs To: "Woundy, Richard" Cc: "Wijnen, Bert (Bert)" , "Ipcdn (E-mail)" , "Thomas Narten (E-mail)" X-Mailer: Lotus Notes Release 5.0.9 November 16, 2001 Message-ID: Date: Fri, 7 Mar 2003 09:45:54 -0500 X-MIMETrack: Serialize by Router on Titan/Arris(Release 5.0.9a |January 7, 2002) at 03/07/2003 10:06:20 AM 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: , Subscriber management acts as an auxiliary to the re-marking boundary: It does no re-marking itself but polices any filtering/re-marking that should have already taken place by (possibly compromised) modems. Given the nature of (primarily) residential access, I'd think that the need to carve out nuanced exceptions (your CS1 example) would be rare. - Wilson "Woundy, Richard" , omcast.com> "Wijnen, Bert (Bert)" cc: bwijnen@lucent.com, "Ipcdn (E-mail)" , 03/07/03 09:27 AM "Thomas Narten (E-mail)" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Folks, I think there are two issues here: are Dscp mask objects legal, and are they worthwhile? Note: in my latest DOCSIS Cable Device MIB submission (e.g. ), the new object docsDevFilterInetDscp is defined with SYNTAX DscpOrAny, with no mask object. I can't really say whether Wilson or I are correct on this topic. I agree with Wilson when he emphasizes that these Dscp objects in the various DOCSIS MIB are access filters, not PHB selectors. In fact, such objects enable the DOCSIS equipment to act precisely as "re-marking boundary nodes", which are also described in RFC 2474 Section 3, pages 8-9: The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service. Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors. On the other hand, I see the definite lack of structure in the DiffServ codepoints, and I am debating with myself whether a "Dscp mask" is worth the trouble or not. In particular, I am looking at the current codepoint assignments in , and wondering how I could optimize matching on Assured Forwarding class 1 (AF1x) using a Dscp value/mask pair. If I use Dscp value 001000 / mask 111000, I accidentally include Class Selector 1 (CS1) in the matched set. If I specifically add an "ignore" Dscp value 001000 / mask 111111 filter for CS1, then I need two Dscp value/mask filters to capture AF1x traffic -- instead of three Dscp value-only filters for AF1x traffic. This is a small savings. On the other hand, if I desire to optimize matching any of the non-default Class Selectors CS1-7, I could use an "ignore" Dscp value 000000 / mask 111111 filter for CS0, and a second Dscp value 000000 / mask 000111 filter for CS1-7. This is a significant savings compared to the seven Dscp value-only filters for CS1-7. A really tricky case is if I desire to optimize matching any Assured Forwarding or Expedited Forwarding codepoints. I might choose to use an "ignore" Dscp value 000000 / mask 000111 filter for CS0-7, and a second Dscp value 000000 / mask 000000 filter for AFxy and EF PHB. While this represents a huge savings over the thirteen Dscp value-only filters, it may capture traffic with Dscp codepoints that are not yet defined by the IETF/IANA, which represents some risk. -- Rich -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Friday, March 07, 2003 8:12 AM To: Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); ipcdn-admin@ietf.org; Thomas Narten (E-mail) Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Keep in mind we're talking about a *filter* here, not a PHB selector. And we'e not inferring bit-structure in the implementation, merely allowing the network operator to take advantage of any structure that exists. Do we really want to require the operator to install three separate filters to catch one AF class? I don't find anything in the cited paragraph that contraindicates this sort of usage. The fact that today's PHB selector set is likely to change is all the more reason to give a filter-installer some options for concise representation. - Wilson "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Sent by: Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs ipcdn-admin@ietf. org 03/07/03 05:57 AM This is one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Good catch, Bert. The idea of a mask for the DSCP was killed some time ago in Policy Framework based on its incompatibility with the following explicit prohibition in the definition of the Differentiated Services Field: RFC 2474 Section 3, page 7 Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. John At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote: >Do Diffservers think that the following is wise and makes sense? > > docsSubMgtPktFilterDscpValue OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > matches all DSCP values. A packet matches this filter if the > following is true: > AND (FilterDscpValue, FilterDscpMask) == > AND (Packet DSCP Value, FilterDscpMask)." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 10 } > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like >to hear comments from Diffserv experts. > >Thanks, >Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 13:44:11 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22155 for ; Fri, 7 Mar 2003 13:44:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27ItnB25793 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 13:55:49 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27ItYO25765; Fri, 7 Mar 2003 13:55:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27IgSO25273 for ; Fri, 7 Mar 2003 13:42:28 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21857; Fri, 7 Mar 2003 13:30:19 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h27IWNH1028640; Fri, 7 Mar 2003 11:32:23 -0700 (MST) Received: from 147.191.89.201 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 11:32:15 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 11:31:45 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0566379D@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'diffserv@ietf.org'" cc: "IPCDN WG (E-mail)" Subject: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 11:32:11 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12763A251179081-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Diffserv folks, I'm looking for further reaction to my email below about DOCSIS/Dscp interaction. Note that I am not subscribed to your mailing list, so please include my email address on replies. Since I sent my email below, Wilson Sawyer has sent the following reply which you might find useful: >Subscriber management acts as an auxiliary to the re-marking boundary: >It does no re-marking itself but polices any filtering/re-marking that >should have already taken place by (possibly compromised) modems. >Given the nature of (primarily) residential access, I'd think that the >need to carve out nuanced exceptions (your CS1 example) would be rare. > >- Wilson -- Rich -----Original Message----- From: Woundy, Richard Sent: Friday, March 07, 2003 9:28 AM To: 'Wilson.Sawyer@arrisi.com'; Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); Thomas Narten (E-mail) Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Folks, I think there are two issues here: are Dscp mask objects legal, and are they worthwhile? Note: in my latest DOCSIS Cable Device MIB submission (e.g. ), the new object docsDevFilterInetDscp is defined with SYNTAX DscpOrAny, with no mask object. I can't really say whether Wilson or I are correct on this topic. I agree with Wilson when he emphasizes that these Dscp objects in the various DOCSIS MIB are access filters, not PHB selectors. In fact, such objects enable the DOCSIS equipment to act precisely as "re-marking boundary nodes", which are also described in RFC 2474 Section 3, pages 8-9: The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service. Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and are outside the scope of this document. Standardized PHBs allow providers to build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors. On the other hand, I see the definite lack of structure in the DiffServ codepoints, and I am debating with myself whether a "Dscp mask" is worth the trouble or not. In particular, I am looking at the current codepoint assignments in , and wondering how I could optimize matching on Assured Forwarding class 1 (AF1x) using a Dscp value/mask pair. If I use Dscp value 001000 / mask 111000, I accidentally include Class Selector 1 (CS1) in the matched set. If I specifically add an "ignore" Dscp value 001000 / mask 111111 filter for CS1, then I need two Dscp value/mask filters to capture AF1x traffic -- instead of three Dscp value-only filters for AF1x traffic. This is a small savings. On the other hand, if I desire to optimize matching any of the non-default Class Selectors CS1-7, I could use an "ignore" Dscp value 000000 / mask 111111 filter for CS0, and a second Dscp value 000000 / mask 000111 filter for CS1-7. This is a significant savings compared to the seven Dscp value-only filters for CS1-7. A really tricky case is if I desire to optimize matching any Assured Forwarding or Expedited Forwarding codepoints. I might choose to use an "ignore" Dscp value 000000 / mask 000111 filter for CS0-7, and a second Dscp value 000000 / mask 000000 filter for AFxy and EF PHB. While this represents a huge savings over the thirteen Dscp value-only filters, it may capture traffic with Dscp codepoints that are not yet defined by the IETF/IANA, which represents some risk. -- Rich -----Original Message----- From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] Sent: Friday, March 07, 2003 8:12 AM To: Wijnen, Bert (Bert) Cc: bwijnen@lucent.com; Ipcdn (E-mail); ipcdn-admin@ietf.org; Thomas Narten (E-mail) Subject: Re: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Keep in mind we're talking about a *filter* here, not a PHB selector. And we'e not inferring bit-structure in the implementation, merely allowing the network operator to take advantage of any structure that exists. Do we really want to require the operator to install three separate filters to catch one AF class? I don't find anything in the cited paragraph that contraindicates this sort of usage. The fact that today's PHB selector set is likely to change is all the more reason to give a filter-installer some options for concise representation. - Wilson "Wijnen, Bert (Bert)" To: "Ipcdn (E-mail)" Sent by: Subject: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs ipcdn-admin@ietf. org 03/07/03 05:57 AM This is one comment I got back from Diffserv list Thanks, Bert -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: woensdag 5 maart 2003 18:29 To: Wijnen, Bert (Bert) Cc: diffserv@ietf.org Subject: Re: [Diffserv] Dscp and DscpOrAny TCs Good catch, Bert. The idea of a mask for the DSCP was killed some time ago in Policy Framework based on its incompatibility with the following explicit prohibition in the definition of the Differentiated Services Field: RFC 2474 Section 3, page 7 Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. John At 11:36 AM 3/5/2003, Wijnen, Bert (Bert) wrote: >Do Diffservers think that the following is wise and makes sense? > > docsSubMgtPktFilterDscpValue OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The Differentiated Services Code Point (DSCP) value to match > in the IP packet." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 9 } > > docsSubMgtPktFilterDscpMask OBJECT-TYPE > SYNTAX Dscp > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The mask to apply against the DSCP value to be matched in > the IP packet. The default for both these objects taken together > matches all DSCP values. A packet matches this filter if the > following is true: > AND (FilterDscpValue, FilterDscpMask) == > AND (Packet DSCP Value, FilterDscpMask)." > DEFVAL { 0 } > ::= { docsSubMgtPktFilterEntry 10 } > >It is defined in draft-ietf-ipcdn-subscriber-mib-10.txt and I'd like >to hear comments from Diffserv experts. > >Thanks, >Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 15:47:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01179 for ; Fri, 7 Mar 2003 15:47:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27KxON06934 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 15:59:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KxEO06882; Fri, 7 Mar 2003 15:59:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27KkJO05724 for ; Fri, 7 Mar 2003 15:46:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28956; Fri, 7 Mar 2003 15:34:08 -0500 (EST) Message-Id: <200303072034.PAA28956@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: Fri, 07 Mar 2003 15:34:07 -0500 Subject: [ipcdn] I-D ACTION:draft-ietf-ipcdn-device-mibv2-05.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 : Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems Author(s) : R. Woundy Filename : draft-ietf-ipcdn-device-mibv2-05.txt Pages : 87 Date : 2003-3-7 This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document will obsolete RFC-2669 when accepted. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP- based management of DOCSIS 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 author. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-device-mibv2-05.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-device-mibv2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-7150422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipcdn-device-mibv2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipcdn-device-mibv2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-7150422.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 16:23:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04990 for ; Fri, 7 Mar 2003 16:23:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27LYfU12005 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 16:34:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LYPO11843; Fri, 7 Mar 2003 16:34:25 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27LLYO10592 for ; Fri, 7 Mar 2003 16:21:34 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03663; Fri, 7 Mar 2003 16:09:20 -0500 (EST) Received: from mms01-relaya.tci.com (mms01-relaya.broadband.att.com [147.191.90.228]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h27L9sH4020710; Fri, 7 Mar 2003 14:10:35 -0700 (MST) Received: from 147.191.90.10 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 14:10:27 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 14:08:54 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637A7@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'John Schnizlein'" cc: "'diffserv@ietf.org'" , "IPCDN WG (E-mail)" Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 14:10:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277D5491200844-02-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit John, Thanks for the pointing out that the DiffServ field code points in the registry are just recommended values, not required values. Let me react to this statement, which I believe is key to the discussion about Dscp "filtering" in the DOCSIS Cable Device and Subscriber Management MIBs: >I don't appreciate the distinction. What was intended by PHB selector >was that traffic could be selected from the aggregate by the DSCP. >How is this different from filtering traffic based on DSCP matches? The key difference between "PHB selection" and "filtering" is with regards to the purpose for the matching. I understand "PHB selection" to mean packet classifiers that map traffic --based on a specific DSCP -- to a particular per hop behavior aggregate. I understand "filtering" to mean packet classifiers that condition traffic -- based on a specific DSCP value or group of values -- at the DS boundaries, by re-marking DSCP values or similar actions. This function is mentioned again in RFC 2474 section 7.1 (page 16): The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of- service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate... The same device may apply both "filtering" and "PHB selection" to its inbound traffic, in that order. The most recent version of the DOCSIS Cable Device MIB (an update of RFC 2669), , will enable the Cable Modem (CM) to filter traffic based on criteria in the new docsDevFilterInetTable, and overwrite the Dscp according to the docsDevFilterDscpTable. The DOCSIS Subscriber Management MIB, , will enable the Cable Modem Termination System (CMTS) to filter traffic based on criteria in the docsSubMgtPktFilterTable. This table enables the DOCSIS CMTS to drop traffic with illegal DSCPs that happen to elude a compromised CM. These two MIBs should define their DSCP-related objects according to best practices for their intended functionality -- hence this email. We do have a MIB in the IPCDN WG, the DOCSIS QoS MIB , in which the docsQosPktClassTable is similar to a PHB selection table. Unlike the previous two MIBs, this MIB is constrained by some outdated notions of packet selection during the DOCSIS 1.1 specification process (late '98/early '99). For example, DOCSIS 1.1 specifically calls for an IP ToS comparison: the packet's ToS is masked and compared to a range between "tos-low" and "tos-high". See Appendix C.2.1.5.1 in . This implies that this base DOCSIS 1.1 specification is going to need to be made DiffServ-aware, before the MIB can be made DiffServ-aware. I believe there is some cable operator support for such a project. -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, March 07, 2003 2:15 PM To: Woundy, Richard Cc: 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Comments embedded in context below: At 09:40 AM 3/7/2003, Woundy, Richard wrote: >I'm looking for further reaction to my email below about DOCSIS/Dscp >interaction. >... >I think there are two issues here: are Dscp mask objects legal, No. >and are they worthwhile? No. >... enable the DOCSIS equipment to act precisely as "re-marking boundary >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > The structure of the DS field shown above is incompatible with the > existing definition of the IPv4 TOS octet in [RFC791]. The > presumption is that DS domains protect themselves by deploying re- > marking boundary nodes, as should networks using the RFC 791 > Precedence designations. Correct operational procedure SHOULD follow > [RFC791], which states: "If the actual use of these precedence > designations is of concern to a particular network, it is the > responsibility of that network to control the access to, and use of, > those precedence designations." Validating the value of the DS field > at DS boundaries is sensible in any case since an upstream node can > easily set it to any arbitrary value. DS domains that are not > isolated by suitably configured boundary nodes may deliver > unpredictable service. > > Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document. > Standardized PHBs allow providers to build their services from a > well-known set of packet forwarding treatments that can be expected > to be present in the equipment of many vendors. > >On the other hand, I see the definite lack of structure in the DiffServ >codepoints, and I am debating with myself whether a "Dscp mask" is worth the >trouble or not. > >In particular, I am looking at the current codepoint assignments in >,... You may be running into a subtlety that was worried about early in defining the DiffServ field. The code points in the registry are just recommended values, not required values. While there are requirements regarding which behaviors must be supported to claim DiffServ compliance, there is no requirement that the recommended values be used to indicate these behaviors. The point is that there is no reliable structure for "the network operator to take advantage of". The presence of masks in data objects would encourage creating the sort of structure the RFC prohibits. Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): RFC 2474 section 2, page 5 Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > >Keep in mind we're talking about a *filter* here, not a PHB selector. I don't appreciate the distinction. What was intended by PHB selector was that traffic could be selected from the aggregate by the DSCP. How is this different from filtering traffic based on DSCP matches? >And we'e not inferring bit-structure in the implementation, merely >allowing the network operator to take advantage of any structure >that exists. Do we really want to require the operator to install >three separate filters to catch one AF class? > >I don't find anything in the cited paragraph that contraindicates this sort >of usage. The fact that today's PHB selector set is likely to change is all >the more reason to give a filter-installer some options for concise >representation. >... >RFC 2474 Section 3, page 7 > Implementors should note that the DSCP field is six bits wide. DS- > compliant nodes MUST select PHBs by matching against the entire 6-bit > DSCP field, e.g., by treating the value of the field as a table index > which is used to select a particular packet handling mechanism which > has been implemented in that device. The value of the CU field MUST > be ignored by PHB selection. The DSCP field is defined as an > unstructured field to facilitate the definition of future per-hop > behaviors. John _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 16:51:42 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07759 for ; Fri, 7 Mar 2003 16:51:42 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27M3Mp16456 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 17:03:22 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27M37O16418; Fri, 7 Mar 2003 17:03:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27JbYO30197 for ; Fri, 7 Mar 2003 14:37:34 -0500 Received: from motgate.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24022 for ; Fri, 7 Mar 2003 14:25:25 -0500 (EST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (Motorola/Motgate) with ESMTP id h27JRUkm017683 for ; Fri, 7 Mar 2003 12:27:30 -0700 (MST) Received: [from ma07exm01.dma.isg.mot.com (ma07exm01.dma.isg.mot.com [150.21.2.102]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id MAA24686 for ; Fri, 7 Mar 2003 12:27:30 -0700 (MST)] Received: by ma07exm01.dma.isg.mot.com with Internet Mail Service (5.5.2656.59) id <1SR76GR3>; Fri, 7 Mar 2003 14:26:40 -0500 Message-ID: <19CD0E423FC1D611893500508B6F0B9C0849B7@ma07exm01.dma.isg.mot.com> From: Murwin William-LWM008 To: "'Souheil Abihanna'" , "'mdolas@broadcom.com,'" , >, "'ipcdn@ietf.org,'" , >, "'andre.lejeune@imedia.com'" , "'docsis-oss@cablelabs.com'" Cc: Jean-Luc Dugas Date: Fri, 7 Mar 2003 14:26:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] RE: Docsis 1.1 QoS 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: , Version 7 & 8 of the QoS MIB do not compile because of the line 69: ::= { docsIfMib xx } -- xx to be assigned by IANA The QoS MIB is being rebase to a new OID branch and the root has not yet been assigned. Version 7 & 8 has have some significant changes do to the re-number of objects within this MIB, thus it is not backward compatible with version 4,5,6 etc. You can change the "xx" to be a number (i.e 7)...use at your own risk to compile the MIB. However all agents will be incompatible with this version of the MIB. Version 4 of the QoS MIB is the most commonly delopyed, you can find this on the Cable Labs Website. Will Murwin -----Original Message----- From: Souheil Abihanna [mailto:SouheilA@UniqueSys.com] Sent: Friday, March 07, 2003 2:08 PM To: 'mdolas@broadcom.com,'; >; 'ipcdn@ietf.org,'; >; 'andre.lejeune@imedia.com'; Murwin William-LWM008; 'docsis-oss@cablelabs.com' Cc: Jean-Luc Dugas Subject: Docsis 1.1 QoS Mib Hi gentlemen, I was looking on the IETF site for the DOCSIS 1.1 QoS Mib file. I found the file , but when I try to compile, it results in numerous compilation errors. Is there any place where I can find the correct Mib file? PS: I am compiling that Mib file using MG-Soft browser. Regards, ______________________________________ UNIQUE BROADBAND SYSTEMS, Inc. Souheil AbiHanna, M.Eng. Manager, Software Development 3700 Griffith, Suite 389 St-Laurent (QC) H4T 2B3 Tel: 514.344.0851 Fax:514.344.1995 _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Fri Mar 7 17:26:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10040 for ; Fri, 7 Mar 2003 17:26:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27McCI20879 for ipcdn-archive@odin.ietf.org; Fri, 7 Mar 2003 17:38:12 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Mc2O20858; Fri, 7 Mar 2003 17:38:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MbwO20826 for ; Fri, 7 Mar 2003 17:37:58 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10006; Fri, 7 Mar 2003 17:25:46 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h27MRLH2016840; Fri, 7 Mar 2003 15:27:46 -0700 (MST) Received: from 147.191.89.203 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Fri, 07 Mar 2003 15:27:40 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Fri, 7 Mar 2003 15:28:32 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637AB@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'Andrew Smith'" , diffserv@ietf.org, "IPCDN WG (E-mail)" cc: jf.mule@cablelabs.com, narten@us.ibm.com, erik.nordmark@sun.com, "'Wijnen, Bert (Bert)'" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 15:27:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1277C3561235981-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Andrew, Please keep in mind that the current Cable Device MIB is an update to RFC 2669, which pre-dates your RFC 3289 by three years. Since the publication of RFC 2669, about 20 million cable modems have been shipped, with our industry presumption that the Cable Device MIB was IETF-blessed. :^( I described the Cable Device MIB filters as "re-marking boundary nodes" using the language of RFC 2474. But the original Cable Device filters really were designed as extended access control lists for cable modems, e.g. to keep unwanted traffic off the cable network: NetBEUI, spoofed DHCP servers, etc. The filters also happen to contain IP ToS matching and overwriting capabilities. As we figure out how to update the RFC 2669 MIB, naturally we want to replace IPv4 ToS management with IPv4/v6 DSCP management... two weeks ago we start to look at RFC 3289 for the first time. :^( The Subscriber Management MIB is designed as a light-weight extension to the Cable Device MIB for Cable Modem Termination System (CMTS) filtering. That MIB separates TCP/UDP port filtering into separate filtering tables due to performance reasons. Otherwise, it is modelled after the Cable Device MIB. With all that said, the right thing to do may in fact be to adopt the DiffServ MIB for the filtering and/or classification functions in DOCSIS cable modems, particularly since: - it supports IPv6 addresses better than the filters in RFC 2669, - it supports DSCP and flow ID matching better than RFC 2669, - it supports more flexible traffic classification, and - it allows cable modems to reuse an existing IETF MIB used outside of cable. But take heed that this is a very significant change to a critical modem function used by most of the cable industry. It's going to take myself and others some time to figure out how to adopt more/all of the RFC 3289 DiffServ MIB. Here are two typical cable industry considerations: - The base DOCSIS 1.1 and 2.0 technology is not yet DiffServ-aware, since it currently relies on IP ToS masking and ranges for upstream traffic queuing. There is interest among the cable operators to start to fix this, but that may take a long time. To see what DOCSIS expects today, see Appendix C.2.1.5.1 in . - The standard DOCSIS cable modem is an inexpensive device (e.g. <$100), so simplicity of implementation is very critical. This might be satisfied by a simplified MIB compliance for DOCSIS cable modems -- if it is a real issue here. If you are volunteering to help us adopt the DiffServ MIB for DOCSIS, then I accept your help! I appreciate and support the IETF community's desire to reuse existing work. In return, please appreciate that this is changing the expectations of our IPCDN MIBs (and impacting its publication dates) yet again in a very significant way. -- Rich -----Original Message----- From: Andrew Smith [mailto:ah_smith@acm.org] Sent: Friday, March 07, 2003 4:06 PM To: Woundy, Richard; diffserv@ietf.org Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com; 'Wijnen, Bert (Bert)' Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Rich, You wrote: ... > I agree with Wilson when he emphasizes that these Dscp objects in the > various DOCSIS MIB are access filters, not PHB selectors. In fact, such > objects enable the DOCSIS equipment to act precisely as "re-marking boundary > nodes", which are also described in RFC 2474 Section 3, pages 8-9: ... If the pieces of DOCSIS equipment are acting as "re-marking boundary nodes, which are also described in RFC 2474 Section 3, pages 8-9" then shouldn't they, by definition, be implementing the IETF's existing Diffserv MIB RFC 3289 in order to control this functionality? I would hope that your WG would provide a strong argument why IETF should sanction another MIB for this same purpose when this work comes before the IESG for consideration. Andrew Smith _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Mar 10 10:58:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00303 for ; Mon, 10 Mar 2003 10:58:25 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGBRK22519 for ipcdn-archive@odin.ietf.org; Mon, 10 Mar 2003 11:11:27 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGBOO22481; Mon, 10 Mar 2003 11:11:24 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h280WbO30718 for ; Fri, 7 Mar 2003 19:32:37 -0500 Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17977; Fri, 7 Mar 2003 19:20:21 -0500 (EST) Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18rS6Y-0001nX-00; Fri, 07 Mar 2003 16:22:22 -0800 From: "Andrew Smith" To: "'Woundy, Richard'" , , "'IPCDN WG \(E-mail\)'" Cc: , , , "'Wijnen, Bert \(Bert\)'" Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Fri, 7 Mar 2003 16:24:13 -0800 Message-ID: <0ad901c2e509$0f2c40e0$1500000a@ANDREWLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <6732623D2548D61193C90002A5C88DCC056637AB@entmaexch02.broadband.att.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, Thanks for the context - it wasn't clear from the draft or the WG charter that this was an update to an earlier MIB. I appreciate the momentum that comes with 20 million deployments! My comments were aimed exclusively at the CMTS, not the modem: I think a CMTS probably has a much better chance of supporting the Diffserv MIB, which sacrifices implementation simplicity for generality in ways that seemed appropriate for Diffserv switching nodes. I would also assume that deployment of updates to CMTSs is many orders of magnitude easier than changes to modems and that backwards-compatibility with RFC 2669 is also less of an issue. Regards, Andrew Smith -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Friday, March 07, 2003 2:28 PM To: 'Andrew Smith'; diffserv@ietf.org; IPCDN WG (E-mail) Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com; 'Wijnen, Bert (Bert)' Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Andrew, Please keep in mind that the current Cable Device MIB is an update to RFC 2669, which pre-dates your RFC 3289 by three years. Since the publication of RFC 2669, about 20 million cable modems have been shipped, with our industry presumption that the Cable Device MIB was IETF-blessed. :^( I described the Cable Device MIB filters as "re-marking boundary nodes" using the language of RFC 2474. But the original Cable Device filters really were designed as extended access control lists for cable modems, e.g. to keep unwanted traffic off the cable network: NetBEUI, spoofed DHCP servers, etc. The filters also happen to contain IP ToS matching and overwriting capabilities. As we figure out how to update the RFC 2669 MIB, naturally we want to replace IPv4 ToS management with IPv4/v6 DSCP management... two weeks ago we start to look at RFC 3289 for the first time. :^( The Subscriber Management MIB is designed as a light-weight extension to the Cable Device MIB for Cable Modem Termination System (CMTS) filtering. That MIB separates TCP/UDP port filtering into separate filtering tables due to performance reasons. Otherwise, it is modelled after the Cable Device MIB. With all that said, the right thing to do may in fact be to adopt the DiffServ MIB for the filtering and/or classification functions in DOCSIS cable modems, particularly since: - it supports IPv6 addresses better than the filters in RFC 2669, - it supports DSCP and flow ID matching better than RFC 2669, - it supports more flexible traffic classification, and - it allows cable modems to reuse an existing IETF MIB used outside of cable. But take heed that this is a very significant change to a critical modem function used by most of the cable industry. It's going to take myself and others some time to figure out how to adopt more/all of the RFC 3289 DiffServ MIB. Here are two typical cable industry considerations: - The base DOCSIS 1.1 and 2.0 technology is not yet DiffServ-aware, since it currently relies on IP ToS masking and ranges for upstream traffic queuing. There is interest among the cable operators to start to fix this, but that may take a long time. To see what DOCSIS expects today, see Appendix C.2.1.5.1 in . - The standard DOCSIS cable modem is an inexpensive device (e.g. <$100), so simplicity of implementation is very critical. This might be satisfied by a simplified MIB compliance for DOCSIS cable modems -- if it is a real issue here. If you are volunteering to help us adopt the DiffServ MIB for DOCSIS, then I accept your help! I appreciate and support the IETF community's desire to reuse existing work. In return, please appreciate that this is changing the expectations of our IPCDN MIBs (and impacting its publication dates) yet again in a very significant way. -- Rich -----Original Message----- From: Andrew Smith [mailto:ah_smith@acm.org] Sent: Friday, March 07, 2003 4:06 PM To: Woundy, Richard; diffserv@ietf.org Cc: jf.mule@cablelabs.com; narten@us.ibm.com; erik.nordmark@sun.com; 'Wijnen, Bert (Bert)' Subject: RE: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Rich, You wrote: ... > I agree with Wilson when he emphasizes that these Dscp objects in the > various DOCSIS MIB are access filters, not PHB selectors. In fact, such > objects enable the DOCSIS equipment to act precisely as "re-marking boundary > nodes", which are also described in RFC 2474 Section 3, pages 8-9: ... If the pieces of DOCSIS equipment are acting as "re-marking boundary nodes, which are also described in RFC 2474 Section 3, pages 8-9" then shouldn't they, by definition, be implementing the IETF's existing Diffserv MIB RFC 3289 in order to control this functionality? I would hope that your WG would provide a strong argument why IETF should sanction another MIB for this same purpose when this work comes before the IESG for consideration. Andrew Smith _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Mar 10 10:58:27 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00316 for ; Mon, 10 Mar 2003 10:58:26 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AGBSc22532 for ipcdn-archive@odin.ietf.org; Mon, 10 Mar 2003 11:11:28 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AGBQO22496; Mon, 10 Mar 2003 11:11:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h29McpO10978 for ; Sun, 9 Mar 2003 17:38:51 -0500 Received: from albatross.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18097; Sun, 9 Mar 2003 17:25:35 -0500 (EST) Received: from user-11206ng.dsl.mindspring.com ([66.32.26.240] helo=ANDREWLAPTOP) by albatross.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 18s9Ge-0004wP-00; Sun, 09 Mar 2003 14:27:40 -0800 From: "Andrew Smith" To: "'Woundy, Richard'" Cc: , "'IPCDN WG \(E-mail\)'" Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Sun, 9 Mar 2003 14:29:33 -0800 Message-ID: <0b9701c2e68b$5bcd9ec0$1500000a@ANDREWLAPTOP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <6732623D2548D61193C90002A5C88DCC056637A7@entmaexch02.broadband.att.com> Importance: Normal Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Rich, I, and others in the Diffserv work including John, I believe, have always held a belief in a "null" or "no quality of service" PHB, aka the bit-bucket. Some of us even thought about writing a draft to describe this behaviour, recommending that its default DSCP value should be "everything else". Such a PHB implements part of the "defense against ... class of theft- and denial-of-service attacks" described by RFC 2474. With such a concept in place, there is no need for any additional filtering configuration: filtering becomes just a special case of the general Diffserv behaviour of a node. I have also argued, mostly during development of RFC 3290 in the Diffserv WG, that the QoS treatment that a packet receives is likely to be layer-independent (the differences between a L2 bridge, a L3 router, a L4-L7 load balancing switch etc. are mostly to do with the addresses on which a node makes switching/routing decisions, not the queueing treatment that packets receive). This implies that you may well need two classifiers on a packet, one to decide what QoS treatment, one to decide where to route it - the packet only goes through if both the routing and the QoS decide not to bit-bucket it. I think that "administrative bit-bucketing based on packet contents" is much more of a "QoS" thing than a "routing" thing: administrative controls on routing (e.g. BGP filters) are typically placed on the distribution of reachability of address information, not on data packet contents (other than the relevant address field(s)) themselves. Having said that, at least for nodes defending the edge of a Diffserv domain, I don't think it's worth having a purists' argument about whether bitmasks or ranges are appropriate for selecting behaviours based on DSCP fields. I think of DSCPs as just one more of the many possible fields used to classify the packet (a "Multi-Field Classifier" in Diffserv terminology): in fact you will often ignore the DSCP completely at this point if you don't trust the upstream domain to say anything reliable or useful (that is equivalent to "match 000000 with a bitmask of 000000"). It seems like it's more of an optimisation thing as to whether it really helps to be able to specify a range or mask vs. having to set out all the values explicitly. If this were a 16-bit field then I might think differently but it's really not much more work (given a suitable protocol and management information structure, of course) to have to spell out a list of 10s of discrete values, especially if you include an "everything else" case in the classifier (or possibly even a "NOT" operator in the classifier grammar). For the interior of a Diffserv domain though, I agree with Brian that ranges of DSCPs have no place. I do think it's worth arguing about whether "filters" deserve their own MIB/tables separate from "QoS". Andrew Smith -----Original Message----- From: diffserv-admin@ietf.org [mailto:diffserv-admin@ietf.org] On Behalf Of Woundy, Richard Sent: Friday, March 07, 2003 1:10 PM To: 'John Schnizlein' Cc: 'diffserv@ietf.org'; IPCDN WG (E-mail) Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs John, Thanks for the pointing out that the DiffServ field code points in the registry are just recommended values, not required values. Let me react to this statement, which I believe is key to the discussion about Dscp "filtering" in the DOCSIS Cable Device and Subscriber Management MIBs: >I don't appreciate the distinction. What was intended by PHB selector >was that traffic could be selected from the aggregate by the DSCP. >How is this different from filtering traffic based on DSCP matches? The key difference between "PHB selection" and "filtering" is with regards to the purpose for the matching. I understand "PHB selection" to mean packet classifiers that map traffic --based on a specific DSCP -- to a particular per hop behavior aggregate. I understand "filtering" to mean packet classifiers that condition traffic -- based on a specific DSCP value or group of values -- at the DS boundaries, by re-marking DSCP values or similar actions. This function is mentioned again in RFC 2474 section 7.1 (page 16): The defense against this class of theft- and denial-of-service attacks consists of the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain. DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of- service attacks based on modified codepoints, as success of any such attack indicates that the codepoints used by the attacking traffic were inappropriate... The same device may apply both "filtering" and "PHB selection" to its inbound traffic, in that order. The most recent version of the DOCSIS Cable Device MIB (an update of RFC 2669), , will enable the Cable Modem (CM) to filter traffic based on criteria in the new docsDevFilterInetTable, and overwrite the Dscp according to the docsDevFilterDscpTable. The DOCSIS Subscriber Management MIB, , will enable the Cable Modem Termination System (CMTS) to filter traffic based on criteria in the docsSubMgtPktFilterTable. This table enables the DOCSIS CMTS to drop traffic with illegal DSCPs that happen to elude a compromised CM. These two MIBs should define their DSCP-related objects according to best practices for their intended functionality -- hence this email. We do have a MIB in the IPCDN WG, the DOCSIS QoS MIB , in which the docsQosPktClassTable is similar to a PHB selection table. Unlike the previous two MIBs, this MIB is constrained by some outdated notions of packet selection during the DOCSIS 1.1 specification process (late '98/early '99). For example, DOCSIS 1.1 specifically calls for an IP ToS comparison: the packet's ToS is masked and compared to a range between "tos-low" and "tos-high". See Appendix C.2.1.5.1 in . This implies that this base DOCSIS 1.1 specification is going to need to be made DiffServ-aware, before the MIB can be made DiffServ-aware. I believe there is some cable operator support for such a project. -- Rich -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, March 07, 2003 2:15 PM To: Woundy, Richard Cc: 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Comments embedded in context below: At 09:40 AM 3/7/2003, Woundy, Richard wrote: >I'm looking for further reaction to my email below about DOCSIS/Dscp >interaction. >... >I think there are two issues here: are Dscp mask objects legal, No. >and are they worthwhile? No. >... enable the DOCSIS equipment to act precisely as "re-marking boundary >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > The structure of the DS field shown above is incompatible with the > existing definition of the IPv4 TOS octet in [RFC791]. The > presumption is that DS domains protect themselves by deploying re- > marking boundary nodes, as should networks using the RFC 791 > Precedence designations. Correct operational procedure SHOULD follow > [RFC791], which states: "If the actual use of these precedence > designations is of concern to a particular network, it is the > responsibility of that network to control the access to, and use of, > those precedence designations." Validating the value of the DS field > at DS boundaries is sensible in any case since an upstream node can > easily set it to any arbitrary value. DS domains that are not > isolated by suitably configured boundary nodes may deliver > unpredictable service. > > Nodes MAY rewrite the DS field as needed to provide a desired local > or end-to-end service. Specifications of DS field translations at DS > boundaries are the subject of service level agreements between > providers and users, and are outside the scope of this document. > Standardized PHBs allow providers to build their services from a > well-known set of packet forwarding treatments that can be expected > to be present in the equipment of many vendors. > >On the other hand, I see the definite lack of structure in the DiffServ >codepoints, and I am debating with myself whether a "Dscp mask" is worth the >trouble or not. > >In particular, I am looking at the current codepoint assignments in >,... You may be running into a subtlety that was worried about early in defining the DiffServ field. The code points in the registry are just recommended values, not required values. While there are requirements regarding which behaviors must be supported to claim DiffServ compliance, there is no requirement that the recommended values be used to indicate these behaviors. The point is that there is no reliable structure for "the network operator to take advantage of". The presence of masks in data objects would encourage creating the sort of structure the RFC prohibits. Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): RFC 2474 section 2, page 5 Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > >Keep in mind we're talking about a *filter* here, not a PHB selector. I don't appreciate the distinction. What was intended by PHB selector was that traffic could be selected from the aggregate by the DSCP. How is this different from filtering traffic based on DSCP matches? >And we'e not inferring bit-structure in the implementation, merely >allowing the network operator to take advantage of any structure >that exists. Do we really want to require the operator to install >three separate filters to catch one AF class? > >I don't find anything in the cited paragraph that contraindicates this sort >of usage. The fact that today's PHB selector set is likely to change is all >the more reason to give a filter-installer some options for concise >representation. >... >RFC 2474 Section 3, page 7 > Implementors should note that the DSCP field is six bits wide. DS- > compliant nodes MUST select PHBs by matching against the entire 6-bit > DSCP field, e.g., by treating the value of the field as a table index > which is used to select a particular packet handling mechanism which > has been implemented in that device. The value of the CU field MUST > be ignored by PHB selection. The DSCP field is defined as an > unstructured field to facilitate the definition of future per-hop > behaviors. John _______________________________________________ diffserv mailing list diffserv@ietf.org https://www1.ietf.org/mailman/listinfo/diffserv Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillis t.html _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Mar 10 17:41:00 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17814 for ; Mon, 10 Mar 2003 17:41:00 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2AMsA227373 for ipcdn-archive@odin.ietf.org; Mon, 10 Mar 2003 17:54:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMs9O27362; Mon, 10 Mar 2003 17:54:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMNdO24729 for ; Mon, 10 Mar 2003 17:23:39 -0500 Received: from motgate2.mot.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16636 for ; Mon, 10 Mar 2003 17:09:58 -0500 (EST) Received: from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h2AMD0Cq016762 for ; Mon, 10 Mar 2003 15:13:00 -0700 (MST) Received: [from ma19exm01.e2.bcs.mot.com (ma19exm01.e2.bcs.mot.com [10.14.8.10]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id PAA11579 for ; Mon, 10 Mar 2003 15:12:05 -0700 (MST)] Received: by ma19exm01.e2.bcs.mot.com with Internet Mail Service (5.5.2656.59) id <1810SAVF>; Mon, 10 Mar 2003 17:12:05 -0500 Message-ID: <62173B970AE0A044AED8723C3BCF2381018E7D99@ma19exm01.e2.bcs.mot.com> From: Li Yuanqian-MGIA0534 To: "'ipcdn@ietf.org'" Cc: Chen Weidong-MGIA0462 , Wang Daohong-MGIA0610 Date: Mon, 10 Mar 2003 17:12:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [ipcdn] A question on "docsIfCmtsModChannelType" field in "docsIfCmtsModu lationEntry" 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: During the investigation of the DOCSIS 2.0 upstream channel MIB features, we come upon a couple of questions regarding the docsIfCmtsModulationEntry of the docsIfCmtsModulationTable. The MAIN question is: 1. Should the value of "docsIfCmtsModChannelType" be the same for all the entries in a modulation table? Also, If the answer to this question is NO, then a second question would arise: 2. Should a type like "DocsisUpstreamTypeStatus" be used in the place of "DocsisUpstreamType" for the "docsIfCmtsModChannelType" field of the "docsIfCmtsModulationEntry"? If the "docsIfCmtsModChannelType" value can be configured individually for each "docsIfCmtsModulationEntry", then there seem to be no need for "tdmaAndAtdma" being among the possible choices of the values for the docsIfCmtsModChannelType. It is not that it is wrong to have "tdmaAndAtdma", it is that one can do without ever a need to use this particular value. Any help, especially to the main question, will be greatly appreciated! Jeff Li _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Mar 11 08:21:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18609 for ; Tue, 11 Mar 2003 08:21:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDYh929516 for ipcdn-archive@odin.ietf.org; Tue, 11 Mar 2003 08:34:43 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDYGO29489; Tue, 11 Mar 2003 08:34:16 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDXGO29448 for ; Tue, 11 Mar 2003 08:33:16 -0500 Received: from SCBH02.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18587 for ; Tue, 11 Mar 2003 08:19:16 -0500 (EST) Received: by SCBH02.terayon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 05:21:09 -0800 Message-ID: From: "Raftus, David" To: "'Li Yuanqian-MGIA0534'" , "'ipcdn@ietf.org'" Cc: Chen Weidong-MGIA0462 , Wang Daohong-MGIA0610 , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" Subject: RE: [ipcdn] A question on "docsIfCmtsModChannelType" field in "do csIfCmtsModu lationEntry" Date: Tue, 11 Mar 2003 05:21:01 -0800 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: , Hi Li, Please note that I have copied the applicable Docsis reflectors. Please see replies inline. Dave ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@terayon.com 613.592.1052 ext 222 ************************************ -----Original Message----- From: Li Yuanqian-MGIA0534 [mailto:jli@motorola.com] Sent: Monday, March 10, 2003 5:12 PM To: 'ipcdn@ietf.org' Cc: Chen Weidong-MGIA0462; Wang Daohong-MGIA0610 Subject: [ipcdn] A question on "docsIfCmtsModChannelType" field in "docsIfCmtsModu lationEntry" Colleagues: During the investigation of the DOCSIS 2.0 upstream channel MIB features, we come upon a couple of questions regarding the docsIfCmtsModulationEntry of the docsIfCmtsModulationTable. The MAIN question is: 1. Should the value of "docsIfCmtsModChannelType" be the same for all the entries in a modulation table? No - please see following email trail from Docsis reflector Oct/2002: -----Original Message----- From: Alberto Campos [mailto:a.campos@cablelabs.com] Sent: Monday, October 07, 2002 11:40 AM To: DOCSIS 2.0 Majordomo List; Cynthia Metsker Subject: RE: Correlation between docsIfUpChannelType and docsIfCmtsModChan nelType Hi Steve Sorry for the delay in responding Your configuration settings for operation in multiple mode is correct and will support tdma, tdmaAndAtdma and Atdma. In tdma only IUCs 9&10 are not used. In mixed mode TLV 5 is used with UCD type 2 and in DOCSIS 2.0 only case TLV 5 is used with UCD type 29 and IUCs 5&6 are not used. Your interpretation of the spec in the example described is accurate. Alberto Campos a.campos@cablelabs.com -----Original Message----- From: Steve Malenfant [mailto:smalenfant@com21.com] Sent: Monday, September 30, 2002 9:39 AM To: 'docsis-20@cablelabs.com' Subject: Correlation between docsIfUpChannelType and docsIfCmtsModChannelT ype We are having some discussion internally here, and would like to clarify things about the modulation profile. Let's take an example, expecting all parameters are good : set IUC 1 docsIfCmtsModChannelType to tdmaAndAtdma. set IUC 3 docsIfCmtsModChannelType to tdmaAndAtdma. set IUC 4 docsIfCmtsModChannelType to tdmaAndAtdma. set IUC 5 docsIfCmtsModChannelType to tdma. set IUC 6 docsIfCmtsModChannelType to tdma. set IUC 9 docsIfCmtsModChannelType to Atdma. set IUC 10 docsIfCmtsModChannelType to Atdma. Would this burst profile be good for docsIfUpChannelType tdma, tdmaAndAtdma and Atdma? tdma would only use IUC 1,3,4,5 and 6 in TLV 4 inside UCD type 2. mixed would use IUC 1,3,4,5 and 6 in TLV 4 and IUC 9 and 10 in TLV 5 inside UCD type 2. Atdma would only use IUC 1,3,4,9 and 10 in TLV 5 inside UCD type 29. Also, If the answer to this question is NO, then a second question would arise: 2. Should a type like "DocsisUpstreamTypeStatus" be used in the place of "DocsisUpstreamType" for the "docsIfCmtsModChannelType" field of the "docsIfCmtsModulationEntry"? If the "docsIfCmtsModChannelType" value can be configured individually for each "docsIfCmtsModulationEntry", then there seem to be no need for "tdmaAndAtdma" being among the possible choices of the values for the docsIfCmtsModChannelType. It is not that it is wrong to have "tdmaAndAtdma", it is that one can do without ever a need to use this particular value. Any help, especially to the main question, will be greatly appreciated! Jeff Li _______________________________________________ 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 mailnull@www1.ietf.org Tue Mar 11 08:41:41 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19018 for ; Tue, 11 Mar 2003 08:41:41 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BDtAk31094 for ipcdn-archive@odin.ietf.org; Tue, 11 Mar 2003 08:55:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDt4O31085; Tue, 11 Mar 2003 08:55:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BDsNO31031 for ; Tue, 11 Mar 2003 08:54:23 -0500 Received: from SCBH02.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18999 for ; Tue, 11 Mar 2003 08:40:19 -0500 (EST) Received: by SCBH02.terayon.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Mar 2003 05:42:20 -0800 Message-ID: From: "Raftus, David" To: =?iso-8859-1?Q?=27Jo=EBl_Demarty=27?= , "Raftus, David" Cc: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" Date: Tue, 11 Mar 2003 05:42:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7D4.063EB0D0" Subject: [ipcdn] RE: draft-ietf-ipcdn-docs-rfmibv6 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_01C2E7D4.063EB0D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joel, =20 Please see replies inline. =20 Thanks, Dave =20 ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 =20 david.raftus@terayon.com =20 613.592.1052 ext 222 ************************************ =20 =20 =20 -----Original Message----- From: Jo=EBl Demarty [mailto:jdemarty@juniper.net] Sent: Tuesday, March 11, 2003 5:58 AM To: Raftus, David Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 = Reflector (E-mail) Subject: Re: draft-ietf-ipcdn-docs-rfmibv6 =20 Hi David, I have two questions regarding the new DOCS-IF-MIB (any version, not = only v5): * 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 meaningfull 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? Note that the description for this object states, "Preamble type for = Docsis 2.0 bursts". It would be logical to deduce from this that this preamble = type is not applicable to Docsis 1.x bursts. Your statement is understood = though - a casual user not familiar with preamble usage may misunderstand = this. =20 * In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable, these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. = Another use of these objects would be to let the user configure each object of = a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate to true. But this seems = overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc = give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, = the adjusted parameters are still available for further adjustments.=20 On the other hand, this mechanism has a potential drawback because the = user decides the ifIndex of the template upstream channel entry but this = ifIndex may conflict with existing or reserved ifIndex (e.g for multiple = logical upstream channels). Given these points, I propose to have the objects = docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.=20 This methodology was arrived at after much consultation with CMTS = vendor representatives. They are indeed intended to permit the operational parameter update of a currently active channel. A clone of a currently active channel is created 'offline'. The desired parameters are = adjusted using the offline channel clone. This methodology allows the underlying software to verify the new parameters' compatibility with each other = before the snmp commit begins. This would not be possible during processing of = an snmp packet containing many SET commands. =20 Thanks, -- Jo=EBl Raftus, David wrote: Hi, Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 = to v6. The draft has been updated to incorporate editorial suggestions from = the Feb 13 IPCDN WG meeting, and is intended for last call submission. Thanks, Dave ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@terayon.com =20 613.592.1052 ext 222 ************************************ =20 =20 =20 ------_=_NextPart_001_01C2E7D4.063EB0D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Joel,

 

=

Please see replies = inline.

 

=

Thanks,<= /span>

Dave

 

=

************************************

David = Raftus

Terayon Canada = Ltd

340 Terry Fox Drive, Suite = 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com           =

613.592.1052  ext 222

************************************             &= nbsp; 

 

=  

=

-----Original Message-----
From: Jo=EBl Demarty [mailto:jdemarty@juniper.net]
Sent: Tuesday, March 11, = 2003 5:58 AM
To: Raftus, David
Cc: Ipcdn List (E-mail); = Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6

 

Hi David,

I have two questions regarding the new DOCS-IF-MIB (any version, not = only v5):

  • 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 meaningfull 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?

<dave>

Note that the = description for this object states, "Preamble type for Docsis 2.0 = bursts". It would be logical to deduce from this that this preamble type is not = applicable to Docsis 1.x bursts. Your statement is understood though - a casual = user not familiar with preamble usage may misunderstand = this.

<end = dave>

 

  • In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable, these = objects cannot be used to duplicate the configuration of an existing and = active channel because parameters like the frequency cannot be = duplicated. Another use of these objects would be to let the user configure = each object of a row independently until the parameter are compatible = with each other (valid upstream configuration) and commit the new = configuration in a single operation by setting docsIfUpChannelUpdate to true. But this seems overkill as the SNMP protocol = already allows to commit a partial or complete row change in a single = operation and all SNMP tools like UCD-snmp or SNMPc give the user the = capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the = SCDMA parameters off-line and when satisfied, asks SNMPc to commit these = new parameters in a single operation. If the commit fails, the adjusted = parameters are still available for further adjustments.
    On the other hand, this mechanism has a potential drawback because = the user decides the ifIndex = of the template upstream channel entry but this ifIndex may conflict with existing or reserved = ifIndex (e.g for multiple logical upstream = channels).
    Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 

<dave>

This methodology = was arrived at after much consultation with CMTS vendor representatives. They are = indeed intended to permit the operational parameter update of a currently = active channel. A clone of a currently active channel is created 'offline'. = The desired parameters are adjusted using the offline channel clone. This methodology allows the underlying software to verify the new = parameters' compatibility with each other before the snmp commit begins. This would = not be possible during processing of an snmp packet containing many SET = commands.

<end = dave>

 

=

Thanks,

-- Jo=EBl

Raftus, David wrote:

Hi,

Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 to v6. The draft has been updated = to incorporate editorial suggestions from the Feb 13 IPCDN WG meeting, and = is intended for last call = submission.

Thanks,

Dave

**********************************= **

David Raftus

Terayon Canada Ltd

340 Terry Fox Drive, Suite = 202

Ottawa Canada  K2K 3A2

david.raftus@terayon.com&nb= sp;         

613.592.1052&nbs= p; ext 222

****************= ********************         &nb= sp;     <= /p>

 

 

------_=_NextPart_001_01C2E7D4.063EB0D0-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Mar 11 16:52:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13854 for ; Tue, 11 Mar 2003 16:52:04 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2BM5g704252 for ipcdn-archive@odin.ietf.org; Tue, 11 Mar 2003 17:05:42 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BM5JO04225; Tue, 11 Mar 2003 17:05:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2BBBAO20703 for ; Tue, 11 Mar 2003 06:11:10 -0500 Received: from fr.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15601 for ; Tue, 11 Mar 2003 05:57:11 -0500 (EST) Received: from juniper.net by fr.juniper.net with ESMTP id LAA21841; Tue, 11 Mar 2003 11:58:22 +0100 (MET) Message-ID: <3E6DC135.2000804@juniper.net> Date: Tue, 11 Mar 2003 11:57:57 +0100 From: =?ISO-8859-1?Q?Jo=EBl_Demarty?= Organization: Juniper Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Raftus, David" CC: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" References: Content-Type: multipart/alternative; boundary="------------070006050409060002090208" Subject: [ipcdn] Re: draft-ietf-ipcdn-docs-rfmibv6 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: , --------------070006050409060002090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi David, I have two questions regarding the new DOCS-IF-MIB (any version, not only v5): * 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 meaningfull 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? * In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable, these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. Another use of these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate to true. But this seems overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, the adjusted parameters are still available for further adjustments. On the other hand, this mechanism has a potential drawback because the user decides the ifIndex of the template upstream channel entry but this ifIndex may conflict with existing or reserved ifIndex (e.g for multiple logical upstream channels). Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. Thanks, -- Joël Raftus, David wrote: > Hi, > > > > Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 > to v6. The draft has been updated to incorporate editorial suggestions > from the Feb 13 IPCDN WG meeting, and is intended for last call > submission. > > > > Thanks, > > Dave > > > > ************************************ > > /David Raftus/ > > /Terayon Canada Ltd/ > > /340 Terry Fox Drive, Suite 202/ > > /Ottawa Canada K2K 3A2/ > > / / > > /david.raftus@terayon.com / > > /613.592.1052 ext 222/ > > /************************************ / > > > > > --------------070006050409060002090208 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David,

I have two questions regarding the new DOCS-IF-MIB (any version, not only v5):
  • 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 meaningfull 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?

  • In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable, these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. Another use of these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate to true. But this seems overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, the adjusted parameters are still available for further adjustments.
    On the other hand, this mechanism has a potential drawback because the user decides the ifIndex of the template upstream channel entry but this ifIndex may conflict with existing or reserved ifIndex (e.g for multiple logical upstream channels).
    Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 
Thanks,

-- Joël

Raftus, David wrote:

Hi,

 

Please find attached an update of draft-ietf-ipcdn-docs-rfmib from v5 to v6. The draft has been updated to incorporate editorial suggestions from the Feb 13 IPCDN WG meeting, and is intended for last call submission.

 

Thanks,

Dave

 

************************************

David Raftus

Terayon Canada Ltd

340 Terry Fox Drive, Suite 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com          

613.592.1052  ext 222

************************************               

 

 



--------------070006050409060002090208-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Mar 11 18:47:50 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19164 for ; Tue, 11 Mar 2003 18:47:50 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C01VO12766 for ipcdn-archive@odin.ietf.org; Tue, 11 Mar 2003 19:01:31 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C01DO12747; Tue, 11 Mar 2003 19:01:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C00ZO12707 for ; Tue, 11 Mar 2003 19:00:35 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19151 for ; Tue, 11 Mar 2003 18:46:23 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h2BNmSH1018375; Tue, 11 Mar 2003 16:48:28 -0700 (MST) Received: from 147.191.89.203 by mms02-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 11 Mar 2003 16:48:22 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 11 Mar 2003 16:49:19 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637DD@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" cc: "Jean-Francois Mule (E-mail)" , "Woundy, Richard" Date: Tue, 11 Mar 2003 16:48:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1270AA4C357856-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Proposed IPCDN WG agenda for San Francisco IETF meeting Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here's a preliminary agenda for the IPCDN WG meeting in Atlanta. Please send suggested changes to the IPCDN mailing list and/or the co-chairs. IP over Cable Data Network WG (ipcdn) Wednesday, March 19, at 1300-1500 ================================= CHAIRS: Richard Woundy Jean-Francois Mule AGENDA: I. Agenda bashing (5 minutes) II. Review of Interim Meeting (15 minutes) February 13 meeting, Subsequent updates to DOCSIS MIBs ToS vs. DSCP discussion III. One-by-one PacketCable/IPCablecom MIB review (60 minutes; 20 minutes per draft) Management Event MIB MTA MIB Network Control Signaling MIB IV. Acceptance of CableHome MIB submissions for WG (10 minutes) Address Mapping MIB Configuration MIB Gateway Device MIB CableHome QoS MIB Security MIB Remote Diagnostic Tools MIB V. DOCSIS Set-Top Gateway Discussion (10 minutes?) Discussion TBD See VI. WG Administration (5 minutes) Re-charter progress Next steps -- Richard Woundy, IPCDN co-chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Mar 11 18:50:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19249 for ; Tue, 11 Mar 2003 18:50:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2C04BW12878 for ipcdn-archive@odin.ietf.org; Tue, 11 Mar 2003 19:04:11 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C041O12863; Tue, 11 Mar 2003 19:04:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2C03wO12836 for ; Tue, 11 Mar 2003 19:03:58 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19213 for ; Tue, 11 Mar 2003 18:49:45 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by peacock.tci.com (8.12.2/8.12.2) with ESMTP id h2BNppJD020507; Tue, 11 Mar 2003 16:51:51 -0700 (MST) Received: from 147.191.89.203 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 11 Mar 2003 16:51:40 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 11 Mar 2003 16:52:37 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056637DE@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "'IPCDN WG (E-mail)'" cc: "'Jean-Francois Mule (E-mail)'" , "Woundy, Richard" Date: Tue, 11 Mar 2003 16:51:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1270A906359435-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] RE: Proposed IPCDN WG agenda for San Francisco IETF meeting Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I forgot to mention below that I need to post an official IPCDN meeting agenda by Thursday March 13th -- so please send your comments by close of business Wednesday if at all possible. -- Rich -----Original Message----- From: Woundy, Richard Sent: Tuesday, March 11, 2003 6:48 PM To: IPCDN WG (E-mail) Cc: Jean-Francois Mule (E-mail); Woundy, Richard Subject: Proposed IPCDN WG agenda for San Francisco IETF meeting Here's a preliminary agenda for the IPCDN WG meeting in Atlanta. Please send suggested changes to the IPCDN mailing list and/or the co-chairs. IP over Cable Data Network WG (ipcdn) Wednesday, March 19, at 1300-1500 ================================= CHAIRS: Richard Woundy Jean-Francois Mule AGENDA: I. Agenda bashing (5 minutes) II. Review of Interim Meeting (15 minutes) February 13 meeting, Subsequent updates to DOCSIS MIBs ToS vs. DSCP discussion III. One-by-one PacketCable/IPCablecom MIB review (60 minutes; 20 minutes per draft) Management Event MIB MTA MIB Network Control Signaling MIB IV. Acceptance of CableHome MIB submissions for WG (10 minutes) Address Mapping MIB Configuration MIB Gateway Device MIB CableHome QoS MIB Security MIB Remote Diagnostic Tools MIB V. DOCSIS Set-Top Gateway Discussion (10 minutes?) Discussion TBD See VI. WG Administration (5 minutes) Re-charter progress Next steps -- Richard Woundy, IPCDN co-chair _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 12 09:26:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04278 for ; Wed, 12 Mar 2003 09:26:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CEeWd16082 for ipcdn-archive@odin.ietf.org; Wed, 12 Mar 2003 09:40:32 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CEeQO16077; Wed, 12 Mar 2003 09:40:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CEdBO15993 for ; Wed, 12 Mar 2003 09:39:11 -0500 Received: from SCBH02.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04236 for ; Wed, 12 Mar 2003 09:24:38 -0500 (EST) Received: by SCBH02.terayon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 06:26:30 -0800 Message-ID: From: "Raftus, David" To: =?iso-8859-1?Q?=27Jo=EBl_Demarty=27?= , "Raftus, David" Cc: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" Date: Wed, 12 Mar 2003 06:26:31 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8A3.605CE850" Subject: [ipcdn] RE: draft-ietf-ipcdn-docs-rfmibv6 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_01C2E8A3.605CE850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joel, =20 The methodology can be used for non-scdma parameters. Its necessity was inspired by the number of scdma parameters, but it can certainly be = used by other channel types. =20 Please note that these objects are not new - they were introduced by = draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by oss2-n-02016 = on Feb 27/02 - significantly predates the first 2.0 qualification. They = remain optional for 1.1 CMTSs. =20 Thanks, Dave =20 ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 =20 david.raftus@terayon.com =20 613.592.1052 ext 222 ************************************ =20 =20 =20 -----Original Message----- From: Jo=EBl Demarty [mailto:jdemarty@juniper.net] Sent: Wednesday, March 12, 2003 9:08 AM To: Raftus, David Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 = Reflector (E-mail) Subject: Re: draft-ietf-ipcdn-docs-rfmibv6 =20 Thanks David for your detailed answers. See my comments/questions = below. -- Jo=EBl * In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable, these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. = Another use of these objects would be to let the user configure each object of = a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate to true. But this seems = overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc = give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, = the adjusted parameters are still available for further adjustments.=20 On the other hand, this mechanism has a potential drawback because the = user decides the ifIndex of the template upstream channel entry but this = ifIndex may conflict with existing or reserved ifIndex (e.g for multiple = logical upstream channels). Given these points, I propose to have the objects = docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.=20 This methodology was arrived at after much consultation with CMTS = vendor representatives. They are indeed intended to permit the operational parameter update of a currently active channel. A clone of a currently active channel is created 'offline'. The desired parameters are = adjusted using the offline channel clone. This methodology allows the underlying software to verify the new parameters' compatibility with each other = before the snmp commit begins. This would not be possible during processing of = an snmp packet containing many SET commands. =20 According to your explanations, these 2 objects are defined only as a convenience for the CMTS vendors because no technical issue prevents to implement a CMTS that would be capable of "verifying the new = parameters' compatibility with each other before the SNMP commit begins".=20 Moreover, if you read the DESCRIPTION clause of these 2 objects, it is written that "[these objects] may also be used at the vendor's = discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, these objects are either optional or useless because the MIB only requires = the transfer of SCDMA parameters.=20 This means that this clone mechanism is not usable as is from an NMS viewpoint because it cannot be used consistently on every type of = upstream channels. So we should either make these objects mandatory for all = non-SCDMA parameters and channel types or simply make these objects optional and supported at the CMTS vendor's discretion. As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.=20 Thanks, -- Jo=EBl ------_=_NextPart_001_01C2E8A3.605CE850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Joel,

 

=

The methodology can be used for non-scdma parameters. Its necessity was = inspired by the number of scdma parameters, but it can certainly be used by other = channel types.

 

=

Please note that these objects are not new - they were introduced by draft v2 of = the rf mib, and were made mandatory for 2.0 CMTSs by oss2-n-02016 on Feb 27/02 = - significantly predates the first 2.0 qualification. They remain = optional for 1.1 CMTSs.

 

=

Thanks,<= /span>

Dave

 

=

************************************

David = Raftus

Terayon Canada = Ltd

340 Terry Fox Drive, Suite = 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com           =

613.592.1052  ext 222

************************************             &= nbsp; 

 

=  

=

-----Original Message-----
From: Jo=EBl Demarty [mailto:jdemarty@juniper.net]
Sent: Wednesday, March = 12, 2003 9:08 AM
To: Raftus, David
Cc: Ipcdn List (E-mail); = Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6

 

Thanks David for your = detailed answers. See my comments/questions below.
-- Jo=EBl


=B7         In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. = Contrary to the usmUserCloneFrom object = in usmUserTable, these objects cannot be used to duplicate the = configuration of an existing and active channel because parameters like the frequency = cannot be duplicated. Another use of these objects would be to let the user = configure each object of a row independently until the parameter are compatible = with each other (valid upstream configuration) and commit the new configuration = in a single operation by setting docsIfUpChannelUpdate to true. = But this seems overkill as the SNMP protocol already allows to commit a partial = or complete row change in a single operation and all SNMP tools like = UCD-snmp or SNMPc give the user the capacity to modify parameters independently and = commit the change in a single operation. If you take the example of SNMPc, you = can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit = these new parameters in a single operation. If the commit fails, the adjusted parameters are still available for further adjustments.
On the other hand, this mechanism has a potential drawback because the = user decides the ifIndex of the template = upstream channel entry but this ifIndex = may conflict with existing or reserved ifIndex = (e.g for multiple logical upstream channels).
Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 

<dave>

This methodology was arrived at after much consultation with = CMTS vendor representatives. They are indeed intended to permit the = operational parameter update of a currently active channel. A clone of a currently = active channel is created 'offline'. The desired parameters are adjusted using = the offline channel clone. This methodology allows the underlying software = to verify the new parameters' compatibility with each other before the = snmp commit begins. This would not be possible during processing of an snmp packet containing many SET = commands.

<end dave>

 

=

According to your explanations, these 2 objects are defined only as a convenience = for the CMTS vendors because no technical issue prevents to implement a CMTS = that would be capable of "verifying the new parameters' compatibility with = each other before the SNMP commit begins".

Moreover, if you read the DESCRIPTION clause of these 2 objects, it is = written that "[these objects] may also be used at the vendor's discretion = for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, = these objects are either optional or useless because the MIB only requires = the transfer of SCDMA parameters.

This means that this clone mechanism is not usable as is from an NMS = viewpoint because it cannot be used consistently on every type of upstream = channels. So we should either make these objects mandatory for all non-SCDMA = parameters and channel types or simply make these objects optional and supported at = the CMTS vendor's discretion.

As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.

Thanks,

-- Jo=EBl<= /font>

------_=_NextPart_001_01C2E8A3.605CE850-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 12 12:45:23 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13154 for ; Wed, 12 Mar 2003 12:45:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CHxPZ31188 for ipcdn-archive@odin.ietf.org; Wed, 12 Mar 2003 12:59:25 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHx4O31152; Wed, 12 Mar 2003 12:59:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHvMO30985 for ; Wed, 12 Mar 2003 12:57:22 -0500 Received: from SCBH02.terayon.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12892 for ; Wed, 12 Mar 2003 12:42:45 -0500 (EST) Received: by SCBH02.terayon.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Mar 2003 09:44:34 -0800 Message-ID: From: "Raftus, David" To: =?iso-8859-1?Q?=27Jo=EBl_Demarty=27?= , "Raftus, David" Cc: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" Date: Wed, 12 Mar 2003 09:44:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8BF.0C26C460" Subject: [ipcdn] RE: draft-ietf-ipcdn-docs-rfmibv6 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_01C2E8BF.0C26C460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Joel, =20 When the 'offline' row is created through the cloning procedure, all = values of the active row being cloned are copied to the inactive row. After necessary adjustments, all values will be used to update the active = row. Perhaps I'm missing something, but I don't see why a 'minimum set of parameters' would be applicable. =20 If you feel a behavior clarification ecr would be appropriate, by all = means please proceed. =20 Thanks, Dave =20 ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 =20 david.raftus@terayon.com =20 613.592.1052 ext 222 ************************************ =20 =20 =20 -----Original Message----- From: Jo=EBl Demarty [mailto:jdemarty@juniper.net] Sent: Wednesday, March 12, 2003 12:20 PM To: Raftus, David Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 = Reflector (E-mail) Subject: Re: draft-ietf-ipcdn-docs-rfmibv6 =20 Thanks David,=20 I cannot but accept your points, but, still, you are not answering the questions and arguments of my previous email.=20 Anyway, I'm definitely not convinced that the spec should stay as it = is. For instance, the spec is vague about the minimum set of parameters that = the CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. = Only those starting with docsIfUpChannelScdma or all parameters defining an = SCDMA channel, like the channel width? Then what about the frequency?=20 Definitely, this clone mechanism is sophisticated enough that it would deserve a more detailed specification (and testing) and, as a = consequence, an ECR. -- Jo=EBl Raftus, David wrote: Hi Joel, The methodology can be used for non-scdma parameters. Its necessity was inspired by the number of scdma parameters, but it can certainly be = used by other channel types. Please note that these objects are not new - they were introduced by = draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by oss2-n-02016 = on Feb 27/02 - significantly predates the first 2.0 qualification. They = remain optional for 1.1 CMTSs. Thanks, Dave ************************************ David Raftus Terayon Canada Ltd 340 Terry Fox Drive, Suite 202 Ottawa Canada K2K 3A2 david.raftus@terayon.com =20 613.592.1052 ext 222 ************************************ =20 =20 -----Original Message----- From: Jo=EBl Demarty [ mailto:jdemarty@juniper.net ] Sent: Wednesday, March 12, 2003 9:08 AM To: Raftus, David Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 = Reflector (E-mail) Subject: Re: draft-ietf-ipcdn-docs-rfmibv6 Thanks David for your detailed answers. See my comments/questions = below. -- Jo=EBl In docsIfUpstreamChannelTable, can you help me understand the benefit = of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate objects. Contrary to = the usmUserCloneFrom object in usmUserTable,these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. Another use of = these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate totrue. But this seems = overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc = give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, = the adjusted parameters are still available for further adjustments.=20 On the other hand, this mechanism has a potential drawback because the = user decides the ifIndex of the template upstream channel entry but this = ifIndex may conflict with existing or reserved ifIndex (e.g for multiple = logical upstream channels). Given these points, I propose to have the objects = docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.=20 This methodology was arrived at after much consultation with CMTS = vendor representatives. They are indeed intended to permit the operational parameter update of a currently active channel. A clone of a currently active channel is created 'offline'. The desired parameters are = adjusted using the offline channel clone. This methodology allows the underlying software to verify the new parameters' compatibility with each other = before the snmp commit begins. This would not be possible during processing of = an snmp packet containing many SET commands. According to your explanations, these 2 objects are defined only as a convenience for the CMTS vendors because no technical issue prevents to implement a CMTS that would be capable of "verifying the new = parameters' compatibility with each other before the SNMP commit begins".=20 Moreover, if you read the DESCRIPTION clause of these 2 objects, it is written that "[these objects] may also be used at the vendor's = discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, these objects are either optional or useless because the MIB only requires = the transfer of SCDMA parameters.=20 This means that this clone mechanism is not usable as is from an NMS viewpoint because it cannot be used consistently on every type of = upstream channels. So we should either make these objects mandatory for all = non-SCDMA parameters and channel types or simply make these objects optional and supported at the CMTS vendor's discretion. As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.=20 Thanks, -- Jo=EBl =20 ------_=_NextPart_001_01C2E8BF.0C26C460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Joel,

 

=

When the 'offline' row is created through the cloning procedure, all values of = the active row being cloned are copied to the inactive row. After necessary adjustments, all values will be used to update the active row. Perhaps = I'm missing something, but I don't see why a 'minimum set of parameters' = would be applicable.

 

=

If you feel a behavior clarification ecr would be appropriate, by all means please = proceed.

 

=

Thanks,<= /span>

Dave

 

=

************************************

David = Raftus

Terayon Canada = Ltd

340 Terry Fox Drive, Suite = 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com           =

613.592.1052  ext 222

************************************             &= nbsp; 

 

=  

=

-----Original Message-----
From: Jo=EBl Demarty [mailto:jdemarty@juniper.net]
Sent: Wednesday, March = 12, 2003 12:20 PM
To: Raftus, David
Cc: Ipcdn List (E-mail); = Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6

 

Thanks David,

I cannot but accept your points, but, still, you are not answering the questions and arguments of my previous email.

Anyway, I'm definitely not convinced that the spec should stay as it = is. For instance, the spec is vague about the minimum set of parameters that = the CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. Only = those starting with docsIfUpChannelScdma or all parameters defining an SCDMA channel, like the channel width? Then = what about the frequency?
Definitely, this clone mechanism is sophisticated enough that it would = deserve a more detailed specification (and testing) and, as a consequence, an = ECR.

-- Jo=EBl

Raftus, David wrote:

Hi = Joel,

The methodology can be used for non-scdma = parameters. Its necessity was inspired by the number of scdma parameters, but it = can certainly be used by other channel = types.

Please note that these objects are not new - = they were introduced by draft v2 of the rf mib, and were made mandatory for 2.0 = CMTSs by oss2-n-02016 on Feb 27/02 - significantly predates the first 2.0 = qualification. They remain optional for 1.1 = CMTSs.

Thanks,

Dave

**********************************= **

David Raftus

Terayon Canada Ltd

340 Terry Fox Drive, Suite = 202

Ottawa Canada  K2K 3A2

david.raftus@terayon.com&nb= sp;         

613.592.1052&nbs= p; ext 222

****************= ********************         &nb= sp;     <= /p>

=  

-----Original Message-----
From: Jo=EBl Demarty [mailto:jdemarty@juniper.net] Sent: Wednesday, March = 12, 2003 9:08 AM
To: Raftus, David
Cc: Ipcdn List (E-mail); = Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: = draft-ietf-ipcdn-docs-rfmibv6

Thanks David for your detailed answers. See my = comments/questions below.
-- Jo=EBl


In = docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom = object in usmUserTable,these = objects cannot be used to duplicate the configuration of an existing and active = channel because parameters like the frequency cannot be duplicated. Another use = of these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single = operation by setting docsIfUpChannelUpdate = totrue. But this seems overkill as the SNMP protocol already = allows to commit a partial or complete row change in a single operation and = all SNMP tools like UCD-snmp or SNMPc give the user the capacity to modify = parameters independently and commit the change in a single operation. If you take = the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single = operation. If the commit fails, the adjusted parameters are still available for = further adjustments.
On the other hand, this mechanism has a potential drawback because the = user decides the ifIndex of the template = upstream channel entry but this ifIndex = may conflict with existing or reserved ifIndex = (e.g for multiple logical upstream channels).
Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 

<dave>=

This methodology was arrived at after much consultation with = CMTS vendor representatives. They are indeed intended to permit the = operational parameter update of a currently active channel. A clone of a currently = active channel is created 'offline'. The desired parameters are adjusted using = the offline channel clone. This methodology allows the underlying software = to verify the new parameters' compatibility with each other before the = snmp commit begins. This would not be possible during processing of an snmp packet containing many SET = commands.

<end = dave>

Accordin= g to your explanations, these 2 objects are defined only as a convenience = for the CMTS vendors because no technical issue prevents to implement a CMTS = that would be capable of "verifying the new parameters' compatibility with = each other before the SNMP commit begins".

Moreover, if you read the DESCRIPTION clause of these 2 objects, it is = written that "[these objects] may also be used at the vendor's discretion = for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, = these objects are either optional or useless because the MIB only requires = the transfer of SCDMA parameters.

This means that this clone mechanism is not usable as is from an NMS = viewpoint because it cannot be used consistently on every type of upstream = channels. So we should either make these objects mandatory for all non-SCDMA = parameters and channel types or simply make these objects optional and supported at = the CMTS vendor's discretion.

As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.

Thanks,

-- Jo=EBl

 

------_=_NextPart_001_01C2E8BF.0C26C460-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 12 17:59:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27384 for ; Wed, 12 Mar 2003 17:59:30 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNDda24249 for ipcdn-archive@odin.ietf.org; Wed, 12 Mar 2003 18:13:39 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNDMO24221; Wed, 12 Mar 2003 18:13:22 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNCGO24152 for ; Wed, 12 Mar 2003 18:12:16 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27264 for ; Wed, 12 Mar 2003 17:57:36 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h2CMxgH1013940; Wed, 12 Mar 2003 15:59:42 -0700 (MST) Received: from 147.191.89.203 by mms01-relayb.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 12 Mar 2003 15:59:37 -0600 Received: by entexchimc01.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 12 Mar 2003 16:00:35 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC06B9ADD5@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" cc: "Jean-Francois Mule (E-mail)" , "Woundy, Richard" Date: Wed, 12 Mar 2003 15:59:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 127164531684092-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Jabber at IPCDN meeting in San Francisco Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I am curious whether our WG would like to take advantage of the jabber text conferencing service as described below (thanks to Marshall Rose and others) during the IPCDN WG meeting next week. The jabber service will automatically collect a "conference log" that we can use as the source material for our WG meeting minutes. I need to know two things: 1. Is anyone interested in remote participation through jabber? 2. Who will be willing to act as jabber scribe during the meeting? Please let me know as soon as possible if you would listen in on a jabber session from the WG meeting, so I can be sure to identify a scribe and get copies of presentations posted on for remote viewing. You probably ought to test your network connectivity to a jabber server *before* you indicate your interest in remote participation. Note that your access to jabber servers may be blocked by your corporate firewall, for example. -- Rich Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ NOTE: the logging facility will not be active until later this week... ####### _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 12 17:59:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27397 for ; Wed, 12 Mar 2003 17:59:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNDeu24262 for ipcdn-archive@odin.ietf.org; Wed, 12 Mar 2003 18:13:40 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNDQO24238; Wed, 12 Mar 2003 18:13:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNCJO24157 for ; Wed, 12 Mar 2003 18:12:19 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27267; Wed, 12 Mar 2003 17:57:39 -0500 (EST) Received: from mms02-RelayB.tci.com (mms02-relayb.broadband.att.com [147.191.89.213]) by snowmass.tci.com (8.12.2/8.12.2) with ESMTP id h2CMxjH1013961; Wed, 12 Mar 2003 15:59:46 -0700 (MST) Received: from 147.191.90.10 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 12 Mar 2003 15:59:38 -0600 Received: by entexchimc03.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 12 Mar 2003 15:58:03 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC06B9ADD2@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "Brian E Carpenter" , "'diffserv@ietf.org'" cc: "IPCDN WG (E-mail)" , "Woundy, Richard" Subject: RE: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs Date: Wed, 12 Mar 2003 15:59:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 12716450483534-02-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brian (and many diffserv folks), Thanks for your input and of the diffserv WG. I will assume that our IPCDN MIBs need to use explicit DSCP values and not use DSCP masks. Please forgive this question for my DiffServ education. I have heard several times that "network operators are free to ignore the recommended code points", and that this is a major reason why we should not use DSCP masks. What benefits does a network operator achieve with an unstructured set of DSCPs? In fact, I *am* a network operator -- I work for Comcast Cable, which has lots of regional networks and millions of residential cable modem subscribers. I see the pain associated with network management of my boundary nodes with unstructured DSCP assignments. Where's the benefit to me? I don't mind if folks take this question off-list, or if folks refer me to specific diffserv mail archives (e.g. a specific "thread" name) where this was already discussed. Just as long as I am not mistaken as a spammer. ;^) -- Rich -----Original Message----- From: Brian E Carpenter [mailto:brian@hursley.ibm.com] Sent: Saturday, March 08, 2003 6:59 AM To: John Schnizlein Cc: Woundy, Richard; 'diffserv@ietf.org' Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs What John writes is definitive. Masking DSCPs is simply wrong. The fact that the recommended AF code points happen to be numerically consecutive is just an accident of the code point assignment process; the bit positions are not significant, and network operators are free to ignore the recommended code points if they want to. Brian John Schnizlein wrote: > > Comments embedded in context below: > > At 09:40 AM 3/7/2003, Woundy, Richard wrote: > > >I'm looking for further reaction to my email below about DOCSIS/Dscp > >interaction. > >... > >I think there are two issues here: are Dscp mask objects legal, > > No. > > >and are they worthwhile? > > No. > > >... enable the DOCSIS equipment to act precisely as "re-marking boundary > >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > > > The structure of the DS field shown above is incompatible with the > > existing definition of the IPv4 TOS octet in [RFC791]. The > > presumption is that DS domains protect themselves by deploying re- > > marking boundary nodes, as should networks using the RFC 791 > > Precedence designations. Correct operational procedure SHOULD follow > > [RFC791], which states: "If the actual use of these precedence > > designations is of concern to a particular network, it is the > > responsibility of that network to control the access to, and use of, > > those precedence designations." Validating the value of the DS field > > at DS boundaries is sensible in any case since an upstream node can > > easily set it to any arbitrary value. DS domains that are not > > isolated by suitably configured boundary nodes may deliver > > unpredictable service. > > > > Nodes MAY rewrite the DS field as needed to provide a desired local > > or end-to-end service. Specifications of DS field translations at DS > > boundaries are the subject of service level agreements between > > providers and users, and are outside the scope of this document. > > Standardized PHBs allow providers to build their services from a > > well-known set of packet forwarding treatments that can be expected > > to be present in the equipment of many vendors. > > > >On the other hand, I see the definite lack of structure in the DiffServ > >codepoints, and I am debating with myself whether a "Dscp mask" is worth the > >trouble or not. > > > >In particular, I am looking at the current codepoint assignments in > >,... > > You may be running into a subtlety that was worried about early in > defining the DiffServ field. The code points in the registry are > just recommended values, not required values. While there are > requirements regarding which behaviors must be supported to claim > DiffServ compliance, there is no requirement that the recommended > values be used to indicate these behaviors. > > The point is that there is no reliable structure for "the network > operator to take advantage of". The presence of masks in data objects > would encourage creating the sort of structure the RFC prohibits. > > Note the distinction between the SHOULD regarding values, and the MUST regarding treating the value as a unit (copied farther below): > > RFC 2474 section 2, page 5 > Codepoint: a specific value of the DSCP portion of the DS field. > Recommended codepoints SHOULD map to specific, standardized PHBs. > > >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > >Keep in mind we're talking about a *filter* here, not a PHB selector. > > I don't appreciate the distinction. What was intended by PHB selector > was that traffic could be selected from the aggregate by the DSCP. > How is this different from filtering traffic based on DSCP matches? > > >And we'e not inferring bit-structure in the implementation, merely > >allowing the network operator to take advantage of any structure > >that exists. Do we really want to require the operator to install > >three separate filters to catch one AF class? > > > >I don't find anything in the cited paragraph that contraindicates this sort > >of usage. The fact that today's PHB selector set is likely to change is all > >the more reason to give a filter-installer some options for concise > >representation. > >... > >RFC 2474 Section 3, page 7 > > Implementors should note that the DSCP field is six bits wide. DS- > > compliant nodes MUST select PHBs by matching against the entire 6-bit > > DSCP field, e.g., by treating the value of the field as a table index > > which is used to select a particular packet handling mechanism which > > has been implemented in that device. The value of the CU field MUST > > be ignored by PHB selection. The DSCP field is defined as an > > unstructured field to facilitate the definition of future per-hop > > behaviors. > > John _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 12 18:17:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29253 for ; Wed, 12 Mar 2003 18:17:10 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNVJq25302 for ipcdn-archive@odin.ietf.org; Wed, 12 Mar 2003 18:31:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNV3O25268; Wed, 12 Mar 2003 18:31:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CEKnO14712 for ; Wed, 12 Mar 2003 09:20:49 -0500 Received: from fr.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03844 for ; Wed, 12 Mar 2003 09:06:18 -0500 (EST) Received: from juniper.net by fr.juniper.net with ESMTP id PAA16473; Wed, 12 Mar 2003 15:07:53 +0100 (MET) Message-ID: <3E6F3F38.1060309@juniper.net> Date: Wed, 12 Mar 2003 15:07:52 +0100 From: =?ISO-8859-1?Q?Jo=EBl_Demarty?= Organization: Juniper Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Raftus, David" CC: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" References: Content-Type: multipart/alternative; boundary="------------050509050101080806030201" Subject: [ipcdn] Re: draft-ietf-ipcdn-docs-rfmibv6 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: , --------------050509050101080806030201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks David for your detailed answers. See my comments/questions below. -- Joël > * In docsIfUpstreamChannelTable, can you help me understand the > benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate > objects. Contrary to the usmUserCloneFrom object in > usmUserTable, these objects cannot be used to duplicate the > configuration of an existing and active channel because > parameters like the frequency cannot be duplicated. Another use > of these objects would be to let the user configure each object > of a row independently until the parameter are compatible with > each other (valid upstream configuration) and commit the new > configuration in a single operation by setting > docsIfUpChannelUpdate to true. But this seems overkill as the > SNMP protocol already allows to commit a partial or complete row > change in a single operation and all SNMP tools like UCD-snmp or > SNMPc give the user the capacity to modify parameters > independently and commit the change in a single operation. If > you take the example of SNMPc, you can adjust the SCDMA > parameters off-line and when satisfied, asks SNMPc to commit > these new parameters in a single operation. If the commit fails, > the adjusted parameters are still available for further > adjustments. > On the other hand, this mechanism has a potential drawback > because the user decides the ifIndex of the template upstream > channel entry but this ifIndex may conflict with existing or > reserved ifIndex (e.g for multiple logical upstream channels). > Given these points, I propose to have the objects > docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for > DOCSIS 2.0 CMTS. > > > > This methodology was arrived at after much consultation with CMTS > vendor representatives. They are indeed intended to permit the > operational parameter update of a currently active channel. A clone of > a currently active channel is created 'offline'. The desired > parameters are adjusted using the offline channel clone. This > methodology allows the underlying software to verify the new > parameters' compatibility with each other before the snmp commit > begins. This would not be possible during processing of an snmp packet > containing many SET commands. > > > > > According to your explanations, these 2 objects are defined only as a convenience for the CMTS vendors because no technical issue prevents to implement a CMTS that would be capable of "verifying the new parameters' compatibility with each other before the SNMP commit begins". Moreover, if you read the DESCRIPTION clause of these 2 objects, it is written that "[these objects] may also be used at the vendor's discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, these objects are either optional or useless because the MIB only requires the transfer of SCDMA parameters. This means that this clone mechanism is not usable as is from an NMS viewpoint because it cannot be used consistently on every type of upstream channels. So we should either make these objects mandatory for all non-SCDMA parameters and channel types or simply make these objects optional and supported at the CMTS vendor's discretion. As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. Thanks, -- Joël --------------050509050101080806030201 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks David for your detailed answers. See my comments/questions below.
-- Joël

  • In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom and docsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable, these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. Another use of these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate to true. But this seems overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, the adjusted parameters are still available for further adjustments.
    On the other hand, this mechanism has a potential drawback because the user decides the ifIndex of the template upstream channel entry but this ifIndex may conflict with existing or reserved ifIndex (e.g for multiple logical upstream channels).
    Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 

<dave>

This methodology was arrived at after much consultation with CMTS vendor representatives. They are indeed intended to permit the operational parameter update of a currently active channel. A clone of a currently active channel is created 'offline'. The desired parameters are adjusted using the offline channel clone. This methodology allows the underlying software to verify the new parameters' compatibility with each other before the snmp commit begins. This would not be possible during processing of an snmp packet containing many SET commands.

<end dave>

 

According to your explanations, these 2 objects are defined only as a convenience for the CMTS vendors because no technical issue prevents to implement a CMTS that would be capable of "verifying the new parameters' compatibility with each other before the SNMP commit begins".

Moreover, if you read the DESCRIPTION clause of these 2 objects, it is written that "[these objects] may also be used at the vendor's discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, these objects are either optional or useless because the MIB only requires the transfer of SCDMA parameters.

This means that this clone mechanism is not usable as is from an NMS viewpoint because it cannot be used consistently on every type of upstream channels. So we should either make these objects mandatory for all non-SCDMA parameters and channel types or simply make these objects optional and supported at the CMTS vendor's discretion.

As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.

Thanks,

-- Joël






--------------050509050101080806030201-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 12 18:17:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29266 for ; Wed, 12 Mar 2003 18:17:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2CNVL225315 for ipcdn-archive@odin.ietf.org; Wed, 12 Mar 2003 18:31:21 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CNV4O25283; Wed, 12 Mar 2003 18:31:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2CHXDO29262 for ; Wed, 12 Mar 2003 12:33:13 -0500 Received: from fr.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11962 for ; Wed, 12 Mar 2003 12:18:37 -0500 (EST) Received: from juniper.net by fr.juniper.net with ESMTP id SAA19496; Wed, 12 Mar 2003 18:20:22 +0100 (MET) Message-ID: <3E6F6C56.5010000@juniper.net> Date: Wed, 12 Mar 2003 18:20:22 +0100 From: =?ISO-8859-1?Q?Jo=EBl_Demarty?= Organization: Juniper Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Raftus, David" CC: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" References: Content-Type: multipart/alternative; boundary="------------000707000601020905000704" Subject: [ipcdn] Re: draft-ietf-ipcdn-docs-rfmibv6 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: , --------------000707000601020905000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks David, I cannot but accept your points, but, still, you are not answering the questions and arguments of my previous email. Anyway, I'm definitely not convinced that the spec should stay as it is. For instance, the spec is vague about the minimum set of parameters that the CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. Only those starting with docsIfUpChannelScdma or all parameters defining an SCDMA channel, like the channel width? Then what about the frequency? Definitely, this clone mechanism is sophisticated enough that it would deserve a more detailed specification (and testing) and, as a consequence, an ECR. -- Joël Raftus, David wrote: > Hi Joel, > > > > The methodology can be used for non-scdma parameters. Its necessity > was inspired by the number of scdma parameters, but it can certainly > be used by other channel types. > > > > Please note that these objects are not new - they were introduced by > draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by > oss2-n-02016 on Feb 27/02 - significantly predates the first 2.0 > qualification. They remain optional for 1.1 CMTSs. > > > > Thanks, > > Dave > > > > ************************************ > > /David Raftus/ > > /Terayon Canada Ltd/ > > /340 Terry Fox Drive, Suite 202/ > > /Ottawa Canada K2K 3A2/ > > / / > > /david.raftus@terayon.com / > > /613.592.1052 ext 222/ > > /************************************ / > > > > > > -----Original Message----- > *From:* Joël Demarty [mailto:jdemarty@juniper.net] > *Sent:* Wednesday, March 12, 2003 9:08 AM > *To:* Raftus, David > *Cc:* Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 > Reflector (E-mail) > *Subject:* Re: draft-ietf-ipcdn-docs-rfmibv6 > > > > Thanks David for your detailed answers. See my comments/questions below. > -- Joël > > > · In docsIfUpstreamChannelTable, can you help me understand > the benefit of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate > objects. Contrary to the usmUserCloneFrom object in usmUserTable,these > objects cannot be used to duplicate the configuration of an existing > and active channel because parameters like the frequency cannot be > duplicated. Another use of these objects would be to let the user > configure each object of a row independently until the parameter are > compatible with each other (valid upstream configuration) and commit > the new configuration in a single operation by setting > docsIfUpChannelUpdate totrue. But this seems overkill as the SNMP > protocol already allows to commit a partial or complete row change in > a single operation and all SNMP tools like UCD-snmp or SNMPc give the > user the capacity to modify parameters independently and commit the > change in a single operation. If you take the example of SNMPc, you > can adjust the SCDMA parameters off-line and when satisfied, asks > SNMPc to commit these new parameters in a single operation. If the > commit fails, the adjusted parameters are still available for further > adjustments. > On the other hand, this mechanism has a potential drawback because the > user decides the ifIndex of the template upstream channel entry but > this ifIndex may conflict with existing or reserved ifIndex (e.g for > multiple logical upstream channels). > Given these points, I propose to have the objects > docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS > 2.0 CMTS. > > > > This methodology was arrived at after much consultation with CMTS > vendor representatives. They are indeed intended to permit the > operational parameter update of a currently active channel. A clone of > a currently active channel is created 'offline'. The desired > parameters are adjusted using the offline channel clone. This > methodology allows the underlying software to verify the new > parameters' compatibility with each other before the snmp commit > begins. This would not be possible during processing of an snmp packet > containing many SET commands. > > > > > > According to your explanations, these 2 objects are defined only as a > convenience for the CMTS vendors because no technical issue prevents > to implement a CMTS that would be capable of "verifying the new > parameters' compatibility with each other before the SNMP commit begins". > > Moreover, if you read the DESCRIPTION clause of these 2 objects, it is > written that "[these objects] may also be used at the vendor's > discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA > channels, these objects are either optional or useless because the MIB > only requires the transfer of SCDMA parameters. > > This means that this clone mechanism is not usable as is from an NMS > viewpoint because it cannot be used consistently on every type of > upstream channels. So we should either make these objects mandatory > for all non-SCDMA parameters and channel types or simply make these > objects optional and supported at the CMTS vendor's discretion. > > As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my > proposition to have theses objects docsIfUpChannelCloneFrom and > docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. > > Thanks, > > -- Joël > --------------000707000601020905000704 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks David,

I cannot but accept your points, but, still, you are not answering the questions and arguments of my previous email.

Anyway, I'm definitely not convinced that the spec should stay as it is. For instance, the spec is vague about the minimum set of parameters that the CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. Only those starting with docsIfUpChannelScdma or all parameters defining an SCDMA channel, like the channel width? Then what about the frequency?
Definitely, this clone mechanism is sophisticated enough that it would deserve a more detailed specification (and testing) and, as a consequence, an ECR.

-- Joël

Raftus, David wrote:

Hi Joel,

 

The methodology can be used for non-scdma parameters. Its necessity was inspired by the number of scdma parameters, but it can certainly be used by other channel types.

 

Please note that these objects are not new - they were introduced by draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by oss2-n-02016 on Feb 27/02 - significantly predates the first 2.0 qualification. They remain optional for 1.1 CMTSs.

 

Thanks,

Dave

 

************************************

David Raftus

Terayon Canada Ltd

340 Terry Fox Drive, Suite 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com          

613.592.1052  ext 222

************************************               

 

 

-----Original Message-----
From: Joël Demarty [mailto:jdemarty@juniper.net]
Sent: Wednesday, March 12, 2003 9:08 AM
To: Raftus, David
Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6

 

Thanks David for your detailed answers. See my comments/questions below.
-- Joël


·         In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable,these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. Another use of these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate totrue. But this seems overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, the adjusted parameters are still available for further adjustments.
On the other hand, this mechanism has a potential drawback because the user decides the ifIndex of the template upstream channel entry but this ifIndex may conflict with existing or reserved ifIndex (e.g for multiple logical upstream channels).
Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 

<dave>

This methodology was arrived at after much consultation with CMTS vendor representatives. They are indeed intended to permit the operational parameter update of a currently active channel. A clone of a currently active channel is created 'offline'. The desired parameters are adjusted using the offline channel clone. This methodology allows the underlying software to verify the new parameters' compatibility with each other before the snmp commit begins. This would not be possible during processing of an snmp packet containing many SET commands.

<end dave>

 

According to your explanations, these 2 objects are defined only as a convenience for the CMTS vendors because no technical issue prevents to implement a CMTS that would be capable of "verifying the new parameters' compatibility with each other before the SNMP commit begins".

Moreover, if you read the DESCRIPTION clause of these 2 objects, it is written that "[these objects] may also be used at the vendor's discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, these objects are either optional or useless because the MIB only requires the transfer of SCDMA parameters.

This means that this clone mechanism is not usable as is from an NMS viewpoint because it cannot be used consistently on every type of upstream channels. So we should either make these objects mandatory for all non-SCDMA parameters and channel types or simply make these objects optional and supported at the CMTS vendor's discretion.

As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.

Thanks,

-- Joël



--------------000707000601020905000704-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Mar 13 08:24:44 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29725 for ; Thu, 13 Mar 2003 08:24:44 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DDdAR27398 for ipcdn-archive@odin.ietf.org; Thu, 13 Mar 2003 08:39:10 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DDd9O27380; Thu, 13 Mar 2003 08:39:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DDcuO27348 for ; Thu, 13 Mar 2003 08:38:56 -0500 Received: from xchange.stargus.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29692 for ; Thu, 13 Mar 2003 08:23:57 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ipcdn] Jabber at IPCDN meeting in San Francisco Date: Thu, 13 Mar 2003 08:26:04 -0500 Message-ID: <9093431B64301C47986EF078512912AD942ECC@xchange.stargus.com> Thread-Topic: [ipcdn] Jabber at IPCDN meeting in San Francisco Thread-Index: AcLo693Hqh7Ao1vcTfKYoiBBM/a1yAAeAqrA From: "Jason Schnitzer" To: "Woundy, Richard" , "IPCDN WG (E-mail)" Cc: "Jean-Francois Mule (E-mail)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DDcuO27349 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: 8bit Rich, I most-certainly would like to Jabber-in. Thanks, /j -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, March 12, 2003 6:00 PM To: IPCDN WG (E-mail) Cc: Jean-Francois Mule (E-mail); Woundy, Richard Subject: [ipcdn] Jabber at IPCDN meeting in San Francisco Folks, I am curious whether our WG would like to take advantage of the jabber text conferencing service as described below (thanks to Marshall Rose and others) during the IPCDN WG meeting next week. The jabber service will automatically collect a "conference log" that we can use as the source material for our WG meeting minutes. I need to know two things: 1. Is anyone interested in remote participation through jabber? 2. Who will be willing to act as jabber scribe during the meeting? Please let me know as soon as possible if you would listen in on a jabber session from the WG meeting, so I can be sure to identify a scribe and get copies of presentations posted on for remote viewing. You probably ought to test your network connectivity to a jabber server *before* you indicate your interest in remote participation. Note that your access to jabber servers may be blocked by your corporate firewall, for example. -- Rich Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ NOTE: the logging facility will not be active until later this week... ####### _______________________________________________ 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 mailnull@www1.ietf.org Thu Mar 13 13:30:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11897 for ; Thu, 13 Mar 2003 13:30:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2DIjOu19713 for ipcdn-archive@odin.ietf.org; Thu, 13 Mar 2003 13:45:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIjBO19696; Thu, 13 Mar 2003 13:45:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DIiEO19634 for ; Thu, 13 Mar 2003 13:44:14 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11867 for ; Thu, 13 Mar 2003 13:29:09 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.8/8.12.8) with ESMTP id h2DIVGKg000858; Thu, 13 Mar 2003 11:31:16 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [ipcdn] Jabber at IPCDN meeting in San Francisco Date: Thu, 13 Mar 2003 11:31:16 -0700 Message-ID: Thread-Topic: [ipcdn] Jabber at IPCDN meeting in San Francisco thread-index: AcLo693Hqh7Ao1vcTfKYoiBBM/a1yAAeAqrAAAqp8GA= From: "Greg White" To: "Jason Schnitzer @ Stargus" , "Woundy, Richard" , "IPCDN WG (E-mail)" Cc: "Jean-Francois Mule" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2DIiEO19635 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: 8bit I would as well. Thanks, Greg -----Original Message----- From: Jason Schnitzer @ Stargus Sent: Thursday, March 13, 2003 6:26 AM To: Woundy, Richard; IPCDN WG (E-mail) Cc: Jean-Francois Mule Subject: RE: [ipcdn] Jabber at IPCDN meeting in San Francisco Rich, I most-certainly would like to Jabber-in. Thanks, /j -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Wednesday, March 12, 2003 6:00 PM To: IPCDN WG (E-mail) Cc: Jean-Francois Mule (E-mail); Woundy, Richard Subject: [ipcdn] Jabber at IPCDN meeting in San Francisco Folks, I am curious whether our WG would like to take advantage of the jabber text conferencing service as described below (thanks to Marshall Rose and others) during the IPCDN WG meeting next week. The jabber service will automatically collect a "conference log" that we can use as the source material for our WG meeting minutes. I need to know two things: 1. Is anyone interested in remote participation through jabber? 2. Who will be willing to act as jabber scribe during the meeting? Please let me know as soon as possible if you would listen in on a jabber session from the WG meeting, so I can be sure to identify a scribe and get copies of presentations posted on for remote viewing. You probably ought to test your network connectivity to a jabber server *before* you indicate your interest in remote participation. Note that your access to jabber servers may be blocked by your corporate firewall, for example. -- Rich Remote Access for the 56th IETF meeting in San Francisco: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: plenary Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ NOTE: the logging facility will not be active until later this week... ####### _______________________________________________ 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 mailnull@www1.ietf.org Thu Mar 13 19:05:58 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26188 for ; Thu, 13 Mar 2003 19:05:58 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E0Kbx12541 for ipcdn-archive@odin.ietf.org; Thu, 13 Mar 2003 19:20:37 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0KZO12532; Thu, 13 Mar 2003 19:20:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2DDQJO25605 for ; Thu, 13 Mar 2003 08:26:19 -0500 Received: from d12lmsgate-5.de.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29210; Thu, 13 Mar 2003 08:11:18 -0500 (EST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.8/8.12.3) with ESMTP id h2DDDMOI097812; Thu, 13 Mar 2003 14:13:22 +0100 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.8/NCO/VER6.5) with SMTP id h2DDDMcx247858; Thu, 13 Mar 2003 14:13:22 +0100 Received: from dhcp23-54.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39300 from ; Thu, 13 Mar 2003 14:13:20 +0100 Message-Id: <3E7083B4.C2E75FF2@hursley.ibm.com> Date: Thu, 13 Mar 2003 14:12:20 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: "Woundy, Richard" Cc: diffserv-interest@ietf.org, "IPCDN WG (E-mail)" Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs References: <6732623D2548D61193C90002A5C88DCC06B9ADD2@entmaexch02.broadband.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Woundy, Richard" wrote: > > Brian (and many diffserv folks), > > Thanks for your input and of the diffserv WG. I will assume that our IPCDN > MIBs need to use explicit DSCP values and not use DSCP masks. > > Please forgive this question for my DiffServ education. I have heard several > times that "network operators are free to ignore the recommended code > points", and that this is a major reason why we should not use DSCP masks. > > What benefits does a network operator achieve with an unstructured set of > DSCPs? The reason we did this, after very explicit pressure from ISPs at the beginning of diffserv, was because they didn't want to be constrained by (say) having at most 4 AF classes, or only one EF class, etc. In fact it seemed pretty clear that there was no one-size-fits-all set of PHBs, since different operators had different QOS business models in mind. So all the code points became RECOMMENDED. I would expect an operator to define a structured set of PHBs and DSCPs. I would even expect many of them to use the recommended ones from the various RFCs. > > In fact, I *am* a network operator -- I work for Comcast Cable, which has > lots of regional networks and millions of residential cable modem > subscribers. I see the pain associated with network management of my > boundary nodes with unstructured DSCP assignments. Where's the benefit to > me? None whatever. I would recommend any network operator (ISP or enterprise) to define a set of DSCPs and stick to it as long as possible. The SLAs at the network edge should specify how the sets are mapped across each network-to-network border. There are more words on this topic in Differentiated Services in the Internet, B.Carpenter and K. Nichols, Proc. IEEE, 90 (9) (2002) 1479-1494. > > I don't mind if folks take this question off-list, or if folks refer me to > specific diffserv mail archives (e.g. a specific "thread" name) where this > was already discussed. Just as long as I am not mistaken as a spammer. ;^) Well, I did switch this to the diffserv-interest list, since we are now closing the diffserv list to reduce the amount of get-rich-quick mail that we have to delete each day :-) Brian > > -- Rich > > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Saturday, March 08, 2003 6:59 AM > To: John Schnizlein > Cc: Woundy, Richard; 'diffserv@ietf.org' > Subject: Re: FW: [ipcdn] FW: [Diffserv] Dscp and DscpOrAny TCs > > What John writes is definitive. Masking DSCPs is > simply wrong. The fact that the recommended AF code > points happen to be numerically consecutive is just an > accident of the code point assignment process; the bit > positions are not significant, and network operators are > free to ignore the recommended code points if they want to. > > Brian > > John Schnizlein wrote: > > > > Comments embedded in context below: > > > > At 09:40 AM 3/7/2003, Woundy, Richard wrote: > > > > >I'm looking for further reaction to my email below about DOCSIS/Dscp > > >interaction. > > >... > > >I think there are two issues here: are Dscp mask objects legal, > > > > No. > > > > >and are they worthwhile? > > > > No. > > > > >... enable the DOCSIS equipment to act precisely as "re-marking boundary > > >nodes", which are also described in RFC 2474 Section 3, pages 8-9: > > > > > > The structure of the DS field shown above is incompatible with the > > > existing definition of the IPv4 TOS octet in [RFC791]. The > > > presumption is that DS domains protect themselves by deploying re- > > > marking boundary nodes, as should networks using the RFC 791 > > > Precedence designations. Correct operational procedure SHOULD follow > > > [RFC791], which states: "If the actual use of these precedence > > > designations is of concern to a particular network, it is the > > > responsibility of that network to control the access to, and use of, > > > those precedence designations." Validating the value of the DS field > > > at DS boundaries is sensible in any case since an upstream node can > > > easily set it to any arbitrary value. DS domains that are not > > > isolated by suitably configured boundary nodes may deliver > > > unpredictable service. > > > > > > Nodes MAY rewrite the DS field as needed to provide a desired local > > > or end-to-end service. Specifications of DS field translations at DS > > > boundaries are the subject of service level agreements between > > > providers and users, and are outside the scope of this document. > > > Standardized PHBs allow providers to build their services from a > > > well-known set of packet forwarding treatments that can be expected > > > to be present in the equipment of many vendors. > > > > > >On the other hand, I see the definite lack of structure in the DiffServ > > >codepoints, and I am debating with myself whether a "Dscp mask" is worth > the > > >trouble or not. > > > > > >In particular, I am looking at the current codepoint assignments in > > >,... > > > > You may be running into a subtlety that was worried about early in > > defining the DiffServ field. The code points in the registry are > > just recommended values, not required values. While there are > > requirements regarding which behaviors must be supported to claim > > DiffServ compliance, there is no requirement that the recommended > > values be used to indicate these behaviors. > > > > The point is that there is no reliable structure for "the network > > operator to take advantage of". The presence of masks in data objects > > would encourage creating the sort of structure the RFC prohibits. > > > > Note the distinction between the SHOULD regarding values, and the MUST > regarding treating the value as a unit (copied farther below): > > > > RFC 2474 section 2, page 5 > > Codepoint: a specific value of the DSCP portion of the DS field. > > Recommended codepoints SHOULD map to specific, standardized PHBs. > > > > >From: Wilson.Sawyer@arrisi.com [mailto:Wilson.Sawyer@arrisi.com] > > > > > >Keep in mind we're talking about a *filter* here, not a PHB selector. > > > > I don't appreciate the distinction. What was intended by PHB selector > > was that traffic could be selected from the aggregate by the DSCP. > > How is this different from filtering traffic based on DSCP matches? > > > > >And we'e not inferring bit-structure in the implementation, merely > > >allowing the network operator to take advantage of any structure > > >that exists. Do we really want to require the operator to install > > >three separate filters to catch one AF class? > > > > > >I don't find anything in the cited paragraph that contraindicates this > sort > > >of usage. The fact that today's PHB selector set is likely to change is > all > > >the more reason to give a filter-installer some options for concise > > >representation. > > >... > > >RFC 2474 Section 3, page 7 > > > Implementors should note that the DSCP field is six bits wide. DS- > > > compliant nodes MUST select PHBs by matching against the entire 6-bit > > > DSCP field, e.g., by treating the value of the field as a table index > > > which is used to select a particular packet handling mechanism which > > > has been implemented in that device. The value of the CU field MUST > > > be ignored by PHB selection. The DSCP field is defined as an > > > unstructured field to facilitate the definition of future per-hop > > > behaviors. > > > > John _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Thu Mar 13 19:05:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26190 for ; Thu, 13 Mar 2003 19:05:59 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2E0KcG12554 for ipcdn-archive@odin.ietf.org; Thu, 13 Mar 2003 19:20:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2E0KTO12515; Thu, 13 Mar 2003 19:20:29 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2D9aNO09580 for ; Thu, 13 Mar 2003 04:36:23 -0500 Received: from fr.juniper.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24822 for ; Thu, 13 Mar 2003 04:21:26 -0500 (EST) Received: from juniper.net by fr.juniper.net with ESMTP id KAA02997; Thu, 13 Mar 2003 10:23:17 +0100 (MET) Message-ID: <3E702237.8050000@juniper.net> Date: Thu, 13 Mar 2003 07:16:23 +0100 From: =?ISO-8859-1?Q?Jo=EBl_Demarty?= Organization: Juniper Networks User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Raftus, David" CC: "Ipcdn List (E-mail)" , "Docsis Oss Reflector (E-mail)" , "Docsis 20 Reflector (E-mail)" References: Content-Type: multipart/alternative; boundary="------------010102060604080507070804" Subject: [ipcdn] Re: draft-ietf-ipcdn-docs-rfmibv6 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: , --------------010102060604080507070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi David, Raftus, David wrote: > Hi Joel, > > > > When the 'offline' row is created through the cloning procedure, all > values of the active row being cloned are copied to the inactive row. > I don't understand how this can be done with the current MIB. One can initiate the transfer from an inactive row to an active row, but not the reverse according to the description of docsIfUpChannelStatus. IMO, the operator must do the transfer by hand "create an inactive row through an SNMP SET...". > After necessary adjustments, all values will be used to update the > active row. Perhaps I'm missing something, but I don't see why a > 'minimum set of parameters' would be applicable. > > > > If you feel a behavior clarification ecr would be appropriate, by all > means please proceed > No problem, I will submit an ECR. -- Joël > > > Thanks, > > Dave > > > > ************************************ > > /David Raftus/ > > /Terayon Canada Ltd/ > > /340 Terry Fox Drive, Suite 202/ > > /Ottawa Canada K2K 3A2/ > > / / > > /david.raftus@terayon.com / > > /613.592.1052 ext 222/ > > /************************************ / > > > > > > -----Original Message----- > *From:* Joël Demarty [mailto:jdemarty@juniper.net] > *Sent:* Wednesday, March 12, 2003 12:20 PM > *To:* Raftus, David > *Cc:* Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 > Reflector (E-mail) > *Subject:* Re: draft-ietf-ipcdn-docs-rfmibv6 > > > > Thanks David, > > I cannot but accept your points, but, still, you are not answering the > questions and arguments of my previous email. > > Anyway, I'm definitely not convinced that the spec should stay as it > is. For instance, the spec is vague about the minimum set of > parameters that the CMTS must transfer during a clone operation to be > DOCSIS 2.0 compliant. Only those starting with docsIfUpChannelScdma or > all parameters defining an SCDMA channel, like the channel width? Then > what about the frequency? > Definitely, this clone mechanism is sophisticated enough that it would > deserve a more detailed specification (and testing) and, as a > consequence, an ECR. > > -- Joël > > Raftus, David wrote: > > Hi Joel, > > The methodology can be used for non-scdma parameters. Its necessity > was inspired by the number of scdma parameters, but it can certainly > be used by other channel types. > > Please note that these objects are not new - they were introduced by > draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by > oss2-n-02016 on Feb 27/02 - significantly predates the first 2.0 > qualification. They remain optional for 1.1 CMTSs. > > Thanks, > > Dave > > ************************************ > > /David Raftus/ > > /Terayon Canada Ltd/ > > /340 Terry Fox Drive, Suite 202/ > > /Ottawa Canada K2K 3A2/ > > /david.raftus@terayon.com / > > /613.592.1052 ext 222/ > > /************************************ / > > > > -----Original Message----- > *From:* Joël Demarty [mailto:jdemarty@juniper.net] > *Sent:* Wednesday, March 12, 2003 9:08 AM > *To:* Raftus, David > *Cc:* Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 > Reflector (E-mail) > *Subject:* Re: draft-ietf-ipcdn-docs-rfmibv6 > > Thanks David for your detailed answers. See my comments/questions below. > -- Joël > > > In docsIfUpstreamChannelTable, can you help me understand the benefit > of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate objects. Contrary > to the usmUserCloneFrom object in usmUserTable,these objects cannot be > used to duplicate the configuration of an existing and active channel > because parameters like the frequency cannot be duplicated. Another > use of these objects would be to let the user configure each object of > a row independently until the parameter are compatible with each other > (valid upstream configuration) and commit the new configuration in a > single operation by setting docsIfUpChannelUpdate totrue.But this > seems overkill as the SNMP protocol already allows to commit a partial > or complete row change in a single operation and all SNMP tools like > UCD-snmp or SNMPc give the user the capacity to modify parameters > independently and commit the change in a single operation. If you take > the example of SNMPc, you can adjust the SCDMA parameters off-line and > when satisfied, asks SNMPc to commit these new parameters in a single > operation. If the commit fails, the adjusted parameters are still > available for further adjustments. > On the other hand, this mechanism has a potential drawback because the > user decides the ifIndex of the template upstream channel entry but > this ifIndex may conflict with existing or reserved ifIndex (e.g for > multiple logical upstream channels). > Given these points, I propose to have the objects > docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS > 2.0 CMTS. > > > > This methodology was arrived at after much consultation with CMTS > vendor representatives. They are indeed intended to permit the > operational parameter update of a currently active channel. A clone of > a currently active channel is created 'offline'. The desired > parameters are adjusted using the offline channel clone. This > methodology allows the underlying software to verify the new > parameters' compatibility with each other before the snmp commit > begins. This would not be possible during processing of an snmp packet > containing many SET commands. > > > > According to your explanations, these 2 objects are defined only as a > convenience for the CMTS vendors because no technical issue prevents > to implement a CMTS that would be capable of "verifying the new > parameters' compatibility with each other before the SNMP commit begins". > > Moreover, if you read the DESCRIPTION clause of these 2 objects, it is > written that "[these objects] may also be used at the vendor's > discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA > channels, these objects are either optional or useless because the MIB > only requires the transfer of SCDMA parameters. > > This means that this clone mechanism is not usable as is from an NMS > viewpoint because it cannot be used consistently on every type of > upstream channels. So we should either make these objects mandatory > for all non-SCDMA parameters and channel types or simply make these > objects optional and supported at the CMTS vendor's discretion. > > As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my > proposition to have theses objects docsIfUpChannelCloneFrom and > docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. > > Thanks, > > -- Joël > > > --------------010102060604080507070804 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David,

Raftus, David wrote:

Hi Joel,

 

When the 'offline' row is created through the cloning procedure, all values of the active row being cloned are copied to the inactive row.

I don't understand how this can be done with the current MIB. One can initiate the transfer from an inactive row to an active row, but not the reverse according to the description of docsIfUpChannelStatus. IMO, the operator must do the transfer by hand "create an inactive row through an SNMP SET...".

After necessary adjustments, all values will be used to update the active row. Perhaps I'm missing something, but I don't see why a 'minimum set of parameters' would be applicable.

 

If you feel a behavior clarification ecr would be appropriate, by all means please proceed

No problem, I will submit an ECR.

-- Joël

 

Thanks,

Dave

 

************************************

David Raftus

Terayon Canada Ltd

340 Terry Fox Drive, Suite 202

Ottawa Canada  K2K 3A2

 

david.raftus@terayon.com          

613.592.1052  ext 222

************************************               

 

 

-----Original Message-----
From: Joël Demarty [mailto:jdemarty@juniper.net]
Sent: Wednesday, March 12, 2003 12:20 PM
To: Raftus, David
Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6

 

Thanks David,

I cannot but accept your points, but, still, you are not answering the questions and arguments of my previous email.

Anyway, I'm definitely not convinced that the spec should stay as it is. For instance, the spec is vague about the minimum set of parameters that the CMTS must transfer during a clone operation to be DOCSIS 2.0 compliant. Only those starting with docsIfUpChannelScdma or all parameters defining an SCDMA channel, like the channel width? Then what about the frequency?
Definitely, this clone mechanism is sophisticated enough that it would deserve a more detailed specification (and testing) and, as a consequence, an ECR.

-- Joël

Raftus, David wrote:

Hi Joel,

The methodology can be used for non-scdma parameters. Its necessity was inspired by the number of scdma parameters, but it can certainly be used by other channel types.

Please note that these objects are not new - they were introduced by draft v2 of the rf mib, and were made mandatory for 2.0 CMTSs by oss2-n-02016 on Feb 27/02 - significantly predates the first 2.0 qualification. They remain optional for 1.1 CMTSs.

Thanks,

Dave

************************************

David Raftus

Terayon Canada Ltd

340 Terry Fox Drive, Suite 202

Ottawa Canada  K2K 3A2

david.raftus@terayon.com          

613.592.1052  ext 222

************************************               

 

-----Original Message-----
From: Joël Demarty [mailto:jdemarty@juniper.net]
Sent: Wednesday, March 12, 2003 9:08 AM
To: Raftus, David
Cc: Ipcdn List (E-mail); Docsis Oss Reflector (E-mail); Docsis 20 Reflector (E-mail)
Subject: Re: draft-ietf-ipcdn-docs-rfmibv6

Thanks David for your detailed answers. See my comments/questions below.
-- Joël


In docsIfUpstreamChannelTable, can you help me understand the benefit of docsIfUpChannelCloneFrom anddocsIfUpChannelUpdate objects. Contrary to the usmUserCloneFrom object in usmUserTable,these objects cannot be used to duplicate the configuration of an existing and active channel because parameters like the frequency cannot be duplicated. Another use of these objects would be to let the user configure each object of a row independently until the parameter are compatible with each other (valid upstream configuration) and commit the new configuration in a single operation by setting docsIfUpChannelUpdate totrue.But this seems overkill as the SNMP protocol already allows to commit a partial or complete row change in a single operation and all SNMP tools like UCD-snmp or SNMPc give the user the capacity to modify parameters independently and commit the change in a single operation. If you take the example of SNMPc, you can adjust the SCDMA parameters off-line and when satisfied, asks SNMPc to commit these new parameters in a single operation. If the commit fails, the adjusted parameters are still available for further adjustments.
On the other hand, this mechanism has a potential drawback because the user decides the ifIndex of the template upstream channel entry but this ifIndex may conflict with existing or reserved ifIndex (e.g for multiple logical upstream channels).
Given these points, I propose to have the objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS. 

<dave>

This methodology was arrived at after much consultation with CMTS vendor representatives. They are indeed intended to permit the operational parameter update of a currently active channel. A clone of a currently active channel is created 'offline'. The desired parameters are adjusted using the offline channel clone. This methodology allows the underlying software to verify the new parameters' compatibility with each other before the snmp commit begins. This would not be possible during processing of an snmp packet containing many SET commands.

<end dave>

According to your explanations, these 2 objects are defined only as a convenience for the CMTS vendors because no technical issue prevents to implement a CMTS that would be capable of "verifying the new parameters' compatibility with each other before the SNMP commit begins".

Moreover, if you read the DESCRIPTION clause of these 2 objects, it is written that "[these objects] may also be used at the vendor's discretion for non-SCDMA parameter adjustment". Thus, on non-SCDMA channels, these objects are either optional or useless because the MIB only requires the transfer of SCDMA parameters.

This means that this clone mechanism is not usable as is from an NMS viewpoint because it cannot be used consistently on every type of upstream channels. So we should either make these objects mandatory for all non-SCDMA parameters and channel types or simply make these objects optional and supported at the CMTS vendor's discretion.

As some CMTS vendors are already DOCSIS 2.0 qualified, I reiterate my proposition to have theses objects docsIfUpChannelCloneFrom and docsIfUpChannelUpdate optional for DOCSIS 2.0 CMTS.

Thanks,

-- Joël

 



--------------010102060604080507070804-- _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Tue Mar 18 13:37:37 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22869 for ; Tue, 18 Mar 2003 13:37:37 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2IIsaQ06375 for ipcdn-archive@odin.ietf.org; Tue, 18 Mar 2003 13:54:36 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IIsXO06335; Tue, 18 Mar 2003 13:54:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2IImRO06005 for ; Tue, 18 Mar 2003 13:48:27 -0500 Received: from ondar.cablelabs.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22667 for ; Tue, 18 Mar 2003 13:30:55 -0500 (EST) Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.8/8.12.8) with ESMTP id h2IIWrKg025168; Tue, 18 Mar 2003 11:32:53 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Mar 2003 11:32:52 -0700 Message-ID: Thread-Topic: Review of draft-ietf-ipcdn-pktc-signaling-00 thread-index: AcLpvkpyW9ZwJtAWSXyTFWFleWSzugDvZVVA From: "Jean-Francois Mule" To: "Satish Kumar at Texas Instruments" , "Sumanth Channabasappa" , "Charles Schell" , Cc: "PacketCable Provisioning and OSS Majordomo List" , "Richard Woundy" X-Approved: ondar Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2IImTO06006 Subject: [ipcdn] Review of draft-ietf-ipcdn-pktc-signaling-00 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: 8bit Here are comments from my partial review of draft-ietf-ipcdn-pktc-signaling-00. We will also do a formal review of this draft tomorrow at the IPCDN wg meeting in ietf 56. Jean-Francois. jfm@cablelabs.com # Review of draft-ietf-ipcdn-pktc-signaling-00 # ID location: # http://www.ipcdn.org/drafts/draft-ietf-ipcdn-pktc-signaling-00.txt # March 18, 2003 --- General comments: - align Signaling MIB with latest CableLabs published version: + update mib object defs & corrections made so far + update reference of PacketCable 1.0 Provisioning Specification to match the latest spec version - update section 2 per current mib boilerplate http://www.ops.ietf.org/mib-boilerplate.html - please read draft-ietf-ops-mib-review-guidelines-01.txt and make the following corrections: + copyright inside the Description clause of module identity + split references into norm. & informative ref. + add clarification text in description clauses (See below) + remove oid 99992 replace < ::= { mib-2 99992 } -- to be assigned by IANA. with > ::= { mib-2 XXX } > -- RFC Ed.: replace XXX with IANA-assigned number > -- & remove this note + update revision as: REVISION "" DESCRIPTION "Initial version, published as RFC yyyy." -- RFC Ed.: replace yyyy with actual RFC number & remove this note + add copyright statement + review all MIB comments, 72 chars max per line - update Rich Woundy contact info see ipcdn charter page for latest email address - descriptive mib text in section 3 Add a paragraph that gives in one or 2 sentences the scope of this MIB. For example, explain the NCS endpoints/codec/ring cadence/etc. signaling functions of an MTA and how the mib objects defined in this draft help manage the MTA signaling piece. - remove pktcDcsEndPntConfigObjects > 3.1.1.4 pktcDcsEndPntConfigObjects > > This object is reserved for future use > in Distributed Call Signaling (DCS). I'm not sure this "for future use" objects belong in ipcdn. same "remove" comment applies to > pktcDcsEndPntConfigObjects OBJECT IDENTIFIER ::= { > pktcSigMibObjects 4 } - revision date and last update: Please correct this warning: W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (65,34) The first revision should match the last update for MODULE-IDENTITY pktcSigMib --- Comments on mib definitions: - PktcCodecType TEXTUAL-CONVENTION See IETF AVT draft-ietf-avt-profile-new-13.txt, section 4.5: this draft is an update to rfc1890 and it defines the latest and greatest encoding names for audio video codecs. The PktcCodecType object definition should use the encoding names defined in AVT. In particular, g711a/mu must be replaced by PCMA/PCMU, etc. These changes were made in the latest PacketCable spec PKT-SP-MIB-SIG-I05-021127 and should be reflected in the IETF ipcdn ID. - PktcSigType TEXTUAL-CONVENTION + Update the description clause to state that NCS is defined as the Network Call Signaling protocol, a profile of the MGCP protocol defined for PacketCable MTAs. + Remove RFC references in the description, put the relevant ones in normative references (NCS) or informative references (SIP) - (the sip rfc is now 3261 and who know how long it will last). + DCS: I don't think there is any normative reference for building DCS MTAs to date so shouldn't this option be removed? one concern here is if DCS is a derivation of SIP, where is it defined for MTA devices? + signaling protocol types and protocol versions: remove version numbers in the description clause - another object takes care of version numbers (pktcSignalingVersion) + is unknown (2) a possible value given the TC usage? If it is unknown, how different is it from other(1)? - pktcSigDevCodecIndex are there any good reasons for choosing 16383 as the upper bound? - pktcSigDevCodecMax " The maximum number of simultaneous sessions of the specific codec that the MTA can support" The description clause should be more specific. I'm not sure I understand how to read this object when you have multiple codec entries. Does this means the max # of simultaneous sessions of this codec the MTA can support when this codec is loaded independently of any other active calls of different codec types? if not, how useful is this - just asking. For e.g., let's assume an MTA supports G.711, G.729e, G.728 and pktcSigDevCodecMax entries are 2, 2, 2. What does this mean when you mix/match codecs in simultaneous calls? - pktcSigDefCallSigTos OBJECT-TYPE - pktcSigDefMediaStreamTos OBJECT-TYPE Both objects are: SYNTAX Integer32 (0..63) and the descriptions refer to TOS. See docsis qos mib discussion, our IPCDN MIBs need to use explicit DSCP values. The current proposal for the related docsis qos object is: SYNTAX Dscp -- 0..63 RFC 3289: DIFFSERV-DSCP-TC The reference clause in both of these objects links to the PacketCable NCS spec while the conformance statements put them in the generic signaling group. I would hope that these are independent of the chosen signaling protocol => remove the reference. - pktcSigDefCallSigTos applicability Is this only applicable to NCS or to any or all signaling type(s)? Should this be an additional column of pktcSigCapabilityEntry? - pktcSigTosFormatSelector See docsis qos mib discussion. This object will likely have to be removed. - pktcSignalingType remove references to the TC labels ("this can be NCS, DCS, etc.") - pktcSigServiceClassNameUS, pktcSigServiceClassNameDS, pktcSigServiceClassNameMask, pktcSigNcsServiceFlowState These objects are applicable to the NCS signaling type only. Should this be an additional column of pktcSigCapabilityEntry? - pktcSigNcsServiceFlowState align 'notactive (1)' with 'not-active' - pktcSigPowerRingFrequency SYNTAX INTEGER { twenty(1), twentyFive(2), thirtyThreePointThreeThree(3), fifty(4) } Not sure what mib doctors would say about this? Remove reference to ETSI spec in the description clause and add it to a REFERENCE clause. Also should move this ETSI spec in the normative or informative ref section. - pktcSigPCMCoding description uses EMTA as in embedded MTA - replace EMTA by MTA (this object also applies to standalone MTA) should there be a DEFVAL to express "The default will be aLaw(1)."? - pktcSigPulseSignalTable Any references for the columnar objects of this table? - pktcSigPulseSignalDbLevel if this object only applies for row with pktcSigPulseSignalType=meterPulse, what is the default value of all the other signal types (like initialRing, reversePolarity, noBattery)? - pktcSigPulseSignalFrequency same comment as above - pktcSigDevCIDFskAfterRing please specify in the description the value when pktcSigDevCIDMode == dtAsETS / rpAsETS / lrAsETS. - pktcSigDevCIDFskAfterDTAS please specify the value when pktcSigDevCIDMode == northAmerican / duringRingingETS. Also, those 2 previous objects seem to indicate a transmission delay for FSK depending on the CIDmode and they could be combined into 1 object since there is no overlap between their values. - pktcSigDevCIDRingAfterFSK - pktcSigDevCIDDTASAfterLR again, if these objects are only applicable when the mode is X, indicate the value when mode != X - PktcSigDevToneEntry note that pktcSigDevToneWholeToneRepeatCount is 34 chars. See draft-ietf-ops-mib-review-guidelines-01.txt, section 4.2 pktcSigDevToneType is an INTEGER starting with value dtmf0(0). See draft-ietf-ops-mib-review-guidelines-01.txt, section 4.6.1.1.Note that RFC 2578 recommends (but does not require) that integer- valued enumerations start at 1 and be numbered contiguously. This recommendation SHOULD be followed unless there is a valid reason to do otherwise, e.g., to match values of external data or to indicate special cases, and any such special-case usage SHOULD be clearly documented. => in this case, I think it is valid to start with 0, just indicate a valid reason. - pktcSigDevToneSecondFrequency type in "in a ultiple frequency tone." <- d in a multiple frequency tone. - pktcSigEndPntConfigTable nit: packet cable should be one word = PacketCable; other typos in the description clause. - pktcSigEndPntConfigEntry nit: type in enpoint - pktcNcsEndPntConfigCallAgentId makes a reference to pktcMtaDevCmsFqdn which is defined in another MIB. Explain where. - pktcNcsEndPntConfigCallAgentId This is a call agent Inet address that is of fqdn type dns(16). Recommendation is to use InetAddress TC defined in 3291 and recommend the the InetAddressType be dns(16). It is recommended to add some text to indicate when the call agent DNS name should be resolved (probably when the endpoint(s) initiate an NCS RSIP and/or each time a new call is initiated with NTFY ??). Indicate relationship wiht max1/max2 objects defined below in the mib. - pktcNcsEndPntConfigCallAgentUdpPort replace "gateway" by endpoint in this MIB. - pktcNcsEndPntConfigMWD - pktcNcsEndPntConfigTdmax what happens after this delay timer expires? should this be made more clear in the object def? same for all the max timer objects. - pktcNcsEndPntConfigCallWaitingDelay longuer than 32 chars; typo in description clause - pktcNcsEndPntStatusError + operational: when is an MTA operational? could you be more precise? for e.g., does this mean when all the prov 1 thru 25 steps are complete, when all 1..25+1..12 prov-sec are complete or when the provisioning 1..25 is complete and the CMS DNS Id has been resolved, etc. + noSecurityAssociation: note that there may never be a Security Association when ipsec is disabled between MTA and NCS. + description: prepend NCS in front of RSIP: ... an NCS RSIP message exchange... - compliance statement: Should there be a module compliance including pktcInternationalGroup for IPCableCom? W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (2058,6) OBJECT-GROUP "pktcInternationalGroup" is not used in a MODULE-COMPLIANCE in current module - smicng compilation results fyi - no errors; some warning about object names longer than 32 chars: W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1250,6) Name of item "pktcSigDevToneWholeToneRepeatCount" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1406,6) Name of item "pktcNcsEndPntConfigCallAgentUdpPort" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1433,6) Name of item "pktcNcsEndPntConfigCriticalDialTO" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1473,6) Name of item "pktcNcsEndPntConfigMessageWaitingTO" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1486,6) Name of item "pktcNcsEndPntConfigOffHookWarnToneTO" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1537,6) Name of item "pktcNcsEndPntConfigStutterDialToneTO" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1695,6) Name of item "pktcNcsEndPntConfigLongDurationKeepAlive" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1732,6) Name of item "pktcNcsEndPntConfigCallWaitingMaxRep" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1745,6) Name of item "pktcNcsEndPntConfigCallWaitingDelay" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1757,6) Name of item "pktcNcsEndPntStatusCallIpAddressType" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1822,6) Name of item "pktcNcsEndPntConfigPulseDialInterdigitTime" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1835,6) Name of item "pktcNcsEndPntConfigPulseDialMinMakeTime" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1845,6) Name of item "pktcNcsEndPntConfigPulseDialMaxMakeTime" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1855,6) Name of item "pktcNcsEndPntConfigPulseDialMinBreakTime" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1865,6) Name of item "pktcNcsEndPntConfigPulseDialMaxBreakTime" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1875,6) Name of item "pktcNcsEndPntConfigNomJitterBufferSize" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1888,6) Name of item "pktcNcsEndPntConfigMaxJitterBufferSize" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1898,6) Name of item "pktcNcsEndPntConfigOnHookDebounce" is longer than recommended max of 32 W: f(draft-ietf-ipcdn-pktc-signaling-00.mi2), (1908,6) Name of item "pktcNcsEndPntConfigOffHookDebounce" is longer than recommended max of 32 >end. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 19 00:33:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16895 for ; Wed, 19 Mar 2003 00:33:12 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2J5oOb21877 for ipcdn-archive@odin.ietf.org; Wed, 19 Mar 2003 00:50:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J5oKO21850; Wed, 19 Mar 2003 00:50:20 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2J5jqO21648 for ; Wed, 19 Mar 2003 00:45:52 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16739 for ; Wed, 19 Mar 2003 00:28:08 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.8/8.12.8) with ESMTP id h2J5UJOe004489; Tue, 18 Mar 2003 22:30:19 -0700 (MST) Received: from 147.191.90.11 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Tue, 18 Mar 2003 22:30:08 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 18 Mar 2003 22:29:17 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC0566380B@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" cc: "Jean-Francois Mule (E-mail)" , "Woundy, Richard" Date: Tue, 18 Mar 2003 22:29:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1266DFEA6769-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2J5jqO21649 Subject: [ipcdn] More comments on the PacketCable MTA 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: , Content-Transfer-Encoding: 8bit Folks, Here are some additional comments on the PacketCable MTA MIB. Many of these comments can be traced back to sections in the "Guidelines for MIB Authors and Reviewers", . All references to the "Guidelines" will be to that document. - Please keep the width of the ASCII format of the draft to 72 characters. My copy of the draft has a width of 73 characters, which includes trailing spaces. I'll admit this is closer than the other two PacketCable drafts. - The "Abstract" section is not supposed to be numbered, and is not supposed to contain any references, e.g. "[5][6][7]". See Guidelines Appendix A, item 2. - The first and third paragraphs of the "Abstract" can be deleted. The first paragraph is irrelevant, and the third paragraph is redundant with the "Management Framework" section. See draft-ietf-ipcdn-subscriber-mib-10.txt for a recent example of a good Abstract. - Change "The SNMP Management Framework" to "The Internet-Standard Management Framework", and follow the MIB boilerplate in . You may wish to delete a number of References as a result. See Guidelines Appendix A, item 3. - There is a non-ASCII character in the definition of Public Key Certificate: "entityÆs" should be "entity's". This appears to be a Microsoft Word artifact. - The DHCP definition should refer to RFC 2131. The FQDN definition should refer to RFCs 1034 and 1035; RFC 821 describes the format of the entire endpoint name, not just the FQDN. The Security Association definition should refer to RFC 2401. Perhaps these RFC references should be added to the "Information References" section? - The CMS definition probably should refer to "MTAs" rather than to "TAs". - The text in section 4.1 should be cleaned up. There needs to be stronger correlation between the objects in pktcMtaDevServer and the new RFC 3495 for the DHCP CCC option -- which should be in the Normative References section. Note that pktcMtaDevServerDns1 and pktcMtaDevServerDns2 needs to be reconciled with a variable number of domain name servers possible in DHCP option 6 -- note that it might be OK to retain these two objects (it seems overkill to add a table for this management issue). - Assuming that the WG accepts my comments on table indexing for the RealmTable and CmsTable, text in section 4.2 concerning "Realm Table to CMS Table Relationship" will need to be revised. - In the MODULE-IDENTITY, please update my contact information to "richard_woundy@cable.comcast.com". - The MODULE-IDENTITY should include the new copyright clause. See Guidelines section 3.8. - Our IPCDN MIBs should not define a TEXTUAL-CONVENTION called X509Certificate -- the name is too generic for the usage in our WG. At the interim meeting , Bert Wijnen suggested using a name such as DocsX509ASN1DEREncodedCertificate for the BPI+ MIB. Should that TEXTUAL-CONVENTION (when it is included in a revised DOCSIS BPI+ MIB) be imported into this MIB? Is there a reason that the BPI+ MIB X.509 certificate can be up to 1400 bytes, but the MTA MIB X.509 certificate can be up to 4096 bytes??? - Many comments in the MIB need to be fixed, so that the comment text is on the same line as the "--" indicator. - Is the value of pktcMtaDevMacAddress already captured in ifPhysAddress? So is this MTA MIB object redundant? - Objects such as pktcMtaDevEndPntCount should use SYNTAX "Unsigned 32 (1..255)" rather than "Integer32 (1..255)". This also applies to pktcMtaDevProvisioningTimer, pktcMtaDevErrorOidIndex, and quite a few other objects. See Guidelines section 4.6.1.1. - Some folks in the WG have had a dispute about the use of DEFVAL clauses for scalar objects such as pktcMtaDevProvisioningTimer and a number of other objects. I already asked one MIB doctor at the IETF who wasn't sure about the answer. This needs to be resolved. - Is it important that pktcMtaDevProvisioningCounter reflect a count "since the last reboot"? If so, you need to use ZeroBasedCounter32 from RMON2-MIB instead. See Guidelines section 4.6.1.2. - Why does pktcMtaDevErrorOid use the SYNTAX SnmpAdminString, when it could use the SYNTAX OBJECT IDENTIFIER from RFC 2578 section 7.1.3? - The object pktcMtaDevErrorValueGiven seems somewhat odd, in that it might encode a value of any SYNTAX type. But maybe this is correct. We might need to ask a real MIB doctor here. - The DESCRIPTION clauses for pktcMtaDevServerDns1 and pktcMtaDevServerDns2 need to be revised to refer to DHCP option 6, for alignment with RFC 3495. - The DESCRIPTION of pktcMtaDevConfigFile assumes a TFTP URL format, which won't be approved until draft-lear-tftp-uri-02.txt is approved. This draft has been stuck in Area Director review for about a year. - The SYNTAX of pktcMtaDevProvKerbRealmName is SnmpAdminString, which supports UTF-8 format as well as ASCII format. The DESCRIPTION refers specifically to "upper case ASCII representation". Wouldn't it be sufficient to state that the value of this object must match the value of pktcMtaDevRealmName in the appropriate RealmTable row? - It may be worth investigating whether multiple InetAddressType objects are needed in this MIB. We might be able to define a single pktcMtaDevServerAddressType object that is shared by multiple MTA MIB objects (e.g. pktcMtaDevServerDhcp1), rather than defining individual objects (e.g. pktcMtaDevServerDhcp1AddressType). Objects with SYNTAX InetAddress (e.g. pktcMtaDevServerDhcp1) need to refer to the appropriate InetAddressType object in their DESCRIPTION clauses. - The SYNTAX of pktcMtaDevCorrelationId should be "Unsigned (0..4294967295)" instead of "Integer32"; see Guidelines section 4.6.1.1. - Please consider changing the indexing of the RealmTable and CmsTable per my recent email. That also implies that you might relax the constraint on "upper case ASCII representation" for the pktcMtaDevRealmName object. Also see the discussion about table indexing and the dangers of long OIDs in Guidelines section 4.6.5. - For the pktcMtaDevRealmOrgName object, does this refer to the Service Provider CA Certificate as defined in the PacketCable Security Spec? Is the "organization name attribute" equal to what follows "O=" in the Subject Name? Why is this encoded as SYNTAX "OCTET STRING (SIZE (1..64))" instead of "SnmpAdminString"? Where does the assumption about a 64 byte organization name come from??? - REFERENCE clauses should not contain numeric references (such as [18]), because the context for such numeric references are lost when the MIB is extracted from the draft/RFC. - The RowStatus objects for the RealmTable and CmsTable may need some additional DESCRIPTION text. If any columns MUST to be populated before the row is activated, that has to be described in the status object. Also, the object MUST describe whether other column values can be changed when the row status is active. See Guidelines section 4.6.3. - We need to add StorageType objects to the RealmTable and CmsTable; alterbatively, each table entry DESCRIPTION clause MUST specify what happens to dynamically-created rows after an MTA restart. Since Kerberos tickets might or might not persist beyond an MTA restart, we might not be able to declare the RealmTable rows to be volatile in all circumstances. See Guidelines section 4.6.3. - Sections 6, 7, and 8 could be better formatted (this is a nit about line feeds). - The references MUST be split into Normative and Information Reference sections. See Guidelines Appendix A, item 5. The split of Normative and Information References for the MIB boilerplate language is defined in . - The references [1] through [4], and [8] through [16], could be deleted. They were required by the old MIB boilerplate. I don't think you need to include reference [20] in order to describe an SNMP Inform PDU; the boilerplate should take care of this. - Please clean up the text of references [17] through [19]. draft-ietf-ipcdn-subscriber-mib-10.txt and draft-ietf-ipcdn-qos-mib-08.txt are good models to start with. - Please rewrite the "Security Considerations" according to the MIB Security Considerations boilerplate in . You should consider which read-write/read-create and read-only objects should be considered sensitive and why. See some of the more mature DOCSIS MIBs for some examples. - The "Full Copyright Statement" uses the year "2001" for a 2002 draft. -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Wed Mar 19 16:05:16 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08112 for ; Wed, 19 Mar 2003 16:05:16 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2JLMmQ04921 for ipcdn-archive@odin.ietf.org; Wed, 19 Mar 2003 16:22:48 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLMUO04901; Wed, 19 Mar 2003 16:22:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2JLJZO04496 for ; Wed, 19 Mar 2003 16:19:35 -0500 Received: from snowmass.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07789 for ; Wed, 19 Mar 2003 16:01:31 -0500 (EST) Received: from mms02-relaya.tci.com (mms02-relaya.broadband.att.com [147.191.89.206]) by snowmass.tci.com (8.12.8/8.12.8) with ESMTP id h2JL3kOe022106 for ; Wed, 19 Mar 2003 14:03:46 -0700 (MST) Received: from 147.191.89.201 by mms02-RelayB.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Wed, 19 Mar 2003 14:03:37 -0600 Received: by entexchimc02.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Wed, 19 Mar 2003 14:03:03 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC05663811@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" Date: Wed, 19 Mar 2003 14:03:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 126604A371765-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] Presentation from today's IPCDN working group meeting in San Fran cisco Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, The slides for today's meeting can be found at: . -- Rich _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From mailnull@www1.ietf.org Mon Mar 31 22:01:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08153 for ; Mon, 31 Mar 2003 22:01:22 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h313Ot609585 for ipcdn-archive@odin.ietf.org; Mon, 31 Mar 2003 22:24:55 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h313OdK09569; Mon, 31 Mar 2003 22:24:39 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h313NRK09489 for ; Mon, 31 Mar 2003 22:23:27 -0500 Received: from peacock.tci.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08055 for ; Mon, 31 Mar 2003 21:59:23 -0500 (EST) Received: from mms01-relayb.tci.com (mms01-relayb.broadband.att.com [147.191.90.1]) by peacock.tci.com (8.12.8/8.12.8) with ESMTP id h312xPnu021757; Mon, 31 Mar 2003 19:59:25 -0700 (MST) Received: from 147.191.90.11 by mms01-relaya.tci.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.5.0)); Mon, 31 Mar 2003 19:59:20 -0600 Received: by entexchimc04.broadband.att.com with Internet Mail Service ( 5.5.2653.19) id ; Mon, 31 Mar 2003 19:58:34 -0700 Message-ID: <6732623D2548D61193C90002A5C88DCC056638A2@entmaexch02.broadband.att.com> From: "Woundy, Richard" To: "IPCDN WG (E-mail)" , "DOCSIS OSS (E-mail)" cc: "Greg White" , "Eduardo Cardona" , "Michael W. Patrick (E-mail)" , "William Murwin (E-mail)" Date: Mon, 31 Mar 2003 19:59:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 1297DF021308214-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [ipcdn] DOCSIS QoS MIB and the use of 0 as the wildcard VLAN ID Sender: ipcdn-admin@ietf.org Errors-To: ipcdn-admin@ietf.org X-BeenThere: ipcdn@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Cable Data Network List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, I am concerned about the lack of resolution to this issue of a "default VLAN ID" for the DOCSIS QoS MIB. Besides my concern about using a different VLAN ID definition than other IETF MIBs, my concern centers on this comment from Les Bell of 3Com: >We should not use the value 0 to indicate "any" VLAN, as this may be >used by 802.1D Bridges that support Priority Tagging, but do not >support 802.1Q VLANs. In a later email, as IETF MIB folks suggested using 4095 as the "wildcard" VLAN ID, Les' reaction was: >I have asked for the opinion of the IEEE 802.1 Task Force Chair, Mick >Seaman, on this proposal. He believes that the use of 4095 as a >wildcard VLAN-ID would be okay, but he wants to discuss it formally at >the IEEE 802 meeting in Dallas (week commencing March 9). I will be >attending this meeting. I am going to try to find out the reaction of the IEEE to this proposal. The latest proposed IETF TEXTUAL CONVENTION for a VLAN ID (with wildcard support) is: VlanIdOrAny ::= TEXTUAL CONVENTION DISPLAY-HINT "d" STATUS current DESCRIPTION "The VLAN ID that uniquely identifies a VLAN. The value of -1 is used to indicate a wildcard, i.e. any value. " SYNTAX Integer32 (-1 | 1..4094) I cannot find anything in the DOCSIS specifications, outside of the DOCSIS QoS MIB, that uses 0 as a special VLAN ID. -- Rich -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: Thursday, February 13, 2003 3:37 PM To: Greg White; Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt Inline > -----Original Message----- > From: Greg White [mailto:g.white@CableLabs.com] > Sent: donderdag 13 februari 2003 20:07 > To: Wijnen, Bert (Bert); Eduardo Cardona; Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > It is important that the range for docsQosPktClassVlanId include the > value 0: > > If the referenced parameter is not present in the > classifier, the value of this object is reported > as 0. > Well, yours also goes up to (and inclusive) 4095 while bridgemib only goes up to (and inclusive 4094). If zero is not a valid VLAN ID and you want to niclude it as not present, then maybe yours should be renamed to docsQosPktClassVlanIdOrNone or some such Bert > -Greg > > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Thursday, February 13, 2003 11:44 AM > To: Eduardo Cardona; Wijnen, Bert (Bert); Ipcdn (E-mail) > Subject: RE: [ipcdn] quick review of draft-ietf-ipcdn-qos-mib-07.txt > > > Eduardo writes: > > > > FYI > > Could be in other places but a starting point. > > > > draft-ietf-bridge-bridgemib-01.txt > > > > VlanId ::= TEXTUAL-CONVENTION > > STATUS current > > DESCRIPTION > > "The 12-bit VLAN ID used in the VLAN Tag header." > > SYNTAX INTEGER (1..4094) > > > And so... why does yours differ > docsQosPktClassVlanId OBJECT-TYPE > SYNTAX Integer32 (0..4095) > MAX-ACCESS read-only > STATUS current > > I am not claiming that one is better than the other. > But I always wonder why they are different. > Best to try and get in touch with the bridgemib people > > Bert _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn