From dime-bounces@ietf.org Mon May 01 22:56:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fal4E-0000lQ-8X; Mon, 01 May 2006 22:56:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fal4D-0000lA-Kl; Mon, 01 May 2006 22:56:49 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fal4C-0002w7-6L; Mon, 01 May 2006 22:56:49 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k422uk2j029742; Tue, 2 May 2006 05:56:46 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 05:56:46 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 05:56:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 05:56:45 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB40766C@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Meeting Survey Thread-Index: AcZtM1sYPortiF/kR6uLPlMsAqmacgAYIF1w From: To: , , X-OriginalArrivalTime: 02 May 2006 02:56:45.0586 (UTC) FILETIME=[0C50FF20:01C66D94] X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Dime] FW: IETF Meeting Survey X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, Please take the time and fill out the survey below. This will help us run the IETF meetings more effectively, and ensure that your requirements are heard. thanks, John >-----Original Message----- >From: ext Ray Pelletier [mailto:rpelletier@isoc.org]=20 >Sent: 01 May, 2006 18:25 >To: wgchairs@ietf.org >Subject: IETF Meeting Survey > >All; >It has been suggested that if I really wanted to get feedback=20 >on the Meeting Survey (and I do) I should have it forwarded=20 >by the WG Chairs to the working groups - so this is a request=20 >that you ask members of the working groups to complete a short=20 >survey that focuses primarily, but not exclusively, on their=20 >meeting experience in Dallas.=20 > >I truly want the info to make the changes members of the=20 >community want, if possible and greatly appreciate your=20 >assistance in this regard. > >Those interested in taking the survey can find it at: >http://www.surveymonkey.com/s.asp?u=3D649182049947 > >Thanks >Ray Pelletier >IETF Admininstrative Director > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 04 08:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbcj0-0007nC-Vf; Thu, 04 May 2006 08:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbcj0-0007kV-6m for dime@ietf.org; Thu, 04 May 2006 08:14:30 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbciw-0007sO-Nu for dime@ietf.org; Thu, 04 May 2006 08:14:30 -0400 Received: (qmail invoked by alias); 04 May 2006 12:14:18 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp011) with SMTP; 04 May 2006 14:14:18 +0200 X-Authenticated: #29516787 Message-ID: <4459F016.40308@gmx.net> Date: Thu, 04 May 2006 14:14:14 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org, jouni.korhonen@teliasonera.com, Julien Bournelle , John Loughney Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Dime] Diameter MIPv6: Next Steps X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, in a discussion with John we have decided to select two experienced draft editors for two Diameter MIPv6 documents. Jouni is going to be the editor of the Diameter MIPv6 integrated scenario draft. Julien will be the editor of the Diameter MIPv6 split scenario document. We have decided not to combine the two documents for now. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 04 10:45:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbf4t-0007o4-I8; Thu, 04 May 2006 10:45:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbf4r-0007ix-MD for dime@ietf.org; Thu, 04 May 2006 10:45:13 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbf4q-00073w-9n for dime@ietf.org; Thu, 04 May 2006 10:45:13 -0400 Received: (qmail invoked by alias); 04 May 2006 14:45:10 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp039) with SMTP; 04 May 2006 16:45:10 +0200 X-Authenticated: #29516787 Message-ID: <445A1372.2050406@gmx.net> Date: Thu, 04 May 2006 16:45:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Dime] Diameter QoS: Scenarios X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, to start our work on Diameter QoS we need to revisit some design decisions. I will start with the usage scenarios. When we worked in NSIS on QoS signaling (and reviewing the work on RSVP) we obviously realized that authorization is an important aspect of the entire QoS story. The Diameter QoS draft (see the latest version draft-tschofenig-dime-diameter-qos-00) particularly addresses the authorization aspect by outlining different authorization models in Section 3.2. The scenarios listed below result in different message exchanges and, as a consequence, with a different content. The QoS specific attributes are in many cases provided via the QoS signaling protocol and forwarded towarded along the AAA infrastructure for authorization. Depending on the authorization model it might be necessary for the node initiating the QoS reservation to provide an authorization token along with it (see Figure 4 of draft-tschofenig-dime-diameter-qos-00.txt). If no authorization token is provided then the previously executed network access authentication procedure (see Figure 3 of draft-tschofenig-dime-diameter-qos-00.txt) might be utilized. The QoS attributes are sent from the Diameter client to the Diameter server indicating a request for authorization and the response might also carry QoS attributes if there are modifications to these attributes. (We ignore session termination, re-authorization for a moment.) A further scenario that is relevant for the QoS work is the ability to provide QoS attributes as a result of a network access authentication protocol run. Finally, the ability for a Diameter server-side initiated QoS provisioning was seen as an important usage scenario. Does someone disagree with the above-listed scenarios? Are some scenarios missing? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 04 17:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkx0-0004fj-3U; Thu, 04 May 2006 17:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkwy-0004cW-Id for dime@ietf.org; Thu, 04 May 2006 17:01:28 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbkwx-0007P2-4M for dime@ietf.org; Thu, 04 May 2006 17:01:28 -0400 Received: (qmail invoked by alias); 04 May 2006 21:01:25 -0000 Received: from p54985C8A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.92.138] by mail.gmx.net (mp021) with SMTP; 04 May 2006 23:01:25 +0200 X-Authenticated: #29516787 Message-ID: <445A6BA3.9050804@gmx.net> Date: Thu, 04 May 2006 23:01:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Dime] Diameter QoS: Quality of Service Parameter Description X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, draft-tschofenig-dime-diameter-qos-00.txt reuses the QSPEC object to carry QoS parameters. The QSPEC template http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt provides a number of QoS attributes that are used by Qos models (e.g., IntServ CL). By using the QSPEC it is easy support RSVP, other signaling protocols (e.g., link layer protocols) as well as other usage environments (e.g., an environment where priority or only bandwidth parameters are exchanged). Do others consider this as a useful approach? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 04 17:01:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkx3-0004gw-78; Thu, 04 May 2006 17:01:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkx1-0004gC-CO for dime@ietf.org; Thu, 04 May 2006 17:01:31 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbkx1-0007PF-09 for dime@ietf.org; Thu, 04 May 2006 17:01:31 -0400 Received: (qmail invoked by alias); 04 May 2006 21:01:30 -0000 Received: from p54985C8A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.92.138] by mail.gmx.net (mp038) with SMTP; 04 May 2006 23:01:30 +0200 X-Authenticated: #29516787 Message-ID: <445A6BA7.4080906@gmx.net> Date: Thu, 04 May 2006 23:01:27 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Dime] Diameter QoS: Interaction with Accounting and Credit Control X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, in the past we received a few comments regarding the interaction between Diameter Accounting and Diameter Credit Control. The current approach is the following: * draft-tschofenig-dime-diameter-qos-00.txt describes the interaction with accounting in Section 5. * It does not build on top of Diameter Credit Control. * A simplified online and volume based charging approach is described in Section 7.2 of draft-tschofenig-dime-diameter-qos-00.txt. * Diameter Credit Control interworking is possible but currently not specified in the document. Are there objections? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 04 17:01:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkx9-0004qD-Jx; Thu, 04 May 2006 17:01:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbkx8-0004pC-Ew for dime@ietf.org; Thu, 04 May 2006 17:01:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fbkx5-0007PO-75 for dime@ietf.org; Thu, 04 May 2006 17:01:38 -0400 Received: (qmail invoked by alias); 04 May 2006 21:01:34 -0000 Received: from p54985C8A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.92.138] by mail.gmx.net (mp043) with SMTP; 04 May 2006 23:01:34 +0200 X-Authenticated: #29516787 Message-ID: <445A6BAB.4030705@gmx.net> Date: Thu, 04 May 2006 23:01:31 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Dime] Diameter QoS: Issue Tracker X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, we have maintained an issue tracker for the Diameter QoS document: http://www.tschofenig.priv.at:8080/diameter-qos/index Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 05 02:35:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbtuU-0005CT-Tf; Fri, 05 May 2006 02:35:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbtuR-0004gj-IO for dime@ietf.org; Fri, 05 May 2006 02:35:27 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbtuQ-0003LO-4b for dime@ietf.org; Fri, 05 May 2006 02:35:27 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k456ZNEA011101; Fri, 5 May 2006 09:35:23 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:35:05 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:35:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Diameter QoS: Interaction with Accounting and Credit Control Date: Fri, 5 May 2006 09:35:04 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB4076E1@esebe100.NOE.Nokia.com> In-Reply-To: <445A6BA7.4080906@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter QoS: Interaction with Accounting and Credit Control Thread-Index: AcZvvfmsD8c6B02uQhmet74Gut8SUgAT/ikQ From: To: , X-OriginalArrivalTime: 05 May 2006 06:35:05.0008 (UTC) FILETIME=[0B6B6B00:01C6700E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Just to follow-up: >in the past we received a few comments regarding the=20 >interaction between Diameter Accounting and Diameter Credit Control. > >The current approach is the following: > >* draft-tschofenig-dime-diameter-qos-00.txt describes the=20 >interaction with accounting in Section 5. > >* It does not build on top of Diameter Credit Control. > >* A simplified online and volume based charging approach is=20 >described in Section 7.2 of draft-tschofenig-dime-diameter-qos-00.txt. > >* Diameter Credit Control interworking is possible but=20 >currently not specified in the document. If there are any needs for Diameter Credit Control interworking, it would be good if people could state what their requirements or needs are. thanks, John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 05 02:39:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbtxx-0005Wr-Rx; Fri, 05 May 2006 02:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbtxw-0005Wh-ID for dime@ietf.org; Fri, 05 May 2006 02:39:04 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbtxu-0003T1-ME for dime@ietf.org; Fri, 05 May 2006 02:39:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k456d02e001989; Fri, 5 May 2006 09:39:00 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:38:08 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 09:38:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2006 09:38:07 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB4076E2@esebe100.NOE.Nokia.com> In-Reply-To: <4459F016.40308@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Diameter MIPv6: Next Steps Thread-Index: AcZvdE0PIVgf++KYS4e9LkPod5cefgAmg19g From: To: , , , X-OriginalArrivalTime: 05 May 2006 06:38:08.0873 (UTC) FILETIME=[7902FD90:01C6700E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [Dime] RE: Diameter MIPv6: Next Steps X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org As a follow-up, >in a discussion with John we have decided to select two=20 >experienced draft editors for two Diameter MIPv6 documents. > >Jouni is going to be the editor of the Diameter MIPv6=20 >integrated scenario draft. > >Julien will be the editor of the Diameter MIPv6 split scenario=20 >document. > >We have decided not to combine the two documents for now. After the initial documents are submitted, if there is consensus that they should be combined, then we can consider this, but at the moment, the feeling is that these can stand-alone. John _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 08 04:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0vH-0004aE-GI; Mon, 08 May 2006 04:16:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd0vF-0004ZH-0Z for dime@ietf.org; Mon, 08 May 2006 04:16:53 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd0rz-0005op-AF for dime@ietf.org; Mon, 08 May 2006 04:13:32 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k488AG01025859; Mon, 8 May 2006 11:10:19 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 11:10:18 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 11:10:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 8 May 2006 11:10:17 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB407719@esebe100.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Policy representation for AAA server Thread-Index: AcZsHR1DeOyBx6p+TtC2BSlyH0naHAGWaw2Q From: To: X-OriginalArrivalTime: 08 May 2006 08:10:18.0001 (UTC) FILETIME=[D7DE3810:01C67276] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: isalekul@hotmail.com Subject: [Dime] FW: [AAA-WG]: Policy representation for AAA server X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0567811504==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0567811504== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67276.D777CE6E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67276.D777CE6E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forward to the DiME WG, in case any one has opinions for Diameter. =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul Islam Sent: 30 April, 2006 08:55 To: aaa-wg@merit.edu Cc: Salekul Islam Subject: [AAA-WG]: Policy representation for AAA server =09 =09 Hi, =20 I am interested in policy representation or policy server in Diameter architecture. Is there any Internet Draft or paper addressing the issues related to policy representation for AAA server? Is there any specific direction or goal of the WG regarding this issue? =20 Any sort of information will be very helpful for me. =20 regards, =20 Salekul Islam PhD candidate, Concordia University Montreal, Canada =20 ------_=_NextPart_001_01C67276.D777CE6E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Forward to the DiME WG, in case any one has = opinions for=20 Diameter.
 
John

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul=20 Islam
Sent: 30 April, 2006 08:55
To:=20 aaa-wg@merit.edu
Cc: Salekul Islam
Subject: = [AAA-WG]:=20 Policy representation for AAA server

Hi,
 
I am interested in policy = representation or=20 policy server in Diameter architecture. Is there any Internet Draft or = paper=20 addressing the issues related to policy representation for AAA = server? Is=20 there any specific direction or goal of the WG regarding this=20 issue?
 
Any sort of information will be very = helpful for=20 me.
 
regards,
 
Salekul Islam
PhD candidate, Concordia University
Montreal, Canada
 
------_=_NextPart_001_01C67276.D777CE6E-- --===============0567811504== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0567811504==-- From dime-bounces@ietf.org Mon May 08 04:23:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd11H-0008Oq-Ek; Mon, 08 May 2006 04:23:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd11G-0008Hu-Eg for dime@ietf.org; Mon, 08 May 2006 04:23:06 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd11F-0006Z1-Tm for dime@ietf.org; Mon, 08 May 2006 04:23:06 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k488Mwf3010620; Mon, 8 May 2006 10:22:58 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k488MwHm021485; Mon, 8 May 2006 10:22:58 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:22:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [Dime] FW: [AAA-WG]: Policy representation for AAA server Date: Mon, 8 May 2006 10:22:51 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] FW: [AAA-WG]: Policy representation for AAA server Thread-Index: AcZsHR1DeOyBx6p+TtC2BSlyH0naHAGWaw2QAABc2IA= From: "Tschofenig, Hannes" To: , X-OriginalArrivalTime: 08 May 2006 08:22:57.0983 (UTC) FILETIME=[9CDA44F0:01C67278] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: isalekul@hotmail.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0012316063==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0012316063== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67278.9CA2ACE6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67278.9CA2ACE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Salekul,=20 =20 could you formulate your question in more detail?=20 What type of policies are you talking about? E.g., policies that represent the business logic at a AAA server or policies that are conveyed from the AAA server to the AAA client? Are you looking for a language to express these policies or rather for the content of these policies? Do you have a specific application in mind (e.g., policies regarding charging, QoS, location information) =20 Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 8. Mai 2006 10:10 An: dime@ietf.org Cc: isalekul@hotmail.com Betreff: [Dime] FW: [AAA-WG]: Policy representation for AAA server =09 =09 Forward to the DiME WG, in case any one has opinions for Diameter. =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul Islam Sent: 30 April, 2006 08:55 To: aaa-wg@merit.edu Cc: Salekul Islam Subject: [AAA-WG]: Policy representation for AAA server =09 =09 Hi, =20 I am interested in policy representation or policy server in Diameter architecture. Is there any Internet Draft or paper addressing the issues related to policy representation for AAA server? Is there any specific direction or goal of the WG regarding this issue? =20 Any sort of information will be very helpful for me. =20 regards, =20 Salekul Islam PhD candidate, Concordia University Montreal, Canada =20 ------_=_NextPart_001_01C67278.9CA2ACE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Salekul,=20
 
could you formulate your question in more = detail?=20
What type of policies are you talking about? = E.g.,=20 policies that represent the business logic at a AAA server or policies = that are=20 conveyed from the AAA server to the AAA client? Are you looking for a = language=20 to express these policies or rather for the content of these policies? = Do you=20 have a specific application in mind (e.g., policies regarding charging, = QoS,=20 location information)
 
Ciao
Hannes
 

Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 8. Mai = 2006=20 10:10
An: dime@ietf.org
Cc:=20 isalekul@hotmail.com
Betreff: [Dime] FW: [AAA-WG]: Policy=20 representation for AAA server

Forward to the DiME WG, in case any one has = opinions for=20 Diameter.
 
John

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul=20 Islam
Sent: 30 April, 2006 08:55
To:=20 aaa-wg@merit.edu
Cc: Salekul Islam
Subject: = [AAA-WG]:=20 Policy representation for AAA server

Hi,
 
I am interested in policy = representation or=20 policy server in Diameter architecture. Is there any Internet Draft = or paper=20 addressing the issues related to policy representation for AAA = server?=20 Is there any specific direction or goal of the WG regarding = this=20 issue?
 
Any sort of information will be = very helpful=20 for me.
 
regards,
 
Salekul Islam
PhD candidate, Concordia University
Montreal, Canada
 
------_=_NextPart_001_01C67278.9CA2ACE6-- --===============0012316063== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0012316063==-- From dime-bounces@ietf.org Thu May 11 12:21:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDuf-0001fF-LH; Thu, 11 May 2006 12:21:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDue-0001fA-Uv for dime@ietf.org; Thu, 11 May 2006 12:21:16 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeDue-0000lX-7r for dime@ietf.org; Thu, 11 May 2006 12:21:16 -0400 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 11 May 2006 12:25:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Policy based Applications and QoS Application Thread-index: AcZsHR1DeOyBx6p+TtC2BSlyH0naHAGWaw2QAABc2IAApz6zQA== From: "Avi Lior" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Cc: isalekul@hotmail.com, "Tschofenig, Hannes" Subject: [Dime] Policy based Applications and QoS Application X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1500574288==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1500574288== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67517.765F9024" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67517.765F9024 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 This email prompts me to start a discussion on Policy and QoS Application. =20 As some of you are aware IMS Rel 7.0 has an entity called PCRF. This PCRF is supposed to broker per flow based policy actions between the IMS infrastructure and the Network. Initially this policy was QoS and in release 7.0 it also brokers Charging Policy. In the future it will probably broker other per flow policy. For example, it may instruct the network to apply security policies to a flow or group of flows. =20 The QoS Application that is being developed by the IETF (IMO) was targeting the Policy entity in its IMS Rel 6.0 form when it was called the PDF instead of PCRF and when it was only serving QoS policies. Now in rel 7.0 the Diameter application being developed is serving both QoS and Charging information and is based on the Diameter Credit Control function. =20 =20 Also QoS policies are also delivered as part of Authentication. So EAP Application may be used to deliver initial QoS policies to the User session being authenticated and authorized. =20 So I am raising the following questions: =20 1) Is there any reason to create a QoS Application in Diameter? =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3) Perhaps we should just define QoS based attributes that can be pulled into various future Diameter Applications. =20 =20 Comments are welcome!!! =20 =20 ________________________________ From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Monday, May 08, 2006 4:23 AM To: john.loughney@nokia.com; dime@ietf.org Cc: isalekul@hotmail.com Subject: AW: [Dime] FW: [AAA-WG]: Policy representation for AAA server =09 =09 Hi Salekul,=20 =20 could you formulate your question in more detail?=20 What type of policies are you talking about? E.g., policies that represent the business logic at a AAA server or policies that are conveyed from the AAA server to the AAA client? Are you looking for a language to express these policies or rather for the content of these policies? Do you have a specific application in mind (e.g., policies regarding charging, QoS, location information) =20 Ciao Hannes =20 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 8. Mai 2006 10:10 An: dime@ietf.org Cc: isalekul@hotmail.com Betreff: [Dime] FW: [AAA-WG]: Policy representation for AAA server =09 =09 Forward to the DiME WG, in case any one has opinions for Diameter. =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul Islam Sent: 30 April, 2006 08:55 To: aaa-wg@merit.edu Cc: Salekul Islam Subject: [AAA-WG]: Policy representation for AAA server =09 =09 Hi, =20 I am interested in policy representation or policy server in Diameter architecture. Is there any Internet Draft or paper addressing the issues related to policy representation for AAA server? Is there any specific direction or goal of the WG regarding this issue? =20 Any sort of information will be very helpful for me. =20 regards, =20 Salekul Islam PhD candidate, Concordia University Montreal, Canada =20 ------_=_NextPart_001_01C67517.765F9024 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi All,
 
This email prompts me to start a discussion on = Policy and=20 QoS Application.
 
As some of you are aware IMS Rel 7.0 has an = entity called=20 PCRF.  This PCRF is supposed to broker per flow based policy = actions=20 between the IMS infrastructure and the Network.  Initially this = policy was=20 QoS and in release 7.0 it also brokers Charging Policy.  In the = future it=20 will probably broker other per flow policy.  For example, it may = instruct=20 the network to apply security policies to a flow or group of=20 flows.
 
The QoS Application that is being = developed by the=20 IETF (IMO) was targeting the Policy entity in its IMS Rel 6.0 form when = it was=20 called the PDF instead of PCRF and when it was only serving QoS = policies. =20 Now in rel 7.0 the Diameter application being developed is serving both = QoS and=20 Charging information and is based on the Diameter Credit Control = function. =20
 
Also QoS policies are also delivered as part of = Authentication.  So EAP Application may be used to deliver initial = QoS=20 policies to the User session being authenticated and=20 authorized.
 
So I am raising the following=20 questions:
 
1) Is there any reason to create a QoS = Application in=20 Diameter?
 
2) Should we work on a Diameter Flow-based = Policy=20 Application that is able to deliver QoS/Charging and in the future other = flow=20 based application?
-Should this work be done in the IETF? Do we = get folks in=20 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF.  Or = perhaps=20 we can agree to work on this together outside the = IETF?
 
3) Perhaps we should just define QoS based = attributes that=20 can be pulled into various future Diameter = Applications.
 
 
Comments are welcome!!!
 
 

From: Tschofenig, Hannes=20 [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, May = 08, 2006=20 4:23 AM
To: john.loughney@nokia.com; = dime@ietf.org
Cc:=20 isalekul@hotmail.com
Subject: AW: [Dime] FW: [AAA-WG]: = Policy=20 representation for AAA server

Hi Salekul,=20
 
could you formulate your question in more = detail?=20
What type of policies are you talking = about? E.g.,=20 policies that represent the business logic at a AAA server or policies = that=20 are conveyed from the AAA server to the AAA client? Are you looking = for a=20 language to express these policies or rather for the content of these=20 policies? Do you have a specific application in mind (e.g., policies = regarding=20 charging, QoS, location information)
 
Ciao
Hannes
 

Von: john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 8. Mai = 2006=20 10:10
An: dime@ietf.org
Cc:=20 isalekul@hotmail.com
Betreff: [Dime] FW: [AAA-WG]: Policy=20 representation for AAA server

Forward to the DiME WG, in case any one has = opinions=20 for Diameter.
 
John

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul=20 Islam
Sent: 30 April, 2006 08:55
To:=20 aaa-wg@merit.edu
Cc: Salekul Islam
Subject: = [AAA-WG]:=20 Policy representation for AAA server

Hi,
 
I am interested in policy = representation or=20 policy server in Diameter architecture. Is there any Internet = Draft or=20 paper addressing the issues related to policy = representation for AAA=20 server? Is there any specific direction or goal of the = WG regarding=20 this issue?
 
Any sort of information will be = very helpful=20 for me.
 
regards,
 
Salekul Islam
PhD candidate, Concordia University
Montreal, Canada
=
 
------_=_NextPart_001_01C67517.765F9024-- --===============1500574288== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1500574288==-- From dime-bounces@ietf.org Fri May 12 08:11:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeWUG-0005rL-Mt; Fri, 12 May 2006 08:11:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeTy4-00081P-0k for dime@ietf.org; Fri, 12 May 2006 05:29:52 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeTxy-0007tH-Pm for dime@ietf.org; Fri, 12 May 2006 05:29:51 -0400 Received: from ptpxch009ba020.idc.cww.telecomitalia.it ([156.54.240.52]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 11:29:45 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.227]) by ptpxch009ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 May 2006 11:29:44 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2663 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C675A6.9A4BCB7D" Subject: R: [Dime] Policy based Applications and QoS Application Date: Fri, 12 May 2006 11:29:44 +0200 Message-ID: Importance: normal Priority: normal X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Dime] Policy based Applications and QoS Application thread-index: AcZsHR1DeOyBx6p+TtC2BSlyH0naHAGWaw2QAABc2IAApz6zQAAjuL8g From: "Marchisio Marco Enzo" To: X-OriginalArrivalTime: 12 May 2006 09:29:44.0948 (UTC) FILETIME=[9AD79B40:01C675A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: e57e9866f8343b4d31e7c7757767e962 X-Mailman-Approved-At: Fri, 12 May 2006 08:11:15 -0400 Cc: isalekul@hotmail.com, "Tschofenig, Hannes" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C675A6.9A4BCB7D Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C675A6.9A4BCB7D" ------_=_NextPart_002_01C675A6.9A4BCB7D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All I send you a slide that summarizes and schematizes the 3GPP QoS evolution. Regarding the question 2:=20 =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3GPP Release 6 Introduces Flow Based Charging (FBC) and in Release 7 FBC and QoS are merged together with Diameter interface In Release 5, the QoS was COPS protocol based on =20 Marco =20 ________________________________ Da: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Inviato: Thursday, May 11, 2006 6:25 PM A: dime@ietf.org Cc: isalekul@hotmail.com; Tschofenig, Hannes Oggetto: [Dime] Policy based Applications and QoS Application =20 Hi All, =20 This email prompts me to start a discussion on Policy and QoS Application. =20 As some of you are aware IMS Rel 7.0 has an entity called PCRF. This PCRF is supposed to broker per flow based policy actions between the IMS infrastructure and the Network. Initially this policy was QoS and in release 7.0 it also brokers Charging Policy. In the future it will probably broker other per flow policy. For example, it may instruct the network to apply security policies to a flow or group of flows. =20 The QoS Application that is being developed by the IETF (IMO) was targeting the Policy entity in its IMS Rel 6.0 form when it was called the PDF instead of PCRF and when it was only serving QoS policies. Now in rel 7.0 the Diameter application being developed is serving both QoS and Charging information and is based on the Diameter Credit Control function. =20 =20 Also QoS policies are also delivered as part of Authentication. So EAP Application may be used to deliver initial QoS policies to the User session being authenticated and authorized. =20 So I am raising the following questions: =20 1) Is there any reason to create a QoS Application in Diameter? =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3) Perhaps we should just define QoS based attributes that can be pulled into various future Diameter Applications. =20 =20 Comments are welcome!!! =20 =20 =20 =09 ________________________________ From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Monday, May 08, 2006 4:23 AM To: john.loughney@nokia.com; dime@ietf.org Cc: isalekul@hotmail.com Subject: AW: [Dime] FW: [AAA-WG]: Policy representation for AAA server Hi Salekul,=20 =20 could you formulate your question in more detail?=20 What type of policies are you talking about? E.g., policies that represent the business logic at a AAA server or policies that are conveyed from the AAA server to the AAA client? Are you looking for a language to express these policies or rather for the content of these policies? Do you have a specific application in mind (e.g., policies regarding charging, QoS, location information) =20 Ciao Hannes =20 =20 =09 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 8. Mai 2006 10:10 An: dime@ietf.org Cc: isalekul@hotmail.com Betreff: [Dime] FW: [AAA-WG]: Policy representation for AAA server Forward to the DiME WG, in case any one has opinions for Diameter. =20 John =20 =09 ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul Islam Sent: 30 April, 2006 08:55 To: aaa-wg@merit.edu Cc: Salekul Islam Subject: [AAA-WG]: Policy representation for AAA server Hi, =20 I am interested in policy representation or policy server in Diameter architecture. Is there any Internet Draft or paper addressing the issues related to policy representation for AAA server? Is there any specific direction or goal of the WG regarding this issue? =20 Any sort of information will be very helpful for me. =20 regards, =20 Salekul Islam PhD candidate, Concordia University Montreal, Canada =20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------_=_NextPart_002_01C675A6.9A4BCB7D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi All

I send you a slide that summarizes = and schematizes the 3GPP QoS evolution.

Regarding the question 2: =

 

2) Should we work on a Diameter = Flow-based Policy Application that is able to deliver QoS/Charging and in the = future other flow based application?

-Should this work be done in the = IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF.  Or perhaps we can agree to work on this together outside the = IETF?

 

3GPP Release 6 Introduces Flow = Based Charging (FBC) and in Release 7 FBC and QoS are merged together with = Diameter interface

In Release 5, the QoS was COPS = protocol based on

 

Marco

 

Da: Avi Lior [mailto:avi@bridgewatersystems.com]
Inviato: Thursday, May = 11, 2006 6:25 PM
A: dime@ietf.org
Cc: isalekul@hotmail.com; Tschofenig, Hannes
Oggetto: [Dime] Policy = based Applications and QoS Application

 

Hi All,

 

This email prompts me to start a discussion on Policy and QoS Application.

 

As some of you are aware IMS Rel = 7.0 has an entity called PCRF.  This PCRF is supposed to broker per flow = based policy actions between the IMS infrastructure and the Network.  = Initially this policy was QoS and in release 7.0 it also brokers Charging = Policy.  In the future it will probably broker other per flow policy.  For = example, it may instruct the network to apply security policies to a flow or = group of flows.

 

The QoS Application that is being developed by the IETF (IMO) was targeting the Policy entity in its = IMS Rel 6.0 form when it was called the PDF instead of PCRF and when it was only serving QoS policies.  Now in rel 7.0 the Diameter application = being developed is serving both QoS and Charging information and is based on = the Diameter Credit Control function. 

 

Also QoS policies are also = delivered as part of Authentication.  So EAP Application may be used to deliver = initial QoS policies to the User session being authenticated and = authorized.

 

So I am raising the following = questions:

 

1) Is there any reason to create a = QoS Application in Diameter?

 

2) Should we work on a Diameter = Flow-based Policy Application that is able to deliver QoS/Charging and in the = future other flow based application?

-Should this work be done in the = IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF.  Or perhaps we can agree to work on this together outside the = IETF?

 

3) Perhaps we should just define = QoS based attributes that can be pulled into various future Diameter = Applications.

 

 

Comments are = welcome!!!

 

 

=

 

From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, May 08, = 2006 4:23 AM
To: = john.loughney@nokia.com; dime@ietf.org
Cc: = isalekul@hotmail.com
Subject: AW: [Dime] FW: = [AAA-WG]: Policy representation for AAA server

Hi Salekul,

 

could you formulate your question = in more detail?

What type of policies are you = talking about? E.g., policies that represent the business logic at a AAA server = or policies that are conveyed from the AAA server to the AAA client? Are = you looking for a language to express these policies or rather for the = content of these policies? Do you have a specific application in mind (e.g., = policies regarding charging, QoS, location information)

 

Ciao

Hannes

 

=

 

Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Gesendet: Montag, 8. Mai = 2006 10:10
An: dime@ietf.org
Cc: = isalekul@hotmail.com
Betreff: [Dime] FW: = [AAA-WG]: Policy representation for AAA server

Forward to the DiME WG, in case any = one has opinions for Diameter.

 

John

=

 

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On = Behalf Of ext Salekul Islam
Sent: 30 April, 2006 = 08:55
To: aaa-wg@merit.edu
Cc: Salekul Islam
Subject: [AAA-WG]: Policy representation for AAA server

Hi,

 

I am interested in policy representation or policy = server in Diameter architecture. Is there any Internet Draft or paper addressing = the issues related to policy representation for AAA server? Is there = any specific direction or goal of the WG regarding this = issue?

 

Any sort of information will be very helpful for = me.

 

regards,

 

Salekul Islam

PhD candidate, Concordia University

Montreal, Canada<= /p>

 

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_002_01C675A6.9A4BCB7D-- ------_=_NextPart_001_01C675A6.9A4BCB7D Content-Type: application/x-zip-compressed; name="3GPP Charging and policy evolution.zip" Content-Transfer-Encoding: base64 Content-Description: 3GPP Charging and policy evolution.zip Content-Disposition: attachment; filename="3GPP Charging and policy evolution.zip" UEsDBBQAAAAIADRbrDShZf2yXPkBAACgCQAmAAAAM0dQUCBDaGFyZ2luZyBhbmQgcG9saWN5IGV2 b2x1dGlvbi5wcHTsfAk4ldvX+D6zeZ5VTiJlzDyUOVOIzKTEOcfsHI5jiNAg3eRSKjKUJAlFCFES im6mDFGGTFdIikIizv89h6b7u7/vu/2e//c83/N8rfPs9117rbX3GvZ+tfb77vbTVs7BzCKhIfAX 0AIIsEJlBOjvaExQyUGuVTgAaIZwGISuUKlUGukiVL8ElQyoXIZKJlSuQCULKlehkg2Va1Ch/oL/ NXDZcP30OCMAvfdzb+WJxrA6VjVnNbcNL1Kpz6mDgGOXoYkhgMFgwBv6AWov0KfV/inAvwHiK9A6 +UEG9j33HwL1AeBkAHsBFgETBXBOGIITRn0IRKD5iFrt9suchcERSBQaw8DIxAwJlHIAOAyBgCMR KBSSNnsjID5AcqK4Nsrrorn3uGJEA3gUjpzJZNikV1TDa9U2LaboRj7KyMTHLyAoJL5ZYstWSSVl FVU1dQ39nQaGRsYmu6xtbO3sHRydcHiCu4enl3cgJSg4JPRg2LHo4zEnfjsZm3j23Pmk5AspqVey rmZfy7mem1dccru0rPxORWVt3cNH9Q2P/3jS3tH5rKv7+YueoeGRP0dfjY1PvJ55/2F2bv7jwqdF ml8wgPgasL/1ixPyC45EIpAYml8weAhNgBOJ2iiP5tLdg3EN4BZVOMLAo3cms6iGcZOi1TSvG7mN iU9MaUh8huYa3bN/5tjR/8izr45986sHsCBg0OAhOIE2mIvdcqUK0aolslx4yPX6RE/GMSVWEYfq DlnRjjlNH8v4+vfDTRbr3zx94VW4tTRV5XR9T8RTl7dJvuvSu1tdGJVFBEIzhu2PUgKHzcNCX3XP LuXfye5WxsTs225ycU5z91bOguBziS31urfRdmoTqW3L2aXvpqpPLS7erHV2Gr810cNafto2S9eD sG4xWvpTRLtuXn+fFFyBoSfMfu+S6Dhz7qFdVV0v+6+eqIvccPdO7CBLg9/11wl+Ob0FOoOtOOWu tgHXidQV06a0YRfOSatqZckXcV4DQW+G1DqqzTXT5Yg920tWjodul32wsHWWr9b9QhzvFvfQ/aw3 43bbdGvUu/PkuW3VMy8gEk4+0ksLqSw9f+PMooWVuaheovGfYgGZB9efrD2OLFk3eNxWb7e//Mus QtWFtoLCE1q8CyM24scuwj/sPjkiTthb5UM85T3+3E1I6qKuS3n/bOHrQ61CxX0l8k3iPpaZGhkL SOeq/f3K2jWyDEOVn3H1zltr1WxWSlLdHZzF/Hw+uPnUxnoveo51714USdQS7xKb4f+ttD/SoYlr 0qkl58bjPIsnPedHHy09vFlRY/Ph8ditwntUgPPj9LsnM/yOs8Ss3bty9Fri/QMCHJ5lzOT1DNuP HAzKMew9bXboTBx7S95y+ALsitax6YSapAJRx8Lbn5Rz3h/pmSjc5+zdldmIHJAO5t9jNL4rDObS vIHnQHb8iJBDXkKK63hnXu/kVqfUuyF3iVlJhVkR7B8t5mMDNoscu//77TvWsMbdgvc9jtbopVNK WZRniE+oALmf69z66ktS7mFTh24u7Zucyvms2a5kXLBTMfTYQ5XhUARMvCUlu8f5ZV/xRsxoeadT 28l6npHLzRHWLpeqy2QrP25QnC4/URzDKlFX/Ho376lbld1yTYE1kqT6Gp8sHfu4qdOL3W8it+Du Z9dUnOMuNduZ2x7fj88WLww1jMrQ//xokWE6efHFbMqghF2yFru0Q1yEucpiFWOenEeZJGVD2dKb QyddXQ/mefNp2KYKkkqlen2Et+ij+kMOSlvqpLX0CV49by8RJ7Rc1eErQ7moUWdafNKttMP3prSM qGVwg48XS/B0/eUKMemA62OaGt1/dj8QYd9cNUOqsWtHe0qXyk3l9uy4FW/O1jViU+7xcvfzq/dK YhUThiNTCrt6FqgAtU1S4NAHxXOkZjWrU1NP0l/dP/R0tjxNO4cKvF0EwiMlpvOPbLXtYDzycOT1 o6DQ1KJMg9LyylvnK8KW3t8fl3qvOnK/XOQ3LdmFl/PiosL7HCYYig8bUpgdbqvH4nMalSpxGoNH Wiycuye1bubu9azcnXNjv3x8666Od8pSZQ82ytyQ+bPiYlFt4umHxmOpnw2qqu50kuSUmf/YEJ6/ lEIiibuWmRBl3Q+OpXxcx7jhIPMBm9Du+NGsM4QzyY8kz+Ora7MYtFqHM7LvNUcRcjBL+zfO7E2Q si6uO3DrDpPV2xllwm8FyQuR+brVM4WKkwPPe/VUN8jNkH5TYAmzP3FTqdT6ztmAggHmI6Lbyfed POOjA+oGx5QXOV1kIh9XCnasCL8W6jst2jyszTFgyvqASSzNvMPtaC1DL8u2Im/GYJ1x5sTIuQhT F5+heMTrHcJJT0w/lo5qFFNBeXYjPxUcNhRe9I2SWta4c3fZb9EsYCnHPg2TpCHAFPZywC7T3C5+ yiv2fITSgG34JfUlvcnWy5+xM3HTAtGL589psHA2tgd1vb05O1kkIBByXunFmL/60vGi29wuZ2wX hZcIkzHsbKGKdUdsqaC09O6ya28l9OQ5ypzbg2dDntgv0514LJd3euD4rOMOg2ES2/ieJ7iIQKf2 2WtBQCDNuupoY1NEbm19ca7WsVe8C92xz1/gFuoL+BLJoWE2E2Kl91Lnk+z6X2ZX+uToL+ssX1qn HTNYnWW02H2B3J6d5u7QR3ltuttJINyVOymDJTLXyueJX+Epi66BaCGmUJ+hE0dmCzebhiTUzasm +5vtuqcRc726JzXa7+6YnenkC36RWgXWMF5Nmy22OjwogMJ4+8ahwAFXjI58e4pLhyCRlfDCfV/y o/DbW/RSoUhuFJib1a6NVBiWtuCfCeGZcVegAudmRendsiEhh56ndtyUul/ZnJGaUVp2R1nk5NOJ k1KVoVF1PUE3bvETHOTevZXovIYXjs03xUURBU5rPyvMDqwukY0JyogTEhvalMrK1mrVTWw30Mve WJZsUXYR4e9ubrWCYeEf7T2NVtAceXgfPp0Rq9y4HLW//f5A/msFXfHRoerOqR732J7toVQQ6HUQ dc/7dK/hZdEtwkaCN6NQC6Sd02yZAXkLux9Rbuq9bb69dOqscsvlVvf32Y29ed5n9zcIKc0XlT/J i3SmPC581aRlEdt8T98hfZ+xhlVTtrpU+dvaHG2J2rMf3bLG7mp3p1u0Gx1Z0B8/+ll9qC9fJT6K jS2e0fa8JGfWXNxuQatCx11quTax8+fznh2z6Ts7WlnVWni9kJUKohseRs1yUsEfpuwrBlkr3CIQ /tSICsSltT/xVeccHHkVFXep+aM29QUt37vxEoCuW952fAF/8pbM+yIEMGinH/I9OAwkQT9AHWIW NQj1cgfA3BxIQlkHA8DAuKCVAS3vhxIRmBBAgdU1gBtM+CvuDduyJgOHLvK0K+CBChmm8BWPOeEF kGvy6VB5DJWktTr9rosnuRGwlp4kCinQk+SPVZXdBhS2bVPS2KasoaCKlZfXUFLVUNhGy4UQl2Hf bLoM/9Iv3OIy4quO2NW0CaBhiDVZ9Pf2w/i+2Q/b8L39UCzW+oBthn/tm3F2rT/jtf7p97/E0JhG pU4BFrovLvrmkMRbwEavAfxheoteEA1YGBgYGBlYGBlZOJmZmDl52VlY2HkFuLl5ubkFOFnosHb7 e4CxMjOzsrFysLFx8LCxsfHQLmw8q004/0kHq9n0BnD4u2y6H3KVgfoQpv0vOTUCcu5L7gn7KxOK 2dfElAPAkDAo2YajMGgGFIJFkZ7tITdyyaN097hyiwYcUUDzQBmp3iYxXqsaN0Ul8tE2fYx4ovX0 0AwuUJnvSvGxzTvP2uANarMoKvzttsOE9yXRdR1BIx8MJc5dPX77/MPOP2ezSx89G52zcw+OSbpW Vt/1al7VyN4j5ERyTnlD99hHKC9eS4whmzBolDLdhI3yXEjIggBRbhSU7PPQLKiBcn1FMbch8tFE fWteXKDSjDiaZgBms3JtO2REFj/ewFaFQhj+asK/t0Dimwl/SXKl/ApSM4IKWArKkqvGdITaKlq0 n3k3UcFFF3vt97UZH85UzoXOz6anKpDTjts2z/affg88A3o3vO9aWjk6XP1q4FnrSujE0msqaI+V PptuzAk+Jesnjh70vXWuxELMgteoJ/qV1FJbw5lJ38WBOWLZH603X5r1fVjx8wtPkrOiAoHbdsxh RPWSFWHsou/KI7+0fcvVJoS7WRGW9R/xcw14Nn35Y84jnzPaVDfKL9bNhWfXVYqYYbAB59NykZGB Qi6E6tmiTqtGreK4HVVQd5WkoYUoqQMjdRkpmpo1bw5QAZN1/NaoCSPclYiAe86L94tU37jNvB52 et1vrbLMb/+ub6o6Y18hZL0psfpGP7xX0PZg5/3GdQL1J0xkA3q6jrfG5zxdKZrN/L2b6M5u9YgS lhCb3h2VndP1uTHt84r2yuVSo8xlp/Fjebj+hC6plpL1L281uNfuHrjyrq2qZV6ziUzx0EQaX9C0 aJ5zbW4k5/RdcsCPFuuIPBs5eYnR/3Niw9neT2RNLft9489D7opIKaQSD6CeVT1QM056vIfUJRu9 eKOiojN1ovd1dWjM4gnC3uqRdQPer+7fHRp+0XlLvigPpxh2PKvrHvtBkaxH+YFUEDIA/bOfPdeR M7uScez3kx0zLxLcifqmx92Yl1Wqzr9dnirDK3oXD1cZyjmPf0pmkg+UrGxnLpN/cPHm4m6DmtcO 6w3LHY+FKwjUlbbceAvqp0qW7WW9zm24+LQy2bL86rP2QEHr8Zx2//BT+wWEPuCihvqp4Eh+tVXA i1NzxPzQuYuE1gWM0AvIhmdOjKTeuYRMa5+Jcq0YR+tT0q6hSRWV6gUreSpGDhMOz58R8ARbW0FW tuy3/rCpTZHQFIrqedfsLPEs3XTx4rv7KykuexqeVM+l56eDHH/V/uKSd+EZkFCnVP8mfv6bEb7N wbZufWbo1KKi/nyhnoH5MMeJZRGL2ZC9EyvLv7XLTMovtu56Ul8iGVeZkaB76mYfwvHau3b1tpKJ SHKMahfbyeTT8kUlXsVjnl0YxoBpj3dU4Boo4iSfv5zTsVIwWHTnQooFv8s+GVa28IHyTn+R8fy8 7pKV8pX42yI3nqupVQVeHaRUOiYE7nMMuKEr1uvQENg/mz4fZl/dGTLBZVuVZGQ7cafCduhPfLed eW+EZPrguqm3s5M9A6Mv3piHOEzYuKui+/JSkt53lR0dupdMBSr91Y3OGMvmJft9mn5v0yVLXmdG m2zfcirdR+QJbj1pOYI/e7HfaHI/X7DhCY1GhectU3mZfg5L1fMiHsukMJv8KOrTt5GlB3BBO3bd KmgthEvzRyYyhnoGqkwF3V4Kcago/JTSUf2eCkQ+10e921U6N8nOtJIT//ne4q3h3wjBtoTopf6q pTxUxp2K1hcXoeRRNqB6fsO7z7G55+IV/TEPW0/MV7HXRTfIsJNS/gC+TzhGl8fro6Y0KyrLIvYv lpxgb55srshKLUqt/bBs1/UGSt7b9nh0ERM6nIXbwvSZa4TJCmZ944uWor1RuYukxXY2EbPFawPB JIegm8tNYdKFKykFY3eXtvO7zvlH2LBuuiL0++X1f7b2MHyeogLPZQ+PFXS0qMnsBdziTHOUYuq2 I+q4pg9BS08ztjZGHa9hcVk80/i6ShuaHl0WRrkjc5K3CooOO4jcOitiUN7pm9tcWZg526ZVQIlM blP0bQyxb/hDxXYCvSR12Ln7rFZp9Z2Kl9Cg5zte+DgY5JSb/TBj1xO/yA5tw5yiY0Ha488sfgiI 3c53RzeHtO+LqjwSzzUaGjmXuu521vtWDD9au/9jVfVSeUVz/YRjRDh3/t08S+GY/iyRQIaAZYnq zjnN6pbyD9o1l4NWMjoWW/YJykwqDce5n9nr9ErtRDImzYkKbNP2vSn8/Kh+pWm8+lPg71Rw62PU n1bLKW1R78eEoQn6lgoe50Y0DbyiAr6EvhWIdMpihV+iUFNVqCXhTIfcYm3fCbxTI+t8VaEMTmV7 G066aiBj/7trJ461y88I+kV9iHO0nnnTkJdhyTSpArr6eiLbJlZO9RedOvejjuwlxStUMNqiulIH PeFnTPuaV0gz9msKFxLD4pOfzmgEG8gVTnIsadoxi8Q1lJVpaStPEZYinjavPCwOY7dYzowkWUy+ eSDIJhsuFY4nfnze9bzx9bxGa3vURjIVlGjIrTiPRL3RHPjE82aiisGhzsOhQZrNy1/gI3zn77XB WW/dqUB1IettFAsVPMr5bKKZbLdYkuCz7dJK3mffJiZ99L7s7FYcs9ukZufdoGDtT5CdQ1GmVaZX KSy7FHxfy73GXfd4ud5cXbZH37f37WzPho8ar2wGZu8/4Vys4n1xMaVc/NyrFx0i+7Veqb+8GN4/ fy+D9OHSmFvkyUvQ1KUCmT1qd4xUs3p3Bwrrm2sXXefdUdqpUt2xkrwy6rK36u18GMXeaLz6YsTZ CjPtV/u3jj+bnQ/Caq7LcXTXwZk9fxVnYeSRW3ZXeFElQm7M7pKEzqOcgnKNuJikoRFVrntYmLKK eHzgx+TwtOoP2pp7ahoCw+yE2WzZeT2e73NvBOUSwfrBzt3hEyFTHiQquBmZ8IG3MH+hKSs/CK4o mJzoc9XjiOPN4ek3yWEJn/sTcGWWrU31BQnT+2N3RVFfUKfYW75lqYpQlqqmZ2KOFKdnQxzgL0Dj IabWeKv5LvzLnd5uM53H9q2F9uHVVkhWepWWf26g1wV/rCM+0OuMX9rBVlsxrVXoNYlVe5jAl2yN rhMxR8eNgZy7O8Txha7otVarlMyU1K8UBfrVCbp+oSjTrzLfKPQ+F+i4/7972Y8Yp7H///PoPq/5 tlaD/1BjoNc4wOoKQWe1rPE20HnIr3UhGoYwBeCHryCxtJUFdGcGvoAEPKBCBl4AD90p0I+02vO/ wHc0eutY8Bf4u0Yc3+jEIF9fQHcDoN1IQUR8oIWbN+4b3wpHkQdrxttAE9GXRPT40o0ZwZ3yfV2P QvJbq9PNsPLwXOPTTUMH+nrhCIF2vmaBtP5/0IOi8yCECyoYesVk53d9YzzIpCD/H0hoEtnLw4tI IAb5QTUWA2taIws6DaqzugZRSEYEIoHsSiHgafI2B/0Ja8JMq8I0Co1j4ueBBf/z/iOCyL42Bg42 4Ifg/0gxD/Qg/EBBu/pSbFw9fqCx4QhQO0IoxSTQ2MbczI1E8qUxGL6QfxBm9CSRw3R9vTy+RIp9 1XnjL2SIhMET3F2DfCk08WACmfI34nZfyD+KM7t56JN8SeTvgsu52kDP6CuDZsZuEpF2Z6SQ/C2C KIGE7wPH5AsF8l+oLG4kChTQf6EzQ0Ps+Vdx+nPFQ0dpQ7X6N4+F3vmXyX4YKtCTCIPutD8q0Epb 4NfKGvxaWf9aWf9aWf9aWf9aWf9aWf9aWf9aWf8fWFnTc8ON9NzHlpb/0BIhdqBLX2q5AQLAAkvg SV92kUAgHYOWm4D7v5HAAlUgC7aBryvk1bUdBjCs6qAOcRl7Uij+GnJyxEBZV1pGKYsj+cmFuvrL yctukwM7tEP9XXE+BArWjQCtYTQl3t2tlsB64TUl7JXNt5n76xM8vYzDyATrsN02uDAfnDpeQluL aYc2vSsZqBsZdy9fCoEciCUE4jRF9a1EaexQDYjjR6C4YkP9fImBGqGaEvQGGhBOI8tJYOkiFB9N CQdzSyyFRPL18aJgFWTVZBVkFBWlse5kVz9CCInsg5WXVZaAuiTj3TWsdhqudQjVNCXWHAsJCZEN UZQlkT3k5NXV1eW2KcgpKMhAEjKBB4kU11AZYuAmibV2Xg5fm/0QDy8HejggRUxYuqqdkDtkL3+K F4mIdYWWaBRNiaAgL7yGAmGbG56AV5BxdccpyMjL49VkXN1wqjLueHd1d1UlJUW8q5sEE/aL367+ 5uZ/r/HLCPj50bRisTvosho7SbggPwKRYrJTazVieBIOUuv/5Z3MmgE4wn9lwA65f+kMckvuL35B vq7SoLBCAZb7Omg0c/7n4ZeSn4JfSn4Kfin5Kfil5Kfgl5Kfgl9Kfgp+Kfkp+KXkp+CXkp+CX0p+ Cn4p+Sn4peSn4JeSn4L/VAnTt7dCBCJeUyJEQluLOsziYKKv72JpZWFoYmZAf4HFYmzmRSTBOQDw I1LIVkZ6WAdHJyymBcAB7f9aygPgigv0N7c2pH0YBiYG+thASAh8A6iP+a7VT8YdMsaWWCz4OeDE +ZMpUDeWEK6IJwTiIDwawn1DKP40+jSE87j50HA47QstDxkyEMIFaLjHKi5Nl1nFdWg43o+Ih3Ca zf54PzwNfwjhvwUH0T7pI8wgPCbYixAC4Z0QLuYb5OcF4bQ9Ijx+BNdAAOjfgMUoBJwnhNNezrGQ baz0IXwHAAwsHt/hbt/hFEIo7eM20Cf5H6R/bcZuwW3Fyqurq2GNCSG+BApFxhIaFFcyHqtP8vN3 JR4EYNVnOnDRYouFgqwir66iIqMgK/8tTv818x8CbWxXsQ976GMG42v6Rvs7OdIVANTmoNic/kZz SwGg/DgAAj3faGKXAWCHxq2s9Tt/+Gjz5btXfF4EnCwtoF/hvxX4B/CdPllad1/Dg925utsAS4sb juRLCiJjA6FngoCV+esk/o8bfgff2SFtRXAnkAlEqIUdNMu8iB7QcBPxXvRXkV7EfzeI/2Gzv8Dq vIaA++oK4HGRBRytPAAx1QSQ3MwA4XwJ4sC+jpsZox2gPXn2ImOr854Of7P1B55AuwR60Te8AH0r GywuiBy8yqPvcUEBJsAOeIAg2AA2gS1ABigAVbAd6AADsAtYABvgCPYDHPAEfoAMQsAhcATEgFPg NDgPUkEGuApyQQEoBuXgHqgB9aARPAXPQC8YBKNgEkyDebAEg8EwMFYYN0wQJgITh0nBFGBqMC2Y AcwMZgVzhB2AecCIsCDYIdgx2ClYIiwVlgnLhRXBKmA1sD9gbbAXsCHYBOw9bBGOgLPAeeDr4Zvh cnA1uC7cFG4D3wf3gAfAw+DR8Hj4BfgV+A14GbwG3gh/Bh+ET8LnEADBjOBDbETIINQQ+ggLhBPC HUFGRCJiEUmIK4gCRCWiAdGBGES8QXxCopHcSCxSBrkdaYy0ReKQAchIZBwyFXkdWYZ8iOxADiGn kSsoVtQ6lBRKA2WCckB5oEJQMagk1DVUKeoR6hlqFDWPRqP50BJoVbQx2hHtjQ5Hx6EvogvRD9Bt 6BH0HAaDEcRIYTQxFhhXDAUTg0nB3MBUY9oxo5gFBmYGEQYFBkMGJwYiw1GGJIY8hvsM7QxjDEuM HIzijBqMFox4xoOMCYxXGSsZWxlHGZeYOJkkmDSZbJi8mY4wXWAqYHrE1Mf0gZmZWZRZnXkPsxfz YeYLzLeYHzMPMX9i4WKRZNFncWYJYolnyWF5wPKC5QMrK+tmVh1WJ1YKazxrLmsd60vWBTZuNlk2 EzY8WxRbGlsZWzvbW3ZGdnF2Xfb97GHsSewl7K3sbzgYOTZz6HO4ckRypHFUcHRzzHFyc8pzWnD6 ccZx5nH+wTnOheHazGXAheeK5sriquMa4UZwb+LW58ZxH+O+yv2Ie5QHzSPBY8LjzXOK5yZPC880 LxevEq8dbyhvGm8V7yAfgm8znwmfL18CXzFfF98i/3p+XX4C/0n+Av52/o8CwgI6AgSBWIFCgWcC i4JYQQNBH8EzguWC/UJIIUmhPUIhQpeEHgm9EeYR3i6ME44VLhbuWQdfJ7nOal34uqx1Tevm1m9Y b7Tef33K+rr1bzbwbdDZ4L3h3Ib7GyZEuEW0RLxEzolUi7zG8mJ1sb7YC9iH2OmN6zYabwzamLmx ZeOSqISorehR0ULR/k1Mm9Q2uW86t6l207SYiJi52CGxfLEecUZxNXFP8WTxBvGPmyU2228+sbl8 87iEgISJRJhEvkTfFtYt2lsCtlzZ0rkVvVVtq8/Wi1ufSsIllSU9JdMkW6XgUipSXlIXpdqkUdLq 0kTpK9LdMiwyujLBMvkyQ7J8smayR2XLZd/Kick5yZ2Ra5Bb2aa8zXfb1W298lzyu+SPylfKv1eQ VMAppCl0KrIqGipGKd5RnFGSUiIoXVJ6rsytbK58QrlWeVlFVYWsUqAyoSqmekA1XbVbjUfNUi1O 7bE6Sl1PPUr9nvonDRUNikaxxrvtMtt9tudtH98hsYOw4+qOEU1RTVfNTM1BLazWAa3LWoPaG7Vd ta9oD+ts0sHrXNMZ092q6617Q/et3jY9sl6p3kd9Df0I/Qc7ETuNdsbubDHgMrA1SDV4aShq6GGY bzhtpGwUbvTAGGVsanzGuNtkvQnOJNdkepfqrohdD01ZTK1NU02HzSTNyGaV5nDzXeZnzft2i+8m 7i63ABYmFmct+i0lLAMs7+5B77Hck7bnlZW81SGrBmtuaxfrPOt5Gz2bBJte2y22Qba1dux2zna5 dh/td9on2g86yDlEODQ6Cjl6Od5xwjjZOV1zmttrsPf83lFnZecY5659EvtC9/2xX2i/7/4qF3YX V5eSA6gD9gfyDnx2tXC94jrnZuKW7jaN08cl4ybxOvhz+AmCJiGRMOau6Z7oPu6h6XHWY8JT2zPJ 842Xvleq14y3sXeG90cfC58cH6qvvW+hH4PfAb8KIhfRh/iQtIEUSmrzl/KP8R8M0Ag4HzBNNiVf C4QF7gu8Q+GBkqmmoC1Bx4OGgrWC04IXQuxCSkI5Q4mhTQclD548OBZmGJYdjgzHhdce2njoyKGh CN2IzEhYpFtkbdSmqOio0cNGh68fYTric6T56LajiUdnj9kfq4xeH304euS40fH8GLYYckz3ie0n Mn5D/ub1W8tJxZMpJ1di8bFPTm07lXTqcxwu7snv8r9f+J0a7x7fkqCScOk0+jTxdNcZ7TPXEzkT wxJHzpqfLTuHPRd7bva8y/k/kpSSMpKZkoOSBy+YXbiTIpZyOuVzqmfqszS9tML0dekn0z9exF9s v6RzqSBjfcapjMXLXpefZxplll3ZfCUpC50VnPXqqt3Vhmy17NxrQtdOXVvOIeYMXre6/jBXNTc3 b11eQj48Pyh/4obzjac3d968UyBTkFnIV3jqFrgVdOt10YGirmLT4toStZKC2+K300u5S2PLYGUH y6bLPcsH7zjeaavYVVFbub2y9K7s3Zx7G++lVfFWJdxnuh99n1odVj33wP/BmxqPmpFal9reOoe6 zod7HrY8Mn30uN6wvq5Bt6H6sebje39o/FHxRO1JeaNKY1mTclNps3JzaYtKS1mrauudp+pPK9t2 tN1v126v6djZUd9p0tn4bPezti7brufdzt2Dz/HPx1/4vpjpCe5Z6j3ch+qL7efoT3q57uWVga0D hYMqg1VDO4eahq2He0dwI5N/Bv75eTT6FeurpDGRsdxxhfF7E4YTT1/vfT066T+59CZminMq/e2W t7ff6bxrmnaYHp0hz1Dfx30Q/JAzqzRbO2c593Leb37pY+yC4ML1T2qfGhbtF8eWQj5jPl9Y3rpc uWK60kf1o1K/2+uoA77sdYT9c/jbczl+4P/nZ3LEwi0QMM7v9zruoj6EQWktQMMR32U6GAY0CsmI YILDADNERtP0f2VCLAQGzgBjBLS9jnAYAkk7tQPSAUczBtGOvuBEcaE3YrhFAYM8j67CJl7GPXp8 rmKK/FYBRwTczojrZxZNb1YiMwnWtClLDFmrHJ1JvLLTJtDAUNUIt8XWzl6ouLZ9+D3+GOVsNCGr pK5jZKua+4cgSXUNY5NdULJGO+6CftbF6kEXa8dcrB1ysXbExdoBF2vHW6wdbrF2tAXtNA4EbW8k ColEotEoP/phHBu5UPJoIMqtuwej4MoTwKB3ZNMZXqtMNz5FxiKxmjZ98jT/0FEl8URrAdzOmf/H 3l+GxfU966JoR0kIhJAAwUlwJ7hDCMHdnU5wd7dOIEBwd3d36A7aJFhw1wY6uDYODTR0X/Lbe62z /2vtvc8+99z7nOece7/OnqNnjVFVb701Zs0a+fX0vCSafFJmDNiuQQnSbn/l1TJ31+b/FvyPwKdM pImFjX+LJJP+S5Uko4yOhcC/F0r+b3WasrpWXt9TS3/8ntu+FJTTs/YOSytr7p/fuWIWkte38QlP L28ZWNj9D9044GvwFqQx8qB9th1V434YsLfk+3/ughvFgRh81z6r5QLdvbSUN+ur4+fQzzlub5/x Awle+HnQPshu+paPAZ8SDmsWyWIHctPrsCjR8b4rDpEU/WhPauP+hjrHFWbv8LahefFN9IG8lXSc Flwtd6IwxCb2fS4vdZAo9kW25FYUBmC2JJhhsj68gExh/RiyefBMIayqqluWLnFUxLlR7cmaebwk Dfu3TwipN2fUvgZjGjW+SOO95dvZFiTU/aD9cMn3/3EXMGP/H9EmVlYezMhyIkO61f9i5Arm+8B6 DPsrvanL+s7xsZaWxlrFCfRXHcEJZ9XIVrkVZ9JLjbXt/NLq8mOuLoJINgTRSrOuvfao94+lPtx6 NMMbzS9KWBmcgHFNIp5OUewr7rjmrkWlC1iyN1XyIb/SiRFP+DKfS/kErTFtpfDbYOOPegxp8cTn D2hKRzXXluGjkNUto6mp1RZfa0exy/6JmXFpl9gW95m+qt6p1eXq8gqyzBHTeli5/n6A3Gqhj08k LqvDx4nCobDXi1KwvrbMVpNhynlHtvUvkTGTkYHMshaPynEf4XxyfjOGq4dElCBNUaPDzpK+o7AD +CCfI1kOThDIK571q5ZZCAk1+MlxSKKQ8e9fdQXSJDm/Ckcu0G4gAeHs7IJXwcteDvGw6dRdZtIh S5XVjZ9mu8yM9TGJho3Csxx6WfBUv2A5fI2hHzdZFDyNtd8XqOlKTz/C+loWYS0VMrgD+u81778l Vca1XeW0Jsh8UJT4gkkx/UwBBjxAon6g/Fl1YKEci65Ee+TVO/Q7b9J5dSJlVshk48mY1HyzcC5O fteL1Z7LtglVpHAkllZG0KjFVZZWB2qmk5bt0qV7FUV1fz9uq+xx+30P4CTaJ22t1x1F8xrrYXp2 w2dWu3yIr26VqYGFOnb5lyfU314wdbu3wk8yr+YlT/byty+Sz4ZMNTqEYqhiYK0QMj4gk9EP/uKZ 3jGT40uHmczNb01aTYLpabh8n1crqjk3Xh3Q8/THFn4xh4Bv/mQON1S1T1WgVuceOavrjQGIHPaz ZPA+TPllvZ1yP01B/kE1GaIIDxRRWxy6iv4NcHNvRCG+dKy+4e8TkVabSx5N3cSnbJIyzytcV2TW eCtPzm071h1qY/6f7baY8f93XVZqC4zW97PaTm0oAQt3VV14SNqDcNG84F0k22NJn3HQazTl5SFy 9XNhv6NQgppSYmDJhRXtuAzDIl8qYeHD1hTOfWGB1AODRnwRt6min876Gmcz1TZPBIChrSE+Sd6v 5+BeogP+jS7iELL226qtsD+LbK1FBZf63Tlr8d8RrxWkj5GKTUl+b/VkJQ0o1m4uOijOe0SlOLS6 2lCHTuTuhPbPPnES+tJY+A/NSxdVd5tD6E/zChZ5BLFFDNk0qxQCf6sPTUi+TnumOAZAgrwE9TsJ YTcG/Y2BPGUfq6wkLO99fSAQ9bWzhtR8FkK1VHa4xTdIsLhHDx8kA4Zvo0UqvD0LZcrowpfHl7Fk Yr//jj95SsAas1KLH2adAIVmWw5RzioWU1WtwyieNu2Ruap+5LMQ5RYeKXDc4plcKzsRHnTpi00P vaPzu9rkxdgZWPyLSrTbdfWdb8IhNZ7NOS4vpT6vzBtkSdba+LN91bEZT3Ty+kUaL8WpHOj7+RbW 8etEUg9+6rLsKnZKNdl8DeHUZz1Cyo4vGCTiPRz9MIOMN2YIqSDjfsCUXOgJN3VEjy9qoVrrPat3 4a0lTBfQbk+iw1EzJJHND9XxnzH5hHqsVUpahoMyEgoE+I9NaEJ4pepL7/O0QdsXLX0zUM30P2y0 siI4c3PLaDMBgLP7WZbibC45LCcW0/Z1LjHs8/YZrEJtAmyfo58kGHB3pK5qqZXNZ5UKp6VFyTEU WjZmPRH6N3MrwD3WWRfbvKyBZzkuGxgT1ZTOC17aNBDzJodnOhhVGRHMVc2Dg80DuLlVIlPEwRXl 2xO1Ggq8ZMr035/iy4psDJ+spfBnUCwvanbfDn6tek5hI3mvTO5eqfxMAU1pzTLUBgzyaa/bPLRH pj1Uc+ArMkmPhqu4fJOzd86jDSt8YUjrkhoZXv/tCF73fQ8EjKF6e12z8VoLgf6zc/srbakiS/KR Fs8qqd/FzOik5MM0o6JWZ2dNzUy+jS7SxFPJatmicNldpo3sZC+GFO4LpUOHTYoW3FG7HKMGtGKk QEHkjnm1zH3GAflYlUEMoKVj2rWmgXyvxYVKDCEN8wELJQXrk6Xq1kZvLnyoWIUNFm77sLCw9DDL iLh0B3k2OBRk/z+SE/y9gJn4F5Bxo7roRRlX744M7s/2Rg64zwIP2S4uXY1u3pnrWCGGkv/YWff7 F4GOjg050RzigY5EVcb84PgY51ayADgoQEM18HV8UpEbk412SFIRi6SK5FhB3JXVaYnQCYiBDT4J RrTo64W5eWVTTauQUzKElvFuz1ZIN04rCSU3kWor3exAU2OSgXgeJiLGMsc2u9HFrDRTbvdBzSZb Su2rYUhg1q51C534ZqT4GRZQUu52GerO9nTV11OsBRsDaGUbjcm5UdijuhHlPyXEAHLmQzGAcZUp +G0wCnm9d9p3S/EK7dSFAbx3d7zir1mSxACeLvXdDkHEUbZ78KMz+JAOGmRBhQFIiWuALl4fwvdq RqnO3FSuuvBu781C1+8ehnfD4EmF5FrEABA1NaCuSRAn8Oo2FXRLcKuEAcwBoaBqqAhofFx8C+dO QGMMIMHndkr8KGsRtDjoigGAO9oxADylmx7Q1sVnDOBM45wfA/gccItuuTnGAGQ+YgCZ7zCAMQpf tNIeUhUD+OXpjAG4so2iF66R//tzOvxPc+q7msAAOE1YhSEvxLvdxdXht1vm+IfAf6bl/l+mNdOH vBMRC/2sDAM4sGzGAGBAiWQMAG0jLoZ6Y/rYdT36/O7Pn6Dgjeg/UiF7NBzw25Kcy7S9IYt5QSjV PEPoYcAaokluZXwjRf8Z3Ll5BNV17DmvoWS9EhwRJXD52d2pt3ySp0hJmrwGyYyqdQlrE/Zs9HXv iynQmUnzxLaaVsHbK/xxZFu5d9TolQh8pf1twsj3wYZMv8NMtyQExQ0VBgX8KdtbG5hc8bT87BB5 wJzDgMtrRC5IzHlFnnlWpyMlBxRRYM6NM02bomDvjFs+ZXjnwPnEEVlRlve4xVjmsz6+/iv5sTjg B3+fpCvgPNBKkP5aaTLhtm7OY3h4lbMRPMM39ns8WYczJZrXJDiOuExIgTpdSwqQVpKd1zTK0wC9 bi70NkDLu/TNc1qYatNmF/5YjX5bzDitMwYQ/znD4b57+y8BmDk8BEIjNDGmrjkzBd0JTCZhSPx6 LkSjbU9zEhC0NMEfF9gbnDGGfTbcM9xeaGFbNiEQ+rL7HkpFu3kM3u+5iXSbmNh09eXGnxD2AIeA wSlvFwWZLtDG3lYuFREJr9n7e1S3PJfJaDS19XZGZEhkVNhY6dXY05huJqSHESp8DuX1o3bg2Bey 3BRsQfJen3jClWWnyp8QVmv/kDlwRH7zX7xtS/eHOmw+vYrxiP4orVTNKSJPKf5Cln3dy24jylft 5lmYmR6ZhHxhB4WzB1L9cDliP2p+WjQD4kJm4LO/mLHmShwZaVVfNM7MWGFdHCJXxnKcJv80v6yw vCRe36bFWt3KLJ5B5hP9DtjYDokUtr/BpZhS+oB3QvM7kFHiYeCTN7G2M/ouDCInfc0iRXWnEAaH OuOTi5Un8Uym9KF0RsQvSGijumRYHSpoXVhkqFkqGJG6SCo7N7BNhbM7lZmjQ9PIrOl696y5h/TG IKJ8d19zmicpwdTWhpPXrV5LdVBH4mHVq2RJWsaZlkBRyEFr8iSLChg46MjN9jQqPJ4ZF/dJaenj 0DH3A+f157LIZ46h1lvV6jCIP1jwYxnFRpvOk/hHZi+pByoJf7WWfpYsStX+dv5p52ZHPLW+VPvg RvHbc6PrnLIH/JdxlP0fodedvmR47lerOSda/9WZWCFIX//JflpfVwHKINc7lBj0UjndS/nv+C78 X30X+H8RHhWvQTPhp69rfquOcXisPtCeUZ+4L5RRFva42O3bC/Fmv7iapTWkRjZtPM/tbtYQ1sW7 q5yzLE7PW3iOG8rAICMBMXUWzed4xXQA+vYKA2ACsUNsF1JvDmhs7duUtxeBy7eDkZ2fj1ERHqAn BZ0gH+5G3V0bu45V9KMYb+dL4Jrek8IylCxJXvHJ5ViSqv9GVIsCRRv+otKqcmle9lf3WgDRxLuW KKXHj6yErmaWD8AwxJ5nxzy4Jnd+syXpD/jYGFQSvG4RjkfS6d1GwEIV/kck3b32YXZEyXDHdc3l 8LEv2DcD+zKv2aP6ZTxbyXMbrIo+LYfITVOKwF8SGjKESrTTseFD3+PW5F6kjkd1Yi2kzhoEn2xn 64xFLvvbMt1hdcmpLVrTR+NORSKzGICF8bS/CEgszl+zI+hutXduFjCAJMrEO8jG48UA5lOgf39t P1e/ft7+3xl7e3Z8c42cVtgWQt6I5QzXXKntqNwCToG3ab7Iyb7TPbgWR+6d2q9BfNANmSLxswfD oAvzQ7gK1WjN3wdWiKO1geIdqn6jiKXbQATBno9SaO0F6WY5tKVVgyZ8UPOAtcMhlCqwBLVQ1ZUQ LsQp88ivHo+y2Cr2/qPbJh5r0nDtkpI/aRsmpIkPyuDDKlexSLyu5eE9sZYd9zktrebhOGAr0s8A 8sggq7Q4vIafj8EhHNgwvKodZ47G1x8hFhYvPMISC6FzUtCJMc62iEpkE3DXBv4HcRHwkpitSar/ +Uz+50sXrByFdhYXRCU0+0DKrTiXeKYpgqAe4EmLkjnvPDpRektuOZnYqtnbg0TpRIKXCsLN2k/i kt/AltOfTMuNYGkbpOklWXH5wLAWxFLOa4CnrGhrI9Sx5XrlkuhkrHu79DO8Oo9qHQFYicM6d5os kt67Xo/E5HTCAcfQ7WztKd0zWmmu5fqF75/up+bpGCkZxysJ915rJ5Zo3f53NLp47YX25/4rNPg5 Wl/8DaphA68P72xwqdZe3y4Z5Oeg6DERYf1p750bF0Lxvumxko4aoYMK4zmhuoO+X6TP9C+rMKlq vMaJ8gJr46ROBLWNjfPuz1vI5D8Z3MfQq1C/9JEbhcvWNmFLKxyejA1uMh17u3K7W9qky/TMGVd+ RRai6nDSgaflyTn2E7MjhOYa5W+UOmlgcfQQwNFOWWYfyee+KhfxlTO0PWggRh60jZWOAewPLuTc KWlCvDxlzP3w0l88A3hSMJFzfW8TiuJCHt79NNtRDpSYhf7HYfCObPEc4+sy/79AEjp51YQBMIve OUkupS0G0MAR8HcxfHeLzijsjo8G631f/UC/O0PaehT8gfleEM2SNdBmuJKIUeE+IgK+NdL4Ghgf Ugx5K0TQycsfl649y2RBpA6Q/8NSS46lUMD6u3JRRdop9h7tF0AzwxfAdTwI4Fuis5vRYYABCHZ8 3RaJ1jFzl8I/DOjKDbGyYT4ikZd3AP/ceCn9bWwdacimJWZSnZTYWLv2KfutI5lmH31uTCHOvAAF ffzGq2cJNy2Fy6NoNwxAAHJuFwP2tJjYNdQzXe3ZV8r6XpEgVQl1Tl6ucxhKGLxie9VZiAGY+fpJ EK+yTFg0Jx69cXtScyp1dZLg3devtAqMUTAB23b9hN5g2Td+olrbWfeFBFMdnatQAtdESSjz0Z5Q LvCjj86O8xcybivnjMm4kxAmvmUHgSAm87zh/dQjJxmWNzRGWhTmNb5kvhXvQ0OEWpZkBcaiwY6X 1idwm5vhXTqEf1kD0mMgMIdfD3ySmjUtm42f2vdTQU0XBhJWssHt/x6pVe4/ZPuqsvy4n8ChyL/Q jXFBbsfN5elrVYLted8SZXdVKvY7YunYB4+eJy/u20u3ODTuz40Gp9dTNCUWFc/5OnKosEziBPxZ Km8C+RqoqH4bVokKqZAOIo/vYri3/jWD4UHhiWH+J/OWwoAJtIc4Pz9CErcke95IMrI9PsLMHsdD uW4yw3/EwA93Wt1sK/mrdShVycLXh6bfa+T0NzU6v449xQCeR5xuDW7e+YyGty065xfYMeLcBgP4 ggEs1WDN3pbs9E0utTFiAEHlXicYAMl239nhaetV3GyTc98cr7Bwq5PFxzsXrXz0fGGk74kZeyri Z/1O7VEXd+kbUSNCp4dwuab26VzJLgojh0JyF6F5g5WaEeWMq4oG5tMlfzW1r0s/8F46ioFHR2U9 xRasswqKa4Bg1+emjjotcSpGT54M8cjHDuB8ZukdzzzasVOvzC+IKZHhh/kL/0PoKmYHR7fET15V dchewI3cqhh0h2d9sdw19xeNtNcX5ll79SEM4JVQwubdjeqixdRdb6bCxbPpwEzWD1O7KbSLSdb3 E9Wny3ZwUtirf1oXut1Z8H90rKW/jqX517FkoFdOGABPTHwOE1r1kw+osUxoWbQieSGji/WwCQyW eZVoGPLs9c2HyNsN7dV+6cat3p+z3QqGLmIdsGS6j6wsxlkhnnG/mpiUwfQXGUVZ2qBTsaufyZcG k62OdLXKC1WIjs4l/FWPbBaXian10txOE2pCFMRpNKqwpndYDRd7UE4akqSpEivdYE0Dq5NZ5azp mnw1YKKm8v1c8j8hvcxdzNrh+BvO9tBUKpuzN6VnJegv3jXooXbUztrV+eFffGmYvVaBw/fTMIBi ECXZ7Z2K6/vQCTfAri30IQYAgo4DkTV9NxwH6K1LfmREDOR078hHJOXcV0GiRiXJx6j00gdKdLdG 7FDM5L/uhOmBhlENTC2zfxjcdhbdUY7CUB2785G5FNIreZ/KHg+Qs+ke/2O4zZCZubVVfesz/FT5 PPVj9amJMKbM5iyT2AcH9tdzLhaI603B4mcv1XPrLB4lF3zhDK2yelKezSMYisRdv/KGHoojEB6p 1RdLNbscBw8D+XTjn1C8yVEMbV5tT57qNcWldSFI+/B9sDjM+Oi0pijg/0Denencz1LpTNNPQ8Ys XXnQd81cSpvjC0h4z+xTwZWf7HFPJq1zG+nGcDJxlXbymgWycwGRP1iqAkOeC7/OLtpn7+s2uxDr JjNlU4uMznGe2OLWvMsWKfNQIpVaYY/ZhXavy+m8rcu2NG1xwA4Sm1UHslId07SqQiEv5XGcd3gO cLp+qIbkPzZpYsYV6s1xDUDCPQ9t9iFynjVO+46evnKFwZV2dNEnp7vUes/ej3Vv/fRXa5Q60Cc2 TSxXYjUP1Qk7HkS/Oq4Fb1g8c77JQAhld2YnKUnrVF1vpkMcEfLh14rrr9Q1tA5bLkqWSPyhCZ2T bVq1Gqa1TWW8akfaDF/keJrrfFlMH0iKYQA/SObMeoiZk3C/mPF4qOdH3i/QXAlm9u46GEUWuooh HJvtxUZO9O2dmycpblG0SOaopziDFulVq9mCqTwqtEinpJjzT44EhZ6uEzmvxUT8XHOLc3eUc+Zu QXRiQq0vXL0qRbSEOyCv4wfYbRooUuEk2r8dWTdw0hgLYqUMgELSb4JfMEu+LGxqPEH31+UXT4Il cQmi5Jtcnk5Jytrss0hKm3be+8I0kuMsuoXUWYooc/Dv3loadJNJojsyS6wqlyMPeNlPmKnP9taZ xJyNgFG3LbK7MVrX98J5ynSa+i7E4G1M5NBe4GTtTGQw2aI/2H0LV+qSCI7VWG8V/2x6PM05pUpP KSSo43K4eC8w5fKznvXurvP4oDSuWd2atTo9Ujiu9y4AedqXz7Quir8wJDEFTKlnTbA9jgzUrlj8 wLjdt8h/+Gl53FXI1/6A6t2l8YwD7XfKz+WiLefr6tXm7GLZA/7q/lJaq9EeCkF/aIyGFqz7yWP7 abkKZFiVx/vJAmvIv/cYUSiF19e+CToTO/4U+PShmfsZILqeuuUdY+cLmft494VWDo0M/sWKo+En K7tmBzUZUAoPNinKB3SRGIAsgUGreMTiGQbgGTiIyG4vLodnpOAafZwiYWTBACL+gDekeDRPP1jv 0idRpxWELUu9dqFf4Hewn0OQ4BccB9V+1mIh5npHHdKSJAsIf/me52F23eyh9SguYmtpcinAPHx1 l2x0ydH2YTKi2KqaI82uakNmlkQF23pCOo5Mn7qhl2Ra8/ZB+2YOkO1WDXK6tnyyhuZxH9Vbs7a1 5Vr6uuB25f22oCQ7F+dx3y8zi988g/cFgUjOnD7r6Z91NzE2bH3eYu/dkrcvmK8SZorhS8N3SZkQ +SjaZw+619fkTtn+Ju9sB1wcXx6u8cicV4p2lzCdNNUsULWSvdI0Sa3z8xnf1vL1rNotqsZtQylk SPtjE4FXZZImjp62jQ1p2apJ8RCRbL4ZnQpWNh5U0+d8l0q5EOTJj3ez7Sp+tVeNAdRQnqvtzWz7 Cy34Xj0+Z4VZFqEKmurd3Am8RZFzAu1ZcoSGryS4VsBE+C7UXhNWY5e7J74TbrSGrxTFSxpTHlcW bEzsSeU3UHFP35FpvpGeon3HbKNxPjFXtej5BPvl1mJ/n2lmj2h437hlngL3I11+4Vm60PVX5wyw o3Dpdvof9uqQ3F3wbeukqFhXE5L3I6emBmJx/0iFdBDnaJXrZRePMi9tnGzifrz0rsMTWvzDacp2 h9DJSugSxR0PFuldwQBG2RUwgLL23YLZGtVrd2uq/tkiT6LDq8Fa1ytWSu1QvGmYr5fH8w8++/ZG bML9z99eVFMTpucTr51iAGRLPBPlQaWVrO9raXmF75EQrk1eDCjmTj4QdQhG4EkbWeGdQmtNEVSp cBrPLFFXs1IWYR3XVWfCosHCS6UqXY9qwj+mGABj3+vg0D70uKMFZzh1TIoUV5a64NWZ+i28+BoO ++OpN+2O1wWNEcZ7E0akQjEzZwjWJyBC+XUcnDriVLGAyuNT3mbH0zsiuF7tt0iWzd1c84W59QZt jIORypn/GP4sEE2AN8/jBnuVKxRCMl9PkjX7A0XakYVXjI3bHEbm+Jp17cSW2ZNXNwadt4wBxNjY h+i1yHjMSd1cTx8udMSebUkED228lONMzcyWFkilrVdV1dIqVO6sL4xSIQiPHGC/V0dzF+DukosW 4Rq0d9SdBWYbpmAAGr7TMjUGeWe7AQyfHEV6Nci+F8HIgg7q07BF3Pkq2WU5slvyhazcqcDX3nSv kbsxxu2SO7Pjr6o8pDkqW/Y+n48QfjDhIxqBGYiTfS4kpWgKKeiabH4tVhIeyYkuzDEvnIr3uxZQ JXhEjqXfjQHwQje/ZsBRoS5+VpfnPzZ7zjueF1c8mvc9fCYSq+PxWD8z3S95/tc6DRMb31CvJlZg sWylSwPNI1dprEXmkDcAD5IdnNN4+beI06vz95RTZwl5pqUtLD9895zEZndGWpZEgzNCXmnoKEGc 6zUn18pC75ewxMd2RXZPNuhpy6flS7sQvOzG87HQIjRVriwdscovKeD/gQEkU42yVYWVDZuL8TsK llrtmFWWEiuGTC1O7zyUNYstpnFwwKnW9yYkyMLvPADdR2/TRaLZqz8lBjyYEg+CY0EwgKHnR8at PGl3TJovWEoU5OgQnk6yw+xRTGKjz981KaMnR2vdxh2FE6uqoZidLEcfp6gqK3otd5/N76blTI2E SiV2beZE1H22VbjsQmxuLxr6c8K+PaPhmOfS7jFpmPxPGSllkgjhOi5NLS3lQ55TWX29rbh1D0sL unt0YQwx0uH3v+R+cq/COv2MtrwaHvzhyd+DAUSjkg2Nh34p6UBQBrXv3KWZEfCU4I2iwf1haNyX KyZwNZ/UOx3NXwNXJF3dVRfhSvKlnwFYn7PjDJXlGEMp/W2HESqy10QtQfnCoVBPnAyd4utDVw8i l2y8lsoi2Bm9FedUS2OVsg6d8OTqseYBOsknLV/b4R5DzH+7uHm2kABsP8h2VJXYBcI4agkFtJpQ eKgFCzPAy+4x1S/65iSmXmG/wf00IlDve6Sc2mrk74H0Jq4grTjiMT6fBilq7Pp0t3887B2cSEzy YDTCf6vON8F6VNPAYcN6dTHVx/sG3yErS0/t/oFRna6sVTp51X18EqdfpInhn3h7C7WmhJJEjfk5 az/Pjsk8Su87UKQkczaxIBSovGChSO/VZGucMj1JjJ1VU2SVbWycrPAHiQ16mRY42dwjF8IJkPQo wpN1s7S7mPaX4uWyowhu9iTEr9jEzpym5AIdoAWq+uIVq513duLYedtyA/znpYvVdn0qwEkWZxR+ xydXdtEgtsSRTeaNmsHNet5muyK3dZI9F0HSNFuW8k1mAhIbGwtLWwD78tAP03wXGxuvs6U77lZh jFZ49T3A7/zGXIG0Km0+lukhINgjQLpEA7iLPYnftx5jN3qbtiMFuSjYF3XI+ge9EDdTHcr8/cBk gwFDUb9zI99plyn37J6wNLEFzc5pEeECUcW6a0rRrua10mQSOQ46Arc/MNl7fkx5WGXb1Z6zb0vu RVe4wtq5J4tfvdLJGTZ5p/nErGbYnJGTRy2mMsmb+UfpTiwoQokrJmBlNkRJ6Pou3Do5YwDbFbdE 8Ns7Sys4PHheARqEoppvl9qhu1Tz5q7AHBkexOTJHmbqX0l1tcoNoytYg2rG6NkEQVLq040lskHh +bQb0KK3pzQXbk6YsKONNqluxex+Lcm8Z8Bn3mF5uLtGdOPLGtgUzc8OpMMH0VbLBa2xNDpr3YB3 +G55RU6VRpeRST8RvHv8SC0XYSPX0OaONRVHtzJzSBek89ra8W1Lyi67jpry1QoRuDjszdFadj2N Vx3XbtohuRCi5H/+ntssnMTC/kUPbXVA2EueKAyAtpRhuZPV6pGKlqdsbxk583WCytGZ7bXln5LB arRwQEHF9bM6V1228RvZFc9smQcaYPAj/VXx7+xSIzeLBa8a8+R9Mg3P1ow+cWmVwIrL5k2pjSoS mnN8jsgc50uszKpTWPK55WfPScMCn6wlLHBH5+E5iZ1kd6OAqBl2V6S4NWSxsk2cdJzeIGKaa5sz Jh9y7BBmHkeFT8FJRVj2gp2dPxe6IoraY7vh5j2R/OGUIRYGs1sv91DRVxts4Sdo1Hq76ym9OOhg V24CRsNGTVefKuEa4RiEhJVTymHFMyYc0FFkzAuXiQh6Lo2bGk+YfrexIW9paCLUdXr0MUI/8wvv J4ZmDGA5Y1BbXA+Ckvut8xoJMJSG+AZFWD2oIlr2qlrjUnF+lv77WHGG+yF2qGSrl07wcd+V082H y58KcvS/diP5VpYSk+b28z04zNTXIOCrGIbgAR1zJ29ybZm3MTEkTSx1L2fKZdiJYkhPsW28GbhV Xg4eGM41kyV7+2vO25ci3wStDjyM15JjlqD+LuWVqz/2Sp1lVuB2AbWAOjyknSzhdm3vqe49liOp rbVmYx1y6Y0bJo8rSGNXV/1WvzTo9Lo7yQS/d0NIBN2zZOr4V9PjJMugoZwV+l44iqqqHvgGTKnj dFhZ9JgvvcHGvAypPQWL23jNjftcxdtRkTwpQ8d+TC65u4igglevvNBn1yc99XMu18xH/JatDo3G 9sbaBJ/gkrQvj4iF2NxVW6vUpKQTtEunKjvpdM1iOG7HxY4N+wdu+oZnsmcOnOwN7Dho6IaU7F0F Y35xUBQV/mR3IJdiSpKXWhl4m0xsFr9N15rtaHJQ1/oPM9ZQ2dy5qarPeOBiEaBwYztP71A3/KRC GK+aL+q5K1vcvOB5/pLe0mR7HTGO8oKf9tyujaIY9lObyOYHlOJvtce7CHgsiPPumL6raFvyhLfn bcgEmCPN5H13gdr8utYzqW/MgTZLlVYA/XuLKj9K4B8G0/mioAt4nt4RKgKwaTvHg2zigtYgo0a+ mfhhts74NVdrC/dIVtKSkHcTIimUNP01r1hoCM2ZB2TNP0kykb+QqHtI5QTCoRR113zRSciLVd2+ V3X+bx6m03zzxWckw82vGm4UlgBLuiI1rtn1q5wT7Q1LjHkN8Uw+HDIBI2h5tdxiiHhPSLIy+DyE fOQb3iQzbqULDE4+pU69Ta41iDZp74h/bA4BCxnw6HhgM0sz96+qkk5pftUq3UxB5rl+g3HUizQN JPs2qqm0HcY9zaXnpr1IrlMQJtR+/D7OKILPm3pCK11g6ddwHhIXmbDkpFDN+v1iKnzm2kbVHlRV Lc73FwiocIDHA+JXb0Gr2XcMbWz0KsaDfCnt1HPdwn9PHZxCMufNlhARTy9dEvO6libIQl1K0fS2 AZ+Yaz2aYinjdP/XW9kpvxbm1N2k0dF8GcRI+p5fzUbrzKl7zM+7AJ1hSRMdHUqnVUe9NP+EklZv piRg/UR4PmAvCuiSeHU53uVS5IYWTRmwpaGM+kxqInGyfehlcjdODQPof4YBEFzAlc/gqQNr4AMy tqwBxUSvTHo+KGd8GfX4pKqptXlVVemngrMelWecGIAB/MdajdMoUIh9fFndg8PCg+HTQLwM/RVc uMFLxPWFeRSE3QfKZRpbxmws3l4HeU051Jn7IN+C18RfRa7yOWWN09a7OexHs0aZA2u1Zzb37LW8 hX5blc10JXiX3F++cM5ufHQXF7jOLwa63Ud+zYv6B4WZdtnZF0E8Qph4mOOiYanhIqKUuey8pD68 DAmu+7Xp8T6CqgQAgXsT0A+gMuAVLahH9M5E5lTFvuCdf6G8W2uc1oqAsXNLlYsYMzOb+OgYk31c WEthKWi/49UjI+D9N+jFSc33ZaTRenP3+pFNhJ9EVbRMi/TasYBC1pvJxdblDHEb2fl69Ol6xK2D rNVm8TIWdGlLc/EqtDkW/q/OaM6gRtMXW47uodpjDXQ6nw8RRQ3q5k07s86WjM6uWmSB9yck1Sde StRqHCq6lYkFVTBODXSU1ORXPSIU4wuJoZAhDo8PjM8OT357Fp6dTBD4pO+SVu0rumveUoZC4d8i SAnWadf+pWff8OP5M4cqpSkj1ya+KOX4HgPudNTwqTFSLEtOpnnnra0/6UuxjhlYuAxQY9x9Ulve 53nZIOyWfs/5cN19NtTaj4WsuILqYtooax7W59qlQa2vv6hMwdnKFRx8C3QkdFisOEY/9fjc5Svl ZEsniiXNlx+nM3XunP7qVv7OUGjQTIjoxHPEM3QRCIZ3WXKXXZenXLXeQCoux4/B9lWNtssRDa09 Jxks9lq/Sic/XUzxTGEA8KweEmv8lbLQ17HR4clSj1bLq+V0UqOyg3mbVO5N+Ibx0N07ELUGIjyl 2nEoHk3AatZlnN0xAMX92rBseGtgAh6h25iKmkxwrlC5K1kQDQVX4xbZ1+6fvIbX/tICsuRxh4o/ NetWpuMUatW6zztK+qiijYDHjhVHWVrTugJ1qX52zqMpAwNxYEePrYVsYheyDOdZ5opZ83p6fFCh qjQRsdbbKHyFtIgsmQJNqSi30m0vpHHNpNRjeOdqPUklmONZWJ+5J50Wm8Nqv+paGRPL6XSi5jtT xvIGwlhJCmnl/AQKJXJ8kSEEOWNpIeMDeMv0YyXuafu75ASePA0k6uA2Y7rIch33SHHUnNoXjdFS oRMo/6kuJ2+5lNFkkqGRs0JsifKiuAuo51OjZxqIOQ2DrS87GWEiPH3dPhPCC+gIIUIhyVJPywCP kV87iDgCx2Z+9Gpe59iokOKZ15wNeYckbzzKayON00vRzWV6qr6C6+ezF09rkcWfcuv+CNWXeWAL ZENmLgePKyrRTOfSz8qF+oga5278rDWyRqYKLQXb+Mlre9PY+nPKpR777M6/Ggsc1/jwkjjJVErV cN8ogjJKjYgXuyDP19u+Uvl0QbjAyrJ054RYaRzSIOzLIan1UkVJJ2rIdJfzvFYF52u87EZJ6ScJ qhyfx98oK9+/CeqqyaT8EDumM6vagGXDPJD+Ye/acHLoKNngi10Pu2jamdKU+B2SO+bdQDzpAvYu OY4z2OJLfcpLW2ZCH23G7roqNbmQUFR9iIRrvxtbKVDIVs72TxlgorltJ/1l+5Iq5aPl1YEn4zyQ GJyipg5woZjseMNbOEDQAxY63uYn9MZnmjlkXynrYWQYeyF6NYkYdK9IPtupKC787K9yKTSlszAS cf13i6iK44pH8xZ6em/XbbzmAIwBWGoAtbNe77X3iUHzptEmM2t7iDQMoEFU3P62Hu1vN3gzGKDY cwxaDcAAFi9355iQy+dFCdVCB4/L3mlFdbVY2zDZnGrakj2NzNB5yFzP3DXGEEhrIhK4Y6LkgJWi UOKPn7DpM/4+48SbIV5laz5Uysj9jq7nYQCrycsZ7jfZl4eQN2HFdlCPc3+y3vytTtQktk1mzDn+ JEsD1a9A/+lh/JjBil7mbTHTmjzH+uWoa8z0v1JjI9A78WSZPgwgQ/QrxJcKjKSyXXX1NbXUsMt0 p+9eNDDFC7PTYrflz9IPT/ebGVhMUjczqxgZqNwTkjaR7XwvyX3vKieWz9iuLRDlmr1hHs2B82Se QJWbV9bMVL/utIgpuh46B+zgaBH3dNBZ8laI88iK9m85ua1et/3NTpfSbfU5VL6R34kxkpX5PaOB moluIIAp5wwP+SvnChEgDdp2rhVHafniYgCVUCYMYEALebMeg248FwD1j4sdYQBnIyc5t3HLd/Rw sAY0Jg7HBm01XZFgAHm9nRgAQusQvscxADpJ8scABGkwgCpRX7RyGDIUAyj2TMQA9qOR6AsjX/RX 9KUGBiBa83v09jkfFgZgU3OnLL2Au2uJFYdX/VS31nvwEzeVNvFb7raSv7uWUGT9Hvw/CYm8HjzJ uSkCgkZkMYA9lb9FCfn+KxjATtaGOIqmHQNoT7m7lgvqIMAARm1PuDEAyaivGMBCBRw6A7wTZ4MZ hXaRwQD0fZA3Wa8O8e5w7fBuzvMUh7f7LfugXyA0wQPXdjEpyCXFca0daD27UgN9+h9naOSFAfgw LL/BAEbaB0AXMr4YgC978c+bwI6XHySEU6BbNGjhw6jUrtvwGgPqjLsBB3v7s0wc17wrKDOV69kJ b/E25CEh/ePxgV0xbU/QxbIPVy0GwOi4MXnvsXhUar7M5OCcaLMaGj4KXYeiqCwHETk0NbjB4lu0 fTdc7i/6kQeoOQUj44PRHAWKKtBPMyHeJedj37VQ1UHI7vVgfkuBuTkYLMqZKtoXNJfhkuGprsHO rshaL9f2XBQp5e7vwW79tryitCK5vM48dpQ2iib5pe4Jug9MbOC4wJYfz5tf35vXWZwTnd5PnRsv Z5OeoDFFM9xx6ts0GtYiMUK54ZgRFbVfLFe12ZZVpdcm8e7+rC74o9z9RudCBXIpja6PT3KfLw9f R/1TGRq25XNzfRlxDMfL/O1B5bWv5ypAHqKCpVZ7Ee1L0tb63Ggworh/mA+WYPWHeY9LV/9UKyw5 amsAG8efzVSGUEvx0cxK1Fpms61puE7H0sqxWvil1c/1qXuIscIk3odajaU2jz8bl4zaB+yLXaOq QOCFkxoIWTwCqSbDtbwkSVf0HRJXcN/ZXajQlT5NWzV5mefkI8lKiGpJ+fsrMgwAG7esKn/UfjSi XUaM0npgYtWXv3HXavfkndr0n62QenBodR2uRnjflrP39bf4EJshsHa4rrVEab6jYDhxgj+ysl4J i8M+WHfFPDX8iw7tx6Z7QaRlluZvPNmthLgR/Ei9LkdnsMPyqevEonT7BAJlU9871HD/O/JkJ24l /hELV4+9PVdbTpFTxwtvxr32DuubgismDfXbvkXUqNsas62Vi6mNVLwffW9Bv2mdY0jRb1M+MRxT cDV7s/PEINmwihx5fNqmJ+up/Cj+Ifn8kMEp5yJSz5hLYux56s8HstS8+Q/k13GmEuJtxzEAe7FD 4yFfKRyW32Jw+wudMLK+c3pO3jUZ2kBtOQ76Y3YzlRcsj7z1dD7a5LJaEdQ8Nv80IPtJ8vHDEBzc nw9dnoh1QcXFitXvPcSPhgijlanE60GMPrNvJ5YgzSynt8fTApNAIhsoleq5L6yCCfg0NHdRsL2T mdlk0OGG3pa20ZuknKaotDLERq6/soz3/FmS8axrwenzZZT2hqD/5rxtaZAeNakmN6+Ske6OiZUs s2+G3t7W7OEV0rjhwjKjyr9r3SifBWiHbG4kVptiK179ZW385NNEMYtefuTg/QLZOCGVF0RHEbpR M6iklq3Qf3K/+1f4N3UBJH4pNcMHbIdTZ76uAZa/eEGfz3sMM7hdh7Xn+xvmydvd6V4qNbpe3SxJ GR5rr7uktuzurKTGMHr98fqaAX/jUo0+VfEGf2sL4ProJupuQ/t1bmj6bdp4alAfIDL3ouQwCvn1 IhDmsODtmU3bupGhv10HVfN0IPjwNprWknqX+K2WdPgz39TPMvLbzCcsCR4YwDcM4IaRNq4NLVUq Pm90XFspPjM9HQk/FPv1HxFGpQs1hj4GqJ4gmXKug/7BNUPQNtVhsPjpwk0kBjC29gl0UY48PE/Z EL+S78AAMuMwgJlsCAbA8BHVhQFMCv87MN0Nfo8B+N2hXPbsuiU6lOwBBtCkAwX9K9gfXgkxLFOh 05bvELleGI6ad/MVI7l5shMTxJMVLDN5ld01JDWvRWZSIuaJtnTcNAtUKqH0YbXq6Xhmg0i4L9sa DnqXMuxSViBToduV1Mxvs/GwXalab05ZE/J9AP64XEOe45h0psNQqBfahrfsukjVFnlTIS6GQGni NbL9+nmmpvLis8tnLq9A24zwuD/08S1M2tMVpMrwOkvdnX/qiqP3leblai8eX8IJT6VUJBs8QjaW eF1Hfn4OyXBcqXBpkGNyuE/r9i3nCFnL/H7v49irndkRDZbE6uENLr3KrI9J3qzt/hYaNDrcr5PL Wzry5VtawnRPJpTUWLip+sWGrunXJoJqwBY6dZCDgb0bcgvDkculDE+r1QJsoLaM88YOJ4Gn1npp dp0cBoDnQ/8lYaazDOAs6k9ypBtu+PgVXmCeEY+uorY4vjT4gRI7XzypkHvtH31GmfoRUfJIbLe9 OzqRD7zpFhZiL7jUOWHwSHvo7i7qmTj/o2AEunr77Wjfzi/uiwSbktifV1TbdQmXF+uSmuFi/vzc 1mGjg1VPblPdNCYyzA8We38ukxn4Idakm2+zfjihcp5ckWIbFuF4+xF9yGGISq6hMCCfch+T0lOM HJePIvtq8fCl6HZ4IN5z8NOH+N3u5hjA0RmVOHRrEwG8JRK+C36V2QtHNGc7GEBZymXo/u5dPE8G nmJdJZw0bChjVaFoap28Kb5GLxi0ejlkeoh/ssdR0vJnZw5h9eDK4vLaVyRMlOd/bhEtY+bO/l1j exmWTPuRFuds/5Uc7Vfdtaok0aIdRy3fm1VhyoQaNNZF8MMEr3qjuMQFCs+Q950k5VyC14YHWmz+ UqBWA4+Wi79FXUCHTpY3V249/YVKp3tyQNtr1t1RUMKWvsQcBiDs0+HTqR9UXddaUL9rqjY4CjlW ifmVpf32o3AMrwwTOl84wL9JsNBya/Jir1zryrIKdpu7Pfrv7x6vTm669rsWgUy+h3WdTezr+7dT l3nn5j9NTrhW+K6bmx9r/Vyz7oJF6UAoh2KtpajYw2nt1YX9rtk6ENNCdQ6VaBsgt5BlDV+K9vkF Cibgn1bvzPmZDy1k3DbfdKox1kPbcE/U3YHapqV5Pd3CM17a0sNErvliPJg4XtrH2zLuvaoU1gdt 8avfoHeZVf5EHFRzMJtiKJ2OkoSUEp7OPn9yfnW9WUlxIB36sbsc6wRz6U3CofHDgCyDXQuBmpM9 Vz9sc+qfKwUjykl6pce660OafeROfWqJ8gI6b4Ukn+iayJV31Wre0yR7Lpon4sNFjqWvhwEIOByk /BCzdczk5Tlng7Q4hASV1xGcDCg+oAmx3kOaG2qupAsUZrisl7+xoCyjLorRGQO0PJokvjrTc1oo ovltWt54gVR0r/M8ebydyuVb8UNMen0aiKqRUJj2VeZ2eUWXra/U1VLxm8UsPYVEQeKhIu6AtuKT a18llzmtHfP8jZyTPctDayGjf99ytQ672fGtL2jssNjyMHwu/aCQ74Dq01qcburWkPakVIunqLeR XYXgbwv1sMp7LO9TKGffN8pfnxm4LBSWxO4WtLdPBICp0O+XaORS4Vn9J1gM+J7zunaWhvaq24qS DK16p2TxzeRVydVBr74XfbVzoP4t+2TdV8npH2GmGq5Nqwr8C3c85eyP02Mc7KpWfljEmYQ+aII8 ttEzDJZd61m12cuWNnmPHXGPFgOQODSlfd7o9HRvEwOgSaP1JjuX3UegW+tM0Sf+d2nSLN7fNCn4 poGTe6UDy8+yoCxsJd6hA81c+qeCmHt+f8Ql+T2eEH3x74Kya8LPjuYnGIAVBuAoXQsyy7HUh4GE lrdiGjrMzTwCuBnYHLCKwMlkJmwCtGoSLcwL9n0tGyUa1+XaflWihJJzRtv3T168LH+UrzN0Fr7R JKfydlp2THXGnKW0LnXXuoKLhLTFh5RUyI1LRUdPh0tjYlKC9ORURSS8HIvuO+XyjrhKK8xmdt9+ owWsraNybJT3o0HYkrHUoSzhpxkzZ9qToOfEUnrye84/Ie0PVPEMqL9FV3JfiWmJ8p8+2e7W0iZ0 W0qT36hxl5w2mPCXMxHVz32QzaoC3kIPt/jAUWY3GMDPsZ6bvQ4FqNNNpnLBT7Mo5d/b2MxR4CMZ kmgSFBnr2JSjT/1Gkya5i4bamnTRfcHS4nGnjfRa+sTpTZ+mwV3/N39AoeVx82TCTh6UxwuteDaq comLsEGnVb7eB1SEQTPmp0lHpqVvpvwZazRUW1Ln1RzkAFSOLwG0RzsCD2OxXk1KG38xqZ8X+ZQt lBf9e2YMOxU6rIktlGZ9cwzMIV8WVUBjLV/Par+6KQZnGrRubUloaNK3+NEreDj0P45dMIcJk7ls OB9IPMQVlH3Dfx3TJ7aQOsG3s+esp1G13p67PVmDmfk/+BmdG9Vhx/xuR5WhqYej+TkGYMRuewgK 4kMtG7haVRtcOi6A8NHEno8VKFkwgNDbG0oQEfR1tqj2DETG8wcC5SUJAuHcqyjpdpefSCrOZ5EP nwyWqfmQrb8e4L4l6dWW1Y8q3rc/84LKWIvOBq/aHN2o3Ocfr5HcnlbSJ1NyS8cfWUfbiz8UMr1E UHi6jXs8XvsZ6Yi6EMohAXbYcGEA3dDQfjv2ncLojGqWgF/h0FGNCn7iiJ+sItMMsNjonQMZBoQx c38r62SR8NvHH2xVgvt20h9oLDN9EHurXC8eK7YG8gY5gTwWDXx96WcbFy9z1sgywyzqvHz69gw4 bc9mdvKF9MBV1vRvHQm0YrxBv0K63Xl1D6OWCAmmxnRU++VaWzPouMmjeeuUXTQT7CjS4gr9lOz0 mjUlVPlx9UVZHzY+o/2j0WcAbe/klqmzO1eVonTt1qDp+sDo7iT2tvPPU8SwuD0G0FLa+G4JBTnQ YB0mC2laMKUqYfguwvcaYrXMTCzBQTXW/TH6/u9BCvMSh020BVBAGE7wjmwLCrFnX/bBWWaGPKpb 63Hv5RYMX9Q8Utuoy8jO+Wx6sb2ke50uIPKBPKwsXGA9SU1TidEL6r6FdlimOXJAphFhv2OhoMYh BkhefnYPfMQ4fb84U8l1DYYBNCOXBmEKky0u8KYLjpawz3H0bVzAfpxYbhF1g6a90bOR6oWmnysN XHkmitaFYf20CcIKrDGs0Qoi8dzCrVQV3HWs3RiAxj65HG28jU+/5seoD9TBEp333ouz//Cd1f73 yplv1bmI9ttxo7gmYYNKCG7A7HKrMG0auTSQgpq1oowyuz68mKQgO76VLCEvXd6mXP/7ZlF5SdJq uiC1p/S7BaTwcDoa5gLb5Fz6OP0w4Bde3EPNFxIPXz55M5kbKubCweqbNGAApz2NniY85AD+Mk1m eBz6Nm4qkIQ26lc/+fdBWhfmNofq8i5/lZA7kioks5kCNIGIAy3r5qLOUneKl5ckEofG+jvARh6C dY1X3kAqtIJB1gKTXnIxgfeAj3tBufz3CQkVbYbCIC5Bgwxwtm199OqAuUG7eNnTz6vSUg9MH8UX Wsfi0ue36JeLmYtiACiIbxTSZzNjKSfdo79ko4CRKKPQWaChVU5E+jvWgaxDuNTb5OF1rl5TDw3W x4LrggE9oqYYwP/cTXXwTi32GYWQfxw9myts7EJO8zvdD+jUwkUNURVOa9b1ibmBz0NgqrOtMQXS keJiS9+0pXYygmQzqsj9a7ZrKkjQmhTm/JZ++zsCoveDTNfr/dMSPe41StbXJZHgWEmJlxUvqkhR oWRd4DH2itZkftc+S+7yUNbztpxGCtJ/BFArOd3an+fr66UImmkcELktmG+cnGl2eIxnYmoxONVd ds5B70gT/Sngq1roup7Uj4qEbSEFj6n3HSVVMu2V29A8mhohT3Cri2KlqM6M8B1TN/9ZRJtWekE/ NnrQ1y1jPP3swxXvT1UdUsIqG7mP0kZikq92OhLsibRW3+/+1OsgZMgTvk3gSMlBRuS8wQDOlC+w MABT9HmVeGTAMmRFDo1ynPPpgK7bH7vWC0HcPPssPbb0HLNbRsSeWe/b5z2/XhBsr9ABRg7orLu2 lvu5eS8wM+1+ks+kZDMqUM89Urq8SF/5iU0QKKRjS8bkYf7mvA7YuMS6Z3B4qapiOdH37RI1SXBg 3FLB1NwqzP51n2mHkYlmodU7jcMD1V8vKPzq2o9q7VfF52N+2WrYH+Bolblo+c5rAwrQL3+fmfgS F79QxHVqkPbnI5hkde1E4sNC4cCGt838L3REKohgP+AlfzJQSi5OFRODUoOQjZkR4wm3f16wbeNf scxzuSH7RnYRpL6kS2EzwpMupgSxD9P8PB6D7UQ+xr5/ufGQBd23FGtjTiVWjigiaccCiuiZx1vT putY0yUt65m5enjTmozsq9Clhd2xA6CF0auzYzC4d23Ze9FiZoEYZ2R7sbklKb8LcdseWTm0Wd8U WbmnEN1rulJaVVVq9uGDdOTMQ1hMAC1OQjT4Hv0Xy7y9/44e9v7RQ9V/1QMPBvAk4NVNVNmV4/GJ /e3x1g++maEuDw/YElkMb2vLrMcfjw0ifmstkHcRiUixKZ5CdCBzcnclc73AST91L8QCMCH3WlIt 2Hoy7iOaWguXZWdmX1Dxm0CmhQyTGgZw77iR1/sp4ufR+GS/GlvYHx8asTE3y9kRyVrPaI1a5OY5 fL5Z36/3YikjwmOD3oN9woyfyLiGQ7snI7nt3B7dNZ9KAHBTVJJjCNt5e+hvWzUDTRAHjtvlfF3y TA7kkUf3L2bs+W8sqbLIqcKia6xViRwrdn4i5A2AO6ON3Om/A4xIYNgf8Wq0ixDZOf8g3E4qcwNn fSmryhnAMOfiwZ3nAoUot5e9n/cg0BPwZv0yFheyvlpIyHpZeVIET0zq6OwsWxiDolXCIylyZgDW g/n0cEYq9rC5XQuGoTMSX7jWnjvVent97gLogcdzLauJ5BrQwXLnMu+E15mC7k6zzUUWoWJhlIqf 8cxX1VseRsjsAsmwmTh7ZFUwNRX3dBXKsohCZ+tUBiHbkvEH7mP+iu5GmKMVfEZh/3Vsg5mFBbLh RswaxcZE9JnZvjz8qp+IhZwVRLn43SbOx8Jj8pWliNC4wXyolL/Q53fzbH3p3fb7vLRNV5EX6kG4 YXlfbNIhdIkV4SEh8YToqSZCjXzGO7q/yD37pSx3bXbslJDoQW4LDdkj65I8mCj3NIGzVpJbSHoG 7ixKniezMnQsroiecQ7FdpmxqSJDLHV1b3Y0ox554dkkjOd3YbyVZLEojPJwwIWnuUEjzTyfq5cw aZDfC2NRwUmiowHu53+9vDB5BHgwmB9CF2bafWYPTU5RLXG7Wdj2r9P6HNZ50L1vOFM0FW96vZpt v0ZBHmHqVZ/GKiVKA2oc8Z/QniSjzPzqLh80GLO/fe+KawhOK/a+AW7g6WnLvfxn1x6ZzeZ76pvj oRIcMFLB0IsBWG/LXErBdaGR0DdH7dOJBeg3HgFDCPqusWuZpQM/qIFDJvtsMevvVYFy/scfsuhs fUwsRBb61NmbJk/3nMVCcQJAf7ZrLLm9/YczhhxE0B8qOLJGN1hO9Sqr3KpEHVTYEsuTW2mAOtw+ RWWVFVnrcTGsQyqtXyUkuspfytEe786DEmvkM5PPDvCSYCHxWWDHHofaJVTrazXtzsKsBL6ZYS3E FfXX7/LBnSaMLLZ6MVfhOU2OFfdJ0mpLBRLuMsnk2CO16Y+yCJa2u3gdPbIfUDmiwCm+KneBlLtu zlk3aNgavRn77fAuZ731VSkk2UQPt5LZlfASt0bpBfSiMJSX+1nAC5TJnwuNrYkMNT3bbaFFyQX2 SB/M7L+TyjHeE4bGhMIWqh/Cjge1PEn+/rPCra4r0LbT247nrS5rTk0uCDs2+4pjV81M9BpKn7hs pTQkv9zmWwjRy9/ZA8j2Tnthsa1mm/dj7w9ajooCs7BdWMpKc+8/pQ+idX/jq9Fvf8DRnBn8e/nR 5M+Wgxnwya3QbhrbepLUUNn8G+B9vJcWcXHxPNLxEnkGVc/Mr9ZOteXM4wJ0b8LDzOKWTJXX4Ss0 OD2Bb9Civ3L5qFYOn+MJun6+w0A9jhAQfAI0ZuTPy7CUc3D0Pdw/ZoPr/f0Sm/qyq5zx0z0qlCic F3rIJiYN2l6HYwC3AUjgXgwfaFLh7y7XOgaQ2wK5wRX3jLl5+3fH36WC43pyFjp/cFWFAXhb/926 l6HHADCAPSQUZOjdgE43OLwaZbh9NAv9Y41qA63gboijkvRAM9nt6FHPYUfUoEpczrUg/98hwHbU 9dpwztkEHDTiLb79dwvsgcrS2h2gOjJhAIvlg383vC58O2xBy/p+kRjAeD8UA7i+PYTPUtphAMXJ KLRr/10O6H54SRpwSHUp6a2C3tAGnpfUgBqWTg3QJ5Prluhopb9Pmj0MQP84tbzlgcBPs1Wun9WA OieRXhjAL7IBEJK5/u/rEHf0qON/EQ/6vy7eWTiciingLklhxnlt6nm3OodDdGx+evqGYsf7WfBm Trd5Wabd0pV+jbVTEp8BWZcXEzqjLxVLaXU33R9ifVJfOqV6B+yl7lg+KP7O+6GtupM8/Itu+H/5 kBnfZasePXbiv9+awoQCDqIsVo+J0w0Mnhl4k3IN9PJ55Wsz6uGHvyqsZ6IuZ3w6ve5CiKhuaamv O1AuL08rJ93adWRpvlA9kXtb8Vv3pl9UNlZ/AYbLNzPeCx1Xhf55UBqwMxH9n75dCFHOuEQuAd94 ahEN7oxAloRPnbS/06H8+Pi0C/LyS3+PrUIjLVymKXGUn91TAiaURBe81eMh0OzQsi6S4r+wb7Lz BSOdwK1G3xIUQd8+3X8/NWRFKEFdKatmGDf2IOd28uJ0YSl+LdUblVEJHq4WldSsx3XYjWEIJlDQ s0iL5zcLpPU2m/ho1UdhxPAR9CsANeupMbHRelh/EaMyPrVma4FG2F+7zqEGgthUEvXl5clbTE+I /bMoxaDk8Vrh6azTdnFBOPZPPFMQG/YZ8/bLG9pGe07R8/LZPZQsQfqAKeZE6uJyxDqTuvUo0AUD aCeDGYXrVfrXbzxDXLulYU0pwyWsjnl80lbZ45dey2F3myZPEJrQuseWl0Qo5dCixRxHI7KG2300 6nLzjfoa6vE/2Dq71607C/oZfwhP4QgaWrOl0V0q47o0DBaVl+Fx0vrQ8DCb2ALvZU8Gus97sLVq edIPKwp/FVeSCVDxYFsz6MM9wjzAWiUGcBGxJKaHzIEdGCNfJa7HIviPX+V/ZGJVp2nUkKJOj1JT jCExs4waSA6Xo2Hex1bTmVmzIaqg0lGTUk95Jso6IcGItduyZm7PcCIWOi8ve1zrtVjhE+n+dtHA YKl7bOl9/AevEEDMHVcx3XIc/gSgunP2OZDxxv5j8X0Fy36xbvH/4FA4Oa06S3/SMYBKRybQYnnf nR/C/zNMHP4HmJj9vw4mzgrm4VxiHoei82CP6AcbWP1Dy66uW3UC5NJUr2AUcXED5i6CNtuMVseX +/6UFj4tu7vNW7qrIbTetB7Y5XIPFiKUrbfIWit8db1DnbzN3FXzreVo0wEAm3i/L9slARcPDiYH UZTHHQfZwy7uYJilPevEIPv8p7g+clmjZRmvwHzmwKGhD6UP4wE1BjcIRTykji2ivebGVrxZvNUL RwwL1dNyIt7LL+17KSaUQXVj62Ledkcbe7ivVCCnM5qXa6dTsodF7roW/m3iKo6PoOGHeYTuglOI wntl0cy9SaabNj5X/stIcbjvyGEb+rCp8bq1zOKIreCoauXYzPKoarXCy0mm4qParhANdhNPjQp6 ebvmH7c2Fr9U5TedUDuv+eBOq6XoIhzka4l6DI4inueE6TyB+YTYxAo0KRkjMqVAZV8xgJImvi5W HxkPXzW/vZkq9PRZaNU36Ir4kmGz8tSh8mqZQfHwvC5FUOT0mc3SaUoKb2yawJ3u5WTqCz44XtvE nF+kr1+U31zrWbWPLAdVFbcX7nj+jZwzJcDRyQYbV+hboZzy/NhMS+PzzNZkzeduGAAF/GogdbeL YeJ45SLrqcb5bRfCvGVcwSc71qjJSOf381LTheh4dzDkBG/v6oiKBMVfa7PdI5IVvHAybrorry+/ Tz/QaVr6J1F8emdleJOLk+OPkHij5+NqrNztX2NqxNfZNQYLAUn/nmTq64GEKH8X3JmvIDKEg0p9 mqfdtAHsaNSw28YSW1RYtiRo9RmdYxu/pC7JcLMU1l79RZ3zdBu8PqNxQqGFBWlRmdkE9TNUl4Et f+Gwb6PoS/o9km+XW1vq8zVZeLXYOahbGYgJ6kNQun8W9o+jtU9a8aYROJv1GmNu5naN36k0ptv+ 8tW/kmiJ3myjqBs+3ZAs/aj0l5+Y9vA4mW/3OiBmHY0urShf0rP6TKXOXIfS+pOAtpfvOkVsPzKj Yk9YbKIW555Jzp51M5iuA9Et16TUBrjs36De2nlq2IuuzLkjH0jKOxdYrJo0oxc2IG7cAEHqV7d4 YEueyBjjRAM2c6wxnaqJ9rztwb/2sXMP9vz43NJcDp+F2g53/bgenbsHcWENBnW/W1ueXaVy1HcM 7hjpcDEeuqb/J0QsN1zpzY6ti92/cUyg4tGQUWnidnt1mWbQYyTRzs/L5sdlzfCxTOvVIqV/yvBt gZs11oXc9Bdfx5J/YksqRHK6D+xJkHrU2/5OzzP/2XWU/tou7jtjnSmLZw4yUPeCzvNTt9jmeEm6 m+DFdnTLIIXOnYUYDwvR71HdjYeMoA2sP+Q8CuCM9Ja8t8fq+tuUH9gRD3lz9U4ptMpFifHzpS2K IwUlg/LhDUXRooSEl2E7y00GaF8owzZ/yie7nEhhg7cKRtF7WOhrD4LETRlOx6ERIXlDoudyvE9w frDVGJ4OEPDm0OOHtynmGbWovhbzf9PiExs0WOV/W7bDoF1zkx0gNOMZOoioarW1KoeZn6l3zTcP nH3hJVl0I2Sh7OpSUP/TR6hl8ed+k3rPeknvqK2BeoPwzgeRURVYcfO9E5LdW/FMuFvfNBAbojxf bEmyvDO64jNJbuqhHURGW9XsKaoR/Kbx5acjrvF37U3aVQfsoiVfbd+IZbE023Pibzr/F8XP/M45 yjlIKyjvR+aAzEopdutUV4QarLX7cf+E1b8/MNq6OGmJQ1rjslM8/UBCnfZ1VcXawWDFOHmBoxsD SNH0POnFa7qSO5HOnjlC9jnI2OtXlYAs+3bRs9foKYZO6Kcd1pwF8QUfDjRiWihFQsIgsTq/19Sa meVEkLTFBscfl5xLU2tmZkYx8awxsfGYRUFUSvGEmZqRdajznusdn6j6iXwtuYYmwAAYKRfnNJ7s eJqDlLYqUM/bikRctT3wLCUlggbU5Hg5WTQo354cmTDlaNiWFEbCExAvHF+ai2ltd5cEO3SNpN1c T0IWliNa5iDoV0tB1pCa/qwBk7O1C4jBnwkTqPSQOcTILw4LchHyVO71Dd7RHfasYCmwPTa8zboL ZQgGhZb/phXitBxI2HjAAXqJ3167E4m6Etbx2Vf+EV2p45/3i2pV4/CKKxCvsQxNaxb6mZcq1Egs p/XUGy+ih9b+oOeOdbrYr5sIZYSZhjcVZ14m/bH9vqPoXOUsmYkBLE0PPEgXO81sDZjNfmmX4b5x ZUTa5jhJ9EFoF/g85EyhOgb4rGuCd0/pze2qOFDa/3+9E+NEhC2CYrq9QWC4teFi09HNskGQlFWM Ae9Lr7a5ix5rtXw+s4gHX0h0OElJWXV1RRp1CK36ieyK5sv3F/kLM5snun+aIN70FtiEErTxVoAH YQwA7zOttsNWDnYEMgN822qgZ598LFI/yBNG4NxHmuxNsRisKfUoLeye5kvZBxUB21TrlqfPmqAh Gyh6trqxDO0qcI9bTNsJ56ZnlvYDwfICOrXI+QzzE+6xA5zHohIZJNllP5WQXIU44/UjnxIugFaC Oc5H64siwsKuhcgsZa16qwh9rmiWt5Lqj7kVcZHiqN/t39ZjKus2Xrdt+u88+nXPmiR83DIUzBt/ 8Eea8ml2HjtrQZsKrv57YuJvKVHHkCtGP/EdYsb6rOCw6iusDmuW43naYUeoGIfVuOYql/t5Y1jE 3pCyvKKRFq4/69S4mbWrO8mAT29RS+G7YTZhhQy8JvK6xofxJzS+Xk+ECn/df0odFySP//7n0JfJ 3y/bXYOWRg9fILcW9RxYm7Wv2bU3IOGyQ9o+Zi3uyTzSXEAF4jgjYtkxOWuKjG7aQTlaa0YIqzTN K8ixQNtzrNfRvz4dpe6ySr9+9j2/uHfVmTjTnkfTa9+Yg0KGgMeNeBdbQJ3xTdhLgQIpLdVcPBdD NRkc5y4cm9j8YC1VAAAbAOgEfLr3ReinLQqFmLg+dV08pGterDb3Nk/WsaZL1iNui5ejiR+lqWM9 6G7gpI2XExVAQeWEKlQ2U44e46X7SzzW+LTGd87xm7L5RGc/c9jnNtjiADb+E8inULF7agGODozH qXKX11qz/E17NuV+3Ph5e6W6slz3dFFM0dh2oWu+N8gniLPup3tepVQ5AEdJs+lDbZEmN79eAZId NdaP9NnqZ23OPtm5rVoqTXFm8NEfkX+CJAyVbCUeV3QtfESbTISjvapg66UcRcgzOT6lIqf16qeG EmusCk7gKHkdp4w01bSubzeftrSZs/Tj0JpCXYvwVcat4K6Pu09ovmK9OQ9a8nH9lxykkuxK57zB I2YUFC3guAr6RQNrhd3SDOpcALsfQre7SIDQ1Z5LsYOIXldXxHTBqa0j+PSqzeXyRpn/YrMLGSq4 72w7QZPSU8VyG8ul8f0yfKcmyVZS3j0C6K/sQJ6GNEXaOl2LUxxcHOY+q5ES9/qdLC2/43NJ7coe jvdKJrSM19bo8nZTB8hp9G++OJMFHGVpuEOgoXL7NMk3Xj4JlRcdszXYPSmXBwGGIchKmi+51RzO qr2dxsMkzTePwKth/1sZccHfMmIn6LrRTCNMYWVTMoDQNR4RMLjYbE1njv2YweYJXwhfmkBroR6O uVsKdMZEnHLckLT9bw1xhezerk8LlZ1byT/L85Fj03Ju2ijjNGVdzMKnqLy489D74jGrdE9uSd/5 OR37uO6n83fP6IzprbMXScw9blDvvqvzUhAqLxS5nm5/93UtbmnGACLgI+KeN8bb7aHjrZ55Hh5/ evfD7RolRQ1aG4h3F3u0bcWTFgmbpt0S58JWwrXLB+rnhH1UXRGhX4SJ2CYSmxnzPuC4iWEAYxJL KRiA11Id6Ex4FAM4j1kKSAXh78K14Z1CXNAX0EwZO7+SK/xZUSqlYwzA6rO1Z4jkm/m2c6Kj4ZnR wM7PTvM4y0DGxFOTt4Fyb4v6kqKMpo11tNrnfCs6S4ua3NY9cWnKt++i5UayAHW8d5ZJCPGynpkL IU00L/vBvpeW1MOES8pJt5qa7Nf9lL+VV67uLVEUPOqhvNlf2mmuK+9OoGRgyK7OwX/Keq9NoDdM nKpkPj6KuWBjXBhcYnEuej8bMe3THh2D9vRejthBg3cQ7ccVtjOrPluWny6KxKSVewcmlJJTXkuR 8zanh2suuBaJaltAB7WYsZzqFTtfCl5k5eL0NDnvqBtZqeaLUYkFq1w/UfDFAJY57YG3JPMgdFf7 3k7o8bljpfghdAvdJ6PxB3iqCwfxtM77xBuH/rJb5KUcWySDCrdwombpMlNey4TZkDLz8GiRuZI9 wL7pUM9+liZxrx8Ag7l8wHe32ZmrxqkpkXokxAQ9yl3+VcoLIvcpzi6SYp50DPg5qFZxvV7q7Uzm 6qjZT+wo30PuzStNE79/7w+qvfYyRmkJ0gnN0Z9DaU2wx3j+FM/0Bgb5VgQ43ODpr/g+Y2m/QHPb 7w5tVRyFfe8bNwMyab4h4OEtLjohZHpcpe/25FFN6XwzzTHg4WSJSWK33DN1n/rD6yfC9RjAIRmY Ax3qjQGg61C2d5OlzL4Go+/NQrffHAxhAG0Oc9Brii0M4Lr/EK4o/v38sMLxD4VdTqNN/d06lV9M O5z0qptwoWCfTWwgYmQUPE2aui2IfsifDI6IgrLyaMHyT3npYNl4OXy9X4ul7e1FAvTZ7ewkasa0 7qcbByOVI2cxDh78agdaNNyzrVD+pt3i40ZrIyI+sG6pS+Pu4m02kGq1/NstKUliNF4DnVAi/ta4 JJO2uZhMbuvydY12xk0HBpB2gbxUkUqeE8wqFeYoOfUWyjyGVST7if2BCQeWYwvZREbD+qckYvMI COvUyspy4x/JWdxOJTNweevHv6W3ld65tOT8FF6jndIsviIhqvGYN8fKz2eftdpwklOWn34H5oVj 527uzzzt9cOTTXNqAANQfxuVGoAFDkhrm3PLXaqJJz2T8Jm9akEuH1+lTS6Vwbx3WcU111wTEOQ1 Boi0itpWsqeNyAowGdMP253NqrIM4XTY+HSXIfNeYRL0d+PHtzKfEV3Y3z4JnA0sCsbpxTgafCuM nfoV3308qqL2sp+8rqWfYGzga9xa3FOd6I+2gU8fUormb/fVZDv2dxQOnan8fr64a7fPguswBCcp x/aIxCc0JirPXb/YlAe8Z3ms4TiroZkrUj5wb92XS3qqvCs/VD16wC/mvU6ru3JN15UjiB837rik jNPo0XKrhruOvX1d3NDU/jCiIb9wcMa0bn4oSduh4mn2TzMX4h2zwAwOI9UjzYmhfZpE6U/1tkwb 31ptNLKTupzw3d71SYPWc07X9gZEq+J++RnPG2Twt53wcP2UaUdhkUmFwFot8m3zZ9URv/dc9HD7 DBRTzMIL9neSlehufpPy5cPSkZnuni0Ehaaitng5o5tIbVeOZk967VbBH9xXpEMdttwJZckNNAn9 6ww+6Qu7C2VpRdnFxd4kaamLCQhdAgJyoY9y9CUxeuDeuUXhSefPfNGTXbMHuMPNXG5ehkSvXj+Y NuNKU/y2oyQjJXcfV4X1VBZwfe+cFqACfSWh0VUDkAPgnLdtnexfuksdTa5dsFisBxMCLQ52Vpfa y9IKsXfYV0pLnspBrJm19YKlWaxUIQsfdpcFt06nyksWCR+ddIBrUqRj+1aK8Lq9zj9CRwtaNDxu vu6NJPds6JeQTMFoN7kvL7PH1B2VroS0G7UYiyemJRrr5vpVMy4nqr6Ai1si3POTz0VpW21+ACWm X/iqTRhD8tHa/qJaExjAEyEgbkLY2+FDVi2g1aYWje6i3BwhW1aXlJptg5a6vXXpmwSdUhEpLwAA yG0TF3MnCHtqovfxngoGkJGoFH0VcRKdVOMMz6p612bBwmZ8PjSd+8TR/KlA3TX+6NbCHPohSugu 3ZITmxw3QgZk7K5AE1731JytnZiITS56zZVfYwC5RKHummxmL+XkEuHTcLeM11QkTCvxilLmtM2W 5xS4Utj1C2qINLi8qrMoI1hJpTTyefXgFezA+kj8Ef9jLpI2SW8PGWP78uCHQaIiJNjtM2NHUn0p djRUpfUoFayLoP0drfFCmU2fSaqFgwgfGN7Vvbus+/JwMWMlTtt+Gjb2R63xejnBEsEqqvmxqVpV y6G5c7MzCEHRf6B2suOfu296unvtX7IDBP43LZhn6qmO8o2Hv0sdQ0ucUeHtzCD48Vxrjc3HK1nn BLWROaPWOu7putTJZ3FV4cVBTj8VJRW0pENsvxeUa/A8OAz5c9/OQF/ZPaCwOq1IWJtP/Ft6GGBV R+SBZR1wSa5/BLjUEdCyYPIOAwibMzCMI4nlCitpD8ZVHM/TqfO+94y8UOYD4unReTAyJstD8n/c Zmb/fjdzYPcR4GE8KPdBwqGfz/gb7IToFF+OCmHuutPL24rZW/92/urNQf/Ro7bH0zCSzAvTtxdu 7iSkDTLRvWpT05pV9GLxehuMhTI4yghz9Q8wJYgTNI2tstIi2aOKED81HTsd8LTzYc57ljHbVO/J hCsF25blq4J0j9tWyyCVMNHhbtXu9CVTIxfZ3YqyeTUb6RJzNfX3u70+plc8fnuI5ne8aWJNhbtG dZkk1KiIxoZUBFTjOzEcGqFsaqahELdvQ1RTmXukYdO1AOTROJZHOwkutFds3v7+NTEXYetZ41ZJ EK4TaVKPHScxnx50lH4e1vHnjm/gLdXEabhCGjaRcP4Mx+ex9mP9QoOrVuJFHr+EscZiquWNPLa9 MAAw8MkSBvAR9OaO7yz5qikkHRittQvvMcnEVWc52xPvGUUYRZb2VFFQEOk8Chyw4Dc8/7EfMajb 9MJyJz/pG2fbY55ETQVf8QbDVhNtpYlNg/4H5CBzkoeq98sVpkjv9CnwUJX0NGMReiiIzEjPzx6E 3QY5bmQwUUus6iCDV2XriTyjrQvC52jjgr8XzMsO4ETXPzbjNMTTPHNUPrMgu8RSOU8e2Mu0Hftc 1wRfUoJG9+hsll3c8kz9CPOkN3ny2NR1nXG1PPV2WdqnvCTe28ybVM7MIuECUWK3QH3kMfgkNzr8 eTCgVk2iNLKOUNBESY52KruWI6v999ahiyfeciZqhCwa4UGX/PE6bT3urfUcT/4ytR+Lm0nFtSqt c/BHrfeludjZQ0KP3CguYuzPU+TtmZeQMOEte3f0ZN5pwSY/n3oOBaGRGfH1fmn3KtO6Y/vI1m7p 3x7/pqUFpdUV/9Ljf9i72agPt/ZG+X1ZHg+lXfcDKVXdScAZy/qI1BaVMz8sQH89wKBtib+f8aP2 cWOwZovM6kBXPbHWulS8d9rbGFUuochzXS3QCHzl221XfUuBzTq/w0avgz8CcpGt0bTLOXebN5Ph E+Q0xiXTXPz74CabimduiHK9rLCwP32A3I1nyqS6XrBE38ukIga2FK0pXFQMc2SNp40vJyl9SYcj xtysnV93r7wcMNUZm8tnJnG7BPQSuMJK9Yb7NNU1tDXASppj7PUo95yy/jgp/YieEfx8TA/Ro4Pg KwnLcXx1OO6d+H1kiNfMX4nzj9vNVFzdUR+mJdS88KHoiecaEVxpPHWxX0yjSajm1ePXhEmCisbE gzptF/a0oC6axSbfKM6iE+IzQpKWoWmJdHx9W0ohAarFHPtD/mfNzUEpK8f0CdwfeIJUm92Ip/Sz BlMseUmbXrR7o2L8kVeWid62dheuy6Jj87p6cZSwZvmJ/tehtI0GCmCxtxBdnC8SgkyWhPlP1q+d HaqcK6rMcR2EPItqCu909EGySwMn9jerbEcYodxrcqo8ZAwHWW+P2YeqbSmh/aX24fYpW97GHVqZ r+pPbgtKO3Ym/33bYeYX/Ci7o0gQfXiQvVlZ2Klter32yeQiQPgyWHzR0jmjpI5rWEMhHdYr/zQv /xiRlZOUV1Eq/535oeA97Mo4FbEw6DwbpHfJ0346CVviiYRhrTeuOzvnQmThFCkv19MSFlC7ZDbI HeWK2IJcnC7JuLc6xBvJ5TV20TVF6uszbf9pd2CvKg7niiGxwvlW0EdZ1Xi7nmLI/+8g2OEP5fbl 9Y3ZsAy44NFGsf2ch6Vx0nLa65LT2drfPIgHgS8NNR9VdZrY9zUQkKrJDOaHkWlGw8UiOFrPlTu+ ij/12UwoQ9PeeM9N1fo3rPlUWJu5qBHgQ45vh6Mi3BwEKd4/FGneH1YgOx0VGyzk9RAXi8onNZU4 2R5HlSi7fd8fXsMyOu/FAODnLGST+/5JLRC/He7L1Xg2SFD1UJuL3O039/w68S/++9ixQpOkTGJB NVnPQYLxi/OLM+tDU00Wpk7m9YJDTQbolspk/Xqb6927LMomuzxv7i4eXFh2UbxKUJdbm5SBulf/ G9zvXkBjQQZTW2g5D0+LNqk6f8/pquBX1i3FvgGWjKZ97DW5bKEwPY7ji+w/F193fbSsmPeXg6pi xMw8HK/J/zZ5j/5C2t48I5xzqWoxUSKckutHBH/eFRvKn1gy7WB/trVgRpolM1pUD05dvGm5OkNx bhf8S9gBa2EA367cEbLiNK3G+anY/GQ0NU7nwfesmU0E/ft/7MT9bvlukkEwdG9LH74tWtQsjn0G HvOznw4ACQZ0kq1tgT6b5v4mvX7eCvNl+DweHNv/iLbxBzH/c+Pot9dqZaet0WXmD3YYP3lTLv7d at/JSNBTGSyv+lvP/G+7YZLA3gNIzI+A925QHU0blOjVfCuH3XqaBBslDVNOXhDnO2zNZXIDRQxA 7TqgY3dLvu6MQu+1Rvl1dkdonRQ5vsxDxjpJHGsCtVzsuD7Sbx+lyJnzvwBu8Mzbyd3lqYaBV1Y6 ftklyhc7pALik8nwHo01/uez1mXbZShxR9NbnvukLS3hPsxs8K8lFvLedG9tyz5MtpaF4Dl2sUfP XPooiZCiZtcwADz9xIPhnJYLStDbJk/wwgiCYjA88Wd854GilgMZhyTjNZuy+FtcUUWJUGb5+ZRY 2a2FMQlCLIrXsRJ5JDuCh0u2/xRAjd54XjqecG/Q22S8nqKwzxhco4tLbvAxf5PytLaOs7vHMoWm lWU1htjsWxBaRXlyRlaqIBgW426peRmjI7ssudDuCBwTfuVxDpJ3dzR0rJpWaEda9M6TgWwt+JWI xBTN2Y3t6B7qXtKFp1sXZ3UTxMo8Tf9Qr5k6NPJ9gkB9803dG9MCzUdamumxQpUxm0U34PIOnVUr VGiJdWnuYVZBeCihTnC6vKI7lQUi3Ho9Gcdc+kPezk4Zv/SrA1oeXm5w2F2MpktK+oj3amywoKmD MjWb6oUNMOZG1IamDSx9stfeBWxEHkwvknG7rtFa1RPjjn6v/mVeRmK01tYoSMy0+9BhHJwymdfZ Ei9a+RBf1Xnc+yEpvuSEwfL17D8fCwVugyIoUCcGoipfd7IbFjN+DHJL6mRHR23zhVD1EhYn8Le6 UNlDjk3onNwUVOliY+sK6rBtRsqOKavjWtOZz8HQkwu0rhHoaDM8B+SInf785+F+tEiXTssjTvSj urK9MtOYt0FztVocOf1vralLBwbqtLQ+9BAJUFvTuLnIAx88G//27smJy62+vZKUKIXIubtrj5KC Ak4TIS/37zoJFZX7PA0qPNVaNOGMUw2cbwDs/g2Tt35nASoX55b+fsEHz5crOWF+h5XLGuSxyVZl R+80Qbgwt++Hu7FqiF3mO/bxbLs9GLHf/1q+/Pp5OK29w/Cuj8qZjIGW52u3cxWtCUkt4QusT/ZK FQIFD6ckY4YsSne4ksLtPlpLRMXrLY0WveTq++KPiE5iGHMvNFKs2PW5frtyLLD/mOZ1YLd6n2TY r7VSZ4EWRokX42t1jeNq4+rdT2llVJSw8zGALxd6450EgOeN3GgTtxzz04iNh3yTNRB+XqOmPQzg 66mMoXLe2TSSH3Lh6NjXQAxtUGnIT4M2gSD5tjhcU0qEoiLqKiIntO+6sHnih1krXwrkR93zpo2b e6T6lHbOF6p03sFwcnDZ87qHI8L32afZsSbK69HJatT+GlPw7ms/B3khQZY6FdYHkj3g0k8lvcXx A3AbY6QHbYfOzPqVmy22l/PXra1pe9Cvr54/cndGgvYKs7SQMqYHFHA2ARrDWLsqMCfzekAN6XCH zKUxfBIG7mqOGSx2GLXBy9GvQulMPIdIoeUNTPyhR+KW65bfe/mjb/aVhu+xmNLiW4q39HOIqw6D lWLOKMdGbN+ihLjABN/9SyosL0blhf6bUxPGlQ5rgoCEHSoObdrIQ+PifDiq4Ckkd+FHW5HxNpzY VOZLcb/ZydEYHeXC4qWhb/DvTWYzrkYlbm+eFOZSAsG2kxj200fdnr69Cw2L1FYPGwPDn/Lk10ez KlkDc56X4Nl1nIido/jrjU+2wG3H9LMNhka8Q3FV7ZktxVZr35t9I7wNPaRId3BeWJeqKrzEwgC6 PmIA7DWo3jZxdGh7AwYwf1gfc964Drp+x3CznoEGu9NgAD9hyBoM4Fe7MwZgZmB5W+d+eGmVszF9 x6RnQzGAMSQYhBJFHv7LqMNL4YBzDOBSp1p8P8Lujkv/fduO++qmBXpIeoQBXFNejGIAlh23aHBm DAYg/RADyEwAzYzc3YTluAzFALDP+27j7HMuemahK/mgFJ3bNWMqDEByeR4D2EfCoTOTcRjAdmfO abzj9fws9A8CNYsBrBj/wADq2RrQcy3IGx6Vk10MoM226+4+X5j4bTYKeb3gIn5L/ArtooQBGAgh byigPhjADcss1YUUGAR7bRSzQXjTkhgoxrtSLfganlUrgzKFyor9tyLGYwAzI20Btzk+J4z+y//+ NN9fGAAzdOPqy4Ap1yUGEGWgtnvMe+bNrFufERSwVRc/paopo/HQW4Te1cPMab4cK/4NfVFlSXZy PpdpMn9UmsK4r2e/Uz95WK1UmSx1FQ2OJfOIVmjpJwniN9ERELwO6HKMa0NbbQvS50xCRIWM+E99 yPvqIrloK/uCZAbANG3YhOxCZGTlvQcI8W6OsMZvvBw9h9FTQwKPc4qEZl5iXRJfDORYsgwa/khT BtZTmeHjXSFLO4ABoseZ6o7ezVV9ZxD/TgwgZK3g1f5h6T+bxDuiLUiPqblUnJA9OFmOo91SVZi+ x8CB0Wx6L2L/MafN7s7xWVTskPmu1fGUghZQhwA/jdbIVfY7+9A9i9XN5YnXP1qzqCHGrPuEUkqP dGMfyT1gCCuRbqXvaT9l37Gtd9kcdv/hqLF7hEDkx3uvT1Qi8hmTCv0ZKxFFSoR60fdENYF+GIAI MCQLGBjuUN2/1YoBeGilSYlh2a26tvI/jeaZ9upOQfW38Gc/DtHnaL3jjvEJlwHizGbpsT0CxXov TUkOxQ5cqpee8L1sR/TfMJIQqMaELUkxPy1O8gun4MWq3LsYRf0IOCLfaBbx27K0H0CRu03zdtcu DdMXxcaUQBrTunbcpVL6smHy8pQcxBUMmllw6Cj/JpYNBvCq270CER26MG3fXGqilBOt2HtS3ml5 /+9ZQL59LuwffCh+fs1Vr10/0rwU7FjVydLme/GE2n9vCW2x6CcLxgCejyzuUgRpJNlht2pHFgRJ v5hKiNTIF5sDeWzVLiaceS4uQzKH299AXBwK/54FNF1ohbAfwAq0zPP17WtTwdXm0iVRTHrbgaKq FZZxmj1Y7l+G1QQcRBZo8Mk4OeKgNZwtWJQoKMSEYg5cSPTLy8uk7jJ0RupHVeSc1GxJ7/GzNm4v 1oQX4Uv9vF3qlfu66dg48V4AwBngeUNBcrNCUjO3DXiuWSbFzmM4/cUvAbZPf48Caowpov6vRwFl /XMUELAx64kPLOiKHvQO76yikRP+wpcPhMQA3Dtgv7Xds3d/W4qck8HMTG2JtBd4X1i4cADF1ufd eGdyQynrNbJaP2p2Kf44pdNW9FUZyWmr0kiGPMYAKCCRqZlgs0iqL7u8rF8ugkuPZgO3K5xaUd3o PfhU1fUhPFolBi1J1r5Av2IXO27PQSv/rIhTGt/+YEncqIQZAzB6Ry0XNSbL9xTJcz7o8Jf55lI1 ozlufK5wFdjE3dzQPfDzl6bbdZxb9ZfyXp7+z1moEu2m2bnx2+ugpq1Hqee/+2naeNzHZJhHuQSs NpMMc9w2bhN81Vur53GGC3EVC3QBuwCBgtIqJ+IH6s+fVqYhkG0du75aXAqIO3MzMKTWSewiGLI3 lon5ZU3XmGBUOWKK/WDwWX1iVGJIFHaSBVoNNFiVWnc5G9LMzwfPqi64rT/sxKrduZiMGwE5MaAW oecNZaX+1+jzPwDRpR8lN8f20DsABB6Niw9WoI9r8DCAvMM7LL3wPYTvWf/GAM4+qVz189/a7YGO PG7vIuxRjSFonugOIu2MfNGkDFfuoGXelbvbRBE56FF/1K29IBU68ikGIEiPAVRl+aKfw9tBaMK9 GBQ1TBwRUcB2jFzV6asJPzpoCQjaSzduD/IdDM5wk1L4we/gzFWP2Bigp5Y2Gs8ZwZYpVByWbaPk eJMwWyFvLTbv7Wi2Me7Uyvv9qzlLdSTCiLeke1jeRoTp9GT3LVIBLu4uuptglrJ4YOc/o/RDnm1Q wv5ppMpKmsxl47tdHJOYtekSFXteXkXLhpF8h3/LWLbvJ6ym9OwUxlt3CLpp1g8cstb3T7XirsfL Ebf204AfNrTW0cbL0aLAYDTNtAgP+h5KaAU94NkDRfUe/D06Q6YWdP3zcAF2GWN8NHmJtb/tF85Y thr+hDqa+G0UdQhxnGk4Y4FqXA+BFSFNNI8q4XvAvc8H7cDKv92hHAZXOYWDCON+WjonklTSm4RU kCR3m1sznRAPFQuBX5dU5v5WnZZhYzMnNBKJIq+TrYynIfwkQQP/4bS36OTl9gRUn3Vsiz5uzbtb fLV9KnSt738jJRLFBCeCHpK1/D2sg/InBrCHBbV1XBX17VL5Q9VQ85/HXtyNnW37Xxibh2fqrqPr /s2bsQVWDeYASqX56HEd72eVfF3oT4wPs9Tn/139PDDY1jjOxgyfhJe4O6p4IepMTkTJp1YLGPx+ BwNwtbdvaHdyR1l6Ifbp92DeUmFcXrh94XnDKy5MKmqEhk+NIvolNKS0Y6ffxzPGEbN+rxQEoMZo zcjPV+8R0FA8gO6X+On/fW+zDbol8L2jF5WUiCro93MgrviXgJH2v/qp+R/oZw/+n8fe/h17+L8/ dlt13si3tgVGyPes+kJ5Ys5LPn3HxZ04KgPiTGZJIibvZb1T/FtJIrggvygZrO8jW2Ctp1AvXa6U eC9fbtV2+suzL4xCEltivH7ui/N+yX8Ws3AnDYJEUysy3iYPb7YMmm9wzcvvhnCIWkjSGAVn19eX W/Jb03pYiGsc+mRcxugzfpvKrZmfBP4PlGP7f1qxJVHQY+jayOSwKYRyZjs7C+Ybiq/KfKy3iKdv NyRtSqJJGKu5dqJJbOMzIPQl+r3Xku59byRC0Ul3surbe5sXOvvbVkjjqn8+Vnx14fnRDeKm7p9i d278c18gOXOii29/YS6yx58cZ2iB80qoRY9LFyZM9Pip6afeP0GHn9O8XgpVMEO6c88UuagGGK78 1m3pqgK+RSdtgmgm11DPGhmtfrb/Do/P8S588RYD0CDWovqKGCVVWd2BloReChG1oK68bhj2SPLL FnLIWsYr3hKFQ1xXLeDucZTiLsxZx1o/ikKMxdUJHY+RGqyhEZTg2u62F25OnHOLHpQhKa/DcvN7 1hg/y9uwegglYzOTCnn1FAQmx6cLlO2sSHRqqhYciU6WeH1y5/+3+vrP86JMk7c9HzlvK2bI8Gp3 4rN2PpF12X5umBz/SfPaLLfyt9qoXozYB12el9I/298HjbaHmP+xntbT6qDDytdLQavBBw85Ddjc 2h+pSLIO6a10O44M9ozft0fbhMR4SckpFxzV5ZeisxePC9HsGdde0KA8vM8gNmiQv6MGrsXi5dLs tFbsy3HNg12/7DuGvLg8EtZRbxBO4A7FISC88R1PluyJMXjxd4ouRz9E2GG96iseB1Svv3ap5oWH vgrumzA5TnQmYjctys0LwdZ3Y+2ef/Esx36mzccN8E7AbecOHUubpnj0hJiHHKTj06FUsUWleTV5 lSFC6fILzD+yscvly72TVkqLSwOlZaQfGck9fOF/p/aH/1NICoABKTrE94c2Hm/O31JMCes4r2br cabdNs+gxJ+l98nxvJwYpnuuQRZaXFXobV3iNde7q0eReCT7v9kYwZ2Nmd7Z2BhHziX8eMt900U4 xs1NRflAqSullNfb7sC3is8ByJlQYa5pkxkiD8VV09NT/f3lddz89wc5HlNdQZTlak/LJIANpQR/ u3aZVjC5EGMAMRRUkkBJjUfmhPYMmvv6PuXyLdbaNjblNt+d5FgJXyh+HZ8K0QYEOR8u/HXD/wIF nkjjmjHfDp+E8lbR43oPFX07yp8JOE1y3/0RjXzoHTt9HWLSJufhzL5ZUroKnjqSjz5+IbzT/tSw h9EPz/PL4S+DJrBuEw8jgMiopbuImx/zCQM4D1o+hxxTVqyUHOHNj/WDwb2w+R8iAfMLZKBnTeBN esG3PX/4DthDnwX3SbFOTA0SPucge8RLSOuiqXjyLoqAu5VzPeGgMCHedfoLQBXH7epwybHmPx5S 8D8s45J4vnuFNZbxmh8I9oR4nt/xx9Q6RRdfkLuH9hBsvs2psqDkt1r6jTKQVw4oy7zNvJotTmu7 HqLp3lJLC17znkfQebFDDKxK9LWMNbUJAeGBneGBT2risPI2BxGWzYuDEANH8lbEyC2oUamiKxvm 2JpNwsNNY5XMmEamUEFjbSqtrfHhyXbLBdYp5yXFjLeuU2vBOtxIxUgtJoI21GIwbT/9YUlyfnma Seng+QiN+6q1y315fjY51h3NuMS4AvzBV4IUh2In/t8CWaLQ9zds5xTzk2giP3cK/FGylpTHn6oZ uAs7h219AnpyP+yWRw4G7epTR6efVJLXaplos1zZF5kVhMuXmrKSSCbLYL9H2V7d5WyfFqRbIsp9 DutRlgwS2aV92EPfe86XJwZWrHv8TJ0+uxIqNXuS54O9rBeykyHPJJlKsrJNH9Z5kb9u9h0fBC9M OtT/aI4VJOSJwg5HslAoZaoSaEhqfGB0AcVBW06XjY4MDF2hvPsoikzwwDXNMUe1aVoj1X2rlJ0/ pPecTqQ8uS6/E3FSi4c3fV2kGm3dOLjQX6Cs/nkOlV+7C1+v1jn1FLUfoPZa1zofACmeLw/pOIYO 2YsEPWH+7JPeYkeH06CpwfLxTdj61wLE5LKxRetMhtsLffqWwNfd/oL5CXSqx4TUvLSRqi+Fhqol 0fugz1dusMXT7I3WU9zZiXI58oRburKM2rZjutTwDa5KmnCF5qSXH8gHduuxQ/c7dhEHm4M92Yjo Ybh/TGpgIKsWn6SPQ+bMellRj4SGlsFjrmTDJnsDjbU/FdXpmsFspP3ctaRZYZEQXLjbktkrB4Nv k78f3fO0yC3jIaQPLEz3SZjxOAmFZIYhbiMQmTH9KIfJTxNpJGxseRDt2PIC2V+0qiNa+ArZq+X5 jaoA0/3WvJh/MWDW60PQQXU53Fey3kNM4VLscA4Wg9sCXpadVNeho7R9EFvSv2ZDl/dbY3ptzyS8 PokkL5vpc+wzofp40Yra9maYI5vj/vqk+7OKslwe8zeRpEFxnYFCeKdAlv22vUEDJOMpRc6UnXBS IXgWf9eMg+D3+O+88aSxRJMHNCwchJ9cZ/aAzzCADGAvPL6V7BWe2WFU2gTFuERU6iFFVluDGiKr ykBMYI1plxtG434g+OfXrInrK7OkneME7cxhpug8UqHvTB3XfrUbKi4eFOiJt/6ehMW7rzv47Zll i/T5HSaqDJnsTSIZP+yJi4h7if8Ybc0eO6U7yywYzAjlRPmydu04VFHzv2as94qsXTZ4T2qW/JYE zyk2Qo7348/VZMfi6FnR30ufqf7XWw383/XCf+0dLfVsa+uziRB0xbE/CpYZ3mFDM+VbY/Mxda6s uMwQ8lmNsqNTcUdLS+ZFfsnIQbg1s65gHFOydBRdLKsy6RbLNvhAC15djCUzKWQaZUZJekxDmqkz kpTL8NgLVXNSdZfW3K7458xdzIY5iAfADBPefuogjLh16yTUEVog8ybifF/8IW+eIAWYg3UsknKz zwI9rQZdXx0+vdETh0ehVIAaQDlrDICx7s6HY07dD1f1qK7mtDGALc07/D+Ft8n9c5fxtYLKlVTM 7Tooowb08i4HG/kFwQCESjCAmuzbVTn0jeOCD3JCHzTACjqkuVnyvUyWQXsQQq+mxW/9kIcvVZBr AZOzHfGTaDVTDMCbanMP3l0vflp7J/1I2R3p24J6xYOgZBfZ7WfJOScRVKi7J/Abo+niMICsYEe0 uwoGABRFdSfcXsIbzw8LGzGARF0MYFnmqgV5zBozebgHOi3/O6ll2pzD3tuSGn+6mpsCGfSJ+PDM U2ZmulW9zViQHJ3nXSKZiiqzENE9W+156YfPiAJQfEYaZ/7nIgFaNQWRMBz8fp76d7qrYaRyFDHj ai+ILMTH8HwBdfek/jbPns6WwQ4Ko//iX3j+SfTBTY2YzU0omiR24VYwY8FXgRpmkufZZ16DxHMA P3C3SQ9yW33sb+2Cgj5QiZHU4V5hclGvEoystJt8Xx8FBjoK1vgeLeNWrYLtsbpTzmYVjtynpd2L lb/0JvZKOf89I7HDcmlroaayadkbvYDy/27IMY7AANYaLmfmfK39KNT0h0Y+yrKvQ9RXvn6iiS3a vQFhAN/QbtWTaKr0q2fzqIwml998Ix/8CxqsNUz2f7MwSU4dREHjB5XYgW4HlUTyLolj2urgxSp9 M+/7PTxlFxPowX3wpG2+0QFaIc1X+Rsl6X2uXRXXlmxADG6ZxnvZyWGQG6j99SLb6e4FBmBzxTdq VieuGuHu0XuCiCsFT/a9wDcwUCKujCEIRL96q1lRaL9mG3aCAaxuXl2GLhu0lvJnUcpOmO7tsXhI b1T1FQtl+O1bV+z+gcGgZISiAfpR1ieNU32DOO7uuFKa9RNDv/Kfxr3psNqAdeguHXgMFtkDEsji JGjdhQxV42K57gkpaa6/EJrcF2+7gRxCwKjXYi633WIidczGBgUptsKd4ZMLv/Wo7dW4PVo/BuoO KBFzykb2fHtZ+EL2zeILOwmqD0/W8fdFp36/p/5mWhZEFwe4B9QHEAG0VD6J51IqY7X+V+O8i0A1 VMX/fSdA/l/tBHee/Z+coOQmv++vE8xCw8xAW58N7v5IAwOYHQ04psUAAvgRor47bOIbROLIOLRD +40CDQYgjA2/2c1Bd/giwxhQx1DrPfj/3cHh/78u//91+f/VdfGAr8fNxu/nfBXmd1JJS2ETt3eM Qs2/lOBl6ZwDUso/b4kgYKYEl64n7Vyfs4gsMJ3dwiN6/Yz1uEYXfF9Z94MTeIrSN/XoVo62uops bL/vGToXcWqcVtyutk1l9iAzNnGrRdskKHvA87r3ialI65quEmSljrZne9kIfS71z3F9XsJu+40+ QfXrQKLLV4tOSIjmOd/4sl6bFN/vvYGo4Zz8TguWus/cKBgnq5NkPOrpztD5uz8eCNZx1vQ2Z60l +3XbCohaURi5iqxD5p4W1pfdpQBOt5zPEjcNFzm69lVd7HhNvpKFLk2HLcikABdwAW6zsCuVXmIC g5HGq2nz1TLY5f61jHKcbvfZeMSzV4iUz6vxXg/QzxOlS34CKFfFu2Y64NwBj2/CLrWm56pH4FQM uUsvLJABwpYm4IulRWE0TpORvQM/W1JyFRkDmwiVtaTcd1em5jcteKNNTNS/rV4Vxn88ZjRlUBJ/ isa5yb9qqoNYfkKwX1bNwUB2Dt8W1EZbkM9ROZczapyJzYZf+sSY9b8dr1mfEPxSkjlXBFxTBcR/ jPyiI2rDWJj4kjKoKgiaovPTuPMSRGVh7mvQ9KrJ0/jC77k4no5M/BKh1+Lz5W42eyUtLokfhQY6 5i5a3ydaZLrdxr8s1l6k6z2YCAwqiu02rS4uE9XYOrW+qmhDwVrK0Nw3/gMOgmCIqpYDcztMr4Hl 5IXmAQL5pdeM2VMkip7dawjlWv0u9bqJ6yXNKWm/8XHPq9CVSOY9B4bC2ZfJ9k+cxKdvWkjFY2Ws txpaE9aj+xZhEfzZ5TlPZzNqXnLrhd8UaGisViClaTguBo3UBL/J0TvE6Cnx1y9fEFX9Cmei0B8P Y396tmdWvjBg505o/AGsFRgdkpxfX+3JJ2tdZuK9lTS6Yhr2VPzP3y6K+ro3nssUEacsV0mI8hYK WOsxytIfOWPbsPeu4scpp6opmGhhcJ1//1K6KLrJeu07YohrjDl4slqKaHN59h1+t3OsEOuHCUVG pac1BpW+kuM5Wis3U75h16Yrr53MrcptmbhhM9FBleANKVzFRPd3Zp5FKvMz01I6z2inTlQRcywl 2pKlbe/vczjts5RLne2kwRSVdp2n9UBvRSEdSGPEofLqIirDabNWlw36bc+PR7DywoABJy3y4APF YFo6ts1Ac9laCpVkYIH6hvtORX3sMyNYIECLgtO6NNnEuasqnjutTXr+lwU//Z/fE6vvhEGvY4c3 T6YnKgl0h6SZ4232kz/Ue5x1KUjJPOinoSQkyLF+X5a7NjHx/mE2hfWz04TNUBu/xoMl5DwZDUd7 rZForZTY8nwjcWSxDolE2MJoPPFiwJ/hqldqtCRZiERxt/531iYndAKW8k7Ls32k+V8CaMYN6xsj dV8VuteGnsjtRxZjAJfmbM9d2eKHNjw4bA+Nmugs9MElb3XPkqZ+sMEUfNKbLbJWtRfjqQNnSJ+Q 41lvEYAGi5IrFb1F8LRvEdGJ/yQ7oP/aBVwz6OZa+KsHfzcOh+7YFih0s7Wgzpn4eojjCN6MFq+7 +GjffIoBHEjb+UvxsZogrWD16MWz6YTdiWzZR+qoMP+1RXRM0lqtXOOgu1BgY3XpZHvDh0dUXSIS YlqkLduzSHMX/E2VAH5K52aYnxE0BZxmRHfMc8mfErqzcvtud8IrGWrY3k8rp6RUDHx4XlzSpru3 /eB/8aDJvxd4RPGOWjew+m3KZa9diz2Ld3q0ZnVMnx8kkNCTmaiZOc91D02PmSFH7NYuirmaOSf6 qCVFzVwGLIPx9TbDDKUaXHLeHe4H2S4UxVPLzkin/nyg9lg6/4H8p/T0L1wyqqPNOV4qFu25IR5b GIATH4plKoz2Wu1N8vFavOTLNg+nveY4nK9f3cKSPsgOfejdcNTIB62IVFFIsausQ7wnFR6SkK5X zC+xSWhQr9fJEAWRaFB9clQ0f/ijfGpYflhN5XapXLroC7NyvUp59qf527gC1oyLgyc4NrEP4hSp 8Dvzpru9LB88LoGkozcwAJ/8Rm49lASiobLqJWHLUpZMKMN3Pyk+vniBOJw3DxP2Cqhl6PJZKOha KcMvnx2TrYGpsGL2RmLmJjadBHEsXHICHG6IuL09yFtTXitFhlD0Ux4sEiSlsbJ5l3f36MaaDD8W S67L1te3eta0EZWT4G1rGk5bt/D2WC3IKzpvfQpwMNOZxAsY5ym1SVIzbl460Fn2hQPda5As1TZI Khejjk2mt7YseoWNdUQnPN9gGbokNEk8A+Ovm49L4t+U8UwEU5CLmwTkKv9VXvkh2gyK9Y6Kz4ev glCZxdrXs6oOleJ8tikdX/wwsMZJW1VdwaCBq7GZNZob29l3VZGNjqky3Yq2d4qW977Gfc1JzUDB w8RPm8N5+YRkiffS7z+5/E744ekzOZ6v6hIa0lUPWMwtl8gOqVr8l9p/h1xokJ3QH7K1kVXaVcp3 Rv9kX7Naiwe+HFJizX5ZUfXr9feS72ODz78Lp9hvgT1WRuxFJ7//RtwOguunL1nRzzhk1GIGVk6J W8qs6gUWox4ZOk2rzYxrfRgfJPheHV347qHBMsWiwbC1yMwsJ5ehdI+e7gutr3kPyQPx4vZ2PK2W Lobv8iwYZDgZzVKVf/Iw/Wm+u9dGuBQeeVxL/N14rvr4J28CZRSz57f7/g9Y/f/3L9By8pxK3Q9o LoqmvbkudIrou95aSiT6VBAmqi6D33vC/ys34Qr7/Ax4mTYV56bTGx2z6xyERqzzeRog0pX6g9F0 N8B9SPWHQJERFAbgwhQ7oKFJmrUVV5Nxk+7NONlfnD3GasOdksI33mgnrAxbsfLKfT9opOnCQm8j UZEsIAQKJdhbR8IpvUEu7X+QVFl3vMjfvAp96DRz6hVA1PrRlTBnJzEqRanQqWaXesBtRn/AMAF3 f6+0oopMuLq4ZBNyyrmYuojdryU1f3sbPpeakjWYj8BtBkbPVyT6PxrSdEZEdUxXV7jE7V7n2M6e rRKeUBBCdkesN32W+dLTsYV8fOR1TUuKikKYbWy81EzDn7yRCic2iXqvGc04xfyFFQD52zGv4vXp DeK7q1HTRDuvRKy3jond4sjZ6PhH+PrRBqRXOjvoNYV80LA7H40diSb+dkgt/vVok0cXztKbVpv6 mtzdHfEkpKq2G/QXezxs3sajeOTAkA5ourkSz4Ezrnl4fYWkFMrO53pQpUQEr8wvieUvFfkYIFrH YhMXI//JiJPxdG1M4WYWbR8TnkVFPzZ3ZVZ8sLxYXPELwVecnTmLwAVLSvzgn0o8YY2OwdEvrdt/ jwGwp8oXBfNEHIz1VZUH4E870B3NfEFSVrheAf3ehYeuvf4tnkjx9cPjnf3oHIRRypRb2v+LvW+B h2p7/17ul0Skq4qKpGLcQ5gkoZJyCQkxxt2MxgxKmu5KByVRKpIk3VTuxNSJii5yS27NcQmR+2WY MbPfPYNSnfP7n97fOedz3ve/13z2nr2e9Tzr+T7fZ+81a82sJBnU5RGQebDszXbcTKp5m5/rpYB3 Wz0+Xa+8Y1G5ufTVef3GuG3DBo8XDb0SD9A95np022n8wMqykrCx5Jhioc1GuXT7/S27FF3XVLxt G4kIWJ38uXehS0Pki3kQkA7IkU4ZG95iSafE2i8gq7ypSf2UcNyB8WhvdX9LOsleYySAPwBrV7Oa srpjZL/pRiG+2x6f/FWrnntHK8dmRjPMJDrPGsduWeGroj2YYmU5fkQnPtYv0MmPNjNkUQUEksLP htW9X3Vik+T9tkDWhluba1uinjg+TJiRJRdq9uZC1/yzpQleSmJeaamfFK9VXywQsLcLNq5gZcKL iuM8I8W71R24yoesPTKsK3scyxusvFE9JRrcxZlZv1QUzSwSXp0uM3eu+yJCSt3UXwM0L0saG79E jzl3p1DUZ1HZyRuYrEH7c+lqWztKi3a2ijY8fnY8V5kckNW46Paoopr48EhD20PpWHN7pQuHB7U7 TpDXkS9VWDxOEKG/lHXMVpirptK4T9en2dQlOcbDO6t993M5RYM4nbh3YTrj17ceylxnUTRjTXpK tkwkcxbLQY2Eoi9MyL5Ke1gobtj/dEwPXzreqDujQarMj4TyCdA5Nd+62ZNcYNuwrbE2jfea9vKQ pBONhMxdnkOt7rd04jQ2aMrWaKU8jc8o98jSGA0X6vCGwDE6Lmx/fNrY7IePknru59Pce45yOZOz G+r3UyTkrOn1LzNOYljZeQ2/pI6RvA3rWtrfPdWvJKZzho7Jv0i76yoEfg3NF1t9tkfpSKfhlo1+ DPu7qo3hW6xF5jgVy5b0vq6MqtcYGj63MCUp6oiwY84NL6zJ8rOyUYTeZY+852oxqCHLe4KVaq8H 7XhcUaNxJ2J7jXryMsliLzPT4nWBzGrd2xjPF/rtg2/jzdMKPiy7j5U7oLL4fEag4Av1E6K7WAZL lUqtMcK3rE93PWiKZWmbQkB27bhlg5Rhx/7O9lPSjH6yR9eHBeSW6IQBQ3KxHj307XCvBJrWzCqv eaQKgecK6NYTEAgLHhZL7PogS+4tZialBWEhEGFBLpkJAUlap7RhzSMTCFBPM4wd+15CYNF1CERJ sRR6q/RD04LgZStl3khEwTTn1JshYo798DLzIKp7sevmzblaETGJJXSPE5soDKz+iHgZHzr9VkYf qlhVLCMi5pIa+581pVets0+jM/b3+r6M1lgulT1y7/1r90ENCLgb7zhzh6GLUw27cS+le6WCXLyD 4AG/op531rJrMusDpT5FfSh95unuVb5jwYW3Vm+B6VXehPVCHXqvdD+VjCdn7e7dXf563cHG9Kcp RfFtzStdzHA381rPVttYPrxWFb6t9Nr1w+UZXdSP4YPPHz4cdL5PWZC/mk9Pj/eigve6GRIF7icZ Hrc8FRy1/KVYvvnht9NUdybuMsFGpbbYydqWGi2XiXlZ30OgRBfPfaoza7WdwLGMm9KSxw20f5vp abmZp0rqtdMBp3z0SlvjHNySvs80FfVrylmqrL7YHTv3bN25Yd+clccW2G10Dkv1e3P4TtJNdJNe QX2CemZBbUO+wL291ReEDxx65lMqku2Mu4wjXH27OWAEF3dXM6L29OercYmrVnWo5goabRW+P9Z8 7s3R12m1eu98Ufm4+4+Pc13f86IpfN2uvHkLUnc67wg7uuPkozHmJ1aj75FgMo5JaVzrndNzUXdL dtizOhMb2/4m7FobATtBTIS3x/xnrSVNeUG+JKo0Obr9V/NIp2CbiM66g9VlO++aoWmnHy1/GiBn vUQ/ZdTqxFHpowlCEbVEs5k7US8Xe7k8MzvYHFTY1d3ad+fBQ8be0uAVNyJx82YvDLf8FH3I81Dy BpGwE0K3Zb0SU3b30rb0PqGF0Sw//ZbXblyr+aI0+3D6RR/rKwcM7rbZXc/ffydu13L/ofan4ePS cw4Yuly4sxPFc/rZb31BdSKa82YaGIc9beq3Io5+dlw9LyIlIlI6/FlLR8uJqBNHTkRJwp9hRpxP sKtimKCWiPkVK8+s2QysAQCSgOsQeMwDSGFra2ryr3R/+Jjr8HJvTsPmgZdr7lWYykapuEcZu9g1 vo8JdLG7EGUqn8rqrXD8Yf5wM3DsInnlQnKUXV7P4Ggjs6HuyhO7JZuyD/q8SjZ0zqK67TQytrbn x4jZzVEf0lJ68tKmKKOaP6X7wUVtLyMHMyPZT9Z6PnplrFolCKzGMeaFLukwUF2qY2G5wWumoJ3Q k7tzSqpeXVfBXWCWHWRZMIyz7YN9e9qrqYRFbuoP88MP2IcXbFk1P9niSduDU0JnddESzY0YZUPJ /gyV+s7IWgeF+sa1F4/iAyh2+MK819bbjc8nPetVvBtXn0m6kOrl1dFUUmFw/lpyVJK0hoNI/50X wupn8qgW9+c35fhK3aheeZRQ33bEYhVPksKy61ZWwmFHVg/oBVCj9Z62biPXtzbuW35Zs7EeZ7rV Vy75ldotkzm7n72efd9GuKN424aHcTsOL005gR/9KD9+htpvjh3SD00k/wuGoeCnqHHCOZYJfjSF sp2+pKDZmDXuVKdDO+E0BfVg4pBecFEkc5SSQeoVofSXmo8tpTTHM+GBlIYEgATwlwTQ8fwA+v2F bc/HbPrLXHANlh8D7n3uuZf5BOeDMbPfmCsiuiXQxfNhFcrOQE+OtOzdDpP+i0tjFM5Zl1ffMaCt tismv7o058qr/Xdb80/ZulpvCQsLE98RdkQssXMFrf1i9hKLEfPGCOz7tI1SjZFKPbPtSzYSzhl7 r97YtEhVM5YrIw9+PKPDIgrDWIOn06KXHEJHNybZVFAW5adl9D/WxGCH37S/3DPr3oMVrSwpDaX6 X66K7Da9kppicVXCIDtfpqpUP8RiU8UvH/aQbjsNbP2Ud5c5qMIQ8LN4dxe1/XNIyaOmmIdC5V40 /SaPrIMacvt2GL7IyD+SdVMC35oiUJdbd8qgbb+hT2ZUygtSTmiGw/zh6+hS816x12Jt9vnK6pLV VdHrqI/8HNYeuccwZX0I9e2+E49OW/6aX0X1pGPobCXTXj/d8O79FlqhL4i2w1EEPTOdhpT72W3P O0RTGqR6SVb68hhSfJVXaaKZUOpt1uLQ6xFxRxf8cn3DXbtz94hhcTFzHsTsE8ehyB7r1zwWlU+S 2KAgf2ixZ296gBgJAmtRl7THsz7eLPEZF90gfCcLnoOrtaqE2L0LMvLSKzhStL3G2sLI3n6Hjbqy rMKyhXF1qZ0NfIOq9+ScIxfPAzSJKD/0Y530pRAQotVtTpz3UbPfakayFalQfaW97codBaBCoKUe bUE+msI6Q17AvGIdONC8gBXLwhSYhsbH50ZFPgiMtMF6zVzU98R6if2cXM29Z3uEZTFL11hy3Ty0 nRBSgCIaf/500isdVb/tbuzYeIDrmeFsU2L8ylb5FziHxujPPo2Kkmolwi6a95QO8MvYqHtZx2TL 58oHxSZYS6lkxnyu/yWdeK37/k2t/o5jEEBR2myyWLOGevzvrTqoiysYTGi41CL3SE3qxlFC5W8W 1xT6g37Zhpo3cl4KI69yWopfpdY0pq6dAHLzoza67iFhbjhf2JhMlPCuHj4gwdpjOd5UGiCp9SGi YbH74a5SkUXna8c/dN14vcJQMcdrdax0aNK103gXadukYquyNYWbxI8brWYcYpjLHly87pb55uZL xdX163Xe0cau9KyhvYBA2+zCEdarxJI2m3k5mrGbuucX6215quk0YyRnzRU5tQ6VZLXeR8eDLFK2 eNUw07xcrj0TYuw30kap8HzuciNHOzAy0bHUIp+t7+MWenU/zdaM4bmdR/aorHzT1xaoqcYlunZh paHZ7Iyg3Ytn8tS8WxctJrlEptkzSeS8JOwbpR+77iRmScbVLnunY+iX7emUCzHt3bja7sWMnBFH /jXVZtvsH6weGWj3l2p5qJbpVDyQQSRW7xNR59s7lIn2t19133bXjXitilcfNCxMlgGu+LNGM7ba XXhLjk0iDSwfW9ak4520zilLJWFpNq7nBantRRmOHpJtef9mR9NrTdHwrtZrUfcWVzuoc9sm4i2e LuUN0St3X1OaFzTUUnd8555xAdOyVqEzLzDr2h8FNFrNybjvRj8nfVG8jLevWJ0RGOTS0eL9IuyG ybWGKPtBN33m3r7UseHbW9eJxdpbM0wrWJx5zLQ/evz/9/aWv2fPzFuEvf+Cvdqrmxb3Rf7GDXan GlweOZd8IDQlpI03lekKQe+h38CszZtMNwEubi4QA78A1CRsZBTk6QaAmRlYBU/fBYEAlwTgga+4 4BfgWgj4ONcAuHBJfbn24lo5qcMNn1TYZyAFHwQuVc61JHyEh3oC3kn96/DxFj5iJuucdwNXvAtW ZrsHnoj398D7yRhayth44lzxgf5AVVlZXUdZU0dVVUZFVUdDW0dZBbALz1WuCb8QBMBV7qn++Vqv 8kxd8xLAROHn4pnEyD89Dq4lX+PgWjE9DpiTyT64lLi/9C0kNtmfySR2zvt3XJqwpVA3EOHE5GRo BrihHiDKqQHXQxyLenAMiAgKCgoJiggJiYjPEJ4hPkdMRERszvzZs+fMnj1fXIRTJt9+v3DNnDFj pujMWaKisyRFRUUl2SdRyQkT8T/TAfQYiAuCfeAqD9cywC3OxSPOBTXCoQpDRVxoGCUfF6dMhswD B8fLxy8gKCQ8g+v7RpgznqnGWYCLl4uHm5ebT4BfkI9HRA1uFOfhXSqhwmeww3n2sr2HVfklzyY+ 2LBcdo7FExc1dcKRckMBuSjLvqZ+jL/G3GsPj67YeM7K1ejXJKLmvArrZuxA+rGnlaSWwU3y0deP Z5wvqmodSs4srv44vNMt4ETMjaxn79pG1hrbuAeGxqZkP69pp4kDbm4YLS8HkwA/nwYHwlIVCV4Y wd5ls/lUD5+VZCN4YlHepybr0kQ4EmVoOQfjr94vx88GILBC49cKGETSPFcja00itvkLhD9GIP8V AlQHRHg4PsUBGhSRUBStirIU33wp3S1XMhTNx1KrIFBRyQqmDAjHrDCzvWLr2lAxYo25kvlAda1P +5j3A+fOAJUsteTWmILE1zLp2zc1jZVGosIW8OZkC+AF7o2WFeUWbgvaJC4e4Veo/TzytHwPBI7O i4NA3BVzphya/U8FZWLHqzrJnxQgoEcd46vs7qSMWZ+npcMT7ZgPtyFw3s4pGD2wmZzX3M/YnTBm 1C86CoGifZET0CzZ0ITIr7elsKISBhshcMZB/6uVqe/XzmIb9wYxb0Eg2mlWb+S48YWfhmAaUjMv si7t9xEkDDvdfBARfOfGQlnGlXrGjJv11eSB26t73VmmYsvi03yV7hag5JLLU2sfqzFKvusI9T43 geI09hwCy2I/7y6jpo23QOCsw7zPbzJh39kQKIdAiRwDdZf80RcCQ+QfkFD/qIPCf1UHsjpOu2TF arNPsdJYpih2Pq0hsDKX9X0PR63Nk27WbHmhhL3Dm/Hiyuudoe90Tj/dNNfwl8cg2yF4VWZs/I3K PXWDQQ1UHsr2220nVp7sk5KlBRQueH3AUDddFLdsVgTaPKle9TKl1wl6++QF6yx+uHFs88i9SxCQ d4G91UDAoro5V7pCkZVPUXCsriS3fnYahe/Kzl2pA8FlL/SMx91Z3jGDCcz5mhamcns/VkWZyibL RpkqmMpGbbaAT9FfBCfPGPTeiJM3ldOKZm6hpxu9ynu08mGKwP1LisptV16P5FXUoJS8T+fd3Ft1 +ZR883D36SL4joquh8ASdGe1vpdKpICgeNVnhU5088iB2sIhQmu85fzHG1ujH/pBQDtbCir/Wfxk 9fGjVeRn5LZcvDZM/FGsbJTNEocfgU8XoCTSWJb48SAI3Hase7SZMmZG6W9h3bVqg4Bh51BCvzsO z7gPgapIqOLfBafy3wWn6t8Fp/rfBecdDOcgtSt/IM3rE2UgADVuRh5WdCSdHbo7Shk4/2l+Qjk8 Ap/GtwonKNigZYYg0B/9su5jzqGFZZhiujLrjiXstuWVAoxgM+zcAnYefT3KVO4bQXIzPKiUwqNU pPSwd73NKRsIKGSzdMnVty5TO0Icz7HWdL+GQIA0/SxUC3WLTZvIqSkpA60Npma8vJyJgsAi9uQK fnFkchzZrE0iA6dW5Oysu3+ZK/F+yplAdhtP90Tb5DSRe+qdY7eC0yYKvhT0ITDR40xOle1rCae+ 4Ns6zyCnLjRlxzVhJTxZ4dTkZ3FqwmBqcsPxyTPMuTYBKDc3uMUHPvNPWk1IEi/GfZGocs674POU RINzVvwq4fQ5yrn2g6eLv1t4OtjNf30bJ+bJ2CZr3JwaR8ipC3LqszioAff6iWOybcl3ugvZVzzG YCq2iWYCeyoO2Fx7AhwgAiwgwO94+OU90esPZZqMbfll8v57Cl/KrK9yHMnHB3BCAvwueBLO1d/c xQvztd0CQ2SvHDjAreBb0wePc5/qZivWjTi9voGI952oT8CwcPeYbOcExe/v44nB+u/02erP7v8b P3ycNvhCAj4EOBXTjdP6FnAn4El+34j48QRPd08cFkfyhWsiRpZsI3OODK7PdCYR8cZYHJbgTMS6 svWt9vlhJ5WFJ5TZEnaLqa+7DPj74+chEXysjGytwDfkfysx83fHfiPhd/YhWjm7fyMTxWBhO2wQ 0dTfxMpsqwse78NuEJwSf6Ms5IEn7Dfw8XSfYkpsIniTKTEsEnDFujmTfIhs9QAsgfg76junxN+q z3BxN8T74AnTyBWfMNhg/KWBDWMbHsd+FyLi/cxJRH/sdOKEfWAif5CKuOCJMKE/yGfAKfb4Xp3z TK2csIMPLnQf+CoX51xyTY5bkpwaO6F8nDpbHwitBhOEXYWPffDlbwA0/8ZZvM5HFqsAWawii1Vk sYosVpHFKrJYRRar/9sXqxPzqKWceYHlxMwKnicCA+AKL1Rc4EWLDNgOPOBrInz4c67g5Ro8tf/P GjLAcKK7if4n1kUCQHDCA9S0wMCDSPTTQaFw/krO7LmWEgbviwpy9kOpKCmjgC46yM8Z440lyrhg 4TWAnnxvPkVextNVT95Gw0zZzM8Q6+Fpsp+Atdy/zQqz3xuj7SqP1hfWDdIJ8vXzxRKdZYJ8fXD+ OkF68pzOdeBrthglL8NRIXrryduabZch4vE+3p5E9hpdUVVrjYwbwdkXG4gneMuoKGnKwx0SXN10 LDZumuwOrunJT+IODAxUClRTwhPcUSra2tooZVWUqqoirKHovw9HdA5SxPkvl5+087T9YvZNuJ62 nGhhR8IyHFcbsf4Ygqcf0ROPk2HXneFVDFFPnkTydNVxdXZTcVbTUlHEqKs5K6qouGopOquv1VJ0 U9Nai3VTw2ioq2vJC8tMusQGebr9vlN2y5RbGRlddlWHM7u3hBnH6quraqtra65V1dbQRX3f9kV/ u2cQ1sd2o6cvFucPY9VX0VDWmlT/vulbG7tpNipq39jYTbfRRX1Hx99AkZ/rHzAEN8AEqXEI+keA TH1X9AdwppqnZe2LTMfE05+IJ+zT10X9KPtn4BM93f6ASHbLNNDsqg68qMfCzwcHi4ou6gfZF0Vb C6w/3odEnLy/UFPK0+VflO3+QNnu95S/yqxxnkR91Und78T/DHnwiPf73E0NhRPUwTUdQwLWmYjd CB/67F+EFZU1FVVVraZ+EV6trKKjrKyL+k5zytgM7+rptu/PGE/T/GIMD52uzkTnP2U+Xfcb6HiC FTzc6v/xD93TwE/q/jM58CdaYP/gDp7Kgj/7qw8U+w4hETBYWH35Nyk0M/vP5r6+X/NoZgZDJ3gG YF03EfC+HOh+zgR/zhdYevJTLjjqMrocaDqeOH+iM479LZr+RHiarq4uymquis5uLtiJ8Fzc3DCK 2srYtS4qyqqqrq5rdVE/2E7r0RWPIcGjLRGWTnxAwgK4469DyKQLlz/jYlpn7BhRPwQ5PfT/0fFE 6pT/U+q+uJju+J+4U1wxX/LsRyL4cD79XTEorA+WDcMfzrXKZKJdMTpueIKvM1Hf09fZHYvy8sO6 66K+Sn8f74QMnnDAUw/Ul8kMJ3F/e0Gc/FRBnPxUQZz8VEGc/FRBnPxUQZz8VEGc/FRBnPxUQZz8 VEGc/FRBnPxUQZz8VEGc/FT5v3Ui/PXnECzOVU8+UB6tP22Tyvovm1S4/kPhnnz7pvB8W76qcvP8 2PonCmeTCi+Br5WHS3z6JpUCqIjrGgyTn5tn2h42AUF+Pl4hHmFuLjADFvOz/X9phJt4BLgFuYQA e5MKNxcPLxcPDxsSN78QCcbHK84nwb9UYPYyIKgiaaC6fI7Qjg1znWXV5lnsPTzf5aycYeKDvhXq BOEFT8o15JssNY/0R13baOVvtGmtMWal9U6bhQ9/rWgecD1KPHcMm5T+tLJFQcttkLRKW8fEdLOt 3S53D0+vgMCgffuPnwg9eSos+nxM7IWLcdeTb6TcTL2VkZmVnZObV1T87PmLktKq6nc172vrWj+2 tXd86hwaHqGNjtHF2ZDZm1r4eHl5+fn5fGHI4rxLJfhU+MGy2QY7BFSdJfcKbji8/Owci0SXuWpC D2SflBsS+uY1HVGXi7Kcj9nYf+3hCo0FVppGrvLC/kfPbSKy8VpjSTvXHjvOATyosDD6egZ7d8v5 ie0tK41t3LS+7HD5usHGxNYj6OSFmzkv3neMapvaee47dTE1t6T209gqnc27vPaHxd3KK63rpH+7 D8YIArpoxr7eEqfx61TGR832R1K0YFa8UgsENNGdRQ4hweQAAZYMTY5cVcPqtY+0Xtej1aVP/5// IJJVceHa6yrPRdY9JxmKqMgqF89tevlcUmVjHiZsZcWeOVYzVh3eo7WkkX7p2soVZ0KitKTvr904 s7Qhc3lGVPe7O69MZet/NZWXjbK4fi7KfHYNqneEAYH4mkByx5Y4CKSxuobnOfV+QrevSRia58hK HUhjSimiP8dJ03nSyORs6vhIfj4ENuyuYZJpvTfzIEA2hYC2KwSu5tGGzc+TO2o9IeD6FgJvFwcz mIUQaM9spNIl2ihdEKCEGNUw6OZjL+WZfDWUWwduQ2DTS3PGilDWoS4qtZsGAb17PbBlrAYEnJiM TiUKtYL8xg7doVTAtPzoRNfcRa5VRw8JOLIggKeMdQcGso7lptEh0EvdQWKxzrEIJRAwIPV2JqyC QPnDSlZJIoxLh0ZjhECgzDufMiT3mlwDgYP002m0oYTBGHP6jDSy1ZgNKzwmYcRMjMlVQ6HU97KC HRohkKjkzaIwaFUOZMp1CFx+SH7rEExPKaUM+WRA4KEHuUO0gMmikgfrenqZQv5OwxCgFl7rYjLl xz+eYx3polbrW0MgCZvCPGcIgfWk3u95ZiI8IzwjPCM8IzwjPCM8IzwjPCM8IzwjPCM8IzwjPCM8 IzwjPCM8IzwjPCM8IzwjPCM8IzwjPCM8Izz/NzzXUi91JdDoPdTk54wxf3RC32xG5e7GtwkLHaV7 a+EIH2mbn4f5kJ3io0OcBnfZV0IpYo2kj8aOa4ZS4SAaXsMkBbNeOjWE1HzwGthHoj+KG/Zqo7V/ wHeSh29U3+xkVj9LsT4YG+69a3x0eMBg6B1lwN88qe/cYwjsDl+y5Hx5Ev15yqYwz8qtnskKYZZp 0Nu/bcMAIkAE/5sEeSOV44ojSwpq3qaxOsgQuPAcHv08aJcpoyvJnZYQ8Co4cAwCA2XoIVkIfDSt gcqRRw8RIIK/QPDTj14F8ughAkTwFwh++tGrRB49RIAI/gLBTz96VX/1o3ev4O39HTvVuxqDI2nP G3VNKCcPlr/rCNGhSfdGUoLOkmcxk9K200k9aKr0wf5lrKUMY8fEoa4GcqE+s9lo3HAkosDwU00O BA6EMIpOj4Z2L94fWpm2lzXKoJ2a1y9WpzMsluLYwuyn9UqgmqUzSJ3S2wqeM1p6P8g6FaE9uqr0 r7D9Uh9x/NbcRPwifhG/iN+/2e89dFp+0APy/Andrsiu3g9rnJ5N9Lu/hc6gnZ7XHzmBIYdVyGwu Hsd8MaQghoghYogY/usNCz7P+vWW97u83kb6j/9Lm0OwJ2suQ8yxq8MGAkQ0BF5hIDCYEfzGaVwS PawAgUzHwg3kMfcEugR54HoXVP1XTzxvr2HZFmCOUkPSC9XqE3hONtg6JD74RcHgcnH5xwcpqFzV BxblW6tyeaPUlhmY79x+Pqf1iGKPz4iac0bjWFRPJ0sybrX3ftC5mFT6m4jyskTrm55hLfc2wh8o qEe7X3ZTHu7Ofbk7Ibeh2/4E45GXml3DFl90xXt7U9lbsscr1oerv3vy2GshMEizCWSF6hxlhRjv IncIZUKAHvvBgrxzH54VPkIdPIKiC6RdoQ6P01pYl0IgwGqXCmVmkHqHtKukBzt1KiGw3iwNAlWF TKbdRwp9bT35jSClY0kBixI/Tq7EUyDQ0OIHgayIgu+dUCm3dbMhsImBH3syj8lTQ6kZpEbSfWkQ YFzGSY+U11Detm8nl93sMmdyacL9WDBow+4xEOig+kJAaxkEru6n0VnB/RAwK4QABPzDn7LqdGj0 RZ1iY8OLPeH2FTUQ6HQ6yLozQGVKdVPaeZ2GxBwh4FR2EP0pmwqBnr055HpjWGJ4xQAC+kl30UO8 dRBgbumlVsfbQyApJHv8t9Osw13UrrHe50xNBtz2Zq0Yw6OL2uF/E91eRUphHbrkBIHUEAY9/SV5 CJ8Fgcvi5Ld6wUyy3igEblDhBU3usyYI+C4OZoqSBMbpERkQeDvbGwLDKMq3JJPT2inSQ/W9EKBp NaC7k9LIiW+uQiBhx7sEOrcvmZVM6+0sU4RAeWE9yw++FdcP9yJZQbKCZAXJCpIVJCtIVpCsIFlB soJkBckKkhUkK//qrLxTyDt945Nz/C3H1C6NsLgFXlh5F9/tvMT+i7sbKmC3f4IJG9LO0vfnra2t DTE+74utzYxMIvTSjocvn/0KK3jyfu36giMR4LdgynBgLHlarql0CATD5JhlfU32U+av7ymDxb7S TP77lOH2D5TblwsgsHIuh1EemFEam1H8V0b9slDj/fbGEDC4g2LugwltR5FL+ThZPgRnmcnOcv3X LDconoaA7s5yOGXeMyDgCAeX+5I6cHgKFHy3waD6vwVFo81wgUDZnAzy0MJfIVCTcJB1j0Abv2rP yYEonIMPcA58p+Xg2yioSBRIFEgUSBRIFEgUSBRIFEgUSBRIFEgUSBRIFEgU/89Ekfl+neQlMiEg El3j25TDovR8B+hWCJP2Xjg+gArHYcqJIFV09Naz6pEPo7v1FouiF0S+zFoSFbl4i7mx6cJmma3E j0tvWK/fZdvqJkMwpR3Tby3zROvilj1TD5uf3Hces/22SfTSpVZAaE/R271dXYE90hmDmtW0za2n 9j0b6PJroM3gytltvk83e3Zug1xUj3LFq7KlVkdsz3KpC18FOoIFR+gv3/z3W7zf/eU7bT6zrO11 m/fjQ/CmieWafdQt4ckJ5rd24yqLZSykBij+9tuzxufQYhwf+/4qav+o0eR19bMz5CRhvucvLde2 17yi0ir8338oYH6k4BPPWQWLvnE/6308p+GeQ4Ru5GFvrrETYyQPx/b4nI/fbDD6YccRIvivBDL5 aIXx5c64Xcm+qmbr9/Zdej9GsFCcVcnScYhkiMEKs8wRkv5ZQdVm+uheqzlju2KF+FVPpC9fLX01 7MTFW63wEPhELEsJJ/HmnX2J3/0kk4NFFs/HRMOzZp4YjMtmiO6sr7FiXHldcH3PvhJ/1fWX1fq1 Ok8SSIMfCRpjOuduJS23t3FaR7a7vWrhNXiAkFOhvWacvoi6J1sQXX0j4EzCpQcY1pLCPm1v5/SP uN31YxicZHa979XMk/uN8RIbjjI/CmwvyC6n/gD5Z7f81fyVA1EebfOhVQfyaPZbDmjU8bge2POp wdDgt9R7dal5t63uXq7uoecGCqnyYG4a7ZCQYqofHqXFF9Z2h3q26j2sLl7cLJFN9zx1BgIreNJ+ oVKo+tJ7D44eGCtMGj1Tj5PHHTu6o8n3rDGm/v+wd+ZRTWRdAi9BpEWRhhbFBdIKLoiAuICAEBGR TUVZVTaVFldAxCCyVaMiisoSBZQtKsoqREWILEkUxIigUQlGtgQB2QIJWxKyVNVX2DNzTvf0d+bM d9Q5M5O/6uR36t773rsv990LVTdf7tVPv6pL2x2oM+EflRD+Yo7shaPvB/qpkbH1k8bc+WrF/vWH fArdZrx4fi3PLBDMw7thhywkxNPOFrKA8WPBZvorr/62DhNKYe1AapXGzVWnDDTqMwu3R8QiAOaX V+BHxU/yHcr15ZQt7bku2/BGSlDpGqcRtejX/FvsDs6ruHZDitPSYYP0rkfkgLe7bDbveDzTgEFI zt7oGvlJxbKgivWTdCNnKLEEavubQTDLCZ+DHvK5lFhQaI0A0pdojDG3rf6ChkP0ozNB4sbpWYEA qWcR4A56XbWT+m17lxBCX84pCuHuoJYfeX7sTW3Gi86BLXKNx9byR99tKczhDCYFD3M8balVF2uM 3LO3XlUR5T8HG94FZZ7FN12vcDzdC9WcUy582zu25aSc55ZxC6e0Y1okBZrf0Yc32wPnXTu9+3Mw QyN8q+/dD10DahezFKUxGsIPP+133IP/uGm1Q75l3TTbMc3IX7ltZOYaLimyNhLn9NRpA+Pe6Fov uyZTBAgPYdADJ87LIsd3BCuiEOCGhMy2uebOuHl105JUqdLVC8Vu+ghA23xl6vvhK1uwHwv6b0Uy 3kK5r1szwk3l7DPaXXr8L/1SMHDyiY3CM3GivjOG/0w4Deo8Y6Ro2BLgEBJiegqbo7QQfJkZ/bbK HHpdHSdhs7jHhWphfNvHAar7tk3U0Cu8Lq633NHZYmdJ2zBYRu6K83XI+tto+N/NeL5pO5drtOcB WdCEaEfz+scul/tHTI+Ru70W4Aqty4xK/XWzYsTgDdrO2/BMxfaYYZ8OCb1duXLpqiWhWZRXux4S JQEW++nC5BCemA01VnwU6G4yFZofKX8assXzVLb5XkAEmTey19zDlVaY6BDo1RxOd6OSEo5JxVFk 2+77gJJnFfLiJGybROgzSJYorlxnzgz5Tb1sm2hffJjdl8i57jmJ9nBqAoyK2MqW7geDIr3e0IjJ OL/PJ+2YVwKH0w+Osjrdeo/5PD5oyx9VAsMu83q/8De1BZF06+5XMkAH99WgxZJwcQDcq7V1kUoH LbyvIG17dR15+1xCXRCpVv0JmJbAdM3dJBWvYHXCVTP/Pun6F/Kdb9q1pvi8aNfQqHeLJoHSe/l1 QHGWFalguR5uX0dzqrpaGLtfwyrxZMBkRJRKhYQrKr9FelMbesDt3PRLYG4KHzP5GrR8eh0SRApC eUdFJm1HdHICJfeEH/JNjQI+vtzAwF54E37BYyE+R6+5L+I1ixJsJttn3w/kDtWFH3y0wCszzsFv tLkstkRx/cSbVQlgAaCC7jr3BvNXb3Qu3NLxx2+Jvt9j1k7g11ui0hxZwfMDwX61zRjnE1gm1ilC LjfL7dPStEDAQ4BzhL4QFl0vJ3F3L65XEZ4jYrYHBQuennx60wEBYvZYaY3Mb7egC2nmgWfyj1HM t1EHDsotQQBNOCrqbtRLkQK5THL/1Hy97enLoSaF9poblsad+2Bv68nzXimWN/LSrGwfBu31/Wbx 55u27imfBXt4YidVaO2sgVRzJwoJdg5rvzL/5XDhypOMyqBJ9RmlUKKYNSb85E0aMLUMeBa/4Ust oeyg3Ab4QKUoDBYZRMCPoP5QePvlIoz+UHl/7Ssv3wb9dsKt8wPRzxSJ7rbcQA6eLNt/3w+882hv 0b7GGarJGbi+bJmWvumjQwX5KhbF6G54z0P9fddEFpt/MDjWvuBSOSxvkpW/P+nzQ9H2okfGnn79 2fnHsF2uKkdIeoy20IZrNTvnjdqjYeRILLX+HSnJ1IFDEAn9eo4vMzTgP927J3+BTkc7bVrep8WE hsJl+fmphXfDC9qr+escXdZBuIb1F+1VJGr2lqJnHzY1Hr7elZSKPa5GE2VTuMaSWd6FNcoldaet AhbaLExQSs7fuluwKuajSsTA4b/fUj6tYCylllkpVkeADhW0vtJAQ9Gw1ngaAiioQA7gsAcxiQDv 7YMvEKQFZt+ugxGn7cRz10dj6pz9rk3FxZb6QzyuCs0ns80QOJerfO3ya2bd8TX1XJuAep894O5l nvJQAO/24vNlWQR8eYPcyobAq+yBe1raHuPRFF2KKFMEV4DhlKjeyZ7RJWlnKkixRfue77e5sF6k MRyjlZJnzX4E7nkjix7fEcyjJu9dqxv6dsGO6ibmoeUYhsvdD1agwKAPvdEmSLZYPxaclo+8SZ+t 4sjttW3afdMrmn0+Y94CM4b6ZrDpQircHXSGZNiRzWanrD/+e5KhtOPkInjNogdj8BB3q0+0pP/U BReDfOPQyo57dZvFekdnTxeBFc5WDqKe33C7fEbOEInwP4+BxABsDfsApyNKCQG4cQggugrCoYln GxDgXBx8HysoYr5yQoDV4wiwxQl2zQK/XWsK54DF3lpBuOGrBtvK0xYkNHAXG6xbcr0k/2JCnKa1 Lz4htaSypPD2g2CbuSc+2Gs/dNtlb6zF+ORJOwMqPHiQj7dfWGo0zc3x98YXnUCZTuacc5HCau7i inpP2poA9zEf70+fOtqtpxtVP36zeo29TrCN2oyzOsnNu1Wt/P2nWa0ozu8SKYy24lceGTCn5n9I TdAo0FWzfN56ZaGLy8tfY9xsPIClvytWQz5BPf2MbRn3c1MAldFLT2er1A0w6xhUHJtsM0SPihhm r1vfVOq4xHx5lz1+m0EPIa9+9YvrveH1cKMTDV1M2MIeAXJmHQf5HmQE8KrAwgnlBMHu+ZBCEziy KqoPAUYyxw2hehOM5DCHKDgIWyIAfWwQC2l4eiJAIVki/lKPABO4qRbql6j9BuWWg77hakcsKnoP OkFLpqQGWsyJuT1uyea+JXs11ZObzg4L51zdEOe+L8Fq8fkh68XJjUXrt67dqGC3YbrqLqvFVjNu i/gKrBaf4bTSgKqrTgp1VdXOdUtv4HX9DuJtl66ZnZCgVPlQYc/Pm7VLfAfy8qh9g3w2fHGjihjd HtByDvsvbMqhYG52NgIQipigWKMTy0GAKU/D6eERcDTRGwH6/X7/2icf3XjiowM8kZh8Bs2QE+Sn usX7yBTKFMoU/s8oTOYG3pHre1I5MUs+pHqN8SMxZhwW3i/Yh7PSOfTk4nSxq0cJ9q82vX1lyyxT +K0UxmNDBKkv6DwTGEMuLz40w0TT1sbJxZHwkuHyiqvs5mi9+pR6kMuADiYfzZPe7YAmWtjjzcN0 qRTNNTh9UyOSIRmSIRn6L1CFcvcTO4bJNpb24KLJOmVqPxh6J7dwvz/VoKCrrmjnHV+HeD5NMlBK 7StqI4hEaOrOpOMGoYi/oKmq7f8BCjZn++v24YZhUF7frha6oq1Kk3AtJt8tHMUcwPapi3APZ6pj GhPHkqUXwzkS3mME6HvQhlY743kIEC9pDmddFEU3IwDWB5YMUUUcYwSAIwcQoIsC+ZDvUHzLQDqT SpEYwuFvqOiJYAZOEqkexCNBacO+43wej4LWntmlQajStwRYj9fMaV30ReIhRZ3xV0v8cMG/WbIb IkWf9plBiXQPqaismnXj/ij01kSfUt5rRiG80Ug3tNA8tMUuPTklzfnKuZ86JfbLPx+YdbP3lmrc z3utMEeWk2euNjXMPONpQ20VFFXd1Kr8LZ61V/uYWm5CvOv7mBlx01VpuTzBb7AZWp2JB9iQhsRp qjprEpa0IICuKgKQiSKxB0yK7gTfJ6CzrV/x9Zl/yVpQE+yDTvPgq1HogJt9IAnzBALcuIQALCY6 ISgQeoaWh5oIAOGdvv642H+2IfmTDaG4QxKDANvMEUCiQ5h6iH+oXopDF5HfRBUbCQgI4BYh5HmX ws7aCBAxtZz8KqE8fBU9nAX22Knf62q5PomevVhOHjjhN4yFC4U8VtVh6T1bWEDt47A5Z7iKkAYP AYbw4NQbBaUrRpkwyNyJHvi0VhBy47HJoXSRXSI0POXDj7x2FbERGwFadNAiVdEHAfyduolSBCjJ QoD3iWjRKi5iU8OHCWPJGEkrOkoiWMx+ipnwQ93+GC2M++dUoSKO3aRuilkMtZN8uQydsubUBIpg 54N/TAAnaGs3Gd4Rj2ploFb4xLu0saZSQSqvRYLBPCa5y+O6xhZE5vpHJrQ37PZfqdT1fmSis3mX +X0p3TXThBNvsylnWiIM89Y4lgVU4W5cWeq4Hl+eOvvJNTkDW60+P6sB5lFsxfnWa5zjQr3ss5Kb Q/cfpwW1DZX3p4al6+pFrOtweF0yt8nm3oaNt4N7On7mhdGY7+j//A87/8I/ib7pGwiVAlbKhGZg HjFCgF7D0euD+MpF8jGcZ+kTIcEatxapxp+8p/jSr20iIcghbpSXk6EoTVpN7ctWET8hR66WMBHA KScTHIhAPdNR012AADXL0HGDPclDzHw6EfwpDUIdh7edsi1d6stfAdtrTZkeuQwyCCKdqaGw/13i a9YnE5AJyARkAjIBmcC3FqiCfzGZCBKw0Ps5k1upg05SvMXUofxZDQEKsGN2U4cy9YIjfA8B6rWn TmlY1VB8HQF0EqeO7f+9El7XlddV3navWpv/+ErHtadCNB3Y+s5VhLOKYqeb55AiFhnnueLMS/Wd tncOuufQXDMPqbpAm3bdp9awPuuzgnGVXk4v5v8adaUVm6SJy2iFYsoNg4wDymK1zPfcoja9pmgn PllXFo3r1xshTYLVEfr9Zzup4jifPz4JfUZ8IWtimKcUy0JHGWYI32FW68MYHuq26vkIsIvDmocA KkJ0NqxZCJCP480CKSSq3x93Rv8CYVlgV/ZwW3NslWptntI+/4+rbwcf90xQ5AsYDwpTLBYGlO/8 MBsXess7dl7dJH102cKb1kn0E8othFdGjjt+beTNJCnPT6GW5ZpJANCu+9MvHZIDx58MKc3w0f2E AOVGVCn00RvE9ULGEBdTHeeTH0BSzv6JljSyhEq67tT6ro/RdzutXZu53+yfPhxQQkZT11lRcUTc hB4CVGIQoNcILTpaLfoMYSWM+AYCtBJ9l2ClpXRoJlbkjPu27279B8iZEDRSW0w+gc8/0lSbWSdY F14xT3Tc8XqyVr24VRL+EDNXWrxz6QLGSN4IS2z6EKyXa4DPdiJAkSOzhkrGTohEtXBaBhVqNzDb jSbcfDwCpMzEDu6whRagyRyTCP4Jff1yyYiMyIiMyIiMyIiMyIiM/B8m2xFg4jCacuM1zzNSFs3f z4vieW577zysnFNholMyuj0/RzkuvQxXOo1/Wj7xaFCJ+9vXx/M+LzQHqwuCxk7/+kX/Ynf6WeKJ LxmHVktiO8hP5Vfwc7fSGmcQ92U0kI4VLsPfdT26LN02da+G0WG8+5g5HtTJIPDp1Ue9GWtm75Fr wQZhRvjs0wLuEb+faapKvwNy6YCCglGPohe2chwBaMsR4AQCjDqFQr3Ul2YkMbsdASh0ST0CmPjA HDoCLM6AShGgzkIiTEcADQ6bA4bAEixvhbQjQkLESk8FCdCb5gp5rONSPyJYDNElQwhQTRjH8bjV qOJ6ahtW6sKmniWOJpBhkhDLK4XHwDdM6p+sR3+1Lvwb64kSfwSIjxDyNsBGH2kk4Qa48Q/1bOHB oMlebA9hkknWbNbd4b3RgvqUKDgswIyfzm/NisK375XOYdOefegxmeG3IPZOorVRaqm++431r4DF HR225cojlSn6Sc33D1kJHilhbw24nErjWlR2h1VtedhqrfPWbqNdzmG/2npX/iPh+BKOzWCjysuo ImXT3NwXw8rd5/O8lTVGPuuNTgQPTAcLtNsIYStTZxqH7dr1D/buPKqpa1ED+O61XqtV0TqgIsSp RauVWqu2akipAw5VnBBH0qpXa7EoKg5EOM9qxQlBqdJWIQ5V1IqpRWQQSB2QogJShsggAVFRAkSG DCQ5Z9+D7euya912rbuWvue9+/vP/GJ2TmK+nbP9zjnp85Fa36eDLOyRxOSszUyeq4i8uGBWSv6D /KGdrv0YkpPdsPKx/+youuKzVYY/PWTz3z3L9Zmec/877LBIzOJzBRijuGoJL/6p1Wxv6cq9v8gd BqyWDsjd2CJ0/DB+SoEh7VuHqmGK4TsPxwl5vD83U0g05dRsESZ0lTdkt+Lnead2leooic7JkjWm 3KGkttzvVqRwo6WzTXeMklMSYcCv/+3/46WJlIx8SEmV+5N/cG+dtvqHGVxWksyyl5K7Uc2bZx3U WdlwNlT4jjNHN2/qH4b5NXcYBaNgFIyCUTAKRsEoGAWjPN9RjO3tvKsSuIPuC3LWmn7KepD51qBp s2sz1oUuqPDd3P3EHcWeFnvHvfENd1/rMafEadylMutLisjEENW+la8vPn485xXrEj/5Pbu5+03E yKdcs+bXlxZ5zZr9N/2q8C6Hz8dzbZU7t1T129rWT7rchc9y+2k3lyFrDE6ewld/cMS3MyVeTqnf cgVpMu1iI6dxTeGzJHUZXDH3ixNvvaPeTsn3DTq5bpHyJ1kE76PTlpSLa6oIPp7vrdemFJtDLWrX FOHCAFuLJq4g9V8+WPssHxxsXWkZo1UrRtRJDEGBCn7FTHOrekpiAhXWqGPKbhXKHF5WIK4Gqzdl iK+ssoCSgrS/bxpilemU7tqmxZs2OaY3xFZsu7mJK53upu5TOndOQYe6E6NU5+Icio48cHqj8cDh sb12ObpxcdUzf/5ove+a4pjWJ18z75a+PGlBk2VzwZDAxhV3jbm1cVkLrict3l895dDSLdbJTa9l fpjvdrIuo+kl+eCzu5ooqU4w+q65mzfkchhfan/hRuHfPvv0e6MtOmyHYqPHLQcu+JxHqdOJyuUq xxEt6vnB5yqsoeOGu/gFv2RwcKkPXdPAB8esk1aELrz752cI/9tXkX2mlzL6HXYF2lnSeV3xCMlt tWWm0KIgvaMmV1vhXfqdsiI4PWPKaK+gkKoPJ87qt/eHIWXh6WbrQ43Lsogz3G9Hc71lLRqgd3/P zjLVN92oLXHapqpNc7Z9n0bJjFwhxLgyb7FGfbGzsl5lz0/2sIx4UkVXz+CuJ8sNb8keap8cG3pO TNObdVze+eYfl2peBT89xJNeGiNgBIyAEf6bRki3xrkrApO9UtSZKt5BnI7Pyu/s9Gjy2iUcj35y W8WtGyC77+1iOaBsXNk8ZfO3v6Nk/wZ11TwuJ7V5HjctChc874o7Jsubf5uueWcGI2AEjIARXuAR 0lfMaB9U+tsjnBwVToE+QylpM7f0q6+dvjZr8zrvS3Mc31AdqbndpbFuude+LZ98fvuHWUtXHQ5o W1jwpl3LsOJH16R82frhW3yKLyRkjl4eNVvSP+wlSnr4aVZwiTOLKSktvdcQnRDRMX/4naTclSHi SmSsOmF5kfLtA++67iy8lKWULFVWeQkTneqCq+ZXWrnbuodK06ygLcb2Sdb3KPmOq/dI2VBpkYtT tTImqHpXDvexTrtM0hgqTDTpe1Iy2ahsMOjv7A1wqXZUVFcI4tIxw5WvUD4KyhWCUqw/uozjt6gC D3G/yJqctclreJei5jNZ1o17qP7BXx8bahFXjf2spj3ccatHk8VU+3OKvbF9itGPkgmU3FMG1WU3 qpc3n9rEF9ofFS5pUrNkjyS2cH3Q+92za2SVOvcVOw+Jj7ggoWSr1tBzlOq+/lPjFE/XJNezjxaE dBm4dcY53/aXsmfc7Z/5093GzoniuiFEcVC6LdaS6pNY0m3WvOIOdgdOHbLzHjk96Z6z6UbDR5tS TAG3Ewe3ab3+zoMRn2yeM+ite99QsqS+2Gm3xDbg6L4eUk1dl76eC+f4Via0aXk5O25QuxjeIzY0 WWbdL75JxxMoabtwvLJko/jCJH7qymP/EBd/ioh5FxTpgy9e+fPLk/jXRJvnV0sVqiNy/lbzj5YM CaUkK0f/Pvd4GiV50UJ+QFNrcfUTxT0Uvz2vh6ue7dUW/3IRlKeosOPDvdKVNreUyZQkt5dpx29c L3haJU2VwUKMSv5qqomS3EcPKLEsrFUbI2VjImL3HP2Ly6AAAP9vkCQbI5yzKEyFmtD259dR8mUP I2eKfZCapTv5xrJjVb4RxV/5v31gUO8SB43L/CQf7ZTqpIcSe7O6xeNWyaNN2tXzU9fsTGs37njS F7LjA4dKzNej5R6UlBRmSBJcqy9GvHfzfPjXIw4Gz5w63LjqyufdYt55+W6l0aKJCeIv8/43/mLb rHpTgTgnGP0T1bY3ws+0t6+I59bdGeeyzfdSzZnxt45Gbml18qoh9faeOO93Ll+TJWV7jl/BzXh7 tCr5pDW1prRremBSvG3CoV7W3pOCMmeMqDT6NyzjDYcej/DY+P7ksD7hM2ocPor3PfbFjYSSr7Kj VG2uDT9SdvaVSw9jKbkcKauoMe+g5LM9VZTEFM8sdC6V8BlF3C8lXMHgE6paKSX77BO0DfLf5rMf mueztGc5nz3Tqzf+DpjPAP/l0DyfxasDUxSqg/YNo2pa1oj7aso3TYeGKbkPI2MjC82nwy4dDe+k GWgvr5h3aM/opYMW/dilbMv3B0vK7BJGhZU0addezHul09d54m5prz6SWDddjX3tqJ8ri7OTvHqv LtlrXu14+tUMr5uTE7qqwz3XnJRm/D2xc/T+kb1LLyVpzME1uoEjTWof+V1JfHP0C9RXZSubNy6G 2x5U2jwhzKOkAy9uncIYJ/S2BojzRI2PbYzRIL6SorygZpGPDb2XXTAwX3sjuML/5bB3u7er+J+b 69ZN+abtlNEHKVmdX9tzyZlo3Yq156d/EXTETRK6MbtmsNaqLuYTOo6PbJvZMHRIgJjj/dlyJ3np mKzKqNSmQ5VrQ047Jt11vNB73qOuXevmXxf3i6O2Rm6XXHWrOiArn6qsM9rEGSfO3Z8rqDlVO9B6 hZLEUV6W+aGPr2gmUZLQIEzwruAyAw8KMbULP1Prewbo7Z/pmcjP7GKRfwBMeAAG4GjM/Mfy8qWT kuKd95r318X23psx23PJ6mH5Ka8XGDz35xvy23nOnT93puuwqIn/2P/txH7rBt2cPKRfePXwEuX1 PZl9aw7svjmxX/HVic47nKdObHCWTjWqA2TJMfvPz54dVNbQc9rlXT39ThgSTo/ffmR6x65lbx7t 3+b04ZaEEEdxzbpkaHkrvtx0zYXvKBV3iAqy1wrH60P5HjWy6igXS6toSsrOWrMpKR/3QG6N8pUb czXqwrZmN0o2BNbtEhfhHnM5Q6xWfWrTMXHSvehhdd4lbNZpH3s9uUbh0QYXPnuEi3W5Tlu9bVMv MbCu5jRKjjqfUVsK9dq81OmUHFsYzYeL+IFBbx6Y2kCJefrGCKHyYAR/3qA3jnHtwJVKNi2iJKdT gZxfYdJXyfuLN87mChl3KTkcYLJ10YpTka1/8g1K1mTeEIoCTNbeyldkervUIdzDHToX4YLCZHD5 inuoERfgS+q4W1KF0EafTInQ2Vt8yYkPxKntc6mCD8veKjEFa7upG8caIiiZL7VaIq7LGn2ar6G4 Qf3QKYWSlutLOUrauLwj7iU3rKbkQlSK8POyy3bWK/rdckufAHETYqJ4fvJ9iWVYEVc4Wt5o503J Fxf14hz6pf03XO3GRK7YY6FkM9fq5142qfmqW1loo/i6xIk1LFvRM+J6L43p97dDLb4djS36ljy1 kd13d7Vrd2HV7ZDEeL85Je1Lf1r86arbg7r22Haw+44rn9StzRgXkraoLm9SmJuHR1u/tLZDeo0d 1+Zw/xa3v+i2KH7Hx5u7dCSenp2nne5PnD4QPwDTNvq3qj144n5KrZdDVoPf63fulKjebbhZMyh2 ykD7fXOXrM7ut2/U0IvnnnzgDKc424BSqYOq3OotLHD2z/CZP+W08fxsSiS53IYcU7D49bZO1Rgv KQ9WHbarHf2/u9lLf93NjrGmOz3b3exndkHRPwC+dQCApyFvmdDZIKbc44rSOm39MqF6XXryoj/s ZN7iTE5cxqslK5tUsVx+yo0YT/4ZHyfxzH9t9wkg6wDA0/AiZP35XBQBWQcAnoYXIevP5yQ3ZB0A eBpehKz/3x3rjKwD2IUXIes4pAcAeP7wImQdh7sAAM8fXoSs40gPAOD5w4uQdfTrAMDzB/TryDqA DUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46s A9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTr yDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1A v46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPY APTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6 gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+O rAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD0 68g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoAN QL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD 2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvI OoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/ jqwD2AD068g6gA1Av46sA9gA9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2AD068g6gA1Av46sA9gA 9OvIOoANQL+OrAPYAPTryDqADUC/jqwD2IAXo1/nRvdd+SCw3ivsBD+liRL16/HSsvTk165GVfi+ 9HULS88JlGxy12jUJnken75xoHBCbQooGXkqc4wl1FhR4mPoQEkPIUcIiq0NzlV9Jsnj4p343zFl zCNNnF2VrDg0yLKdC+E+pUTmfaRRVxRskNSkqwPHyq6pz3NK1TSLf82TAbWpRyUV8iJZtuZk4Ejj Ed7d6qfXTrerU9VIKnV5rpGKacIxPsGkPxls1hhDGwxVkqkpJ7npQonClDfG5mN1b7IY7KK9+82p dw2ul0VfOH7gjR35Cye+uSk9ej7Z8q8mHPfEDZqPz/UVppdT8r2P5nJlCiWNlvfVQoRCxUd73Lpf XXFSjY8s4D8f4rpT8qWUS899XCnkORZSctHxnL5b6mNKaqfmCwcqbG8bGiV8urL+Q5OD4FOtNaxc rfPkNlRoNvz5E5xNOU/Jq4HBKv/GgZQkSSh5MISSpiJppYvQRmL5ipIilby3zBabzbeWNc3wp/mF xfftbdnSOkp8A/lRCuF6qLBMaVO8y9XZuGCbTv1oVw2fdiiNktd3qO/tMHMl2aa+5ZIiLlt9K1cz NjCEkuj5F7jcYkp2SOrPUJLRic84yF+mJC60aWNdEuEM4kYs0ZprDIO5hxad1hIqzmpcRbxG3Rjo r+fdKdGq64pFd00yCcco0Tf/VT0vWaigZDolJr1tncUkhJ4V54GTlFhNwqhA8R53jTcleRxvpcQx VbzrmE7FVckEnpI9WvGeHIOmtTpzIiWrhKBgSqSCTyN3UVbEqcyK6DJKIn1skZ6uvSnxqNxenl7f ZPEPsDoIo1OOUOKksgUUK4TRnLlefVcjsQVIDJ+JD1hvu11n/SaGK5mQareZixWyyyWtGmXB96cm fnJTnMF/rJXVeln3+wnirlGiskhtjaDERV6/l5J2+b/EFkVtt+DzDvjPh+lK80yNLVDWnqtxu6O0 nit2qtultxPu1cgf+cqu2MndKCnZSEk/Fz/1g9RMSmabBsd5mfZI1+/68yfQFXs8jr8dYJJ/qLaK ARQWi/NF5LHS1ZSUiTdPefCnDfWdKLkxmpJb4ZTsd5bTwsPjHR87dW9BmmZsvf7a7NZhky46/ZO9 K4Fr4tj/EwLhFARFvCqxgvGCQLgRyEOQQ4pUBBGrzcuxQOQIJkGO93TrVbV9rRUPxNaiVqRqleJJ VUxtVapWRS4VDzw4VeQGQci+2U0ICR6V/v/1/Y+duJuZ3/n9zexM9jeOH713iq9/hWE3sftg6Cy/ QD9A0aKArfADsAdD1s1MEUYBEBwMpgAA9IAuxQxQYY0CP4AyGugQdQB4lDGq+mLKJKWMFrzZ43cw Bl5iCouoD4fXF2uFQFspvwdeRfDaqmwT394CEQ+hfxgjkookMaJEus9ceoQwQSBKlgCWnZ2ju52z O4tFt2e5O8E/jgAv1J0UhV8MA2CnVp99naqd1L66thgoCo1CVWKkqcdBGdcfB2WiehywT5Q2KLZa KttGoUp7AUrsxPeAvgzAqVgDMCJi4vgEAy3sGTAmWkDwCaFxG6wGRnp6evp6Rvr6RqaGBoam5iZG RibmI4cNMx82bKSpEVGUX68ulCGGhkOMhww1Nh463NjYeDh+Mx6uUDF9GwPYz8BUD6SCnVTK+0DL lEI1pWB3YagG2DkKG6LUoRBFGTIVBqetQ9PV0zcwpAxkwj6j9jGHAoo2haqlraWjS9PToRo5QKYp VXu8mb2O9xzusPeXrGDRhm/clTdjgpV56Fmeg6N45XUfXev0uU0PmvkSpxG7D6+a6LspTDDzl++k zhbF4Q+RliOrfy1JetTqx9i8Z83RLedKq9qyj50vq26fF7X00617j18or+lw8Y+ITl6bkXOi8EZt pynQ0oJotQlMujQdJwLCeHszbYhgyfvDdFgrNg7HEZwNvd7kYMV7IF6Z7jPXnC9xbLam4QB0Jzr9 UgxBfGchmBnuLEUeqiC8HgGjHwJWAYyohE9TwAbP7t0vqh03xqpH6+ALH8uz8McW/vpPqIzM2/CD q6MsuPATxscjpmaW+ax7j2n9sxl1hWCoSfG4xquBs3MajFDdXphZWWWoaoc72jk9+y+9gK9B6UGi cAxc+iG3IKvLavPj5UWFTegddktgXyWIqcY/3q/2Zw3PYj5O+Z3/7f3eg2Z/N66siDyVlisPR5Y9 hdGMrwyJOJ4x715GenFd6dN1mU+rNt/DwDfvsTsTMGCHVpVg4Kpx1osT6DZ2S6xFR/QCaB6+CdVh oCq9N6Nc1nIcA91s6KwBVckJUXUVzrtXeY950Ez36e1zndPRlsDJFerxlPXE3toYHlE+dpTAbdcv Rh8s9rx85W77lwUL7ky/eN87ITst2Dxt2t5vPSfmbby/YLSB6WYkj3aKVV3dys1NHpvXzDEZ+eDh g7tY0bO7XZVOeZwi0c/TviqqbfCw8O7a8htHbp921+VWUMz52x/duXA5bpvwtjzTYeL8R4dsD54J +ura1VGFetqPwOV1TT23vb5Mbw3pEXc3dhuFtE7DQHE9+ijjBlrEQzOj5Rlzep9YbLh5FwObTsOX 5V97kouLPxbCVz/OIgx4r5cjWd2LmBrKy3D53K7p1+RP2YXLbKxrsp5Xt1e2jcyqicRAdjEGCpmH MLDzHAZY13ptM+7lpfR+9n/EeokpfVVlsGPP51fQ5stPZHX27N+PYCAoe4DLAl7zC3MMMOCv9921 zxs5nNLcA+bzb0euMeEaC50XJNH8j5U3+GYeDrGu7Ky+oD4Yi7YITpUsqT77pf25U7EY+GzpqEdb XvD2584eYbJefLrDMq51k5trfsGZaWudEpuaeyqZ8IUZu96Y2VMnP9H8cfCOXpcJcicMtM9Mu8ze YVkun3rxiGxvFXpBJv9+/zc1Rd0Flj3z5MmZ8mfsqzFmgdbBj0vTA62yrdIDJwdapc8KhbfNGoT2 ijNfsMty5dkHfss4VNYmlB9E223mdbHhXNWV19ewH82+k9sbAZMLNlb8Z1Ek9455nBOEBp47MdWk /EzF+Q2pSavq0zv0Dl04cfujbWWcEZMFVn5HLQ6cajZZ96BqyYVU3+xCW71CS5MRdxZ+/JNPcZM+ MwgD2xcZYmBqYVcHBurDZDUZM+AkbZYvk3WHB3V67HiEgenydvgStcUjo+t0ZRSzd2HX7iA43uqC zK7sIlnLaTRLJN8S9Cx1eqE8ufexrDrEWi5yufU5BiK8YtLbZOpCcqGU2ZNrWQtXg+zQF9/Ohonf Dgyk5XbNvYh+faWDh4Gya9utCpgacgOwnqnddBqtRe8dkIe1cGpal22TtUtq1r85JOZPVY2WXZWd +/8jATEXHagr6YWr4OMFR1CVv8rucOGP3rF+K7J3mgC6jpcRq/D8Of/9x5vEyx2aF45t+rXBb0lH /vOCqyYt35j/etYjKx8+uiV/8qFJT5/1ddk++JjOgo9pKHxkN+9JD7SerE7IfnJs2Wj0AKc3KGKj GuKDLWiO3KS35Hf0wo6fON258t0oVvo/YgKVNbqMyM8XG23YGAnTegtPs9qTtZzN73GZdK/8jH/I imwYy5OvxEW0jWnSP7w6euGM+qyMmiMtNf7GPv+6tDofDVobvRkDF0p2oTmXMeAl66VnyJ13GPZ6 cbra4QOkU74n8ymv9+ebcL1qxcDz3SJrDHyRAwcvJEO+DO32ZvbEu1t0/1PW+gQulIYHA5l8i2c6 aHYXBnrmuKS/2XJG3uedWrLiHphxTPr6IvpIWCQrqcZAFkf+FXyOx8xeI89i9nRjoG3lk9Cgm+df rODUL0cxMDy4StZ8tI5T34KBa7kYCBgAKWmfNQ45t03GhmvhxBbO8wops60Lrb2BgT1mmpBOlqZ3 2C+/H9HNycLA+WGpGuHoa0BatDjwHyNliVN7mdcw8HD9aY1otDUR2R6zKvgXJ99cnlGLgWbfewPC Kf37EJuYB9kHh92/GdPzOcLfkNOb+zBr7JI1TZ8dl9lflYwtNClIj3Rlrv28LeVMNFb+7I7/KY45 8WM+xbaxNeJ2m/9Za9s3P0I4Ia+wRH6j+SPDscvYDehwOM7YLazBLKA/F3KwtQOuMwKDtbWJd23d sXh+Aj8EzZqgDfUzalk/MX9exY/fUHb9mPNVMs6jNih4ykxLq++b0JtI8IyBqrA/AQqLQ4gm7msc 0R6l2aa2Em39Pj2KQstA2SBajKFEywD05QeET2o7UQ8AzKgoyImDd5pSS0HZlbldRWER9wXw3kdx Iu42/RTC5nOinggzrlcWah3O/u/nETHrEb6HEriA1t8Ul5I3juBpq9qj8Ro1SIVewRbj+SqsGAI+ EMEoECAGUiAECYAL27EKyy8VNRqurcpyXyWgKkP76QlJcXEAEMk5jSdKShBIQniL+f38UL7UHijB h8EHME6UEN1n5gMkSqreniEVxSvaChih0TFKPhEYTRIn5COSeXEfSHD7Gn50CB6smMFLl2gE+qrZ 1o0Wi5ISNUg0kVgYLUxAEpLiYcto5lxcKYSgwfYQbpJU5I8kIGKuFBHg8mGpiYhS2EAhjFNwTmB8 NB389fFTk8RxYTPnhwGNztekBEuiEQ0KjRsnDeNGa9CM+QjUQ1KkgZKAsOAPeCJRHM7Q6yNrCOvH iMRp3nHC6L6eMlEEH9BHhiRdARLFTYqT4uJLEbH0FeLz+sia4oa8aB9RnEis1rmmCoUZ/ioGDmO2 KAH/1peKEkOSpBJEveMM4mBHvkQ14omksENfohvCIY4ZKE7Mq0kKPXhR2E2gn25KVCnK1Wk40cIH VIdoGxFKeFx4h+2EVyqs3gfg4X1il2ckuasDyF0dcleH3NUhd3XIXR1yV4fc1SF3dchdHXJXh9zV +S/s6hCZx3jizXquIjeBmRbwBgKY6vNg6k8HH4IYWJfCS0LUEgGeHL9Zgg58FOYUmY5id0EX6Ck8 YA9GecdIpYnuTGaCxJaLZyu2fFE8M4WbyLS3tWMCD3ZKIpcfi0jpPARm0Z6MxlMyBl0o8GREOAXb BSf6IDHCgDQxMjdtdhg/LZbvJmCwvQw8UtxT4hPjESmXnhIflyBxT/FkEMbdYR0nMxl0QkQa68mY H/whXSoSxcUKpfhelg3LdRo9SsyNR5JF4li6va0zAxoUC6LcQ339lOZgy5OhxJ2cnGyb7GArEkcz 7d3c3Jh2LCaLZQMlbCSpCVJuik2CZAJDqSecr1LTCFc4n4gWOjKgE658EQlfLEyUCkUJdLzN5YmS pJ6MpCShwJ1v72QncItysOE7OrjZ2NsLXG24ji6uNlEOri5IlAPfydHRlWFAV7pEUoRRr3aKc/rc 0ukeeNOdyI/nwh5HvBxZbo5uzi4sNycP5kCeSv5DYQoSN99XGI8kSCBWLwjNVSk+kKWpE6mmY++g oROpruPBHNAdf0EXJQpe00OQATvIgeigdwKkb0/1NXD62GqjpqK5BwglUpE41cuD+TLt3cCXCqNe 05E4Rw003nQPEQsROD8ILPYezJdoKsH5oYhEFJckVT5fzD5hdbpKOPI1wpGvEu6nhScIpV4spewA 8rvpPLjivbrv+pZCRdfBlruPGOFKEV94eeGHj2zsnG1YrLC+w0dT7ezd7ew8mAMk+5SDRQJhVOrb KKtJqpTh0ingSrlvpa4uqwFdJA6Dy63X689UqYFXyr6bMZBIQ5HXPMF9oyDBNw+Z+BOSJOYjUHyC xhAGB79ZPT6+fxyDgyF0sXApIvATi+IJ6IlcsYTYAvZk9LkgxOkeBDR3YYJEyk3A96G9iPAEzgIB zw5Gxo3iIYrweFFRfBs3O8SFZ2/HYgkELh7Ml3TVLApE/CS42kohVfEDCQnQcP8SonTh8jYu1Izh MTJfClI99D9yrBw61puGTuVC3fG7eFIEfNU4JyaJ44hffwGficQhOAwJHGt75UAL+O5RInE8V+ol jOdGI8zFiUi0B7Of+mq8Chp84YCvHkzVywwxcH95IZ0MqpBOBlVIJ4MqpJNBFdLJoArpZFCFdDKo QjoZVCGdDKqQTgZVSCeDKqSTQRXSyaDKn3Vi0P/XIUiCwJORzGB7qR3z+pvqmBflDUVL+aVRqJql X1SL+jL3LQpxzEtbrFNFpZiqH/MqwM5RdkOYNC2q2ilQXT2ajrY+1UCLAgwhmYb7VzEhi6qrpUfR B/gxLy0KVZtCpeKQtGj6SRCftqmOGW287rD3gZ79cG/WBHP9OTNGcK0cLEKXrBjJ22jtsyuvaaKj 2GDU2etOjAdznVc2p+/2DZPM9HPx508Knxcx+vAvxQ9bBKukm1Yj3x35teTRZNeo1qQpbu4BgbPm Ry6IjhEuXpqckpq25tO169Z/tnnL1oxtmdv3ZO/N+X7f/qPHjp/I/+nkufMXCn+7eKm0rPzGzVsV VdU1tXX1j9vaOzqfd3Wb4pDxY2E62traNJpOPIRsqj3eTMeeBt4f5j1Hl8UdvkRvxooJG81Dd/FG OOjnWZ297iNusniw0tE6fe5Ivm/z7sMTnUaFOc8UMAwkqzb5SXG84UjSPJfVawjArZNHb95zFD8f tkVxQGySf0SUq+qMWP8RtYD5MSnrtn2f/9vNuudugZHC1PWZ+366eKu+a4r7rAWL0z7bvv/kpYrH 3Zonye6E5LNreM8s2/M4L75fVXmy0zvnrf618R6Dk8eAzaLQT6ZplX4AqHVgCJQ4JO84IY+YgoHW vWj3dGjs4xcVlV0LD2DgaiYG6hqXP7n7j8ZYtFqciwH3aAx8V/AiN6mx4CAGtlyS9dRnyb/sfFZw 4wxphDRCGiGNkEZII6QR0ghphDRCGvlPG/E7fryw53BuHVo9Ea3HAA3Srt8th/prLx4KYXR73Kgq rWjHQHJuLqe8s/YJCq2iWNGfzS9IAkn4/0Q4tKEIAz+g9+DUk6aiNRswUD0dXslwxnCw6+QsIgkk 4Y8Jb5xFxeQsIgkk4Y8Jb5xFJeQsIgkk4Y8Jb5xFpYOdRT/qd2uh5RZ4IpZm2RuEXmTgeRz08Pgj eaAXlO5Yi4HQypZAXOIou3srBtJDcAO7MFB6oid9GUzpGkzk2bKqTbjJGLTdBgNWWXjq54OBfaIu qxfQSwVpmjRNmv7LTJ9qvoiBsZXyQBFupZDRI0G7rIndlrFZzVcwULUVVzgtRgtdoMZHuFFSg9Qg NUiNlzQWBkyJ+3mffPV8DBzHl5wnuBVciNDCrUDCIku4mEGJAvgOUdeCgSuWGLiUDK9GuBrJsLJB vobUmTQubJjHEPGEkw5MiXksjuQtWOBWlZPV8L0ws+rDZvNYi5TGK9C/dJ7s9KkN8jSjSvmyWAw8 qcVt9FbfQVuLojDQ+oSDAY4nDrMR/w+yvl0FY8pagIHuLtwPmpps2dM2StbTfQMDN67hkby4nI+B 2p2wH2rLZfIzOLTKe4sKMeBJE2HA6xgG2lvx8OUtz9hddQ5oV3suBnK/xdF3ZizBwDXvr+HtINr7 T7yDSGwkNhIbiY3E9r8J2yHmyRPaphc9vl7rPGGly/aQzqmLfvH91J9dy94JDZctvbE0hx9eXh6+ V34vzzo4PHiW/7j6q1ZzrP7N3pXHNXVt6604VapcrQPKEJU4gFDUAgpagyNSwCgIWBCpoiKTiIiA SA5FBRElAiqOhKkyCcggkSFEqRVwAJmHCJFBGQIECCFkOOfcc+hr3/31Pf1d+q6+O5x/v+z1rbXX 2uesvfZeSQQ5Zcoe4t6UmIA5/lNVMbMuI5Hr1RDavFEUvM7QxzTCuMbhm40kwQCzBDnvWyFBwZgz EspLMQPOF1GGV5ZDmENwd8DLThnJZFqDKIjd74mw8RKA2/1NFqWz1Z0OTxcwhCjAvYEC47vhKKDI n4G6rO9gDkFwh0hMe+niUVtsbpsLO2FozCFVjoegimIuSTK3k8JDAe4RwkDCQMJAwkDCQMLADxv4 Y1mv1qC7zOC3kdbBg7nB2tsqm0+Ie4OM1G88f4sCel3d4VQNF95dwUPzQ90RNrdyvRcviiAbmgUG TMUmEPSrJX+sHE/SgmEHRIhZHv8CBToQCtS5KFhZhClG68ZbMibIAsr8n717erD2yb4ji172KHQz 1HYdwjI7SdkJ4WLyhtofkyeA/zPQPb+hkdKqpORpFVS9fCDl4l6qrLnUJnA10mKCLbqeooAHchJA 4eCi7P9tORDApwEsMm80XaqjKgX9ZF6rf+nyFI271oGOpbU/KRvawsklWABzzZ45/PCzw+pHzpZf mF0o2dWWXOsjP2Vj+Io2ZSgH3/XWcMf7+NaP9/E9f+rYjsPe798lW/i0lepOmvICcVFZWCk/a3Sp IgoyMbVVXxGR/KTAyckixKTv1PmZ63QZWjcDVrGXfXlGa48MMjuyEgUPsEGV6wlHfWZAUSHU1kVa zWW5bx4MUR9sDH5zzdnq7SamOvl57AF4Q+ZTbXgHNr52+IMv6C5YQVIC44e2RlHIURQgFmzE2h+j H1fPbNLDhx6vd1tZP3dTmbHUzIHRlfMgpw/btODvdWbi3Z7E6JTNpte+MbFYTLEgDy2whzvw+6uD RCQ/LTCn4opYTc97QohV/uuD99LCtYejFlu2m0Md07ax67GBlacJZ31mYO/UIRGH4dfgx/Uqm9vO Kdj5pZ3O+WOptnlrFj2wkpEmk8/CB/2xsW6qH9pO5VO2IJkowENX+Q4FtygouMpHwTU8B0Pj6tGN 4eWugYpHprReszW9dnWgrW1tpnZ4ko23HHI3CmefQ8Tt0wNb1+Zm2T+VynuUKu056fWXtjbkR49h 3qQAqPoVDYvVTH/CVZ8XsELBwNRj0Jc9Zk/yyHRTToZPreYaUt2wEi1swxlDuVEBy2gU35EOS8ef U8fT+xsnHlIgLyn+wUOjzvnNHWHWj3BSkvoZp1SZ7kstRE32LbYj20OE7dMC+5beVG+7Hmc+6eSg 8YZzV0DY3DV5ZBQEbMTilGYjKVujK2z8wthpJU8jdR8j2Tm56QTUgctuJfz4GYHqv6TshQEWl/uT K/BydcJoX+7O1139WcVlpKBEaYbRtTRzzWLm8W8cNXS1hVPiSmB3jGLGn8yw4+k8jvPjfq9d0KJz Q+hyb6XCznNyHp3p4SkdKHCIL8ETsBERxU8KnLzQe4cxcDkkjzc353lD3tHY99y88AOGuShIPvdr 0VoLEQdznxlg6JXPdnuVl9v/JtFc0P/liJr8Qm3s4f2q1Gj7SfrATLxBMdco8NZCRfWu5Frz6IvT VnQXI9cCry+mTs8YnbwLPzDO+hO59+/tdS6Y2KHQY4gCd+yDFBk3T7tdqdrTOnCh/praVcWbHg3s nrVtBvtn04P4+B0ftIMA/iFAAP2KPiW3aW+vc27U8/dxNcx3MSWGtQoesG4OxFfFBi0nHPWZgXit QXk3yJe2yXWPj+zq6BdrbqckzK1JWXWjW/XKgw3Q4+CgehT44a/W7o9yfTzL/r0tgXEdGuSEkvra LXMiX5ltsd6wqphOzjabu37Drp8XTvz+ZgCY4ImJpKBg/Xrf0ldqfXal+7c7Kd/R2/yuw+ANg4Mk SDGyjP4jgyiItvBAQeftxSjYD2MvjIZG29IrU6rfnIsAcvLh5MjhiZXY2K659/takkpqax140m9+ qDy0QsN5RWpSiveRmbfSw7IiLKiWxtZUzdb4iLVWRttB6sRpkzBreygSp26+WMLyRkFsmNxvl2yJ iezOHiEXCVqn8NsF3b3oaBQwUushieLb32/3bp32Q2gZdijocgj4/eKNICQICcJ/EsLw/mOxEztz 8ofl5TwLV+llSkgCRPRTso3XJvLhnKBJkj3W6ZQ/6rSzJ9xMEP6jCEOX+42w7d8LFDVMraRN+gtN aQa+0ae1frmYEmBpVdPwjBxkZfdduPoS0fxOLJcaUkXVjlCFNZMiENB/b5OscEQBhq3D1OTdUviv Tkx/PW+Z0M8TBZR1v3dnEhiBERiBjQ9L3+LTN1t3RiXzgiQIWb3FXUJqTnJKubEg40WKT6ZzdZJ1 VRzLA5G48sU9I50IzQPv6G4+zd7/Bwg/3vkPgPbtFDVe9G32gxiPX5ivQsHB0qceiJRO05lSaNRA Ff9Cs3OduM1IoCZLgBZH5yPSXraYp4cC5Ew3CtqKhPuZsUX2D6GKenaRVBs5/YqNJQwDaDSDbZ1x 1D2qz14g5POLXmBFT7Y7VvSUM5CV/Fpek9I7qbUM9pPyszDwPgcFYkEiCi5KhadHgsS0WiyY+/+o Cd7P+lVTla1+i4pWrkZ87BtWXh3ndL6NV+pFun7hgOKtZCe7Jp3ksOgin+Z4zfuxjzMXhb4hOd0r yma6zZ+d4PZd5Q31xLQvFLukLu82OnEXrbX9muPpOzvTfGALOUURfHf98t4pIHCb84SpFffcRw4h BliaknRzYUUpFQUprIfSelesdryAgpZ6GayIgjTuI9KwAzbjLGMsvc5kIS8ZJfZiFNitR0E8yQlz sDWbJuRQ3i2hiB7ic0KBLfs4pasEQsGhSBS8VvGDb1LC2AIkH0vF2zdWo6AngwbzcqHnWyG+C0Jj IUzaW6gyDHNC2XIUxBiIpGsgFagTPslHLvljHqvFKsi/NcoPPgY/xpSroACOwIw29OL/z3lIRemN KFCfhQJWhlgikjRLf8S0YzZLyQwkgMftLZN5YVEUVrMlq0cYKLD0E/HtshFzNazcxuMpLBDJIZcw i0eMKfCEenZj5Ci2N6DwEqFhhz4KkiLitxQ4yhKMkBF2J4/L8+6fCitiBXdvBCSRy4Cylw9yeta3 J1aQGnvNUqBRHpd9us9+KHK+tAnfa9Dd4GLXr3+hQT2zIUl9bTIKNDe8/7kXm6Mz/3J44an04QTO ujuqtdezXTo98kZXCzkXk4eyNll8rWc8b+3Ro5WBmZPOejwZiZNPdYmxqdp2RT1W40mSz+vX0SHe 0fu44hN7376XX9C731Iz1OOr4vKY11khc01WrCP/oOzljnC7oj58LPHhA7/xtIim90PYlI7hcjxG D8TB21OOJC7vX9SBPSKhQ1AtHQOcPDgNySTm+u+LI5SyvXknYmBvu+9F/azXvrIl9sLliLEqzjgQ AtUwxGRcA7d4KQrMoY7wsTfitCgYW48RRrhKQoAQIAT+FQUi2g7PN6BWwzuQIuyTdsI1hMA/s0A6 Cs69gpVgJjY+H5mlLcH2N2Q8mfmNbmX3UGUR3+LXpq2zUZBMGcJ7RevZ50yQBBSUqY3tS/89JPZk CKZqNIaJm68+7gl1qz4w0kFWCqhR7IhO85HM2q3zmM6DPObrlC9veae89YDFyHTGe6rdKml+r1au 1OLAyum67WYnIE6pJcX16LkzyZUHBpijUKHfTOG6UW0ktr5QCyHhd1GF81Gwi9cyDwUKIsyyFnkU JHnx5aFgaQnbiz8ZBTUGovPsn+F2zKBAbEup4lfMbUUGsSA9gYQzCwYYXRCHfqqP5yLH+PqeRbWK U7dc9yi7BvavfH7+W+3MrFNXHSrS2imtehydvoyLd2PvXldTlnY+6MreVJptbHwpIYlTk0u5NsNk 9S6o9iuxaMWJDRO16M/uHQnnDE3dgYIwYXkGK73fHW5yu69r7ZadGxS9qcPiOAruLv0ODvD1ygzO DN5b8uF79X9kO/8Y8OKLnEpSt6YjnH0Wg9OcCxRihixZZ9ku14M2PyzgeNUmz9q5yeYOvDUm8Ksh BUw6HNussg6x322mSiJ3Y1vjsbVOIARCIARCIP8iSOYgT+1VF1miRHtlVD8I4zncC3lRZ4LsIWPJ W5c07IgnCgIhEAIhEAIZD9Ln6n3dWX22ortmReutF3O2vFgZsUd+8iSp0LCstT6ntHPr5vsNcjV3 JoijH+r3XljWzDpftHadxRJH5rHWF1vrDm5sKVipOfycKdM8vBkFAaqD9wSnbVMb053Xd3iK5+kg e3hFhTf7tlVoDwXVZ45uVTIx8blQRSOHWKaGLU2hViTYi/ZDox3cPgai3kfh6yKrX0fC7v0Q1xHu QMHtDMirEytDzJBGFLRFw9JX0CUvvpCdhwJ/higSOcaC6xmI/lqpIwou+olw8Xp2HdIJj0AtVHG+ 6L+5+dzC+tES/NReyhBhZL6U9zxusy8K2iOhXGg0kU0T2Ler+I1LdcNtRJ8uXsYdVBVKK+cvzPfG pClcxxGSwEvvtqvpNPcFb+kpzLcNEw706UizJpGj5eK/ZXOk5685LWjv8qeVFwXZP49McjawbZ9X 0VSbExSRmUvdb1W/+HJ8kYlaoGu5eWswmWq5FO64XuKqmetie3CFFTmjaXu8rIwX2DLoHvqS1iOY J1iQYvJo331HZP6cIMXuocqFQkfaq/zLkg/24n30x33/1J+e9KqQ1w6vRYEb3kl/9hb98tW8hSFD y35U7Fh+/VFmgN1l21uBz2oSeakShhAfkgllPTFGgUEXVtAajQUOz/kPzKHyfIokfMzbmBap5hyG IJ2OJODRGVupk5fLePHY2iVh4cSPNQgWgoVgIVgIFoKFYCFYCBaC5f+B5Wv7Vaezgu8hGmcu9L6P v7hAj77b3SBl6tGnjqPPTOaMaipa6cT9kqoRA84e9yVRD22ofpRe+WKtNHKhz6odm8TXqtgvw+5R C5hk5iNEdgJSO19TENR3JGK69bDDVar+veOLQ8pKbOQgzyseMdCD3e4jqnSfvbeT90y3ySH1CHg8 CuxqAY9QHGFPHvdNKwqUo2AmvLify+KM0iXsjQ+RXHWZnBiqK2LB5aTBMogDVanC0mb2BRSkCnhc 3kHGY0oU7PK3wvzfhFmfSRgrt8KgIccx4dtjwkxMGJGSspG84VUnFYyoHP/WGhV7o+3OGusVsvW2 lw88jY6f2frmakNTMPvSldnqKo1pjycxEh/67evLP1ZXcEK5QseYGrkugzFQH2OUx9FKZEY3eip8 +yYlrk/Jra95x5wp8r7k3VcXaMZMeG+2QSLZsNa+UihcOnfyjDVV1S+DVqiF6YZYMUjKJ2u65jpc mrHCcOIbKLiwY5F6VeGUqY31pUrGmtw0/VS2J8nKNVNW9q3RR79e+rFrsD/1B3ltKIhlv037lZJ7 jnMyq/V4leKSZaY79UNeJzQnVeYNwxD+ay3ViaKDkYglNj7ZCQXbpfj6bb5IFVuHIj8lwkpjS/yU OuXdfm3JdcawO64HbkhAwTUfdo8NVIlbKCIYCAaCgWD4t2bgSbOxBK+8GAURaiiIx5s6uYRrCAaC gWD4z2LoweqaVkOl4tAMSlSdu2u18Qy9LcyCLRmnNI1Vz0XbfHnYVIqCZfMeqyw83hVB03xLSrtE 4dM6XH0X9LXruOTFhvbtMr0si0y/DZ1kLIb2bRRZcToyecFRp1jFoxGrVC1NprENWubZ36o5/izE /gijxxoxVh0Q9dh2SqEGXk+oyJR2dmRmvnQdChKgISrLp1Nin4MCRhqtN7QS+oHHdSQN0xFjEV8Z BSYjDAG2BQ4/rd2r4tfbjmCWl22E2xndtGqExpJmaW+Dz2b434GqKOLl3EJPWLsJ/3LLqW1d7Ade /Gy6BHvjk6WiMOgnKVUsEfWXsuaPzGSNeKBgBwo6GLTBimG2E/5dD7hxfhzypL6onNJNkkXyW/SR qD5KJ49bsGTYvsGAqdDhXVN5ylGg2q3urP70UT8zruVufPiEuYEqzFzHuOK/snfucTHmbx//LlbO 6bf8smxGNscQVrXSNFpy2JCKlE5LSDohicZ0k7UkCS0trY5IVEOn0WG6kVOSpJqh2obQaZqm08xo Dvf3N57T69nnYX/P9ng8Zl1/zB+9p6brc1/X9Z37en3u+3sv2fVihV3OXgE1qTZKpJdQq7qeUTk1 p96pLH7yGYdcapJegEJRlnvGYonidNdsK6uY3czpGRZ9SPvtkTOVonVxaYL8hsNTp+Tk3Uowrnhl HTxfNduyOJtkF1QLXyYnqt7kmCn70zc69OqJwvX/aey4PLpG0PHDDYyq477E6NpSNUqOhJ2EAHy8 YG0UcTOGaV5oU393mf2DF6KLzMFZ38yRR4SlX0ysZm7xGGXSrSp0svy601di0XFQPDi3/7Vq6YG5 ttNaGXUe7u2k+3xGbVjxaJ/crtrT0S9YpM+BlKLvSgO3G9rQd56LPLUnr8qwbm6gYNgfN1G1LvWF EW/oMREjinWXPlnHl3Uw06xmjMMCx0p/l1ZFtNGIIVbZ439oHty1VY8YKh5HiWOCwvL8nK8+H7Ht pgXf42vCYC1GmfwhRKHgLBV9PJdW88vLtsLCgtoNlkqTlROyrAqa1kpdLRYmdOn5VHXSqH4i/551 pzBKO8a8f7QwyGz6W8P6H9nDvXqCMqwaADQYrB1IMIY9ciui1tfItGycZDv0rK8Gy9KaQ6/MvGE3 M5n56pn1tpSpXfaL9eUtdsndT9YxuPOOFTb2PB8yqPr2iAUvN29Yp9igx/IgdjR+HbtS8avI+dzV puhfjDhDb3Od9vgnHjrTMyq1PPp+hO0drp342puHRg1XcXew2UxpNqWvCFZHJPJWLpBK1F1VzX99 UPQmrGx2h3bNm17zdq+ncd4EyyNvMfzfNFwacSikjsvrxKj9rMVV14R253mk574T+Zx50UEN9Rc3 TN54Q2Q2lR4dGeFInf8+zzy8b3f+cRWrQfcKj2ZTnOHXzza9zWCLPHVHWIjgQF7PVur1wyDz27IL 2a++rb66nSrzGriWF/WbOf8E7fis5X50pmULL2QBRtfPpmE0bbZAkqEdEORytonzzvXgn2/k9Kcf MQ3LDAANB1aZgXtMXh8v5Ez03CX2P+L6Wb7Mrz7N5xQR4OcX/2RuLeU/riPVxvlUycumCbGJdpcu bTi1yBsZ/UA/5rKdPd21ll5VJ/CdljE6s0Anc5Zk09SlDH97iyJZhOJ6Z06pb8mvmWVjpALO0/ij g71966jBuzz6HTu+YITwK2+7FSdXTl163mYZo/WnPeMwKrB4fRujxEmppPypiCEx+plo4qunoA0d xCP6GIxuuMriMLoZ/oCUmdeSomQ2kfFl+36qXfFClzoUm4GR0JMk7HoWUxE746Q2uqq+fPJZuqJM PVNaNbgrYv3cpRV88umQ15YY7WJ1hGO00MaJkGQKyJQ9SeoBNN9GMSmc2icUtK9hNaqXsMQuI1WZ qZHCSyj47+GJBZWFthgluSarotRwvkT82rCwC6PXtrujqcaYaFWWRCxdYDGcqKPtWY9R+Rc8d5WP TNziPln9Q3oFVaxeM+KDZcqRgt0YKScXlGAUUFpCVQfLFPpxAxhi7cJZRFOY0IjKYcp+fyCY1CBx gXqeGuG2EaPcBvUS5ktnqo6V/UiTHRSMIrsXSqIxcqYr5NH3Gd3e6vk1YxfZNJaL0edBdQRGg4xm Y1TbtR2jnFgudc/zpraiSHzEXT4+WB1CWqxKZf2KJjeuJp6au3dru2EUmi9Wr5AHdE8TbbtziRqb RX03+CyP4uV76GYEizeLzh7MnBlm94trcma7YymHs22gk9PE79JmXXOZs7LiuwkXzzi91LljvKS1 ofVWVI31POvBgVlXw/TDDM/rfHcxxaDcCqUYnBkS5ZY4zLMhfVOja2eIZ6PencbA2vTDp9PZk040 1Nsduppwwuv0S9asxMQWj4WrbeejJp0ebYz67OQor5QQvHv0S037E3/r5Sz6Zx/lC8s9gE8H7HC0 +P3plfr9v//xXy1uIngMsZu6S8zJrsUYdZ5Vv/LfdM+ffgYa9BqATwe8317r1R3O0GsAPgnwfnut VzeuQK8B+CTA++21//Uli9BrAP6y4P32Gvj0AAC8C7zfXgN3GwCAd4H322tg8QIA8C7wfnsN/DUA AN4FPgJ/reny7CvohCX6rNhgKxqr4oX1jVys/UWdnqHVkTu2DjsxcrBb/dijqXlL8xZmXy9L++Wr P59923a5bd+qywbH807uGDfcsl8f+imTjqykUXUtwy0T+q/qp3NL57JWQuVYvuJ04CCXms62ZoPt U/PMnrhmZFz53MlxoaVDv+GW40IH3F1BNosTMWrsDjSljvjGYVQVK1F0bcLo52tE4zSiW9eGSFuc 595d6kfKjPIxSqMzVfRudyV19AJG5RGZGMkzBWSIj6AzWlv5KpIKFQqEtm3Rqm+c2aqSNoyENm4Y 2bB0MWIkpZDdHj4YUakysSDGVHm+CKO5HhjF58nklczzGC3jCTHariDlFXyyQmCFUVlTi79qVA0D o8t0hayhFKMpWzF66IhR0wwulT22magwzsOotlBMZUnE3bJyoktuFoPRIpMyjFrKQlQ9mcR9F0bX KYZ8MBt0gA7QATpAB+gAHaADdIAO0AE6QAfoAB2gA3SADtABOkAH6AAdoAN0gA7QATpAB+gAHRqj o7v/zjbF0zHVPmNauS+yg4I9ovTHWuYU1hf59YsPPhXW7FBQvynm1oZHDYwJ2V7ebner853z511f npoyI9bsy7Unn7saPOZqcR6ubjjqtDnq9M6atGsPRt2Z4duw/9bg+bfNVy1fu8XYK22q4a0dQxX2 5drvvtCkXE6TRCr4ZGBbpJGyHCNlMqFMV8jchL27MfT4Uoz6pJAt42nyJ/SnFrOkR39RK952DqPv Bc/oe5TzRKuCkndEjC/Kyf/qs3XXx9zJKRKYyprW+8qVGX1CLry4R5Bx7Lw4j2KMnNxsypRXTeIU 8/fHxyyh9quuSJ2629UfT92g/M4PinPjniMsqSdMWUWRcrBCqydPYsN2e8yIx8iHrmh+Tn2u2q/8 LTiZz/aiPSJyxqr+42+59kJ+VmQTo0Y7RL6L2Ef8gJGpW4pEWL24myY6SLLMGdfJK0QMe5VcIvpa ri0tEhTG0p65P2GU8i+xgqXHVVqKdWKBjXa7USutQVhlwWX+S3QycfLB17pS7a7AFogNYoPYIDaI DWKD2CA2iA1ig9ggtn+LzeekMvTnoWTn3r19v2KvCg93uxllNn+oeJJF26HL/gWfo6Ca9rvPotix GIlvMdoUNdswGlBHtjTU8G7Wda5JHyZ554X/rrQEjNTzJlc9jzV1YlRKw+h+kPolVg9qZO/2H/ln I52ii/JMDsSo3rnVXdXqzeqKZGJ0QiJTdtcSVY3CtqQn6qF7e0Gc+veXJ1OPpssHsqIDJ8MNHgA0 H/CKafcMKbo4CiPptZY41c2HimL/fI6UeVfOJF6/PLtHhlHIJGU0l4PRmTF8JeEnXOe/25Cv1cut zXu1qQk0MAAAbwcfuoF7tVMKNDAAAG8HH7qBe7X9CjQwAABvBx+6gXu1pws0MAAAbwcfuoF7tVEM NDAAAG8HH7qBe7X7DDQwAABvBx+6gf9PrgyEBgbwqYIP3cDgAwMA8B4B+MBQBgA0GIAPDGUAQIMB +MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUA QIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAP DGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0GIAPDGUAQIMB+MBQBgA0 GIAP/H6OpSszQX/Rhet6zPR0siVadU3Kr7RUeisW98hzovj/imTii/tf86WRXRLRJLYrUWWk2CYW 2Gp1sEW0RmG1jZta0iV36QtBYaL2C/dqRhk/K5arFrWKFN0lWQtpd8gsIo7tRQ8WUilETWSI/BAj gtiMEcPtcbCEr7LDiDNWJRlOjKbKqRDuOYmQLT+PkR9d0TKOMlYlKVXMpUK+u8SaqmXK/j02KcQG sUFsEBvEBrFBbBAbxAaxfQSx5VhTlosUzJev/z7pNWdV3MVno5eJTS06mW0t9x/5tZ4bqwjpT4au KGSS5HAdUuHnRe3jElWlnLQDrJdsF723DxFvQB5jAXUVo2D12Xv5K/VAw8DoZzFGJwXqs3jiL3uJ m8Nq5YW8U+E5Flsk8oZtO5wi8vlPWBVPempD7ELjJhxJiRwY/m2ruXFl4OGOJQcnOC/cseT8Wt64 cEUUPf5pxe7GEluzgeNznCZtvT5S5Dp5gHE/3W237PUCKhSPuOUFUrJtX2FOecCEC88Lyzyzna2H RIy45zfxC5c5fgdcHdc61w79/vrhyuFePAGjiX2JbOQFRlLh3BiMKt265sksyjGafIx4OIBsGlZo jxH/m1qB3IsTqTgjwKhmsRtGVqzVGFlkphLdrq0CKlEmrlUsViZaYvTteIzizWTyBqb6w5abdGAU 4IyRYrNQ8F//j0oRpy7ln5cwGvu5d2upP9OlLIBovlDHaPMmMPLVY6pGStYo5Q/VhVEelEnIwwVk gIjWGaalfBZO7RUKhKfb/FVzau6qSv0xEiWxicTCSxjFOfEY8hlSNbJlytpYSZTtOIx+1SEeqT8v gF6K0YWYXRjlpmGkygoUd6+pcu8Smt1VC6pTv9diFKIqyyLuG9C6Qo3kfdlEumcu2V3hT5MZkxjl HOVSh+WXKZanI0ZN+U9JlZVYkCuN7Fm4n9pqhdH8QLHkgcyUOuP7gmpQz+XScj5Z7r6aKEsV0lS6 TFOMLnIVvzu2XCo3tgGjiuUFRC0PI6pafeAMW9g9krMeGCWKN2Ek0SVDGqsZr/6m3XNDV/UZn4RU QCogFZAKSAWkAlIBqYBUQCogFZAKSAWkAlIBqYBUQCogFZAKSAWkAlIBqYBUQCo0KBXJtRN51fkb t6zx9fXNzHFIS9pSVcNk6uxdWzRgfP/LLgtnhn3f/4efrJtzs9NZKaGPH/Mue/9t4ZijP65K+3bN kpEXvNzdDsmObmxw85jFme23Jibsp8RvggLpxUeMjQc86FwaP6uvw5kt8WmbzUKkSYlu73aQk7oZ QpqMHSL8bax7TxJGPSvUL9c3Bu5fdr8GZ31C3y9DZ73F/CDjVX1dXTfxW5QGYr3Q8wY2+aazi/Sp C8tWerOmaZmaFBP5vMo+fkzh9IGzahIkaBfbpvQYLZMdZyO+JhtRkrfdKGun+FBSQd2METRTw42b HfeE1tmLega1zhVPMHtWBld3A/jIwI6QgyoPSqLu2KQSjOaoF64p6iXSsFDduX/Z7R2cUzCaSmVi tIihFRw85bnOBk733PRHxWdHG0QpBFGeN7PionxcRpiQL45LOAXPpeFbVFUiyaF159sW1JqmbVzv QIr6YBTFjhSLZ8hGMCNkJQ3F41gOijHOre0N8ax+41zsS1QPTjSQ5mP1HN1zDVO13339DwAA/y/g k9sXYrI05Emxv29NttRPb0gu6+m19hhP3dEpARMX06PCRy5M0I3aPcF2najEe2nQ4Iup+v0K2o6n fctbNIBR9IiImXvQ/yXlUJvLCfI1yV+ddvvlnaxzDo8KHo/u2akvbKJn59xhbPB1ZWd06JzblZbA mclcM/r4Xp3JO6UzplmZxDi3HNvPDJDIHg+2dkydvv7qj7b6VhEht1Ym9Qwr/Nvc6F/YPXdPB83w /80xmycKDGBOMV8WbW8uxmj0scjoYXEsstwIvrIAfGTgj84c/orbUjhyOi8KdZ6qJ8TgULPDgRdv t36ZSU84ucZ12yGp2/SWjiGyZ9r121dOL5NwKiO3m2bFrBG7EVcdRlr7Bg1tllvXuGc/Db5uIzaR faUIkM1pyB3H0p1XX9PaPnzz0tqJq2JjPZXL/VaYH9jVl9c8balBXEqjnPnQrfC7+Re0XOGrC8DH Bz65fS18lisPBN91Dbo3rOHSvkGPbX39rtyoHJkfdrmRVZVrZ8p5PqVjXyqRXfaibgmrbuel0lxx qoXOyLy4nAwuYzqSXP8He+ceFtO+//FvNyWREmmHQdpdaduErsPu0C6bCJEoabskFd3vs7EpuSSX XJJ2oYgMXXSRFpI5Ekk3GrvRpLuaqdSMZmZ9z+r8fs8+Zz+/vc9vPx5Pzxk+q2f90Wut9V3r/f28 P9V63q1ZPF6BYJLu6eki250tWY9DizboL6hSzzyVotPy4td4t0ZWssuk8MfFxYxBMBiA/0LQJlEd ZEk6qbawPU1ux4hcRZBrI6nm+Cw/BMPHW3w5jCXRjqB1ri+MXZNWNuDj4Dfgszin/fj2OaG0Ru3Q t/RVEd4KOpkYqbImCBJdn3q7FUqInPjSKT2X8k2bbHfoid2dkiIOYxRmks/p3C943GK0bkad15Nj r971bE1Z32AypU01q7tly9y+DS13nW0LbG+EwV+WAP4bQeUgrT9OVEf1cJyJuBIjcTpDfENEdfJn 9/kZdWLHBvaW6ste9rGBN7d71bKSIsU88+gbt0c86hTTWaN785OOZA/UPme1ce6EmYZFFhyIHqdR ryDz4seeUCVC4e7bR7/yGqpud/G9n3eNa8s7okPL1JRfkdvYat/f11fh9prTzbTue9RfYcHMt/As aGB28y7fYAdsFwSrL3ciViWZv9/XomiPkTCKzMKoaBeHMUjzpn7W/jKQTSolZZNH5mD0bHvhKIwe H4t8hFEaRtTmAu86SU4/7/8cJOAJpwdVDM6twMgstZPT+yNtN9FOsBndLtTkeluFkzTiOsGbNJ9D RrOpO7grVqJ/P4lAfFbxte+g7wBHlPArg+3gilE0r9NExBotwChlgLrd61CNwmiv3k6MLv6AUd+5 WXcx+nqRQJtMlOSRzXluA1V1RKNo8AnZUxKJUVtkHlW2fRzizUE2va2KLm45xGSADJABMkAGyAAZ IANkgAyQATJABsgAGSADZIAMkAEyQAbIABkgA2SADJABMj5XGZsIRTLIuyIxxyp+Y15Yn1lde51p +ObjNyxrg2nnzZxeVzo9GbWw+ptFXL7kxAgVbadbm40jH1vu69ZlWrMCdTOv1UsMFtoUFme6x6TF x3o+jQy7Tyt2eM08E9WqWURsIXgD7PYW+aKAeQMv2DFR8Zk1+0Ky7Jhu1cpq9p6mmba2xOv9tRr9 fxoSb6SlYLQOo7vhAte2Xoye0jAqC6ZWHhHYTcAbyQEA+JQA3kgONgAgxQDeSA42ACDFAN5IDjYA IMUA3kgONgAgxQDeSA42ACDFAN5IDjYAIMUA3kgONgAgxWC4GxhyYAAAPiGAHBhsAECKAeTAYAMA UgwgBwYbAJBiADkw2ACAFAPIgcEGAKQYQA4MNgAgxQByYLABACkGkAODDQBIMYAcGGwAQIoB5MBg AwBSDCAHBhsAkGIAOTDYAIAUA8iBwQYApBhADgw2ACDFAHJgsAEAKQaQA4MNAEgxgBwYbABAigHk wGADAFIMIAcGGwCQYgA5MNgAgBQDyIHBBgCkGEAODDYAIMUAcmCwAQApBpADgw0ASDGAHBhsAECK AeTAYAMAUgwgBwYbAJBiADkw2ACAFAPIgcEGAKQYQA4MNgAgxQByYLABACkGUpEDt066oKVz8kaK tvG5Rbes59V4YXTk7kszedryxFOW39ebV63QGYgNtL9TQY4LJyw0Q3ye3dvXvLWytKQ4b1Zw6KLD pzOyTR09Lr7+4Owf/3zp6rM56nONFhy5pJQSk78yPPyRC0abmL7ztQ9VFqQebD6+0FLdk2thZcTd eupyxCAvfRpGEa2GfsE674oumkzb+Iy9Zn/S2ZM+x64cq2ezRu5KexwbbXDFwMP+RdqpdjOMFj4M 0pQ0tzzFqHJxIkadvByCb8mhvquht8pglJk0iv5WIE7B6OeBPrKFmiq2qitGv2y2GEX29m3FqC2V OrRfwCHehBIYXcxgPJPDyMVcIL6A0Uk6/0ID43U9TeTeyXmvYuvOaHDdyZFoOBNksUggVp2P0ftA hw/3GJ3bqDFPcHqjyXHsClGiDUY7rcLJPTHvTERPnlJXlXqI2rWOE4XRnhaMyKNXMVqgKtnZyekN J1dg9CA8FCP/7YyuaCbj+ezJ+zEKDc1mvF9JXd6giMf5vZ5w0oFRRhM6+NK7vVUlN/t5gyN0bhI8 k3m+ZKwxtaNbpIhUpM45aJ4ufkPvz2YyHvM+UFc0sqtV8pSah9tT7v7BrBGMe30MjGxXY3Rekbwd yPtghZE+o9GqCKOCHPpASR3RNvHoA4yKil4Rg/rZDEmkgCec4ktNYEdy308Y1T6jhtUjmlXFennJ gnnR5MswgURO7aWb4HQiJX7xBGpXZrEEIznqpJLJq8hdtMFXdQTUBmoDtYHaQG2gNlAbqA3UBmoD tYHaQG2gNlAbqA3UBmoDtYHaQG2gNlAbqA3UBmoDtYHaQG2gNlCbz6s21jQVRkIa44Pf84Ex8y3q hVHVPq8y2IHVL7jzknxqNhi+a+uclmBWm1WYV77NTMFwdVrSCEH1TINwr6534v2TO5YF5Lk5Vd58 sX+u0D060dTrWrN94DMHIo7j4il66zMpOzzXT8xWahby4n/OswtsivRw+cbQcWLA9kH/9QdqruxK W15XYHOD8ef/v7ORRs3GOozuhgtc23oxekrDqCyYWnlEYDfxcU9sczFKId5kkv0UvPYVm9Oz6T5G 9claGOXbUSg9Dv51CsDnAALWWVM/U+4lZWJk/C2nP0uV2j7hPx9l28aopfNcqS6xJPpsMepNotY7 Q93zcQ9XQ68B+CLAp+21j3oOGnoNwBcBPm2vfdQjy9BrAL4I8Gl77aOeLoZeA/BFgE/bax/1IDD0 GoAvAnzaXvuoZ3ah1wB8EeDT9tpHPV4LvQbgiwCfttcgXwMA4M8A5GsAAAwPgHwNAIDhAZCvAQAw PADyNQAAhgdAvgYAwPAAyNcAABgeAPkaAADDAyBfAwBgeADkawAADA+AfA0AgOEBkK8BADA8API1 AACGB0C+BgDA8ADI1wAAGB4A+RoAAMMDPnW+ZpvvbOvhM9Z50W2jvQvpPdv/2W9pORitJnpXDB2d mz54GaPj0UMdl0mvMRGftKJO0OVJXmW8TRkaxMuhfylGukMXEr6ekeH2QX+oKeurJI4YPbYZuoja 5I7TpP2UoTbtPqddTVwmcuhDLX3d35dRuk8Rox0R28hGPYpcsIKKA/gcQOWmD6oYyQbliW8+YdT+ 3YrqXJf/eND/80muNQ3JuxmlXCa5JViUTlqbCIsY9wIx2sN4bytakkyN8S2j7cTQmMR7OxHVf5zB GZKh0SXqUUO/L8mD9KHzYPS35KFGxijVYegiMKrUG+rhoXOf1SVZ7SSLwja6NLE81fQ/cfhfqQqp /pShP1UVjsJoHkbVjBw2tYujFZQbwOcAPnWjvvplyWT+7GiEnH7Y4HIwqFxd01g309hmUSjGL/Eb NNZ+id0SJCMjgzZRXwizkc3Qd391kf3XIvfbMjTI7/aR+fetf3HB95CaEtoi6yAnMx3JqsnIqcng h4iGkIzC/wyL/neRkZWTVxihqDRSeRS1Q+5YJCsjJycrL6egIC9PbY2ktiN5NQX1abMXjRi30l1x +m6Nb/fEpyjpfHfr/njHSv6MOZv99o5UnqA5Uesr3a/19A0M55rOm7/AzNzmb4uX2H5vZ79q9Rqn teuc13v8uGXrtu2eO/wDAoOCQ0LD9v28/0B0zMHY4ydOnko4febsudSLly6npV+5mpGVnZN7Oy+/ oPBBycPSR6y/Py57UVVdU1v38lV9I7fpbXNLa1t7R09v3/v+AYHww+CQLhkk99uE/aEuNUqXrLy8 nLzikC4Z2eChHdTkFabNHqG+aKWi++5x07/do6TxXXzKrfsjdeY48sdv9qtUnjBjbqNuz5C0fyr7 a8L2fpSy34T9S1c9UpGToYonp4boiBzUT41Fv1+Lwrl0Fm8vTfG6SaBJbLJmsbbYMruqUVOTSd1A aQkZixImHpSZ7X3F7X6wTlm5bIZO9q0He5f5c3eHbBiv56J1MN0+VrTqpAeteJlOnsmTOZPY4x3k Tm0y4u7ODjpivrrZ0c/7la6Sgd3tX3NcLpQsjpocEYTRXgn5gKN88W6WMPJqSFVTa0zmrCPHsvm0 6O4A3zHqsV26JcK80p72CWsnfN+mYbdlNN/v3hV2ArMkrt6IHKMmuUka3Lh8Uaz9wlJbZCnc2jtH ZX7hTEL8NWPs5sMbTvepxkYs3nnO9FJV/RWbAe+vDcbp7UyJMfrwKJgrkH/bsSL9TNFW3cjz5q2u bkU+czMbqnwzz0o2NrKe+7drcY3b1sTJP9Et2+bFnWNnOd2uf12wlodu2lXWGGo2zm4gq6ynipcL A/npJXUXjIWJTcyRQrkS88CiuuAwzmFTyfySwZ1jXfTOGkVeW1V4++h3V1TLLp89+s2YhcxSRr0F OWak5GiUunVKasTUrB63LjXuoXW8aQc6S5xYDzBS5Vbr/Ky9nWnpwjUKydW+45y2S6U+KDFy4poZ 8+1JY1JPvEl4tefawxPCPC7vIV0r4vse3fJs+/q8w+LFGZ2C3TO6ZySM0rlSMTfIaf9NJyUn/Ytr 1qxWzm0NFNYymvLUPELbfwwxXGc4q30ZOcDM8LM/V/hruJlzl16dRJHPGvAI8Y+/Ps+idIrRo21n mrcZW2tZTlCXeBgsWVW6ZumlprUqnHUB9Iy4V2vJMSrCgz3aAzf5xXtE3wmDGwUlya86H7VjpHRY TejDWn1BcK9Yt3pb9jK50nqMDvK6u2f1zzRgNoUvfT6zq+tNXqGm9sK8zRjV/uBnO3dHW1lbx/Xj RooKG0bY2jraRCtOParE7D3KfHeHVIrGSMH2ubW+UHOhJL6YHvLASPVQw8icOHvhUm7cuB1qpbSH vBHOpVklD1pXFfQmuGmHLK+drbLyh5bIpQ6rQ8qPl5hZt/5M6m3u3Do+a4pB+eWVXL2nS3Kdd2RY 6Nk9brto4Xqu0qDBUNyztI+Wrve8YkbjM60nRcv5Lvs99j/xK1M+6rGnZImj5KFPY9xhl1N2ZUmv Z/v5OAZ8MCorS/Ik2g1j9Znt+8SHlPVTfxrW9XKov6+7Z2B4oOF9L0/5vLWaY75fl9nF9Uw79XdW WcylZPe1Xk1MNkbc3Ir7Ji+zB84IT7nPmL3jAo2atmuR6ktPj9QIE8Rcr9j/fgIq9A2oNT3jvHrS LW3/E65RXkcPrE3Yapbk0NjI7zck7Hf5M+K7+cWLY7lHdRsbtO5da/KfFKgyk95Td015BXUvlxbH Pc0lxBN0BgZqi/XFdjViOdEPIU0L+bOuNnE0O6xHPX8XwFTKTDvUqM0Z2zFO6Guf68IcbRc0tSpn 24EZ31rY3Z5dlPDYUk9sVUcqUzextm49clTRG0Zj1LKZWLCd+WZkD23s6pPpxjzNcravoMbUd21O ZgFGK/PpsmLN++7f5JtHjeO/vvoifaKeZbaCgalG6vlLba6OQXdO1Nx1TW8T/OHIccJwplgjmjxK cBXJUUXaGJWXRu2qXEXe3MZ5b/GI8aYjWRxfhdFYh/vMwbnnZ2N0oIj6i0Cfbks0dhN8R9qgOUYx NOEsvi9Gc8Y7dpLKNdTgXxUdZs3v8ugxNN2iMy9e6Ppgw2QOa8svNtOTE69s8urLinWgV6zPyb7u 4hqYwei1idvbMGbRVZsHPlqOG7OKlDF6rVhVbCK5zdhJm1Kxm36I2GESt55V71ye0Ct26sksTp4a MWJxlXHgNe95E29fGK8zsi+Aea5fWyRxGuhcWc3zyZ1p37utoIionpV2p+hO/tls3dKnNdXHKyxf 3Gw+k7Aj007Db+n0xep2xn12zSUq7hc8dYOUY2PuHAyambsmdEdfx9pM16gXdz2Xp3Z+zRaxJQ65 ZVkq0VNT2388O0tV4bva5pQlSRNf7cxcPtvJ7aectW1177owkk+SFGLkuXuyYB+p5OU6ml9eEias 4FYk8ptKWCPGq3r53liP0QOb6w875/XoHkgOnKLRl69AL8YoO12sHc5nlIweky1aHrGxh1Y6c6E6 hx8TYbHXTTZkuVXlozSjrrDGflWNjpRJZhyfgCwbldjB8uifFuTFfNBLeFsTdR2j5q7F79rZheff XSLul4vj7lsuH3QRKjSaM6O51lYlm/3PBbutupd7+GGfUfiJIxPaKxPubDasdLhIP2Y1qqRecLDf a5lqifkUJnem/4pjpVtS28wDu5kZnAVHLrG90l4usqopSf0He38CD+Xb/g/jlyQhyb6bCsle9i1T CSEpQohJki0kCRmm7LsiZK+QbE32rIOxVJKdjCwziuwz1itmeYY7v9/v63t/Xvfn/v2e5/k//9fr nl6O93We13Ge13ke53EeyzXXXO1rvaoHsPl0BtSRO7PwWrIj2ZN912cbTuJjU/C0Tcn3RkYR7nDz mvgOq6RB3PC7Y/7Qxkf6Y2Ba19aT1/3CfQ+XVOGBFaQSODPpOQVwgAwjDfkcGseDbPaD90vPMdeP ZWNJjD0aWgXa+50OOVwnSH/+DgaZJTsfqujsz43VQ76WXK8La9Q4o6n/XS9dP6em92W1XcDXoiGF 5Pg8eozu7wEcYuEcrqh9joeFQUWYJQmb6qxS57fZJgyrOKSozMeRU3stPzJqjv13Xi9qYgT5xBLW NM7vuBnXJssPlk2GlmATo5oaFDO/Dp3FywbXmTtGeQg2+yh9NijWMutVVP/WWt9Y1y/2TPp6+bkT NF3L5whi2K64gAPwSwRztJGQEzeZDQzCT7d4WwrVvpHX4K6xKcn9HphslnyllNd1kUPXw8GLliOV Pvaa6HXqHjJ5RPaDTlRD8YbDUEdkWEJAf9ZBBYYlTSWiZLeghi2WxNf4fRbCrikwE/xd/73VWe3W oUg4J0MSrvv4pzOjKUnDpj+sbuZFaLL/fHEjMtOh2YfFwZyBe0FcTFytvMqz7nvOrJY5qv7A4LvT Ue2/wlYnJxnHRHE+Ru2aUpnqx3GM3TGHTO0vszbiMFfyDlveC1G7fknn+TQnT1+ueXxVNa95GvkW nJO6izWo8clj+JluKeJpLAJThquzlEmPEcyoLCkYBt/hMHIWgzxeLFzfXFLzEnj9C3mzbh2luQdw DlEA9ChiIge6Sk3Bj0Dx1hPj5DuSK6GRZO9Qv4zeYKfer6evBg5LVLAZlOrrbnaG4z2bpewffShy CElXNuc0vmySvvyFI1f8zI1c8SuulWuulSP/3NpwIP7pdWpRIZn7+jVPwg1Bb3yXrty7fAJ7uxA7 /nJmT7ObjXoXx9wgn2Bdh/sH3roU2SDXj/SCBZNZDsvOp7+WxBoOi1pm1y4QBFRQ9HC2RqyHyndY iIasEZNOep6qBpLWsZkp1RjxYVhbicSyiiAFebFEPhqa993S8ImbdAj3QnHCrxLc0f7cbQGyg3Xa gul8ra1L0VwwNssmX1cHJzvXuxi35IKREalbIiefAcPwkt/yZCbxLUOQAqw7k1KIsv74rLbUrCcN x8FJXGzUy5matrh1o4WT5czKukOKqCMaOotjU4ohuRVlgefZH8oAXxmQA9a02mX4saDXPg+bLjzk O/zsjePgaaxOh6HcZyammxz3Xtk+8RFgJP6gLiU1iGhSl0G5+2WFFELbouJC1XTRKhrX7Hpf4dXA EsUYg1bZVxFevHcQnD4+loqJlaHPjs8nH9dVT6amdGflokUvoSQ6Tik663s5Ymf6nqfdv38vMCrB 3WzE3HV2LI9Y7XHZVReKczvede+bxPW7SsqQcCTjNSyPSS7fgIOxwkyzuM6RwPhoW47nt+L1RBDi FAC/0jUyTY5F4GRJG68Qy6lxoO/0wgrVQUEJ3OStbtRvQ9grVAU9kRWiRUptAIhXwWnE1iVrMBQS ZsPvf0dwP1EiSJ9vMNvDzyHXydLKGYZ/r8jyvpic91aL9ek58bPDB9sjiTTIs3ijOgR2OquqiyRA AVpgW0vnqeZSEbL38g1RVBk9ospIIo9UTeb2QeNCNlrn4kI2EWEanrKBD+auEw9mSvJ9X08VSih2 5o56QJbA4ysNbIu1hBrj7avY0DxIFBQnaAglx7ZRZ3GoH0JcOUm7RAGGhya9W1noqT2LL0GdWKKF oENwC4IELBjCESDainP1mw/9LStzgsCBYJGSjpe8KB0tLWB5L1jhtkYC231+TmIddUN1Qd2zNlWp yo/aGAuhptPO5CjoxLsqjPKO6+nu1qR35B53qBp4R2Ylcnf3clhZIMthdFYjLhsJ/A98NT7kleDV Itqm+PMYry9Og7iXLH9LJCgthL0ReGw5oAdaNo1mianZaB9Z2gcjXuzOJQgEcFWAHgdQXGlvDPPH R351kYplo1cf1vrr6gfyv6GuYvSxNMfRKo9NFvKxwR7orzkvGFGBK4tIcKSd7QKP57W6Y8Qm25uN olBcmhpEE4JRi5Ue0S8XFGsyIx/z12jKlQ1dvbjmzjp+vTgxJk15PX3sZHlESgdwF/9ScLiNulTD 5EEKwIG6swQQWfFU4cLCLVHoJQGfyTYhkUFFQa1zW6z9Yvi8kAeOUotS08qVVS6CGYNInIsDzxXr 4g8qxpKr5uvSpMRV2LeRCbGwBvpfZNGsNsNcFyHhoQoY542Z0788XR7lhXtZLF1ayGn1LxBNHXbC jfXQY0RkkrARdJVxU1pkph6CDIQ74FsqyxPpE+ZVoBG+EF2jveq81UL19ZFLXhBuG3vP8OHVMwaG H+eWVzCPNZUoQFhmwDh01ZMCsCKW6pkowPMBEpL86SpRy2g4bcKrvTWOddZGCnxWQFTGt6Empb3N T2XozN0giAZbkgbqP1WFHjRwysKc7+bU5r8JsSQDAfREtRqwnpCGNW8e0faEtkDDA1jwHrdVHF8T DtfbvbnxPVRjf0VVtS+DBt15FxJEqmihfE7dUPOrSGBv8+DY1979PBeli19fPxpBbx8rwngmBLBE Pke4waL5kI2wYeHJ6VbrfaszDSL4LvSCMYRpVv+WnNOYOIEjaYwHP5bNdgl5KGFmc6xs/8foonc9 j8/tj9ysQR1GTNRTALYpfN58BBYGWBr9NCIY4Roi7BFH/N/40zbzueXiXCowLF/zkVYzwdOPPcY5 aIhLiP+u5tD/rqVwQVj39Dx1h+0XhsVAaQO44FYE+gW6fBBiCiZM1LO3xftc1eS1mp3LHgZDB7yk Zb7PGoMjl+JncnoXjz2LsmozTX+n8gkg9v/TlVChahJfwwm4HziwpeRThUO2Z4VnHgNDEDiWiM3K ZxNzWUcUU/ygzKCLbk+xm2Xf/MOkcOEaAl0nTlNLcHANv0HUKn6N6BmcRYGO0tDfuKG5LjTyEJza beDdgFauTd0I4jUvBB3xID4vfC3GriXeqdsxeUx8QNHa79oQ22CXPvcQ4U0JjtnTKrb5K7vHMd+c GAPPRnqvLTPyNwgdyi4rrNRnA7dYRzD0W09DMPjIX7zurmE7aW02dmohz5HvdsL5wJPe+R9qP8Tz q5var4iY+fSgkiAYqp/x2rKCW/WvSUJCuDe9GyG0n3u17G2xfn7SLm2elr/jeaYGNJyKrhtocJfq dCS8GfkmYQeU/I6bRi2Ybl0m6pCKyXI+ybiNFqvflpMmH+K70EICob4iPURurLpvrho0VOF62m0n V3umxdQrBRveRqItKb58NahvHesqYMqWM9EyDJv3WGhct3d15MIg3HMy5jLGJYa7KVNwJYnG1+OQ LPssXzGxpdXu1rt4a32epFiR1OuNKmes1otJeWsjn2TX4jDyk5mvvKVihA09CLD2yyPfFkU5XF6r PGdvvAIIAHRUw92MAE+2L9Ti40wrqvFxCywEsevamYoUIBjRztfZ1eLKtuLBtG6SA3ZseRxb0RtJ cz9xIysR7QnrDQuDTgRllVxOxs4Zytv0B8j6pN0wcJxsIMiDnzsuJuFWbrJ/H55RCwghZdjT6iUI GEt3HJ9QiD1nZ7D+gLquJ+B8IMOWfhMhngK0PcprQe3z0Zd0tcPmPdGwzf1W+Srbp1c9hW/cnKCT ay/YkIwzQBw+LrLpY2Bgst5cejHr1y97gKRIStKwIyBx9I3uYTbypJdE3lcgLS4rvFzFy9CvefPQ BpIuWlk4IOXMQgYFSNOMKIR948icNpK/wS8uclohpCcxQJ9Ui5p4C6ND3SrXZDUwB7MIpcsdC2aw ww+sdSQlXQ/w4hxK+uu83v1WdnqJ+Z6uoFTSeobUbBt8tWVO8SEEb+w+ot+1LkXKkiWa5yhmDLW6 C3y/4WOA1Unw5vt+VrG9YqUCwuHMVdvzpocoerMZ2/S5w0u0nCXkRSkFYMgUI+iGw11w0u6tY9KD FRBWMKslNXeqAjlXU/99CJOJLJiVV2xdIK19//kzc2rK+9b1zLxYlZcsPYiYcby50UjCpPYCPgzX Od6cdfh7573BBl5Qz62BxUDS90XwYzCV6wMhY0Sbi6O8JsJM9WZUOstTyPpLUm5ujTJySwvu4VK6 1dkBv07ApgV41n5RI8+TFTeyiOxWZIYQHMvInaWrBAoQW5Fh1ZhFQ5QvUHrmXTRj1p3FCo7bBJ4U q+vWEJN5xTGoZIaBK7OmdepcdLOLGLWNVRWR40GYo5wh4LGq+fHXRGbwCS7rCaaqxZ8epxtYJ1oM FmqFwQiiyPByI3ZD7Kjc9LWsc/3zP3ulxSrTLEIHXofixhyTGIatn3XLHWFpjxueJDPObTkQ6QdW lxbcw6l5R9wBLQ1dE7x7q1U1XEvx5+tFC+E+ov2DBLBWtwbT3uHhqVjzwRh/8WUQKTjgM7SCHt2F WZnoCmuQg6vEU3etYV4f/By2/vz124NwCC5D4+iAhmrhb5WYqaoVuyTe5xLWlp0cnzk0e8jeiiRq vt+EgnB7WbNPolq7Aj2NhEHv9iwW9nalwS8j2ZUE6BOvDOhlvZtaLa6I1z5vJi7pyq5fL9s4AECL +cgqUGqwDYqPLyg7bFnD7+CnG1ExY1J4KBpKCyaQj0hz63anGSiZOGuyVIZpETTfCk0aZOodzsWl GbSbjTWiywRoYANhC2IE56EJ3UbZaAiPzI9YearDxlKACA2tvKJPU9qe76yc+nSxI1yXHk9fHfpZ WQU8ZXh+B/U1waQfWZFhcHVQ0aoaWXHGcnPJpN/d4dbKGGz8xpnO0e+Lvk7vZEQdPEdfpAJbcWQh 3y04BejpImpTgIZVWbKJ+RoFoPqJITB5Mi4aWqLc2BWOYtPQfetT1dZwvE/DbHMjvEKLFjbr6UTW JJglu0o3VQZiBLu/XW89ggn6Ge0gJkIBaNZI/YgmiOgKaiIjq6zPdaQUEo6fWNM0akUKate+bFtI aXcGcqnZki0JuWY0LLl+u7YGr1T5wChqnMPrGt4BXfvNLtKlk08l2HxMimBaZ85qcIDErnOcxzqx rnZk7g6mkRX2GUnUWFn/TQGys0BqFOr/C0Z8g7SimpZ6cj/zli55SFOst9xQ+x1ZiMjGjWAiCguY G2hm+eXPmC9XxdTp3RU+8b0BiRN1eZBiETz4kKszHaD/mQEgzqPwehRgRH69nvQSeneJDuTHebe7 84N9jZVkDsJGuNf4YeeYXEE1otMYX215n+H0cPmHE8sLFRnnMdcwc1stN37chswdRj1bApU7mlmd YeXJbUZ8HTyeWKOgiGyr00D4uzorHOkw7JTAvneuGopyLOvXh9bQZ+kCbKn6dpUCTLzkQxLZRyYo wGPNY6B3o6VsC+yIzxzukg1T2LmhipHRA1/7LoWhLder810YPPKGbb7f6HL3zsM0lixoH/9Rcvct /eoyKnYcVIXh0mazeFEOcUFmNUVxrhNLYZnHCOvFObqSB4/217njOHrKRwo/fmQ989mJfOi5blaK cEr479u/UVCCumbrvSX6OzzzdN5Gp57P9OWJuuTru6TM+ZsqqjuulZBOr57Ht4sR3Nu/HsIKiXSY yYbytZi39rp5RP/qRvenRudevpp+rdDvpI1c1EZxQCwFIF7oIniTY+yw7WQBCDtiORaV7z7c106W BZF4MaxYCwUQAi2HmoSkwbAJFmafIQt8aJaXh787dqbO8M25ohEnmFPtxXcOqV8/L4o+L81nWwRo WhEpyGbZsM2wVkRkFrMmj9Otc2/h2oSlYA2WO+t4pohj1QTz8AckNvF4gdeljRvYWKNRanR5lcR9 saz7gavY+b7HUUY9D0aYT3zVoGNwyrPUdnLloQXoQjkFHplPk5mmiUYtPl9W2DPurJXwqHHkt51O LO4yNhy1lLzelma1IG32lpxOeklmA2UnptjRNxLQNozonyljdubcMFYV05b+rPev+BRmmgrWZlt1 cvX7vK8a10v31vhxXNVGnIVMXTdfnt66QV3vZkxXUxeGCSfb3PWEAhyE0xJkG8n7BsbRDJP+iBY+ UlHD0aHV99JEA6W0A/FRdxX8pG3vVDxZXlCpkssfOT65Kklmkt7yFKMm06fGQURTzedh4j1wUqhw AhlWMvIlIh/01lWKzJQjrF61zwn/peaPs8Jc1OG+Wv8k1ky5HS/qau//9kx3WXkdSmlwiHtIZ3DM JZsu8a2sl9+DY2w80q7di89GfmpvdcK+jsmCUS/sVUO5wz74QSRUCvQu11+0SlGVvZ+I6RuFryx1 MpvmxK0p/+Jf1ccasYKIMwSD1gahWOWQOeXQjvdr9mbpEvrpQ4OnY/oyVFWaPTbrZX1bP91Sff39 aNesMBZJFPAjRLVBWOG0WEG/dV/QJMcxQJyADIGrF81WUh3l3eRHbonvXCrV7uS+xbSqHvl0JjG3 Jb4NGSIVpOEAGTp17PHRH0LnOMlXPQxE2Fo1LvV07I/wYAK0pLpP2R+N/lF4eICcBz3ktUpwQLuH NUjEXpXzSWgS4hganDjSoTbHxxn6WoRe9XdDX2bGHLLpstTXlU3iueCvKxIvIkxCePumnT4U9scY WEjz/9iKo18PBZmxqGCm5roOtA1nduIEYQliwM7nWayo2rOZ8/ZTzYCExXJ/QTG/Deb7kuSyH5kx m2roIAPUrZ1BZgENi31cGm0EwRgk0ZAgG17e89pl7Fh9t3GHNn4s0cEbUTCSofl1GTeRu57vwmR/ /mSy6le6gPdDBHkKQC8IN6omKC8g8OPY4PvCTllMAYedhnJNU3INvds3FwsLnF9f+35VPtsRY2HK WKTDoCIJc8chj+BAz+DTKnUotl9TnC7GuZedh6LuTye+Sx1MP1HZu/ELoeF/iCjxse4mYSkUtIss /TipYhzLzxnZ2nM/nVP/wdvPHH2Jqs1O/ndyD/y+nfGusnsdCkZk4ZZIfO3oOKKK5glqfiEIIbBD W8c3FePCIOA9uCE1C1Ej+yMcWB43nCa91VQingGZ8Ztz2u8JiJYMG1d+XRRBtHPtTcTNwUf260hf v4IbTklqxasPB2sC0iS5YsfMf+t2pE+uP9wiM6NIla53F92kyKIBnZsxn3WW0bbckeSjTdI/IuWe imxkHZqoiNV1U774i2G20QP2ddiczacq82px+OfTIFGb7/7PhLyDn8Qt13vVR15DBwI08EbrCB/b 1In70CMqCNHPZXcN6SwzJMAvbXKJYqompgot5dldDG3LLtcbwjdI/OTDTuDj5HUKgH9K/jTGXNMH H9jSd6Rm0Iq1/ONiwp2n9PywgjqjuSMbWm/paocWvefFqWsNJaUj3A38dS+C/r6FoDwuNuzm5rta fF5b4NeRlpKZqzeki1LHgnztFdsSca5c4neiDUTLfg+2Xdu6cCrZenz6N6Fqor0FMjyJq4rRPAS/ 1tP2ZHIJmJ3WIRzI4BxteHVX1M/HvUj27lKxkJVLp/K13kVsdVWibzzD0/cmH1iukSLrEJMUIDSr PAs9zk2Ur+u/W2eb1zrJ5K+62jFc5JDJtLTfJ/4rmVbByqB9XTXnaf7nn55DnG8McBSA50dKtI1X VKYkLQOmgu9p5Nv4h8lS1XYnO10cPy2PWuo9WCGabdL7C4FodHq7Oh4lGWqUIbW/5LqUDTVpr+Sq WbcZTK6IeTQw08FiqURakNHTkTPlyOX8JLvai4xEuKOG1Y1JlVAHyBFyVw2iJQ40xVODXk3OgQoY G6JZiSzB7jTGO5A9xK2nZuySKSSTbJmYUZaszGMktpg+hBmwNEhzTLud0BwTVy1Skt/0kXf/YlM7 J8kv1R7UGJJt/VkdLPDedAKrkHtyTNarkysH+aOHzI2vYnO4AWnxFePEj4le7VqeN9TQEcrOY2z4 WiEu3pdVVsjblywVH28SnP3gXdxPCPlYTBY5jk+WeHqJAnRdjgNDlRCbGo4ofDuKApxRIxeTh50o ADSJAmyQIYTshaSsld/UUA9BDcz4iEvkoxth0NWTyWQOc+quyFtTJhpl9aLJse5ku/sosi30+d7+ oDieYQrwi/CaAqCFqI5ydW6zass+j0imBjJUi94WV2mJ6PqJIlHTbiJV78LPYLtIjKIUIISTAvx2 RLT8JklBf01RgCllSSph/32lnAIE2U2w0fpv3bp0c4KzEhTiMj7lGZaASwveTHRetZYkM6eD6ozt pKqtK3CDelvyB6eAA/i2pGhv+2jY3f6KIK75jXFYnwDmTZorJE0z2/7QWUimS4fPU4+EJG9THpiJ jR8S7g6exjpOJVD9NrcmD+gr3f0Juj4eB5fMLbpYmOSrOVrQVHLNa/60RT++rJnIZ9Ly82kgmSxR Zz5pfRRm6J475SWqy4DTlMsZS3qVbD8L+22wLydAjahOHbov4iaSwUoCbIZRQzqOpf2BeicIsrGT 3dI6hyc5lBroeuGnJc7zZ2X6QsSSZmA5KDqELXSYdt3byjeAhdyFOEQUy8e0uwoEiCJYziHBioY2 7k+JRCscdAHBWpbzuNrOK+GEVb4IaNQKASWniey1WLWLNagFWWq0xWkj0uWmsBR6xQXCliffUm2/ BQsqJ5nrheicrrEKjtNwGFqumowjCmTjh/TirvUhHBCPAyQIMUTP+oY0HCKSrz45eJXXlqapnx2N OZQ6VevLCucItUrjtZD/kA3kxfsmB8GPk3Ih80vFWu4OnBEFWW6OBbHSIzZO2q4P42zCDvqrw/2i mu3eEmJlT75bJNdaVtLu63NSvY8TC0VflvQ7z/YQJWVBOmv+GUXVE1fEsPn67ZLqGnCUgG60YaoP 7F1fhBzqKEIXgB1XDDVFfXF9cMFsZt2W5D4y4aqpdLjDPTlJ0IX0kuqF3lOAKtTCEZnVBbtJ6Wk0 4pCNZX1Ge3DAYctP+C3DTIYTK9ZuXn7qaVnc1r/DL7id6B87EU2HoVVa+tJR2FF8fpGqbleqP9TX 12a6pNWOFKa8o37yPEU2uM3ZFRK+G2nkRsmXyfOBxI32/ur8e1N6MyZHyJbGb8hTs8XKcVqbUDRs 2DMNJ3jIPcrmaC/auKeDKencwNshh6gWHQ6s6FAys6VsTtxc4XocVR/i4fTZHb6vAzoQdBXu/F/z FU75LOHqsfiGJwJLd/nGZtFNm8IwF0xxnfdhreKBqaRpWwDeGNd2xp3MBN3yB7Mn6Z9oSrlQDRvy dQleNvLBaMA4Nizk7gJcFD9uXl4ufTgXS/LW7bsZ738fbdEnc+LJ+NX49et1XXIn9NiUYJ8LJAlf JluEZLuc295ANd694hXjMUkuDXQa1bSE55cP9CUrJHtuUSP1gHCobtbh95zvfXXDeKTMThTzGueH t8u+uyXG29r8MCPAsWc6yiMe3Rxt6a5FUkPYwzAm2I0Fd7xsI0owgN+au5sIe1PorHahT3g2gIOg +PSIT1hz6uc2C5OrPYpHCVxbZS1st7/cPwbVHfpNzc6axFATOd6o97qt9VqGhBpnTNf8b4Ia7vMI 7kRUnnttv8bpgkbNrhyiFp6cvnwQKVv+8bajF5Pjev1COA1Tx/6DiJqlYFQ5S5NRLJmnDw7DB+Hi AgOOggjTCqtaPxTz3CB3QktIipC0lqFFskmv28IPLYGn39GHei5GC9IeMl8zCrM5etOnShzd13Yr vw/H6KRTrNR/A2Npmsdd51B7FRT1qXAzlyVwz5is3sIZAR/mTsfSSrfe0lBs7fc6xfNV7zJrnjKi YOhtwtWWK95hDbi5czrl5vUn0Su669XU9O14QDuqQjm8AiI4Y/ZouhEZXtO6NLJWj8BGP7qtxhIu k6scb23tEsDQL23fPXKl4UOdXKfnnbvvTiTSXuxK6poa2CDyCzoPyQvKrqNrIhvjXbEoUFyw9YdT VqLbiSoww91dnu6MmUoTeQY5i/ov5lvzf7Xs74ra0UI0nacVT/ukx6a7dI7WeEn0GtZb/cgzPlX7 qKrj4YbDs2aIAQXIQdLa89wIC6u70lZUEMzhhGbVZYq+F1kafcyEOwxpfCpST4cRXhLz3NhMd/kZ BTjS1kUBdGO4yTwbFGA6D3aW/BmCdych54e3tIki4NJbcu/M5Ih7SKZEWGsEVha8lndWrX4hMeO7 5X0KcBfaInj7un+ycap4B5OT3DEMIHaPHNPwv447r1VD7oe2xCXdsdMf/LP3B56Pp9cwl+FvhrG8 ByN5Inm11vuncvmH3g3g+swvZxvCsg0Vq+enYYbjuQcQCVPVQq44rfxEu3sD99ZelxIrD18rPNeX L+Rzc1JF9byh+Pmrz919PimkZkaeRPax/OgjiJGZOghy7vQB7XzQJ65ijosBUkQT/FiEH9+n959e +tgMXSHELF478jXIsvfBT+G8ri4UoRbW3UUUECfIGJpMyjYig7ttlsrw7uh6h7aNwdOVFyzzYhU3 eo+5JNILPXIaO6QTLWR6QuQekTrB1MMRb33SrHs0VHPOunm5Isz6HhjKDZvLar4qGGuytd/35JOT m4O20NRjaPUSKJKM9mngD2gc31eMGVhYg/DO1Iy3+JvmaAkky/t02PQrCkr8CqU9VneqkjEMfMax qripdyMOTQEYhn2YGgMY8Urpz3TzQPlmGwF87nOPkxfj+9CYM5nP3EpeYq9oOZ5SZ5x7S/vbm2qg wjRPaHniYMNdEwvlBXd6H8B4iBcHbS3kGl02ahChdSq9F+g/6xKFNzMZfoRO1iMU1zaTqRFi0vYd Cyb69U0w34ndvQT0zQGVsaNRYWMs67phCxUxph49GqgjLhvhZ8lLGlMNAKiO98Nxt3eFk3lBQzzy nDubz1JrH+zcK0fcOtrQILTvQceoM2mqX1E9zVDzK5OhvFGque/tC0xC8vE0AKkXNKVe85dRcNah BiG4dDfKXpK33D3MhgHfHlg+PIIj4vW8nLAZfF26kYsXw9ApFzzHpPNeTPphvxPb80n3qHvSE9Gk XXduy2+caMIOpwYV9q/g8mX46gTzsHY58O1sDSpSbDCg801xeSYHfnOEyU+azeK2h0jY1LlyB0Xi GDW2eYGaeIVa1V7NIqpSgEOo34XIX4VkBtYtIbgu6SmZFhzXB9GvRny8cUZxAcI3XLw3rd+VZM/l u2KLIdp9CsjDLZuhYX5vr+uJJBsiVE2flxZ95qF9dhZSZEr2o3ozZIs9iNyyJ/dqKsdqieYutSLY f23ejf5J7BRuNofhw371hv6gS9bvfnWPHlCiQ/hmCRD9IM2oQArA1XBCT8GMGt8/hisTkNHHk+6/ li0H/dCpsflO/AewX6rMPhbUW7yg+YRcCaqrre6XeYdcyoufXV6fcumoTUkvH+I2lyvv65IUsrS4 c/+LkUgqQNKkyksZrmIUDqsaanZadM2p7msQmiFTE+hHrHoXc7vroN62r29cajwSwRLhFcW1f+0e /SPyj8IdbfIJENBTDkc5LkVVcTkf6yt3PwBX7VnKYPBONm/orzPASV6/Ef02QsH1dA7tu1Xk7PHH jORLqAlq9BLBXAR/CIrhS8e2OivwyugzBq3JSReHDazt2jOPpbakdAv4TuvjvWrfupmp0ghAoYOu CDoI/hoyghaHWPi5dcHl1FjUHDNt6zqZps8C9uDUOTwF0OmrE/Wlq96PTFLMkJj5quIkmFYPBCCi b99mk5OjaRJuOHyYGXFRiIc67sCf+LzQOnWsq+y64fs4Q/xgWM4vvgcuhNAHDHbZ30ZmBh2PwBWP nR8ZOdkoxgnq4vkn6FthGDucYF7zeFAAP4wDHFwxHFD0eTCsaC2m/eTBAh+Nx1trw3wX79SALHeB i6ZnnTjqogteltHAPP+ZNr1kmckjM/Rs+c1BqrLCNMV8Xq9gBSBMqyjAJUCwWyonrE0OLHcZ2qyI zX07e9GCqIj9+V7NsI4rj7ZTdv1VRprOUqcRqCI5SVpPeQUXJKWWW/12xRIkbYjXCKN1MgWyD0Yl Zq2ZmriU+fUSF3IGsvvfWfMftC9/8vukEvk5okkCZb/ET/5EAUpzkx83iIEBXWgEmyIFEARr2zSl +4q9DGUtWfV8Fd9EvJacTVUcWM9S1RTqdr0hoY89FHKZ/x7kC4LIpd5unqm08/CIXeWHxMyOxkGq HZJ5Gt0aUpGZgmUWNm2IkLto6u9nVZdASyvjR7Vzsi5bdtQG0gFdDxEHEHbuh33GlpsHZXnhvqg0 nEwZvCSrEtEsdyjV4YlCvthN3vmJnld+YDc8/0SerLEeEheg4HT7Yrf9Dy9toaJ5Tl2cISIH2Yxg sADpse5od1qn9Rknu4lxGh+t5sGkkrfXAsfP4slZua1sbwEgwpkOeETHYSpodKWy98Go1rU6D8E3 KXbeb61VyUwuJ0WqM6hxJmubIYDggOAtWeKWiQ6kco2rWEPoFeUANpA7D0OU73kZEzYcWg8YGrV7 PzEdDvimofdwnQ1Kl3A5mnU5kliMn3pSAJa1qLGElKvfqR8kGhTNPDoQcydY0sa5pnWVzy3DOQfP 51f7/Ky/4V24FsFrKK7hqM90u3lrw8ikEY9PWmuy34syUl7Lo4EppOodjTLfqrwTDX1UeV0nqleA KVt+AV8x0kTxM6ERuI5xIWuRSL4zFIAFDi0EOy7LBAs2zvEplq60K9CQKgO6IAc0VLc04GygEx7W /LSdK2GChclpU/5LEHO+8wjzGKr468N3cxme1tXVtU8nmFeOADz73DH8LUkBh0F6QlVr8rLIw0x+ 0IDAbfnB6eDwz5lM1kGZz8++oxLLD//A1UeiTkEn3iO4F8hs5GYYp2tLuGJc5H0nCMPqxdSrvIlE kwdDfCt0X3/vt2HtraB90lM5HQmQeQvXHcgH9RzOtC90l7UU/7wOFwSDvB+cVbl4uwY/Gs999CZL +djR6WpkmzM5ATUx5h685IEzwrBMxoxWHu9TcGeGS3W/s1SSlNrsnPQpa2XVPc1/Ienprxo9e3p1 twP3Dn6kH4ThbZZilibchxOaxg+sdp5XUXSPsVEJNLTpOTHioRwIB967YEJvmdRpyUa6KXh8wN4Q RmpM/hbAo0Ir4nh9Es7h88Lmqcb/BuEEMu9Xqmm6VdUNZ76M/odJPcSC1isdJ79/a36nN2E+R0/k Gpp0J0rDRmA38P7pDXeC8FA0nyy60DD6kIlLMmtVJNzkIYe8a6q07g0rBjXIKk2r7xCRDTYxAxZu mVYiPRykB1PwUVjvlriIhMCQYlRFERGqHFonLbBsd9eVO7xOz92Lb83T2e/AS5YvKey3Y9MS19VP rKrqYC5K5dVUyrHkIswgNAhnzu2H7CbChVjAqLyxNFkBZxS+rAFClBf/WTeOzwCzce4tB8tH9UUe Mk6ik1i/z949rMUkTdUU8+VUHRXFVQpAtWnHt9oRZePznVuaMzNn8kIbDszAWBUFr15698wlUwkM ItDChqb6hcY1bzz7Ncab9HlwNFb/44ZKo+dTljTh2C0z1MVbsXNX+yvUK2JV+vW8/Pz9/U5d077x SbG1c6DlMaCsXut9omgOcyIXW+x5Hb9Y4r5uDTvXv7Tqb9a/PFgTm+IpnbFW+KwpfmyKW2fDBJaT hddbGsZBYxAVMjGT7qzDGlmHoA4uXGDfZEfbycpxJzwq462PrO6zHH7BClm26znL2oEipSXV9Dyd AR5g3o1qAjQCrouzau7ywkl7mw/JGLB9cVN0PT95JSMlTjQ6eX/CWUifLpG/CsvOEoaihqFC+mF8 oWX4oWal+6xtD6IgXHOWgZIbIi4Pc2K/cZLEh3DmxCMG6KszkBKHcMWukyJkaXBkUvpc7kho0ogB 1ecErfJwexNEPJ367HpSCtcHHzNSAA1ZUCqslUFTnJr5aFMAx8LWfuk1QfmmR4Mx+CHtLfUWgkXT BIzF6ZFO3i2RuOO6Ya3CV5zkV6RiG1cbKcC5Lo65TUSIhiKOhWP2sl2fhuKr2U3y65mq+9d/rbM7 K9+VO/t5ZIQd9rOJAG0bgrGRReFaYIw/O2YcfpbQFaXh6s2k8sFRBm6OnFVbaNG5eeSLXdLvJ7cA sWXkNCLngP2nJ9jvb+QGvQrM4hfmca+4SP45C7+61gzWLfBRbR5DEXUexjEzN+VqeFT0ct3g9ghX GZuqq005C6UZmZvkWOqUOAN4DQjKZEZ5vMDpc7YTDMSrBGUTmVDrHh8jdGp06q22e+c/koUbSq07 Hxemw78hV4WRkytk5hzQMjWrFYrRnZSeer5AAQ4mB9aJ4je0BkV0WLU9J62dN6yHil0FnrDfkM4L Kqr7zvxJoIABvUJ6MtTtw51EMgkqmMyFILgj0xOWGJ0V4lfKJ68SMb8CTLYu+lSRbm5qm32c6a8/ FHey2dayd6y3IFPJfaCd87IMBei4WWToZ91DPP16TkiEcCDbKfuX5YE0/2IXy9zV5rEOw97VWgtZ 2aV3Dq75HFyV3fJlQpHMrkMrWhSAnp78vQO/gW1L3OIjag7uD5ADix1ccJCoMoyaxqYy+uK722pG ofZJ6jnxX7efCqh4Ee84zP8wxfkz2r53elVGFncJynhbZX6qPh0rZHkP4VZUHuyH2fxU/DJXJmx5 KNCGwyFAEUxBCwndTu9OkquYG6wYhDAZjbWYJxuN9hk9U3o++8HEUDX7dyfVC0QGDPNtLFRvGYHj uJYhbg8fJqOatOYsBiJUYUNHmh27+MxLSk27pzxTRfNTAZglnQ9jkVKprjldInnIZ8to/Rjp6Z00 MgOKGlgDpPd1em8+lo7CpQYCuIniLoWq7A+zcuYyBYYajoOpzd7Vt1N5p0qqenvPcV0ZGdOtTbIk RoFn8HmtFECALA7Sbn/XdxdaDrcj8LfyQYNX+e0+nK9KLcacEx0defmseLVeZjRzaupuwOyYOE/g yyByIEwI4SDLDBehTuMG8Q4pXYPe5Vg3kWFLDH4BP/Ws+lAyX1J2tg/EbMBtzSWEaWXc5dG88Whn 26E+ZUDAfBlxAL8oGe1CQBy5Y9gfIsB1IidXtiqiWD9PLLnme4ET/kOT5RcKQPUamSd+CNHcG3+S yXjPOJbVzjP6XVZZ1I3+++kHZFkk3rnjplr6o8VVO8Cezb6E+1PQr6moXn4yQxguv86eAuwnk+Ir atPiKrogTQjGX2xfeyMssprv6WHPCxl+4bs4dIHx+xon2V2RNI9o2g83hYajJtIRh1dnFg91TnQJ Eq/g686lcwVijDhHfTJ5DrZdOUkQ+6xOO2PT/oQHZdumUqSR9rP4ST4Hqp63N3Urm5c0/SWgbz5h ruHgvSQvjvo39OEzYm8KOPEf3n7uykMxei/l2a0Hojo7yIxOhPOy0dAq1ILepBX/XBRJsUHCRZOj 10301tXyLkAU+USK/Ln2u3/8xTqV4sMqEk3vmW6huucmjVqY1bFGTUuRKPY1qxfz5RQgDMWiYT9p UJt/34ynThm7oGUu1XTOQbWM54pcO209Ilkm7+24C/fGZkOel+JUbv7Yd2e1kB+9GlXc3kNVbNY2 Rh6SbMudHhpfFtvj2xqqZmhebKWrPj9vVZOYU69qa/h7yWTzLlF9/fo9qgjh5pOf37vMgpdk9iVU xo30Zx6vMaoLQIY1oFxhrza7qNI2BSO2oHB+UsnQJPcCC0G4mQIc1lCdkA0ly6Y1W4ZFvG54gCLk hR/Owkb5KBBs88YSP4ShU9/lzE/fOQIoOwhvVhDGiVxhZAb0hOGxNZMtrZlMuXR3LozsY6I8bpx1 dsON2zvp2ZsIlzzMIvPTIXMuQmZnK4JGUwD0IDC1cZk427DhxaLrTPNGvlcktm6EwWWLXSqv2ORc +V6RPsTnGvOd9UaRMmtDmz1CeqAk1PIzgTtEwwQr+YEqRy7QBYZvXSX4v+aHHvlVkxTjJcW4GOMh +C7P1VW+kVd/EaODhSXhqyJ8Nw7am5amZzMFrZtK6menY1WvTT235X9T0MZ3UudT00Jx1zyCryEs gNuHAuC0hRQmNRU7J1OuNhujpYS4GtiOxPDJeP7U93lUYdepVpY+rrgk5mbN8hrlisIoIlziMFlU yTG4v7L2cbgMhuD4XWJYztdXB05f6dNQf/mrxj1k9aAX702mu168q/5cvG5ccoR2D+EC9beHEXeg E0EQvJH7EfhFMJ0CVKBa45i+Y4hi+MsJ7xwpAPOC4ojkC2Fqn11sTso1B7ILZggdou8/4KdDH5zR /3mJfON9l78HX5u31UdzvCSWPq58PGScTUN8stgBO/2kQXLGRrA/aesK6E/ga94wxrtHSkdqmCvx 1WeErGeo3xKTZV3hFU4xzVTltOAnsVADmExUpUOz+4jdekCvBgJfezaq0dPHzIfIOckS8mmdZwi7 WJ1nYWV4ICGP6aDU/GKdoldeh0CN65cr5+OblhU8OjhKdOdBq+f2cJPW5TaH4Wj76BBdG4Ub1gRO mekT400dvH7LeYWpRqM/jDVpZ1BtRKcJ5BNeb1ofp2ZOR7yNMJ2BZGGKTml8o2224ZW8kBhNB6ss Vh2h1lsFAYviH/LVVoLixjjJfll4C/cY5SwO6MRrKES0t0IVWlJH8/YXlOnB+PzW77os+SY+wdiU d26nPh/bOu+Tu0ZnD8glAsTGoU0AzIO9xyeHwrVxxVdTFFDMjpaocEVu69oktPb7D/0y4VK64u53 21MpgAwkYkylFkwjSOK4W/xASyYKEC6kQnCPeTfhpLHCOR5ZsaB1ozqqC/PmKkfVDzdGuoCg1Sdf sgVQYaXBfeuJeZYGVWWRwVZzyIqMuqF4aDLUvopeF9IecMKj85FAfynxXexhZsx3EDM2aEZeDj3c OaJ9xls1ayHDjhxYk0ymt0YQMNBKr7hNxlkYKOhFAdpdlCLJsNL5uPWqb70UIOvq1rNcUlkRotvc mAI0ziHJ6rrrX0uoIYu1AQWgfYcCF+70aCffFmpLJm7GfY+KK5gtfQe5ikq0WpIcv1Ea+11Sv+Pa r9eZUbev2fEU6og/ouP87sNCjYJRkY9Sehp4iVBCVYu0pbAbMhcUbq6ZjpTFuaQwWv0erBFMXC2R ii0uf0/7U+zlR9IzUgZi4nFWJaqN1q4AfiUODSmrClkSTrI4Qcjt9Ylre8WZePMUKIb2vv/bWL+4 1p60nvnr5eL5eyzFibdVv/qaf7PntYdrGwwvn/skOYJLrL5ZMWYoXdFPXIqD2+DRzUSRknREu4Wb Oce7V5bl/uXzyK06Dd/CgYeD/TOds+X9RCUkjOoO6ScdFmhxdHhUEyxkTAVMKy6kOVMVXM5EMh6/ zML+WXRg7aCdtbJ2RfzJtLtVnheirx1KUkEuOKxTBRtIT0aPH3jdtwYN3zQPp4aIMC6MZH3ndAvz eUP15hNTF3tOO024s+g53V7/2JqqssYUcyFwWKpFZnyYhd6Hvwl2eFUSygTSNtvw42FhCr+OV/at Qhh/1bg9ycaccz8SyoMt6V1YcM1mbXm8r4CFGhq3PgVZMicFJB2GQ6QEBSEiUD/znuECjzWTrFfk AJ+0LSMf9pOxYrRYc/pbK9HONbFiPOT8EKOcST1PnHP7Vtl1C99sEEtKQ0yMsmCU24vfzCHK3eOI knh19MaR4TFDLJIlkbDRohSLE5Zuy/JJSuYKONIjs/C1xYlu/TVnqUaDKmmVlImaiB5/bzRPAez3 o7GCea1dHPwHi2SJ5oTY24SijfuK5YNDyWYBAh8iIQcdy6z9X40oDbJ+TAE0TS+SVIeIethxxm+C Vq185Ahsvfid0NG1M37XSnrKf6Z6Mx06sXHlQ1UF+yXice4OocAaPlL2UTzqybLqyb6O7Mj2cyd+ hjsXJZK55zHXJh+mRScqLGakVWZNh0VCLsFydCNPpXaCQ6xJeJKTni5zsvjN94uD94PyDbceffLU TVUsHNCf036AyMwjcnqSGeYKyc1QoROwQxaz5ihAU8zIv5goRqAbSrtfozmc5G+FHSsMsO6YJXO6 5GwpJJxK2jA6re/9sYofIb2w6FCFUBrE+TlVPhUNvPNkPZ6G/1kQp2udZy+qT329iZSoKUAezqIh 2uLlcRosnJnVblVkQQJzwcmBOsFJQVXRhLMEzRc/lBz6Fq/nEJSMZ3v1bt4z1oJNG25dJH8Z50HY QyK3f3tmFCPEjsIPhT9wGXkxv3Yg8McvIane3rPSGtpYwTsXj1cOrkqC9uZ6r39ni31ONL7tmPy7 o/UwbX6zRW3rzXzo/KFraTkLXpeNLK4mzLjOjONCkxOiU8hVJIaABNBdwOe4gFjrcAgUjFQ9c7K5 NP11bhy69WRf23npMS/O56edxZcHfhb8trM5HRdFAe7OQVY5+1F4tTkKENvzXw2HRbn5z4fWz0gd 806Irrekj73k4UHoL8l8xITXEAUQRC4ykZl/gg/IvKRQ6iYx77W+MZvFRU2+UObc5jHC09r452ZC h/pePsn1dqiKM+lZ+tFF+yWx3Q0RWkMBDOK+8WMfUIADqFsUYDgB27qQo6SGDCMfBiVc72P2H4yg poZ6YS2ax3kbpY8NVlhsZOHupnvCykHOJClzHvN2faYEppD0hMq+tBiFOiTDta3ifgqgjHJCcZp8 gnNg33G+7PdQ/ept+ElSTIJH36TwjHSBaW5owOUx3W8cV68LSRKE0iaWmMCEVsyX5nFd/LugIp84 s4zwfYLKWn3vvNRn9G5xs2JG5D3bOUmPEcFh+GJqTG4JPg04ETA2Xn74lSBubIbMRRAMQ3fKd3g5 Fr/Gn4h4A3pfrQwPPMeAY1L/BIG0C5uxENkh2KJxDgrghhruOGulXVvWo+HtOkkytT+L184japTX ENLONB6Nk7Gq5zr5XIj3h+kSjNenq2VoTJEQFkm0y69tyKY6+LmGE/0iz77En1msL7B2Tnb7ct8a 41IpkvkG5YWaGEeEsrmMlyu3LkWuNC/Z4pewiVWhrjniW+VDAUfnnuq5fZ4GJ3uIwvDgw70rI0ch gwvmNdWhnzG4xdlrgYODDO/cHBIDdQ8d0entkIptd9blcLSImKAxk5ykACNbOAP4CVI01AnCf+5R Evc6iklD+9UM990mS0HPtlPIoHLz4Hj5ezVvalmjD3s/OQtpam9bCufO4myQg5uCaYh7G+Y2Z8Cw SQhX3Tu9E9J+MFS/K+6s7icOriEGAZcezrMCjCQXqqU95HOiy5xUTLQiMF3LbB4yBF3wWTf8/Arn ovw8IOEatgVOlszBV3hHz8YbcnppPL3PefHXABh22fzB1/YHX+UrUjxjU5p42xxpSdRMEnsCP006 xCdGZr4L/X282HJ205QYwxmalzf2OWJK4aF35ZDc8dsy6xdvPwt0uymnI+dC7IL/pgDT5agNAjU/ RL2BgcpR2Ok0sQVhwsP5y73akMAAAcflykmuT2mmBOXwbvnbCk9e9n6ll2A5ow0ExCCaHAKEUeil bxCca0w9xtIZwrrWdQCuVira/Enj0ZvaA1XFli1yTKRsdKZQnS5kpTMVFVZDphra7aduWU8kbykT j1dW252h5m0xAcJzXE/wEZwZDSnYOObvGr4/c/0WTDmetbW1m8C+SAMIpyz8Bff934gapFANaPGs iRMmIJtg1N6gSJiTGlLqHv2Up+3lMlEvvciZY2GmKk08bh+ujNfn8Z8l+ZIxPahf0m8QE/7I7b27 ctYqKoTGzDfxbKNpYiNtN9BIY7BemPUbzCJTAD0K0HqFftPEp6xNTTaIyItDCjqb36sMwUKY58bE BmRsk5RjFJZYnKos37xsNrUTsqsqv7vSJDD0+wNY2MLdIE3QjdAwz1fXe+uTBhsgnoPPt6YgvYrP T1+tefjwd0qqX6hIpiHCCsE+FbV+nbr8fDOP9uMb0t6B6AlEqIbKuq99TVoLTEiRp8KITVv+9CE3 aWpAzzH+cSI95DHyLB3iaDkNiQ7RhNLc15cHdhFQODLS29aBPpAs9ItM3/sDVVdVKZvvs2FFHqhJ GnVIkhfGzJAPnvx5jrHqKKROcrOMAgSnobNWTzlmgYrvKcCPSAqgYBp/4esnQfkhF7npuUD5yyvT FCCTGk6Nt1MAPoACXFI/Y3Wp3/JC3xo/03SE1sVK76QNab6SYxaDvAIF8SpivMiJETJjSp6NU1YV BVhQpFu9rys1plzSb2tBY7z+CBmioZ7/7WP1j+zh0Vcm3ZGkWgoQ5BfA3/WGeAxcITgvDwT5dLQ3 COEvJ/qq2olUah7oERtw76y+9XCkfiOGkwfJIrJfyCRWl8z0bOuQD7LNPNV8wQtfiB56tIpRDism KhOydXqKc2v6J3sf+PKTWZeEWh2AeNzm+OXSDy7SF19zVVVUVT6PExd7AJBtimWEemcxU6eYrIyY mwv9B33sLTiULzPYuJAEA+jgtnjddmTw2AGwGL9lWTJIVMYt0Br2v076jFPN6UP+KA+pkGYyjuH5 ZFfkmFy0PmS2TBcvfqWQBbYS9G68GcoeIALSyGTjIS0QfvCE+qC0HyQYboH0cZLld363Vd6DnE/C rh/l9f8OnKQlHdTUDOhH7EPcMTzccQPsIbBr4SNnqyqT1JSenfl8A0ywSl1eZpLeNApbSFkzGFFX Tj8z0Ny+7ueYmKlryjmrqd4no6E7IcvriHEJqxmCC+ME5Y3ixYyLPfJ/DT2sjOMPvBYa73Wsxhu5 cnewYtSzJXnFeez4oJcrwvRDO0bxjMuV2gFFhvV48691Dal+KaeuT3pmVpB+IJpOExEEdRz3vBX+ /hZuPLjOCOvO7eOpq8lkATe197JF4MZZfOw6SvBV0dITqFjJjYqBcpaybEOJIA/P/aX5jqOCj6GB hYUuUZJpUZIfblfVlmdaWRU6Pc15f+PswqHuz9G0UiUXQ64LnePc9KTm2PcJYWFE3i0EUTCt5VHI mxQXHL8sP6h1ubbu2bHHcw3H8KElTq+GGW6EWGVYGbNiztbb+PbQS0lSN3FgRQA6QIKUGnAGLMTF hZafOb8y4dC6dAQGFp4fWnDN+dBHFMMVP8JZ67ZoMgzKCBunPng222eomTJ1V2/+9sWenHiGSrL+ OY3BBC1PV4XKDaXl9jP1LWwK8ucUpJAc1IEiOUrUQs2Mea/vO0y1rfI58SrC8U45F19FCFnYJzZr c1xkqotXT7xwsZvty0XgUCpZDjVRSgEq14O2DIm3uhu44KcHXdeQwSg6yLUq60fN19IMCWEtzIav K4fWYpSmxHwqmNl1yspiP7d5fb7YNnV9+HUKD9nTJ3m9kvQWbj9BwFOtEKpcts2IFZRqTCoFXSzA KFwUSWK2h70jtpc8Nm381JkrMl3KM0WYh0eAEV8sqTfgtXC5Xad7dVTLYlBR/W1R+aiYfml1v5e0 zjK2+ZyTnZ2DwJC5t8nFxuPHy2oFAENAy9bOr2DcwumRV9HGZmy2l6utrZ0TRzK3eXJVQm59bnH5 afF4l6iIH6baV66XAQcMET7QkqFmQQiZgQJsMTglBagf+TabyYDXjdQ8Dbf9EIKlLimDwuYNsgiB OfL70euLP7rLR1QUXtze/7vwdjD7B/NpCJEtjcygWgSXHFyFYqzWM3qEywhjmcL9mtxw6XomKfLh mnip1u333OgU2RpxnI/Pej/z43Rf2kYf64OS3Kr+LLwVMmYZLkmKqjA64JRMwPgETYZFlmcB2kea ahBMGAYNPdwM1tinKr5PP7DtTlPzLI2P1EGArKx5zKfPAnw2ieKDnyNwtiRbLsUQTZFg7fUPqWZJ eoqyR2aTHxVPcgdcZ1h8cfjFFQDwgPVDiUegEwlOUCBAlegwIPXKIC4y83hcI4a5P6IGW6c64S9D qOB9Zbdxd2ltiU2P/fH9pZvyG2ao508ZjgJ6IgDwSQQP0CYkwH4ZbrHCuYImuOef4ZWx1ytczhjo gr65zkInQiZPU/NSBkQkLqFVSJpd2H5gknC47F4kf+IF04WzkGm0H2vo8iLbqVvVmcfPHLpf+gy8 VWhGASIntpQjNfRco/2zYINH2/MS335vj0O7BgRSgCZJavbCumVKHsjk7PMiKYzD5cBbR8E4gsCN s8tOm6FZObCzChDGUSVjJU3xoUv36rSD9GwFO06qMwMBKwFfYGVESAmUyOY3CYsiat1WoHppFFsD PfEsmDWpd6KKazM2y/sdyHSlFM8d7OB9JwX6Xkr2KAu73ed+WZl7mm6IOEvyFAWYKBGSSmiG4o3i Ygqd5w6RRRD7wPOCH67+cCZr4KfXgy8W6LI5mZW9odc+gQrVB8gL1CbxmsxGdNTxQ6EOc/5pbhra uT5pbeau0byQVk15wuF8x4W5GBkrL6HPkquhDe6kWOIJMh3pOeIOVXz6mdZfw/C62Izc2ZvvRs/V Hcv57gzk/4BUdorZuMwwAsRFqrkogt+A0qEmslDlXVFH6z6U9q+5A534lQuZPSXeXIUEOXJH4xUD JjfdiIXjhP0JS7AULmn0M9j0aRiGhSgQQzCeQ8NKN5qoznOd+71VViSMS3RQMcqkZBH5QDYMI7Ch oxCD8qns8QlqUYN3HY8VEjFBC1AA7gGix2SA/dqYYtJhuY1TPs4PFnr0DUaUZyeNxTeFSSukVPjR UlnAo87ALP56+opai2l0TQ2PY1/zeVmjMsukY8WWG/VGiwgy8xxo5z6B+nYKHC0WizIGawl2bQ1i qVNY/bQMWbS7/YSh4k3jbK6n333cfr39sfSsKwD60IX4u4EJ0eSIcqUAjxGMdUx4F2xlFX7kEl4Z XX9gBJ0pUFYPeuQ6Kz/7NlIXz+suO5Wu5+3teQb9SSomsFdVhTZyDQKGs5AZpSmAlnnzOFHxEZQC iJiP4LOiNYTRdaoJP8o6ynhNX52XcFP4tVyNepQdM/cGNy2ugDEs7n0E+ZIp778v4ClZDCzG0UOu flF5pHKpTxFpE+1sd1qAgK7+gMUqvHcVPx/s1JqDMbRQiodWyGJ0J6efUIA7LIFQ1gA1uFatFYKZ CMWTxorWEU5VlXVDXndGXF/5OOi7pByPNHRpSf2Ct8C82ur9wvDbM27FEtwilLWNl7u3wcJR/A3H xki1rVmsdYa+yFmf28tSR91lRnR67u6/11z4BkToVAV+Hj6ff6TxVcMtQ3+TLQtEkxHKJWtEtxFD lWhM5qnuPPydKGReBAV4XyeKTZNlsnTGfOHqs5jZ4MOWxOt58ZR/nE4sfp2w4SSV+3HsbceK2DwW L9wGKx9qlw1F7YPTH0SwwXUIim/C6D5F67nnOIXH28yNHUXF/Aix6UBjmIs759H3k2K/F8S3niNu tLipZwlNWQRwS6CHYi30P2eIiy5ImKXpfWpjS23oDpxydR4s84C+0wxH6DyCaY+xTsqcIkAgyQ2y Lefvt9xyumzyKrjjfc963bNC4wxVy8tyyHBnCenz0V4P3hH7mm1kCQ6P1xagrQH0BGi4BgSXIf3T X6ylgXtgDcIyh3EZtey085LJKJgxV6paN1TM6H9WHavtEDN6scnWBvWWPIiq0CnJG3dSQy6IE7au 9Smqq0cxG1zq1zwFP1/7HvW+7snC0l33+UWNcyLKZt5my6V6/IUi4a3Xj1yEjC6FUfd2HAR/OYPl bI+CC3K4sFltYTAhZybV9WtVwayNZLLpoENJaWivv4lJKvRI0X3YrNwF+8THwMcf0ftOl47jL8aB YkySNFsSIIPF87fHt1rzbIWpIenHtnvnBF0wuRPegm0Z2S9+4qOTStbXBmccf99bUO7TGcqI6/CE YPRWvb6cRlm0g7aZtwgc41IS/c32fclSt7/73iC4eZi76TndGSn1hn4tQJXKgkppbR1vyV3Qcii6 WvZCPGiCI8fgPhRpBQ5WBiji/TNTy0Ts6I5+qMFf+jDLFLqK/GGFywp5jVduoQDhZMZAJS7yYcJ4 NFz6SGLUx2NU9x1ewSwh+uzTrevtjspCKchf7WTmTMJdLgQv1Ika+eg9iIKGa/L7CLesJ7kfZxCL aw4QG1Do+BRPE3acBbxke0gXUNsc+uxzNSqJKQ4MMKzg/frgB6pd32P7RqYHQngjK++yuVakZuQN v1h0a+eVUFpevZEcjxcO4l5Vi87Xan/VxWEoACgNa3UK4EI0qWmqVrwWpqZnwvil5kLD+Z7gqLbU n7mVVUcxBrV5oa7IysMhJZmSxN+FmzPU6PyFppShLXUO646gsIvIDCSiznySJWKzOedDRDb+YaID tviw6iQs1UgNwWNT+iPkAOSG3W8upElbescc0TPqZd4jH0uFfJmhn+ulv1dMndZqqrR+oBy4D2oK bKrayteUxyMzp77VWW/WPPgpwMG+3MB1P+75Uj95+1eSE2HQQyfAbQn9As95+tnRJeURJK8Rslrm uqRNhRZHYATmsSzsXEeSKbNIGWiu/V7i8sU4Z0IV5zeq87CTbmBFEtnn1oMHGiRm1OhWBxs4Q9ux pKk8O3fNYjuCsMnAXWk435hQzamKhYrNuTtiz89/5htUhY9//51IrIMrUh3FcgAmiyFA0Icf6xAI V9zSnCGzgV5YZtomG75Ao7BMEb9wBaNDM2Y1OqluuXHtPVpn5jAjOncQ4lqfv7TqzILe1ACungJQ JzBid613kazhA85iIGGLJ2rxXU+IZ95gQPcmPrrR0XKzDe4kNcEUqEv/z0BBlHND0uyioveFZ3YP 9TeLdCM15MPw5GSGn7/9H31rf3yNP/+gTmpaYPQs/L5rvuplBl1zl/IA2njSQbhrV0M8GMfjg1Lv uP8Vksx+rdMKjXM2bVUz4JjrRRtHO+mcfv7ylY5xhjbfval4U74rye2cJFOqrEofmX2oiVvwLXqx 2Idms4AL9g6aWXAbfRi6mYUTHXl9itSfnDTIffQj/dcIOYdQS7KtBg1+pR3CSXTCdoVlMddJFvt0 tQtJDhzthatj41iGP/nnz5qvpBd5aHHt9zh3xEks1UTg1FmkSGxJoRoFeFVFZBdeF68ihaDsx5mJ pwZs2rZwsAj324Tx1norI68PZVltmPqMxKIanQzvnzpDj3RDFUZOSh1NuBWRyivG2OBxdUXz0I/r 39ujT/nmntS7eUrfM1/dqfOk/pFARKeYZAXx2bMt5AIHQT1MBdYY3ff4NE+NCS7zeHFoCCP35RxH W4JCiWKJXMxivnb3NTsxwrW3z907NGGVDcd9uC+AWRMQPrgKQXj2mY93ewPXEPwYsiEq/8avzeoe uPab7zNqBTOY4jTRsTRf6cT+yISWDpFLI89DgaEfyUQVajDcSgHOi7UgiGpj4hRgcmATSmhfLyBl IO4k4/thQgGyoCT2bsMpa1OiPCSyQtheqUIoGPNodvn6ay31T4JBzoPNOkeBO1fTU/EI8FEYkR1N jp2coABkFhnE7wOoHJ9IIcEpngGjCILqjTLG0z9/Ii2fO+wn/Ui3VxhYzHlXYaiZBy5gK9VnxNCq 0jfMg/tBNNNTu7wuiRRXgfuvbK6N5HZ2hQWF6B7IvbwBL9ZXU8/+GQfegxLZo8jBRuFUE+FVZ0IB 2t9SgLDt32eroH5dAOOoBatWKPFRQx716C2iSQP6a1Fz+5uw5WkK8NTxn1W6NJI/4+1+L0OJEF0K kAR5TQGQiMvum/xgAjUAuYMiPllu/yfi6g8iH2Sn7nacMZMPPU4eUIXgK+Bm7C/bme7FwK4h0P3Q iUzIqjeEngLgfan5xUdFXuom3b666XUKgLYiHr35+LZM1YPpxK5RK+5b/o8VEPY+ssTfEDJLNgXo oCPXk1QryUMEMQoAdCJ+007HKJMPUgOZ/QN9P/ROgKq4GHOXA8tr0CgYO98JRm+gZ9gn6ePN1E3z xnH8Jeg3Wmx/kgnouX4VPCfa+VinvIGgHEYfK4N7pvljarqtbG5F7x60Qe/+o6EEHxSZSYva7zD+ 0ROPLb0ZNWIuk5QQK967BcJeFqLSlKWPr2hNLRHO/pzXIPmjiyp5vIf3PDW9XkXQ+BhNGrVKxkQ3 u0LRj5SDy4NvXryYU0O4XO9QKO5ab9bayCnfDso+h7pyx1e3Fx27XJecHeysTw57pRtKzrQ5+tZW opsAYQ/N9z+tWCZwht5f8GdEvk5MJqYWUhvAj0cEw3lvK4wz+MDQY5x9VW5b9KGrhsoXSkY/HnJ9 UGtwUe7lBLxe0nid3GFYTk0X1UfOqBuVRRpE1c7NhRfNL7ji6Dszp2ax8TzHog8l3wcWXcAucIgC 0B8l95Alo672BdDDhUEvfHyvS0R8hw1BtC2bINx6ZPjpHG27QA/ohzaramE9tiKFPG6yvODGQ5aF e5KombIzDGP8q4tQO5nXAoFYlZ9nmTcguRnKN+ez3eDPKPHRPR+nhy+Xkjko2tutSuN9W2KyqVPD E5teE4++RzY1Z8MV8+eej19wyYOq+6lsFrtuttOQO2H8PkjWQ+gWm6MdywIKPzK0JeJOtanPjovy Sqk/7F1uHYWW9pDaA3qgeAvoN8n1h1uuIdOtI4jIBqlytXRDLDTontZk1Iel1WZhP2YtWODsUNPm teXRU+FSm4GaP+2qDo4g6FCOS6DK+HogIb+uZ/v9caGZnODp1ylur4JahcTjZcM1VTIHL7ZcMaJL Xx/U5Oxxwz6UuVq8JnXqikB0AhF3FRY33SDr8ca763LmmZv4rnlsX1AVCe46YISSwmWsY8bHG3gD usazp6lhk3nrNK90gMhXW2T5lzt52gZImcPxeWEe5AWfIZff7/yM2twxWpPjC8xFeu+IrmDtZFdE 8pt5G12WSPg5f0TOzJAkQyVLjqOBlCVXONcoRsNi5PwTiw/8LyDzW+SDWRSAjjNs/R2oSN9IzfEw 82zkbgjdAxeDE0mb3nxhLYgwrvPM6tqEQMWWTpnsd461r0sG9d1OGB2fwbtFIvGf3sykJpUgHHJn +PwXCwtmuU9bOmHc0lw9/d/Ocid8ft/k4mDveiiZ21xev4mTlXf4w776vInp1vFoWKlyO8thuAFe owb1mCwOlxv6we5UM5Xlm9dVI+bi6t5sI90tE1L8peZOvmOv5Tjmcv6JdhXx42EwSJBKF6QZfs5A xTPDkhNy4rj0aH+Q8+LSQjsuyNW52urn8zjUpg5J4INuWxeTBOifZHvKwvuIPT5JWDxR5fzzUwOv q33PZKi8uyHt5Wz6/Fa/O2OkXL7+QQpwRY2Ais4CApgCuhv4NI+AI/j2JhQ7XOPd7ar3BJsIl7cd eZd+Mt2YUZ4vfPtr4+4t2BimgyPrJP8H5Gf3YQSZqWmLi+iIb3sGaV3i0Ns6Azew4klu4eOOmvcy QB34lN/kzor6gJ+OWR3hH1VdzX/HxMN+ZYtzrCc0ekLdn5rqsBhRrZkPouc7XIhqfOcpADEENvR+ UmbfVzwXMst+4JSX3ZIJ0vi5W5Zeb0GfTXwEmd6u7sjmuXv0bPqR+JGI977kw8VYK6aQ1o4kvfKC K622dif1zvg6X33bNyM8Ja1FPkg1svtHUTXxU+PYsFiFFzneHg55cHNChyW6vvQqtHzNVX+y42q3 QlhsoglZgGXbElO9NTsOShZ056AAhNnNLLLQK2o1NRrM/gBSLWdQRxb5XPY/q0SmJ1lMfPnx4+cz 6/Xic7LV1y6S5AQ8Vn8GCx+cIovez3W1S1NecWNGmQ0vf4Hgz46DYqJ1+K8NNGDw1Nj1KQaxVllO jcu2CV+uJUHLTz649UHy+00+UkrgQddXkWMnB0/ejDkWKGIc/kznifDF7kMSrx8DAoDkRNd/d5px /72qPj1LEPvmLIFFtLM0Wr6wo+tT+OvqavcOxNiDqYdrmvwx91G53FSbPIyaW9Rq+93eT8p7vznG fho5X48UK18P6H1e7UvK0HSxSotXHoYgzHkJ7I0BgmDuhBEPXJnwgNtbk5MwFKYYxwDGYtrISwa1 NT2KI7zlC8aDzOfbrrtLjU19xfZ9iRnoP910oEHh7ztVagx/w0eXHFlURQEYqSzLDs0UoEVg+90P MDYEtoyfAnxmoZIwqn9r0oT+euFTRgEOx8UhfnvDYOQviJKhRtgwvT7hThxetnkzLEyK6PrWKTUr HFVep10MxuKW53Srasr71m/MeScnWKFdmX98iJUrsPj2LMFGj6qdV3a1E0Lt/mcXBTja889ryR/w cSROC3cyB5XhB5p8dDoKteq87fqZX4yTr/iTbMQI1HQiAHTaMiQqo0BDgqdh/1rcfufUpISCWT63 5HezDUKpi3NaNVYLGob+2d8xo/V1yuHxPBvzDtoi9trwkf8bR+MzTlSFkhmoA7qAbs0CH8D9qJFC DRT7ieqTjeI2TwhJUSOL7MlxsvVQ6T+JQBT+ad07DWEKoG1mRQFCFBC/T1HzP9XtX/Q3iFD7uqNM AZ4LUcnh7e0OR/ScIjiQBSHULb+82DBBSofeYQlClCKeuDcIENnwP7tCibL5YOxWqzneZk4ts9bP u3iW69HDjDNfNpOQnl6PPko9KPTpPbMlfJ18hUEEhBDPaJEZsBRA1wOPoPrlZCgxSPef1W1ONkNX Te1RoAk1QktgAYMyZShATyHOiKhkh/h9rnbr4varGSmAfRemvd3SuwUW08BG4A4nXs31cetofuTf GhdDvPrSYsTxIfdmZh5d+aOHMfmWFmFbbiUewp+qvtyfOH3sGksW6v83ckxETERC8UbB9u6gKVlC /aKKe6TQGYl7nqGQEXjQWH3c37Zi2SQPLGRTonScKE6NID+FEc91cSN+DRDEyPynUcSXG+4Y2vUb oPKWIVypt4GVaNHtxWzSaKlUluNSExD1eg5TFZokucBk1NC7WuGSwTXbO2VgoG6oc/Z9Gc8G3S25 At0WFP4HNewWayexs3AhsD2EJQogMzcMxc5C8EYsm+pxQdSzGtVUxeX7p3VDQqwU4HWhNAVoToUS XyD+njXQ/Wcqv270t4xn3Fp7MOJXQQcC/4aaGZyAEOg1rKkiM2/JAu+2UWUfNAN9DCnbaN55lqEh A581QY7yfOkjeanfy9VsrG3DtN+rtrJfsbCyHpXpb2D6obo+/ZOkrZbqwciCD6b76l8lWuurmOkY FxXRSkoe4rx5n/e6wJFHQ41Z+DUWUCyMJNjeRPWLQjeoV2KG/LO6uTiqI+8xTaIAWEMI+RIUd9in lgLoICOg+OEYCvCTXpTQTmYQ3zoCfziIJBoVwk99wLNErMmLJGOGmutvwQ7kjn4J87QxxP56VY+P qIs/b/GT79EnSbavXy67/FxQJx+k3xK0tImKGheCBwxIX91AOHTiULQjusd/PI3/bkFUD/wVfdNe kH+s4evfNuyOe+26LQU44rn9vg841e6GfnGnACel4IeoWm4f0IooW8w9gJqIC9xUQuKizMwrCLpx i8g6v0KLL+m5bWncEWL1vQpR5W4XBh9WLgcRTTcq4MV4l/VB0nOEozuX0YR7IFQQTk+QbR18JD0e vljOcshZ3mZWafNElredvW9BJ5Nlc4STq3eBVctXIxa5w2trhn48AmialO7Nr1ax2eFo63ePTGIu jrpVv8bU1NTUd8V+BRGa2CLPDpU4kTb73/GByaUtPfnnkVINvH5qJdHV9g4OLuqOXyBsoB06QKHb C8rkgz7bAzfBFt8ZLlqLoW1Rc80syXZ+WPR5imlB/koorndW+lcRZ/fjzwd/0MKeI9hQE+FZ7/Pi lpCK0vzoAA3QystPIZmFGz3O2yGUIlCqNMWFMY/afs512OLsdWLJ2RKdoBBTgGZDt3UJs3PTih5X LNsE4Qk47WPQGCAz+CDN2vtSt2KE+8jV2l5ZJPJBhzqILSmpbeG2DM3Q0PuQ7x3xXqXYPQZWwU0N wbZUs5iRbUuRmbzgPbKs4WUj5nbkp4dlLqy/8oz4cpLeW2CsvwiXqOV+eOh1NeXavsse33zpf26E ISaeoEpinz2qsmyPDFAF39EdpQB3Zm1k8W0Zdya82PRegmIG/QfPrH8N60VdCAACWhCl4/PNXIgg KD1RHtvp2eH4k+C1bO2T0BafXSgSrmGOU48xsawINL0lxO/76nHQhuRXFHY6673y9mso0citJevt 11D66TYhMF3rnqTXXtYuF0BRgh0axlphdPjbuQKXpNSD/Smro5qzPzBW379/8rV1YcvZUL1GE3Wa nhZ4SrNqCI/ZukxugZQNLTzxxDIhYxsEhuoujtEGWVTh+9Ucooja2FoX0aEffTkDt+PHtVFlkbO4 HzNKk/AnKWanaID0VRgf4i5sOGH94dBqFyPRGWzHGgE+cdd7dWrzHDHV/Xn9MgoPazI/KR6o6p2X HRsbdKm1sIvJHZ4qdy97ONheC5q0akII7aEa6pNQBufKmo2QOovXTgHC+KmqW9ZFa64sVqVBxr0V kmbPjLXc/ezuxcv8NMOgjwqdpF3RukDdGvLkxkcHKnJcKiFMdRc2MCfybQuHc5daEPzjFvVjad6c P2tGh2/MyVnZWJZ3AwS1UrWf149cRPZv/h6aNFpw2lIJ+FpTGfOKeBesxsLCHrWHP/hd4c9/eeh2 w5YpOc39/uD9MTRnTMzwda6ffKc6qzzFaVVUNub4R1wvf+66WpLcVYaqqKovS7sdfqKyJkSsKvn2 23jdqfMTC/ZmvE1AN/3Pylyqb7lJelzhqntlwD2AF8xdUlQfqT+/0Idzj32tU1OfsehgHyntZBdz qDSe8yyjioD5IKpMbN4bz7J+vlfD5DWRER/TFepa55TvtJkXIaMo6G1B4Mp+25Vr2en0pnljc+Dn zxYzM3FPeV3GUzE2vvy8913KwIEtXeJhUoYCickUHCWIoVGH72oY+nnn/eLmIybrK1rVHjxe3RA6 qK5ulQ+bf/81ev6axNKVyxfpu4nskzAmuC4+OazOeyLmzkiLJivBJtm12MfbuswguHygPK2fDQPD RL11nVbaOG37LIX7/lPd/XzAihEGsn4fNN8yhmtAmQJOz/AlVU8MDSl0HfmUN5M6VYid+dlfHlJj RR+/pVtdXut4fMuqJLqh7WZO4DXzZq2dXHQ/SPVotjj0GkiNFmaKI7eGJh0W+PHQdY/eB9buk94t WSxw1T64LnXqv+TnSq3LU4vXiqswi9iy8vcV9XUp0jclej8KL+NknryQf+mWgIW2LoWOC9Rx2xHY scpR5V38oOS1mn6pIrhWTjFm+Lu1k/n9b85HJMZGMN+LkqrulZ5yHHr27Om5o4JTGbZOOd+uzzw8 Ulwfm+bgYmu/70eRUuW9dndXtni94yp2przTkbXaHDRgKzWD3r5dfA1MIDMKTy6FZopDhOYbuB2h zETRAkc+h7Bc0NsDN7xYYe1nbq1rMWhJ9OlA4xurzAbNrkhpah2RjuJWf2zUyQKGqptSnWlLHzUE +kT1ZytdyLFiOzKj4dYBEGE+8IDZm5qmn86dUxPK9c9x3rQfipqfrHnfv9qRL+U+73YlOmc9+Uq5 m7rcZLHJ9ptk/+H4lzSpERXW3oHMCS66oG2OTPPGysp/WdHgIAzkdSqvLVrVczcXihS7WIjEd5O/ T8D4GtJsIPeS9JqI7EnTH2y4mow90L1xLL0F2QxfTa1MJezXxDR9v5rcf/5jJMEbehCB41kwJ8ex U6MwtCg1bOvSjPsn0xhdAn2XqFpFjl2ZQJC5zBBYXaLGxk4QouuLp4ZbTJJQPBJKuog3IgfhYeA9 BLFuswtM6cIwEKmhDln4BYL8EBIMJRx6WEhtEpFHnVI89cR0FuwNDG8IBUVkg6n+NIusRBhqGbXD XYLxwBE4Q7bx5jGBQf6mZz76Q01jkPgJmEu+nYtSNU49peJMwNRBNotBx/Mj6J8Ft3TFZrv+zhC1 JLAo+tK7aKbUm/IC+z2ei3bSS91PNa5I+JnowDU4OzM8XGzs8JmAiqYAlyGsKlbKE1+lmjyEhMM8 uq8g9Xk5HNWeGkf/FtTnYTS9dhtXPcmbqzLGVmcvQl583cD6TxaNA4HuQkxkUQPjLFqqOEupQRwj iZ7khjXaFF9e+kdYmvUli3Cw7jpV5LYtMNC1DbGcQEiYhBD5k30JBrjpVtmISliFdVhYccAxojYh L076ATcI9czXe43GLbE52xw1FFzjAGMcBAl98dTeVi4cidjn9q16chYBirkTWZMtSYEUwNEMnIA6 FrqHD1bZ7CfIPlmDMGnhMQimM/18C21x/pxD69k+Ize0twTJEUy/73xfhLR8+LRVRRaKou7oVerI akFqkBpyHkGIhGJ/ofBGRpvqqMBx8JrY9ttjvuLhyhOLsBTblbsnXJ6EKiXaG7PMbYq33fi0XLPu PHcn1UUnbub7VptRHgv7vYe2jRZTJi2coDln4GaupWwYlltCIFIgc1AV7pz3OfHNmzepU8YNea3j eGNZqlpEQSdeovg1zhD0J9efVoFeL32MGh+5B5az0HXgMe6cuo74WUxDSeEcvQmMz/HkEF9929vw jnV4+MIkXdo+lOZ/V2+UF3Vl9k4h+5/N1CKO2Uc9zY7gmwlVbOzit8lO/7m2ZWM4+qswJ/l2YnyP o2sTWZGk6sMUet/mMFYjD9p8bwqmbfxK+96C+PI5pflpE5kMvcqR+89/iutV/hhxzQoRpwAH2p21 +zu2bl0PZk4axl+e9BFUEcMFyAct2FRNuINKYRNfMzzsPQjc6y/AZ7gPtzJVkfMa4hPjh32kZW3N TERrrJ1rwmLyKthCMNclVUyWJ1ZgSAR+FQaK5ZEEx5vciRLsFCD6KjWX1t5+9zyiZ5TIRc0uXkHB Vk/jiaX9TnpGcy8YFMiDNzG/kUUiJMGeuUnyM0Q5y6lXGmf0CIpq983cks7pP6/o0+vrsFPZbNMb t/7at36DFIyyR32bNqwpB1nwVfr4KeTbtuMDRKf8Dk8cVHCONfRZsPmYxKBITT/uvYk8Z3mVi5/2 d/0WedjNofYsZpQ76lvXJEtMOTQMwkRVxqVQTVXCUMTPmrCz+Kowr6UqF7W6JCXu1PpZCyuRY+mY mVR4X/VXrpMZZa3+YbCCH3LYn4+vqTi/Yf3Z/7PjrsarkzpmhnnzIzc6FUZJ0w/GpgkoiOyRWQ+6 u+iWWd/2zZ7IwHzxqastuuxm3PeilyL0c16m2x+sWHxnzjOSmEvUQjS1QdkXNSy2HEBJbJ3yPb1c 4klQ/bXY8OStXiufsDZMJRI526k5SPoe/+uZk49JKOPLoQk6/+1XsvKB2SxtRiNZ668IpOheozxn KLeGwWsnbraPok7lCLpO7sAHKZPHIsMd+uqg7G0AzZWCNWSUC6gbWSa7ECDSJa8o2VccWXiSmp+m vJX8rZUIL++mAG+yssepac/bzIM+Fs1luZ/Cm3+8MDdTqigceFN4S6Z261Gi7Ogsx1Vt+O+tI1e1 OYCrlptiYXXncC79fXXKr5zJR/tFPkV2XOiTrbAaBmwuPUw6dePS7AG9Y/fo/KPwaWSGqi0v4l3t D6D/1mm4afV7J9tKPlTEqhF4dtX4NubSM+cA1Sx0kvmV5uJkR5uzp598dclmCm61cy7g0VDUHxgf Dr7xc0NbCb6OaK0Tb37hNKmSHVFKrGLgLCJcj1TxEe1dLlQRRZjg1CQ3vUnbrzYYcQ/f7Ckd2P7F c4yl7JOi23oi1XiH5jQEqK+hn1MTbltNuFPt4ood1TR+FRXuqsjBi+EhYbdGtpSpxlMKQU2fhuEz lmGPGxgdbY4SkhLrcWAQ4RgCq0Fwqo7fX5W0POjvJv6gns0s+siBLKc7bwU/P7aIIKkfw3tGr2Tq v0iXuqdijlT0drL6/Nxd/bfhOadqoi3OfYEFz/LEFC7GbHdawzC9bUaXTuiSXHx9NcHr+U3c+Aga zV4/34XjX99+o4tzAAZRoZHqOt68FKgpFtRsmUZewnHH3HSn82E9ugXFhPxQG6tLiiuy1I99ZXU5 lDAcTnP5MNQfegcJKo00P7rZu7aEKZyk2pEIt14Dv7SlsHGGo/78WsKfvmC8NmK9Oqi5K3ZLi07a wTZPc+CYgIPw5rPIk7gYuxhjlR5OVtbzx4/TXTPVvsJ65RCgctVMcr0oqJHM1aEqeWfAeZIggdHb UjO3NlXRdJiRiI+ajVtBtrJgpCerBPwd6JpNmu+1GarnvC9Z/1bF7S8aVZQlVbmBX723bNaT/RM6 vLJ+kpSEsC9WG0NPeDfB9oNKi3QR9gTldcfBOhc4QbKtdFZIYcjKhKD4/UNiKd+v14vHzsdK4pPJ TD1U+/idAgTXXuiHuo4HNkCewA2xaRwwDC26xrRQiiyMH02/2uREUGLyc9S/4RzAWxmtXaQ+8enN 8RvyLKUNFGCW7631N4yzkvdD7vXKjUHuwbLhMQubc5ytuT8zvhjRdRb/YCtEnynH1wq3NRYWHtFh QFbghA58LGsQRKJX3yvc6w+QuJwuzKlfYBbdfyveP6fquZW54ShCDbRefUJgQRtxlnZxDvpHfSl7 25XMVWI6a5qkzKxUXylUoR+fnhqvfyVhat3U7nKR6cQzsnG/+eIGkVOZfHCNYL7uCYbhuqjmv6zr SYW7YEDn2Il+GY1zXMlYdV5Faz8s3WCuNwsGLp/vyHW14RU0eGHJrWvdeq3ofjvdS1brF6miSYjm E2Y6Eo2FknKlzwJzfSSaqumhlxOJ5zJupySzTHEufxlilrhe41qomJOsd27hpIHPJ8ehjF4KkDN+ qO7KBIrbx0BqUob+q9Ot5S/aKtXa+jLvhLL1PoceT3W7Vmji1htc1Xv1fnD2iedXtX3Ffh3T5rhC 82/80a/5Ur3OV6J02Mftl41+lyh/A6MlSveMf1afuGCt25opuu8Oz8i9PifE8VXxlYfta76wGAT+ vGwIAl+MmsgYP6zoF3PKqaaq1Z3TZxp3Zut5jIz7gtvaDFyRumXDbpSJjPHhW7N15J+wH7JTQfaP R0OPFAWww0+CyQQtY0e6OHQXDYhs82byFEs+lI1+JLhelPT1N72ysWXRTZYXZY9Vj6Oq66Q6zCwa femUORckjb3SlhZyZqnea6L63CMRxJeqPvYo1JBRTl4Ub47Eiu373wlNJgMK2Y/zDvH/rEwvzeDt 6vzUkLeMJJyyDMDA8Faj8s1zAjV5QXW8BCMdfOuXq2VdbnBVPItegjnhhtxFuZJvzg2i+MVXvMKM 2t1N34ehvdAFwS25gA4KwCvNjxNbYMWj0WNqRmGanIOLtgNeIzH20BINdTuBzal3R8OM+udffjMb zb1/pfYukA7QT4gRj2hh14sJtJPjCyxbemAqjb9nrqMwuse570kKEUaQb5HzSYbVVMzStaghwobt hZ8b4Ot5huZ1iZwIHBFFD7U1iqnJCOkarkAKOD2EMq7eWdl/XyMTWh+lM9ii+jv6PahXwWvu/uWQ 7+T+uO64qaDfk1QDpU3+AmFEuBhhgnDkCoIYdiqtmCiKdw9RzAjoazLJOC99uMOSEBeBq8THJi0P jzU9eO9kKcX35AmfsUXx8/gRQ4ReTVUQBbgNAU+gmmWjIPwawvjtlx0qnFz110Swar38bk0BXHyG THo7iZqs+Hfpm4PZPn3Oj2LzC/WYyx0/PslzEvnNmhIAoY6FgSiS1oQo9Y4ki81yFTJPt0Ej+GLG Mu7ZHdwQ4sArloJ2RlI/9vW0404XuUIe0D7rH5ruInIYTDq0yoLiDgsmOQHtiNLOtwSHQE1um7my lKP9rlIKLJxgh3Zl6nirptKAYsq70NRMLnzLJYxbivp7izuZZtHVtSFn6RsRgsRjhKz1BFCbYE5m hBKcZ3H8CF64B34J7X5wxjmBieHBjEIcq2FAzekPV27h8wJf99xV8DOPziq3Vmx/Af+WI03yQDTJ axhBolA3u4bDTGPdofNZh+bhisKL3y+MMfcryh7s5BdI58npYZyslPxNIhUFHKY6KUMi3daR73AV 8NMEKtAGQkoJYLUCJe68x18YY1dbfyGlOCcN0WsImZfN63dHIr2KPb+gXkga3NtgNzimnj40601k zcM9DKPG/k3KCbAhr/1B2uAZHCyavoWb+fikYW95bUrA0bG6tPCDJU41hIT0e460yyvrvdVZ6yiq vD8TNUGZN+pLh0D+NiizJncH7ULmmCFTcwv8PPjchpPuUIQouZA2dKt5VOvmIZa5x8DLnf9vlQc4 DNC+BMwJ56iGfISUG7DfR2z9O5iwZRzQ36CBYOh46zR+pE4XG9WBZPHJa9ngzjwDxiDf9osOY2PY b3yo5Mrk76/g2ag5HvDb1KoCYQ4pQy3kbymRBzBhkQpdj7OO3CGMDgVJrY5QAHZXfFgM8Yx7rtUc +6jVTKbreCRc9bWloeJ8Evt8rLIvY8tClXPCWUiXA5FbuY0vrg2CmVxHkFI1ZH3X07pYfvFpp377 8VuJrAp+wrkYMF2UYZVbkF2XScj9KCfHNvlzqx3alxVWPs4APwzqvXLcSM2NDZtABGexKNTLTFv2 50S2X+6tOz3hfrjJQSYPoc4ZisEMXeo7VFqiYrp/aLls6xQ/YkSdzHQVh4iUGzF4Cxo1C2kSkC1R 5rbTr30QWOt0zSOgq6/kKUecVpGVY+ljlcMP4yw3a8lMkls2YFr72En8OJF9ZN1POfMoISt6DcVi CTeNQq8k1fcrSt+a6iRC8AUMdkkqz8cNPQ+/KnS3jzlidWGeY/QoQCSTXsN1CexkxicE2vUCUs7x 5Os9CIfxYQOsW603fr31deJxJcKovobyzfU+XtdsAiS6s+JrReFHVF1VWUXst5JrVWLr3OSDxyYv DFEAOxgbaJqlrEkLduFqaYTumxgNlRsdAkMHLz20kEW+ax9ghnNix4cdyIzoLY2AzwiOgAO/AmhB 1jdw7gHqtmG5AkbEGDTVICPXMpQtu2XZWzafY5DrT+rqBotX1b0CO3u8zyfhCw69FBtETIwiOS5s ii1oTeQ9Z1jwgoVqilc+rpLlJOVFP0ibuer5UaeveCDubjGAMOCcgvEQ/fKIUqAeAYqzKfY+kPUG pMdSgCiina+vugTanT50lVnLPN6CoZ12PkN+RYj+RL0SShwxUQFhfwVSg7/90+D6ZwTOdnIOxgw/ 1Zu9cumOnoYdTlpt3FTYscPXhr+iIYH26HzTpAoeTJMjf8R+X5E3Lv9l6/z1zJk1+o/I0c+ffMsW 62SxFoT2CAG6ppIgF4Wvp3wsrLwYv0XeS6/o7QnOFfNnMywjbime0dm63l/BDDOpTtq6NuAuqyi5 1REm1+Xlj/AQ7Rxtbak+oJf3ISPnoUaSonGkJHE1IIx06/zpYLuDrSdzbydFiJZePPk6UpuO4+rZ vX+QbhiRPxFfIMtF/pYJBTN8ntWjmo2C+bK+eevccaw7N1l/qx29niCSe/ZJ3/mK/v64ug6xjrZZ 8ojL7xpqduCqyRVDu34XHCY4zxkcgcF1wDJXbAz0mhdM/Sp+A710ePgTW8uklHTx2hLneJ4AL2vZ R+QMF6oCzt+BKAPZaUxbJV4UVEhC0+vT/d0ZPQJiR1l+t2/6eXhvDq+mTkY+mK3GyhX43KU7Y1L1 Ppt3MLJysGUA+Wajfn4VpnIjoH281LBluctjS5r8NZn9++eV70bQJtnQ+E6FlYu3k5zsEYeS4y3s RVNexF+P91XIwrdRgFIIia9qfpwChKpj4yiA3OpVmD8pLB7RnUVN+ALzKcCy2ArL5lLbMz0Z2U42 CvC+hpRM0mAB7RDDLOQYq3V3aoIuiG+nACmPoNgYqmuCbiq6D1Pt3SFvNIRs/+t13LxGAjkYhBE5 qbn8M+5NQhtq9fqdLNAcRgGS6ImnUfNhTdSrm5HSmvYf0W1cCj0aePjcfh/Y0UDJ132oO3HD7XrX rCXXEaDoG4mbBTMUgBFOf7vAL5ELs9/Wc0GbA2H7I1KvKIsJsbm2fQG5wrYbMBuNxA9IuXR1A05r ZPWX1XqWZqpHqzPkDq07jV1iuaC7WcxyoU/hBfj1ADVbHL0I0f/163U937X8K4F5Os9tDe++jjf4 Ua7BODCHc9avPF4+a+r32fATymzx21VtzldPd1I56p95BJi17kHKhLv6bJDlQGa8XWtVn77MiTqC cvMS7dzQ/a5jt1b0PAp+eXtqFOnoSemJiaWefHfjMgtD9JVQWabLRVz5l0/HG9VMXW5/lXwnJdPU YujzCh/ovKQrYSp22fBhnQAM54n4p4uEQPOTPyJWncfLEGSepVAosaNH+z5VElmrYs3UCKwAQYyY pwBIARcKoB1KzedCvCjA75v/pBV1ndy3jm1/BR3QSQFAuwYeCrAiuyPV/9lXOOI/Pf2np//09L/Z k+0ihj5M4wxWmt0APxTyQJofrSnQI32sb9WaFo2xT4p67cR1BP7ewumRWRpdRUhIOuO9Z9p8x9c5 MoXxQ2Eatq9mbXgID5+8BvPQjwZKygY1zuDOSLTf6F6z0vF6WNFfnnGZqZBp7tYvBj07LxHa2JOv 61XOc2D5HuCyD+bE638Sfa0nHf8rLrXQrPhRhaRZvvhgenquuNJPceWHI48qx4rrrQZeCNGC1vgu rE2WXw7xFOg9AQvjs8n1URTUNcRDguFQLLMmBbhypP2uLPIu8UzezOCGeeCYSFznM4v1kzcmaIzB OWwVGhmpZtoQRJBv1GQEI15hYO0Flo5javh3IbgFiSGTUKao6xX8/uqw9/1SWFQkZvH6oP254+2S b1VuMWhfTXn10ke5WYgd34kM0pDEwphBl6ZBrmQuJU12PDkk99cYb2lpbbzv4vyCgrTa4IhBVUVN 6pROvELEVYyOCFtLpm4jjFaTgSjZL6voHgqhb+CCqwwo8h/Lc+ZLftwA8TFo2tjA+KSqP6NGMtgF 4cvVNWXcR3ICxe4YzvLzAj3awMPMk/i8EKL7y1kbTkJe6CqE28fueqSKIoIZzNLtqyDRm4by4moi BQ10B4rfrW79yq5+ImKapMT4q0gVGBKnBklBsIMa4lhpz0ZNLtAEP4LW3E9Qh2WxgZJo8gF8WwxW 9kiG/mdpeWO16TCFBZkR3QFUucKc48L0Cjbhawgn5CTwOhJYGQftxoeFyTEu69uvgxXGd1GdauQq ggZ+DDTElzKbjWDjqCoWhjgsXTFU5e82vv1K5/Hgo4M2n9yOl/mbQVhmUh88irJs95Jou8Py/iLW 48OP14/FfdgnEE2wEEzSqyKiPHgOX4sdROZjEA6zj5BPNCHUIFotKdt2ut17XXJriWWGz39gNA+T baFRLZjw5cq3jwcKZ1BAw/5fY/KI8E3dJlhwjXmLqhc/ycZIyAl1WEPQblJV0fXaDWaTawgOy189 LnFvZ88vwsovO6zcWYH4CbaLctDMmic9TA3JHQghFdevxazVDXpXmj9t93TydfLk1/J08XKVq1Pm GjpSK5ydb258bj/fShZAZAPl8QVzVxpAGD4OG4f2W7Ac4zc0W2m0ocHnBS2uqRv4Wrr4WZ+fRNdc zlBcqGM/fVuPSaJE5BB1LR953Ws4Azrhp3FJCe7YpYgxAG/U4noAQxY0HtEmTIcoQLhnlDDpp75b ab0dmWk4SlXIVw2RY/9QyJx3r963sEV+reBTifTMtnnuoGNw/dOJrALvSzPNt0quCxgK2DCxG8dK pCN5my+zRy3xaueLTaU6PKeu1981FpzT/9VPr0Lm2vmoXLap1BQGQb4O+dsOH/LNV4zEgEeBElkU 4Ph/uvl/uxs/7iA4w0Rc6OYhIS7Qd2Kc0YcFrVTFbW42JoB3CCuPY/qltKGckPJuOuhi9/z8A/BN TUrUxw4eh4DrCdZeHOa5+olqClj9GJXm56bb/xPyQz3H5HhNb9bwlltzpq235r6+k8hJz1P99Nk4 YeCzsWvlyEDliL8RZfiljiD+FCMAaEa6wxuJN8kJDiV3uFzFX1Io3ygTwBF9HT0dgIaGBnCm/gMo I4DWdunvfvb9zw/t//hsd/JfeGj+17N/80NpBFgPAlbAUVqa48A+VhpaVhpKCwABABq6f3QL/PnQ 7KPdT3eA/iADIxOVoeIIsI+Glnbfflo6uv37qWf9qeeB/ax0bMdOnzvAftWW/rgHh9yTZ68OCp8v aeI07sGLyN+6H8jAyMXNw8snekLspLiEgqKSsoqqmtYFbR3di3r6JtdMzcyvW1ja3ba/4+Do5Oz5 wOuht4/vo6DgkNCw8IjI+ITniUnJL1JSX2fn5L7Je5tfUFpWXlFZ9aG6phnd0trW/vHT596+/oHB oW/DGCxu8sfPqelfM7OE5ZXVtfUN8Pfm9rxoANr/IbB/Oi9W6rz27d9Pu59+e140+7y3GVj30x07 fYDt3FV6Ww/243JPDnKcf/aqpIlBWN4Yz3nrfg8jl4gCVpSwPbWdmf29iQX+b83sf0zsf84LAxyi paEuHi0rAAVIT19HSnardnWgwJNV7eMQuHR/Aw9oh62K9pJlcn6UmBVegWRViu+W7h88bi1v1J39 LCf2lq1L+NJlpWhOgfQJuCzecz2elEv0I5hjUUH2YP0kf5Q7GziEttR5xWhtueR/YtoswktPP7dA P5BZ0Trt2fKh+DfFiCYtjesaJluXfOJb5Vzr2F+DLs0eGu5POwWjfEKXL/F0p9xqIBz6eG1J9TKD gCkSFNMNRmCFSbmrrsbXZOkD62RxUA7uk4dcFQY9fJwHIF/U4T3Q8OhP6FOnpiuxxNz0OzzfKUDL IZ3DoUoF2eYQPnGd+wbxcjEy9h3S1XadD9YGrcpIS/ilxyrczUuvzGCt1Rt09iqxR9H3YoXlvEp4 Lp2x7EVG5pnzhgUXXMv56SWx+rZJnxihA71NDj3pfX3gx1OssfLzVew1t1veRzRnM3GRBARGvU16 wugJjJNoIjhcWvser1N7OPk+Y1Kc5YC0SO8DEz4Ui9h68erRQ/ddNhFyrWjZRjuPNU1GDoerm+dl YK/IPPfeaEfhMkWxizyNsuvf2wXDmvt6yeTjReK62qh6xVfEbqIxwcpnA+fewsJb1NvBHUG0wxk+ 7NXTkpcOfVU4dmPY6olUvFpxcaEuX6jq2ZdCagGFiCZJ+HGCE5SrzlfB4wXSfZWFwWk5OoltpsTG Ra30AK2THve1ki6t5z8eQqLWSMcRTVAi1dcdzJtvn+iIuMlVlSlTN1Rn9bBWTy53PU86NFkTZ/Bp yvGRaz49U4gK8JgX9QJ+qsno9KSGzPHC6fUj+Zbmle++RxqRx/O5X4+XQsdY8ha9Qyagr9cCuDqy yrJT7E7xup4sHpCQnZOWfLDuo6nb2/sTwWY0/5m4TgECk8D6csjwZh/ao0xhTJWQGfHm+1l+NkFl bSsk6/eLBUZfS2b5rF9X3bzxiLDJDosYx1/r4tH1mxwPDaCLNDN56WNuRhCdpTugjGCbfea0/iTx MAVQ4oErCtu+v3LxIM/drJE6w3aSblCZpoVlrgOjAXk8fmprInfzFyIJcn77WWArcjxZoKfQII0h ebAwLn8oefaBg1k0Cp/3TXLVbfrn7VOf7nW4A/F6eUknX4ZqlJfpHRsW0K/+8dEQYUkBDtdJcj8h 0k6g6EZKHOHiWGpaEP4jZjkGYlDx3ok38dYJPb7jX1rPicWrDa1obcn6XAIn14NBLWz3K9wHQmVi gc2FK6iUPPCOLkEpf3+La4Jra2jc8en7T3ni/YbWuGH0E+9oUAvfv7oYjfbGTYqvVl30WvqBsCb3 Z8pOf6k7OaFmCg3R4owr5F9asDdiCQswW1dJnO78wUkcCPgudFpIgfRG88QNtOd6mizL+HVQ/+M0 +UwC2tK/Mivf6rFddD4f0TvaSMzzZsLy9ObFAS9Jf26D/oqoT/H8ZySN6vrf2d+dDx38PGaQ/+Nu KbGklfXMB17kj6iWmoXpSA1tHAv7rPrlbByzu/lQBfBuS3O4aNYEZo3N+Y13+JAgGou72K4/3lbU pMv07GckjFNvIH7h4/Pj49a+026p6qsaRsNezRDLSSj7h9li6VOqbhC6y0Zud+0dLHNrbE43NWnm G4rlxHVDwRPQYFSVpupcg0TqwZ9VeFige6p4qoise5FLVVKq/bNP+9tFMJbjj899vNKYntS1dCYA hmiShh9XWApFsGq4ShnreuDieK7/uqqRMnImLEQhJ5N38paSAsKVIPoZf5/xoSDiisscXLLR3yAI 73XDVcNQPxE2Pj85VOTUWlzud4Psu+lHcN8cWE2a5OOY9bSVS+W5QXfm4fo1O7PSqss3DB8RVio2 sxQChoVkhA6RUgOknW1TTvRrKJC5K2/fhHQS/EerQlMviLAh9/OlVUsonzx/LfoO6oUzqZ+q9zk+ 9QrjIZkA/q43m5YnLo7PqLCT7eeFTe+Q8mG26+MZ8S2pSdWOYJvyCZ9JaETqgShfnLTfefxYJudS BcnOqEfq9lHBjdTceSUu8KkSfZrUZNzEPtRRgp0QAW6hIRGwyBei9tC84kd9YUDl24Qq+wHIjOz8 JDb1xulV31aCjvRJjUml1lu+o4lvbbMPibhRgCTFk+bJyQo1zhQgF/IN3Sw90TWchTUNjpkyKvgl ixt+0WaaoynbUEsQLfcUv3Xp6fXZqxeM6FljMxoyi0j8euXd5f6SWiUhtqW9CiPScr2ijGySLkwP Kp9w6Dx7dVzl2r1IyfOonPuX9n1eji6TKb0cwngvoCTQcLPq4WgF1Wof0dDCPapzbYc7tHGmrae8 cYlsnavZbPUduFqlzSkS/ysxrmkJFO+KvlxGKEMHsFdl2JfjHZ4sdH5x5PjkWuQTdSXrSp3ZzdtT hhJjTe/PCpY8S5hAlOgGUQDsadKbBi6LG1a+g480C71xHQlhJ0bh0nnjc2ZyF6+9Oq9YaGU615EO 6B1FLhQrVCEqdFvbqx8mJpv2FfeXtB0rx6+HubrzjDzmOilsKoQerN8iM/i7uou1Z3F/JAh/csG3 X7dy8Kh+xQZmNX86dv6+lpy959AhtMqdruV+vi64TlRRcllxqnMWcSvGWjh7PF5CeSmfvNZBVoR1 SxucpAA+rxr1rz5/8BMZ1yx+uejBliLB+O27dwvvikhjVBe9+YMCZMpThoF/68MC/KL9qUaNWoAZ 2pPU8mMuAJg4Qj1gA4CX3ABARz2kBqHAKeofLbDNt/OhYQGWadP3AYAs8JHl0M75Xpb9f86zAAP0 H3cYq1guUOl5wB64S/13lBqj2gNuwIMd6gY4AbY7tSaAF3CLes4WuEc95wS4U88BAPuf8Q3QA8D+ 40f+Zl/nqa3vAreBS9Qaz53e3ACH/zHXf/R19E9f54D7f9oB/7t9Uee9Oy5bKoftH45/v68nwH62 s3/6ukY960pt70ltd5mK3lQ0prZ33ekf+BvjOsB25U9f5n/O3v6DntS6f6evfcAB6irnsBymlh8D OlRKoQhsnyQDQC4L2z8Yi2So684B/ABU9tHvVOSzbOvM9vE+gIGqFmeBbJbtq9EBFBKUitQloF7z H59dpHLtA/60olCWqFfbxu0Pz3Y1zU5z4CjN0X+oIN02/z9abB/fpL1Ju3v8eP/jbVWkjp9p/6bc NgL4ZbntmgN4HjHqqgWzAzgqR/o/2Hc+gn/w8B9UoP5t6zXjn/KfmQKcf7DnDwr8QaY/uMs/+wd3 +2P5g0f+4IE/eHBP+a9w/57ybrv9f4H/a/vtP7G/wbf9ObgHd+v3/UHbff+1frcf7T+o8wdpgf/K d+oP7vazt/2/wt3+duW8K0/6P7i7jrvn/2pef/c6u+Xd8R7/g8x78O+O//8Ud8cvv6d+V7925723 3bY+igPbNgUAJIB/6PXe8/9rebe//7fm9R/8D/4H/4P/wf/gf/A/+B/8D/4H/4P/wf/gf/A/+B/8 fwZ375ftlsX3lI/tKZ/8g3vb/Z8ibN9/Le/eR/yr8i7u3qfbHQ/DH9y9P7vLx/4H997n2nu/bG95 l3/3/uL/3fLf7f9f3Zek34P/d4/jX63n7z+C3r2PCgH+a3n3vvhuWfoPHv2Du/dp/+p+bNCe8u46 7uW7vaf8r+b1V/fPd/vfvd+/299fyZduD+7Vo912u9eR2MO/t/+9/HuvJ/oH967Lbnm33e592t3+ 9+oT4x7ce1//5h7k2FPebXflD/6d7ycq9/2j/6p9/1Mv/kqf967TXr6CP5j/B/9KTxv+4O59bfk9 uGs/dtvv6ueu/RD884Xmbn+X95TN/6DhH7z+B3fb79bvHVfRH3z7B/fKn3YPivzB3XlI/kHhP6j8 B/+V3lfuKX/4gxx75gXdU/4r3JX/7jrtzmfv9yRv9pR35Z2yp34Xz+3hy9xzftcf7Z5n+zNe0p/y 3v307+Kuf9st78p7t6y4p7w7nn+3vDv+rT+416/sxX/3Orv2ZlduYv8m7vrL3XGK/wXu9r/3e8F/ pSf/qt+/Qq4/uBt3wP7g7vXV9vDb7in/lf3cXQeeP7grR5k95V257C3vfo+5K7/d8WT8wdd/8Mwf fWX9g5x/cK8/2Yt/Jce989i7n07sOf9yz/m0P7hXPrt2Yffp1f/TfSW1p7xXX3f921+Vd+X6V+W9 /nG3f8m/ibvrvtue/Af/1b7c1cO949qNJ/6q/K/0f/f8Lv/pPeXd9eP+gy5/1onvT1n2D/Lv4d/V 893+0//gxT+4a3//x77+E4fv6rPqHyz/g4i9/HvK+/6Ma2/ctsuwt363nP8Xfmj3+/Vdee+2k9iD u/zsf9Of7cW/2k9/l///tLwbX/1d/r/Cvf7438Xd9fir6+193mH3OZbd8l913LhnXXbzPeu/WK9/ dz3s/qDGnvq/iv/32ttd/fpX49jbz258+q/k96/kqvsHb+7hZ/0L/r1x9b/i38Vd/7a3/uRfrMPe ce8dv/KfdQz8U97Vhwd7+Hb37W773bhr177s8u3mlX8l/127/3f1YhuV9/9P+V79Cz7ePfiv+j3z B/X/4K49/Xf19t/FXfnu9VO78t37/NnePHVvffUf3M1ntvmMaGjw92i3n3mix4sA/+xD+W81/1/g Nf7DS0c30pD/vuB4KLNFfWd2Zw9ukwLgGf7nM1zbn/9vjXfwvbMZl8cPzrL1u7Q89AcsKUD52D8e dcT/CST+9/q9kX8ufT0hFx6W5z+1P590mwIkT+zb6Tfn117e38bBn9nMGJ7q1wqde3m/5ykFOMFL u8Or/ol2D6/ZpRtWEQ+/sHFLiRZLaZ3zpQCqYf8Yry3uHxbj/9905//5Nf5vv98DVBj/oZOpTv/Y xbQHmfDbDvwJUOhAQ7Wog2Xb98W2j4N3jkN2uMN25By+0yJih6KA7ftrh2hWqeaBefvk0cM79PGO TX9Cs307JpBme32CaCgUChC8cxyywxO6EwCGNW3T8B3+iB0auUOjdmj0Do3ZobE7NG6HPt2hz3Zo /A5N2KHPd2jiDk3aock7/b/YOU7Zoak7NG2HptNQJ30WRSMACFHjBGrVwaadETbvjBa9M86WHc7W ndG27fTWvlPzj+fLP+3Qzzu0g0aR6iS+bHcDdO7UfN2hXTuthralAVBoDmzfOdsxCDT7Hj9+DOzb 19HRAdBu1xzdv2/76nT7VKhBxYEdSr/D+Y/YmGHnLOPOMdMOPbRTw7xzfHiHsuxssiM7x6w7FLpv OzZ7vHP8ZIc/cN+2rwjal04N9YN36kP24X8fAEJ3jsP2bVA7CN8ZD4oaVLMAjTv1TTu0ed9tKkXv HLfs0NYd2rZD23foxx36aYd+3nfKiyqZfd1s7MCXfacW5imd+85eiwC+7gMeUyVDpRRKN5XTl9Kz b/sB6d59Ry8DQN++K2gA6N/pYWDfEWoqMrjv3nOqDPe916BQvu3UD+/UY3bqKfu4qP57P+22uM/R vhWnAc7vGA4t2m24QAtvoAG0d2oQtNsaG7xTE7JTE7pzHLZz7Ml8nMBIFU70jqbHAKfsaQAEzfbT 45nbGkHJ2qEvd/Ti1c6qvt6pyd6hOTv1uTv1b3Zq8nYoimb7bvTwzjFmh47scH7f4RzdqRnboeM7 9RM79didGtwOpVDrGwG2fduH7DuUY2d9OJu3Obl2arh3KM9OPe9OPd9ODf8OjdihkTs0aocneocn Zqcmbmf2T3eU8NnOcfzOMYqWagwCz+6EFufotnXnPB2VHdD6v6i7FvAoqix9qqv63Z3qdBJAhFAC MiACgSii4ggEwkMeMcEHqENi0iSNIR2T6CKjEITRCCMy4gtkBGR01dVR2UEdZhQQ1FHRZUZdYcZx WT7X5dP5tPn020FUsvecW5Wqru7qVGuepblVfavq3nP+8997z30VGKNMpfhp0zAsfg3D6RQzg8KZ FM6i8DInlozZTiwZcyhmLoXz6K0Sur6cwlInQlBG4XwKr6DwKifKswBzb11I4TUkw7WUwnUU8zMK F1F8OcVXUMz1FK50umAuNFMuq0iX20mX1fT8Gor/BelyB717J8W0UHgXhWspXEe6/JJ0uZti1lN4 D721ga5/ReG9JPlGCu+j8H4KHyRdNpFUmyl8mGTYQin8mmIeoXArxW+j+O0U8yiFe0iXvZTLPtLl VdJlPz1/gOJfI11ep3ffoJg/UfgmhW9R+DbpcpB0eYdi3qXwP+itQ3T9Zwr/QpK/R+H7FH5A4Yek yxGS6q8U/o1k+IhS+DvFfEzhf1H8UYr/b4o5RmEr6cLdfVY5Ml0cLtRFxBhFonhnMYau1zF0U4yH Qi+FPgr9LtQl4EJdghSTRaFMb4XoOpvCsAslz6Ewl8I8CvviRhM4A3Nv7U/hmSTDAEphIMXkUziI 4hWKP4tiBlN4qQt1mUS5TCZdppAuRfT8VIqfRroU07vTKWYGhTMpnEXhZaTLbNJlDsXMpXAevVVC 15dTWEqSl1E4n8IrKLyKdFlAUi2k8BqS4VpK4TqK+RmFiyi+nOIrKOZ6Cle6sKVqhv4nFLzFtGgl J4OdFzPvMB6H1oOt5HccP36c1ZD5J0LA/RCWvwfjsB0ZBHF5Ar4GX4k4w7MOEnoWzWC490vDPad6 T4ZDbq+IvbNWeoZpJQVAP1DXQZAr8V0weRI+c/LDs13w1uaL91+28mI8Y8Muwymxmp45LWojFfC9 iJMdlwGf3NPOeOytDwu5D+ZA3isBbbwV4t+3tn6N1oQcqIdvRa3jU88utN8oziQ/imSZXYGajXbG VzwNydmVfsNqh1as+hOzO+RPzA4H/AZBjjTRkEeV6W8SS3v7DYGCpidz4PggbSbDcAg5LA3Pj0uD ySlDS841hPZdOcMobreMrJjCvNHJrGQUsd7qfJjH+pK7ZaTdOBgP59HTo9WncdR9BntiPpRBCZ3n wwJ2NY3eQZ3n0u68CL31U/Ut9HOnsmeKYSa7P41d43kuy/NKdjWdnTHXUkoD+5/FtCeukVJZm1Oj poLcWUT/lbD/5jPpCth/OB66LmcqoFYtfTlCd/XVZsm042osboxoyDX8EIMGz/uT9WeaHcJRzI+P PHBkjPmNJU6sy+EjAUEJta3fxf8Anh+PaQqXwhGZZ/5XmReWkaCwxBTg0OC2PYUZjG9S/Ak736xu LYwxCI7IgYR3L2FKxWWqMdRCeJWDF0LUp4YcLTy2ylrBBNhG+ZdSDhEGZCPlOJ79HY0rUMjgRnWU pCdwAnG7jCpqQ8XaYAClLfHM1vCBDEk23Amp+XNQnyDqlIwqKisqxhRxwF8djGCILlQHjoqYBg4W Qe9IlSCw9EWKAXiKTO1S/0JS26ZSdhYkdUAUHS9tzLkDjs+oGpDhpLhZRnS/FHEigEzqcHvbBqvp CBSUQ9ytAG0/pJgHHniAzl9lu2HBggV0vWP3brDz3IpnjuLTMhYWIcX2x4WgHZPIBG7g2x8F0LY/ 5mP0aYR3h4zdv9SbKLUJfKtU+qqpnO1UB6ukk3AjIBa5FMcPr3iLOpKPrlqO4pOW04CQTL8HKyFn s8RcBJZuP8apdJs689Wr2QnyNLfJQyVBoNdhiDCEZ8quix3FDu16ibhE1K7vlu4mOpawXGeAPuCm NVoCVcUCKJSSQ/3F0RDVX3yLqKT+aqYXy1l6YdA5iKwcTOd6dmdqQk70FPsf83BAGHMROOL4S6Rf 5YRXEDitMQ9EuJmlVZyQlgOyE1ILJaQWSkjNn5BaGDv9ki+AfHbEHey8weGJI4dxkL6sCTuNYnyi H+9L8eEktTeuDSAaDwf46D1g76Bk+DwyOKzGB1k8VhKi4I+XQ+JAxCqBCeNZjZce7GKFWBceOf+2 gB3bvxCc71H4PoUfUPghzTO2Ch7mWgkOlprnUtJ3D16yJmzwCawT9qCdWPKhuFYym/t8FELpPjJI l6NKtxr8cazXsLpwMqRn/GtYMEuXrQ4wtBJNeM6pczskjM6N5H3nkCEYr6O8ee3HWbZNRgRw8mm7 jCzhVFW4mK0C/W4mtgugOUqHDbX3U3J/4FzjdaZW+2k1IeqI/WhNx2JVxyJmgWWUdvPjTDt6dzWF d1KeOBTkSGkT1PpVirFnGUhpmSEMK9QHUy03IfZ7GCoMkB4WEDE+3G5E7AkZ25LCgqYaZU5FQ2WN Mq6gYDzChz6jTkq8Ehgoq1hIY9mnEQqHAYrpSVAceranQfE3+JUk+p8jKKijkQAF15myoEMAXWdq ik8jQbLATBBEAr3znRJHYoaKRCUjPjaXK5EWIE3GJsC5DxtkF2ngFp7f+QJw7a9njkAD+y/CXBH8 TsEoqKavH1TT9xYqoYa+VNDAriGthv2Ez8Xh0hsCyvSUwTqzVJkKmXUaAK3j+ff2rNN1dvk7vOxf lr2X7PI1SZNIUXSppkbqa2O3ROuqlZlzypTFN9VVNkVjdRW10aZopFFZHGtQKmsqGqrxgWHK9dHa WnaFNsWGTl0t5EHL4XUCkwGtugL42gBeNaBVscLVi73xjmC4I1re8STcEQ133Env4IEWWws6iy4z sGgu6CxCuZz7sIrTWHTX3RtssaiRpXWTDQ4NFN7J9oXfFMyV3eykEr5ld48o4ZIu+/9CTbgl7960 lR3WczFe20UbozEblR0ZJ8sAxZyktk2gtm3oK+a2TTC0bUI7bdsz0u+FAXlFTMhs1R/Y79c6ssyv IKVaDEoJqlI42Vlc0RBRKmujlUp9pEFZGquKLo5WYlx1bVRpbIqysCpSqzRFGptieFUbUxorayJL K4JlkcpYXVVMqY3ejNHMSXmU+kF8CVe2mg+v+HAUILHii4OOylwVlY0MlfEGVJbtCwupvJJMsHlD OCCMzHtQMmMDJB/Hpop+GXtjT1D/xxIbBIFBE+HQRJtitTHUHnPXFqJyvfFXot5LQC+q87SCwfTG qkorqujvOfcht3hRnc+627NZd3sKKMx7jbLiWEmfd8ECadDaQOe+oa3Zw/J2km/lM/CvLKkonneg pxXFF6Gfs9m3mSwzl2RKLIo4mDHuOWVyXd1NFbVKUayuuiHS2Ii1u1YitUVV/CrZ/XgcdEQERCSA fRV/vJn9bsbJK1gt4OjtHZPxnTv3YQPcQhNNG4X1W9fBfcLHL9fA/QK+/5AgNLe2bqJwM4UPU7hH yMfhNdLfqLkkYnNxqYiDGVH1g0IN7ByDcYBTNW32FCYxZEI2e6I4RIQMwoEQvlTPeiCE+6+fjdZq AhznuBZw+CbGJFlKHzxSqAGogMXEthjxDuXEcwN9woiPflTAcvXDTlF2T/vUUBNrLrR4HBKKMrm+ EI949B46YilKvIcuIQ3pCBRgD2iOh/eAprHzNrUHhG5U4TLeA/q5O4Me0LLUPSDHMqEH94CyVenM PaDA9r5Sb+4B4dyGpuNgVUe9JhqwVHStond7itvfCifglPgA1UQzSSZbPSD0HFVSeshbg1SV0GLQ G4JRGhhtBucNAVYVzn1YYHhDgFV+NRXTKFSxcxMNQIIFvT7NOia/kusJmfsZY9TcurufYfRaCwwy 9QyvdWwSQeP1PYKgCU1lfXhD3ubO8FqNXsO4JCg+aeh5UHS212AkR2ESIi/9S09D5EM4HOgXSk+O KZEG1t89V5keaVhaUXeLXXI8BQYHCqFQHag1YHagULg7qQbrDAcKXRPumPAvHFZ0mxMlQ1wcnIXX J0TdqQmSQ/NokDs0m4NoJO7Q4ND0sCYgh2ZcMJMhXWhzaOYbCOnABbpYf6pW0LpQ3z2LtPztMlx/ dtUfkZx4vYau9zBkBll2rTIhp94Js+f0vOMeJaTqkPkcy4muy+mXlXuiOZD0BjhU1wRD7Dh9k+CU aFMAJK4a4vE4VQgn8nHl+hhhjLDIscixQdwg7pH2SIjtlQZsRQtsJ7zc87At9EE4GVtMyQ2iC7G9 leKtsEUnTsXWw7FNRPdkh6CLI4kaupKGLmv5hwKii3UYd8VXCpjqHiGbIYeutZfVBFjuU2t/QMgX j2U96DNrj7I7SXspvtBgV5eacyOz61rQ7Tp1n7VdtWq9O6x7TR8sOS19zfqhRbwObt0fU3JOdYht rzUg7LZA+NC7PRVhLD/JCGON63F0RPk53CEYr2d3pwgcY5+KcQ7DGPsUxq7sVMSvrRQlOx7Vgfbx 6wf9UuCnIbYwsMlRLS8MmKUKdKtUQ4Io1ZCgWaqsbpXqHyTVP5KkCnWrVL/LQql+l2WWKrdbpbpN Rqluk81S9elWqYpDKFVxyCxVv26VSs5GqeRss1T9u1WqwyTV4SSpBnSrVNvDKNX2sFkqpVulWpKD Ui3JMUs1uFulKsxFqQpzzVIN7VapviWpviWpZoBxIB+oH6oNmq6iHHk/dKPw7osx1utcseleJlWY vcP7lca+pLmXiLtI6Di4CQoLD8LBg62wc+dO6iXi2lvsJRbQA9a9RO5DfD4a5VuxZq8QP/31ARne lK90AS32+dTJe4YfO3EnAu8Zoq/hDfGeYb0zuWe4lktFmK8DQ88wpPcM8WsnbV4uvmQYqkAfTGAe ycmY7F4Fn96IPthXLyFueL2Gro3e14/xu1LZD48X3Wdb9P9kN/pY6+lX4nAFelbzaaqNpiErlPqG SGOkrqlieTRWF9G8W20RJPpeeK17XnyAWttfiUgJ9Kd9ycjodV3hGCmMFK5wXOFYIa4Qn5SeJK9r ogFVtwWq0vLuQnUm81yTUcW33CqqXdvzS42hcczCo2JYxjDEdRQahreutcYwuXfQ0Ugu6YP8vCep D4D5ens0P6cYsPVaYFtwf/diiyxNxhY7YZ4OYWmm/avUSOIAclu7goIG9MUJvF2xalGMWqdrXbQx yA5tXbYMfx0nWtePwuk6fSl0MItnJdGYJHKMT7Q2zuKtzw3sXF/EW59i/IuHqfURZ2UwLsne0Vof XIml+QrjWTzyUJtotbMXlu9/tfIk3haWzMI9oPh8q5AP+epeTL4HcTXr1xeo700imzSr++34TjW+ x4vvjuL7iviOHI2hNf7h8oy8Gj8y9FySIzc0FFCGE7L6b8K4WcJtxwgsVwHkL471Jup+Xi/TvUUM ySH56rS6SwbdzzHpfrWh/nGYdG+GGZu/dNlHYJWABcW4h5jv8eX68h20fH8q130j0318m+6ImUII 7M0Igcek/Y7HnBtcdq0vJiAQjF9JsZZrQxX8Hh9eN9O0OKVosTYU6yiqfVj0BMcnVK6+AMOYNMNX YfjuZ7XSDNBH1uoPf+lqpuw4gnzsjO8KR1RSLRcQRFyW1oJqQBnDEeevrXbm8h24Gl5ZziOO65z/ 50S8cA9PSsaAfkjsjkPFy+ihZMGXNLbGZ1UeaVukZmaVlMSqvUd7PqsqPH9wrHG2eu2WK2eXsuoU 6Pg6VXzNC08+OsZQNvBpD2sUUzFJ09jtHSIOdv7TtsYuk8aLKTZxsSJeT59eNhe1PweSN4q0vzVJ guStSWaGuZLrrS8yYxh0A8P2Ssc8VYGCtPWWEW93lzJMMODrtmDYpDgyjCXQztImTeNsp897R+Ab Z1qNQT88Jo2XUmwiw3B+e3KxMpxvghuhES3QlgifADcSTWBEgySi4XPtEc2TRLSvv+35RPO6X/X+ m3+ixy7RvF1KtG/A0AGyIFpI2JUR0Ua5P/E+4s9LrzHoh8+kcYRiE4mGd0umFmsE01+nJtgGwfC5 9gjmSyLYBt+uHk+wUd793v/01/jsEszfpQQztpV+C4I9HciMYJd7n/We9l+YXmPQjwB0bFuZmmH4 XHsMCyQxrLxvpgxr7XKGbZR2yCNzXkvfckyCtmNklzLM2FYGLRh29RnIMMTOHsOel16QZ+Rsst1W ngud0lamdsrstJVZSUQrOLvnE+1TlzO0PDzSdls5qtuqMtmCaN8NMxMtvds/wD0ndEFYsq3xaJtV WUlRaXHnVmWhJIbVjOv5DLvQGw7dFt5mu7Ec06UMOwk6vtkWDFtzXmYMa/AuCQ0NL7StcYFJ4yqK TWQY2nL6VRq/xLZ3HRS2zy98rj1+hZO7lfk93xmrDf7W+5Z/a5bd4bAzupRfRm8/x4Jfz03OzBl7 NHjMu8W/Nq3GXBN+9DdpbOXtGyow/fWO9PZzkwg2YE7PJ9gi+T7vR/67QnaL85ndRrA8C4JNmJcZ wVbLp70v+W9IrzHoxwCbBJtf0skE65NEsN8s7PkEc/r7eTcHbgrYJdjALiWY0dnva0GwLddmRrAr /ZO8nwR+ml5j0I98k8bdMjC2F3Qg+lkBUZ4ZEJvE20W3c5WESpVTTsnNfun5qMswSG72HbgGCTQ9 JMCdNTifmr7J3wu6HmdY6FFQlZkeq8TPvKv80fR6jO9YPXAWU9Ojv4Ue82sy02OdGAkdy26U7BJz rImY5RSbQvcLOlZ3Vku16X6mhe7Hb8isBz7S+2F4YN7/pHdbDcpfaNL9BopN1B3XFuAYT7Bkqu69 +tqS4N8Zb79I4nOpYMDJxrYlmyoMXzEY8LtmHTGRvTXWGVPYAzwTsydmT7M98TQuAehErQf2Gq1f dV6SfUn257anfwpNWg8SdMrnW1BeujEzypd5xmb/Oe/i9JbQRYLzTJRfR7GJlMcFPtOXjVQuUabH lJHK9GUa7bPakuH/nkl62qNamJH+LR0UWCsEjoQ7xiJxoQGmQRYw3XpTZjB94ByX/Wzey+lNB/px vgmmxyg2GaZSDtONDKbSHwjTLDDDZPQTHTbvGAE0Lo5ROmRxjDahH+r0MrbJNVQaKkVtj20FTWXM 2KycZUGe3J9n1qR+4ApKX7lfdtslTxbYbFZiyvCieSVlI+w0K6mHde00K4N7TQW7JesF3wu+iGzX +INMxjcOtg6xGqpYmaE/lfWe77pAY3qZdJFAMRl/McWmGAprqy7M/lT66qIPpCv6RrsP7TV2rws8 43vGFwvatftZJrt/B7rdz7ZqWNdkZvdbAzt8b/ur0sukiwSDTXavodgUfjTZHVNU7e4BcHSA5fFf rNMwGGaBwW9aMsPgBXmP/59Z622PogwxYVBNsckV3/CZdQr61CO0LoW54ksEgXcp2q/0sPjf7uQQ /OQHt3ur1DmGQNsIikb7rB8wjpJZQRjr/WP4SHin7XH38aaCsBv04j+8w4v/u/gvHHRGmy+eEk4J O3xmDUb0Gg02i88Hnw82+bTBCU2DczrE+0qsgvnS5M7R42lfwLEr+HSSHiN7mR4bxCzHi8ENorlJ PLfXNIljXHt9e32+9D7nJGg7ZLB2hUZZNAdT78msORjo2s9cIadtPzgENl2hGzvbFRrda+w+wXPA d8A3wvbISrbJ7sbZ4DEWdn9oY2Z2L/Yc9d0bGG17jCFssnsVxaawe6zjZ4NfZ+cp2sfOTLWWBI/t UDLyBLA32dVzKW/61mY1hvJoS/5p0K051sKaBx7MzJrgOySUSsfT+hiGyS1wmKy5hGKTV4+UTZld gvYcDcmrR7h+rafpeama2ZT7dDy2vRUkRpuOS7Ip/hsQPd2mURcE75FLPajNFtBtWhhP3F7C0dI2 meQ+vMvFZbdjX0Gc27a9RMvX7cCv8t4poq1DFK9vAg7CrqTNIHiYR5DO77S2H5/v+Bq0WSzPK88r sb296gJTDWrU/YJepnuLqMiT8lpEu7pPMOn+PejcnGBR37z/68zqm5d8f8o5J29b+q1+hvpmuKm+ iVJsipXdRUVadaO/zdlvr7oRIXV18wdBB+FCCxBqtmcGwtXBeuFe13NZqNA1lFmiQoOAV6AXKWWR m6OVEWVKRWOkSpkdq6yoVUpitdFK+mjgE4D1j3a4KAFSAX8KghrLf6W/6+zguwKD2dhTR82ekuuB S6nBjOdEb0274/wBd5JTwwNN2GAw4UVWXtAzmZlwglwvj8vbFkIThlOYELnMOHmRai6lSPvnDopi dU0NsVq031rAtQ/akR7l9PbzZPxuagthq+MEOxbyJNzxGO4Ykcd+h9ZWX9xb22r3Pd5S2zMQOWDd fkzsZe2Hx/+Q5yHP/7N3H/BN1P8fx7/pgLLaUqbMMMoqFJC9oYUyZJShOBAIUGi0tLVNQYYKoogb B4riwA2oiAMQAUFQRMUtCrgQF+CMiuBA/q/vXWuTsz3LmV8eD/9+PjyeBHK5u9zn+r5ccnfpvDKf KNbUZtl7/cuWPb5SZmxm7KIyL3uizbL3/pct+8GKS2MyY+3fEwQuezObZe/zL1v2FfGLYybGrrBf 7/2Ll715Ccte9FrT1/HnDGzrpoZ/W5cZ0zVqUXSLMn/aUN1m2VP+Zcu+J1ov+9Iyn81Rw7LsRwOW vV8p+xjjNp7cPsbm6NZRX0Q/UObTFGqq4H3lyca9pV4F2UL9dV858s8PWoqPMAcebCltLznwrN3U Uha/55aTW/xhMU2jPoruZP/jGLD8tSyLX+pFoAPSQ3/W7lxXcQP6l9KAN7adXANaxG2NHGW8/lb5 vp4xs+CF0afVpaWwj5mWlTOz8D1C0X5m0f7lKUUL+Df7l1G2Q+3HLV/C0JL3L/WZvYH7l3quJ7uf H/OXIbr0OtgesA4GlLIOPtt1cutgZ5XMuFU12sUZeSphHTRX5pVSf+7oe7KLV4J7VEFWhjut8Lef Fb1la6GKyn6nvqLt0Bjbofars+wrLFfZvWULXJV/XS1/v5JLX5WBHz2klbIqfXtPblWuqLS0cvfY xbYnaQd+9FDbsj0p7aMHIvi/+ehhkCpugks3oXJxE+Ybi1z0RYvFX+9f1i9atPs6/u0H9Pyvqrbx gL639K/CWmYMN78KK7n2DtfyNj8c5p9JugvrlqxJbqj6+8fu049p7nebixXw2X5hHVlr/Ip2lo55 9vLrc+T6ulL8xhZHP309kQTLRHS5VEDdUs34Rbi1S5qIuU76+asXjhQ4on42fVSiv7Xxvxb++MLh FQIeE6d6+s1PRV1JRat+RAnjVPybcfSCzDGeTPCC6LJ2RT9eL4gyxkv01zbuNecVWHqh9XSbhHi6 5vD+/leMCZR9uv1UQOP1nYtV4X/0Xt5yFbBK1qiAh7UrGkdPrCxP7Jjxr+AnFqmCn5iemH75K1rg ONXev9wY0t0fo4p/GOJ5JvoX50XOMH6XlldNMn7Xtx6hlT/HGKGD8UQCtg1GNVS9/UnGv1L8TfQE 9C/immWMnKyKJ+Y1fhmXHmL+YJjbmt9aVS+cjH4O+nDOicIqy/JXNTplv/w/uazLn+TfawzpaPxw 6kl0VUUrr49/nDEs1V+8mCl+/T2IkU1ULn985F9/6aZu15+zMh99MLIsj9btNDc0ZjuLDwuZpdtZ o3C+OsGRgdMpW+P6+09x2JhPjCElN2aKMSy4Mfq31US2V0mqeHEzVVvj96CUvUGzVGgaVPafrP7+ lel6SOg3QSNDPF1zuGyCwrYJipBNkLNNUIRsguw3QdYG/aNI6xRLpO0jHVH4HPT3Veoqr8q2/P/5 SJfcOIm0+rsGSaTD9CodJa/Szl6lo+RV2v5V2togiXSYIh0tkXYW6WiJtH2krQ2SSIcp0uUk0s4i XU4ibR9pa4Mk0mGKdHmJtLNIl5dI20fa2iCJdJgiHSORdhbpGIm0faStDZJIhynSFSTSziJdQSJt H2lrgyTSYYp0RYm0s0hXlEjbR9raIIl0mCJdSSLtLNKVJNL2kbY26NmTjHRH5SzS/8UUuyXFzlLs lhTbp9jaIHlhDlOkG0mknUW6kUTaPtLWBskLswquEKa4taTYWYpbS4rtU2xtkLwwhynSbSTSziLd RiJtH2lrg+SFWQVXCFOcLCl2luJkSbF9iq0NkhfmMEW6rUTaWaTbSqTtI21tkLwwq+AKYYp7SIqd pbiHpNg+xdYGSYpVcIUwxX0lxc5S3FdSbJ9ia4MkxSq4QpjiFEmxsxSnSIrtU2xtkLxJDlOk+0mk nUW6n0TaPtLWBkmkwxTpVIm0s0inSqTtI21tkHxnqmyCSvxBSZNNkLNNUJpsguw3QdYGre+mh4R+ EzQhxNM1h8smKGyboATZBDnbBCXIJsh+E2RtkLyxCVOkq0mknUW6mkTaPtLWBkmkwxTp6hJpZ5Gu LpG2j7S1QRLpMEW6hkTaWaRrSKTtI21tkEQ6TJGuKZF2FumaEmn7SFsbJJEOU6RrSaSdRbqWRNo+ 0tYGyQl5KrhCmOLGkmJnKW4sKbZPsbVB8sIcpkg3kUg7i3QTibR9pK0NkhdmFVwhTHFTSbGzFDeV FNun2NogeWEOU6QTJdLOIp0okbaPtLVBEukwRbqZRNpZpJtJpO0jbW2Q7Gur4AphintKip2luKek 2D7F1gZJilVwhTDFvSTFzlLcS1Jsn2JrgyTFKrhCmOLekmJnKe4tKbZPsbVBkmIVXCFMcR9JsbMU 95EU26fY2iC5grzkrc5//qO5rrIJcrYJ6iqbIPtNkLVB6Tqj/4NN0LG++n+h3wT9ox2fk9gE/Re3 Op1lq+Nsq9NZtjr2Wx1rg+TtiwquEKa4o6TYWYo7SortU2xtkBypD1OkK0uknUW6skTaPtLWBkmk wxTpKhJpZ5GuIpG2j7S1QRLpMEU6ViLtLNKxEmn7SFsbJJEOU6TjJNLOIh0nkbaPtLVBEukwRTpe Iu0s0vESaftIWxskkQ5TpKtKpJ1FuqpE2j7S1gZJpMMU6ToSaWeRriORto+0tUFyKFoFVwhTXE9S 7CzF9STF9im2NkhSrIIrhCmuLyl2luL6kmL7FFsbJLvXYYp0A4m0s0g3kEjbR9raIIl0mCLdUCLt LNINJdL2kbY2SPa1VXCFMMXNJcXOUtxcUmyfYmuDJMUquEKY4k6SYmcp7iQptk+xtUGSYhVcIUxx F0mxsxR3kRTbp9jaIHmTHKZI15VIO4t0XYm0faQDGxSnIpJqx+jHxiS1Mx4RmRRf+DhdETzWpVzt XKqCcX+kKk6JUqWPF2kZL3Acu/GiHM4v2uF45RyOV76U8YqqtPFiHM6vgsP5VXQ4v0oO51fZ4fyq OJxfrMP5xTkcL97heFUdjpfgcLxqDvtZ3eH8ajicX02H86vlcH51HI5X1+F4DRyO19DheI0cjtfE 4XiJDsdr5nC8Ng7Ha+twvPYOx+vqcLx+DsdLdThe2t+Mp1RerdbGffHm2Nze7mH3nNvc0Updrdzq m+5KXT9EqbER8erYNP2oI3F6vyOTPfy9tY1JquuWuIzpzonQz+XozDh2gD7vrqd7KLIF98+rqdR+ PYsEvRsVxUMrcVuZW31ndW6rcVuPWx6omnKrd3dac6t3z/7gVr+dOHScxOnHIT0vIz8j2+eZ7c3J znDnF7jzJ2dm5E039t71Y/T+9JiMrIzJOdPdg32eLK/HnZ+cm+xJVmYX9n/gMm4bq+KuGItSyu2e 2pWM56yrtNsGLIx+n1EXKRlZWe5UnmFGdrbXk+UeXTAp1ZPr49kaT986OCUna8pQb77Pmz1NlWN4 vzzuVeX1Iz0+D3fqPo3xTs/Idw/PmOkelTPdk60qct9YxpiCfPZFWd85edM9Pve0PM9U7+Qcd25G njs3oFFet56Fr0D/m5ao+owyiiZ58jPcnd3fLVju7jAwPd1ddFcXVZnZ6qejO6p3RFM9eR6fLyPP 6y7webO8s2d7fF6jPUUPSsCwnCksXY4735dX4PMV5Hn+bLB+RDVjQXw5WV73FK8nNyff6/POyCjh J7O0+jnOzd96j3fC1hs+3cR6jFE/RUaqfe3atevWvku3jp31OmjHn26qverC3x1VZ/tJSklJSUlJ SUlJSUlJSYW8/jihVLRxcDC49Hu/iN2v7r4juW78TbfGqKTWv6zWn2jkRpifEejhi5T5Xnyx0p8y KPWUMg/RvaPMN6AfQL9l/kyZ78O/RgX8BP1e+XfI5w/y+cM/+/xBSkpKSkpKSkpKSkpKqmwVfPx2 2xI5fislJSUlJSUlJSUlJSUl9f+tjOP8yjymrY/d60se9cFbfahZv+/Xx+v1cWXj+Lwyj8PHKvN4 vz4Gra/b1Qd59WFc/RmCPiqsj9nr4/r6mLu+zLOOMo+B6wPd+hCzPuzbEG40UuYx9yZoikQ0Q3Po KxVaohX0Zb76yog20Mfs9dFtfT5Ce+hrPjtAf4VBJ+hPJ7oo8xLSbuiOHuiJXuiNPuiLfkhBKvpj ANIwEIMwGENwGoZiGIZjBNIxEqMwGmNwOs7AWJwJfTnp2TgH+vreczEeEzARHkzCZOjLXPVlz1Oh L+zIhBfn4XxkYTqyoU9syMUFyEM+fCjADMyEvmxXX5k6G3MwFxfhYlyCeZiPS7EAl+FyLMQVyjy/ 40pcpfSVJ0pdg2txHa5X5nkfN+BG3ISbsQS34FYsxW24HctwB+7EXbhb6cvRlboH9+I+3I8H8CAe wgqsxCo8jEfwKFbjMaWvYFfqcTyBJ5V5/slarMN6PI0NeAYbsQmb8Sy2YCuewzZsx/N4ATvwInbi JbyMV7ALr+I1vI438CbewtvKPO9lN97Fe9gDfb33PryvzPNhPsRH+Bj78QkO4FNlnifzOb7AlziI QziMr5R5/sw3+Bbf4Xvo66d/wI/KPK/mCH7GUehr9H/Br/hNmefbHMcfOAEdfn31fwQiXeZ5ONEo h/KIQQVU1OfnuMzzc6ogFnGIh74OPgHVXOZ5OzVQE7VQG/py8Dqo6zLP56mPBmgINxqhMZq4zPN8 EtEMzdECLdEKSS7z/J82SEZbl/7SAvKPU9EBHdEJndEFXdEN3dEDPdELvdHHpb8ogfwjBanojwFI w0AMwmAMwWkYimEYjhFIx0iMwmiMwek4A2NxJs7C2TgH43AuxmMCJsKDSZiMKcjAVExDJrw4D+cj C9ORjRzk4gLkIR8+FGAGZuJCzMJszMFcXISLcQnmYT4uxQJchsuxEFdgEa7EVbga1+BaXIfrsRg3 4EbchJuxBLfgVizFbbgdy3AH7sRduBvLcQ/uxX24Hw/gQTyEFViJVXgYj+BRrMZjWIPH8QSexFNY i3VYj6exAc9gIzZhM57FFmzFc9iG7XgeL2AHXsROvISX8Qp24VW8htfxBt7EW3gb72A33sV72IO9 2If38QE+xEf4GPvxCQ7gU3yGz/EFvsRBHMJhfIWv8Q2+xXf4Hn78gB9d5tcqHMHPOIpj+AW/4jf8 juMu8/y5E9Av/PrUvwhEIgrRKIfyiEEFVEQlVEYVxOqrCvV5gKiKBFRDddRATdRCbZyCOqiLeqiP BmgINxqhMZqgKRLRDM3RAi3RCklojTZIRlu0Q3ucig7oiE7ojC7oim7ojh7oiV7ojT7oi35IQSr6 YwDSMBCDMBhDcBqGYhiGYwTSMRKjMBpjcDrOiNBXZ5J/nIWzcQ7G4VyMxwRMhAeTMBlTkIGpmBZh XtHpxXk4H1mYjmzkRJjnYl6APOTDhwLMwExciFmYHWFeCToXF+FiXIJ5mI9LsQCX4XIsxBVYhCtx Fa7GNbgW1+F6LMYNuBE34WYswS24FUtxG27HMtyBO3EX7sZy3IN7cR/uxwN4EA9hBVZiFR7GI3gU q/EY1uBxPIEn8RTWYh3W42lswDPYiE3YjGexBVvxHLZhO57HC9iBF7ETL+FlvIJdeBWv4XW8gTfx Ft7GO9iNd/Ee9mAv9uF9fIAP8RE+xn58ggP4FJ/hc3yBL3EQh3AYX+FrfINv8R2+hx8/4Ef8hCP4 GUdxDL/gV/yG33Ecf+AE9E6/CxGIRBSiUQ7lEYMKqIhKqIwqiEUc4lEVCaiG6qiBmqiF2jgFdVAX 9VAfDdAQbjRCYzRBUySiGZqjBVqiFZLQGm2QjLZoh/Y4FR3QEZ3QGV3QFd3QHT3QE73QG33QF/2Q glT0xwCkYSAGYTCG4DQMxTAMxwikYyRGYTTG4HScgbE4E2fhbJyDcTgX4zEBE+HBJEzGFGRgKqYh E16ch/ORhenIRg5ycQHykA8fCjADM3EhZmE25mAuLsLFuATzMB+XYgEuw+VYiCuwCFfiKlyNa3At rsP1WIwbcCNuws1YgltwK5biNtyOZbgDd+Iu3I3luAf34j7cjwfwIB7CCqzEKjyMR/AoVuMxrMHj eAJP4imsxTqsx9PYEKnPcT9xYiO3m7AZ+qvxtmArnsM2bMfzeAE78CJ24iW8DP1FXLvwKl7D63gD b+ItvI13sBvv4j3swV7sw/v4AB/iI3yM/fgEB/ApPsPn+AJfRppfWnQIh/EVvsY3+Bbf4Xvory76 AT/iJxzBzziKY/gFv+I3/I7j+AMnoN/w668Ci0AkohCNciiPGFRARVRCZVRBLOIQj6pIQDVURw3U RC3Uximog7qoh/pogIZwoxEaowmaIhHN0Bwt0BKtkITWaINktEU7tMep6ICO6ITO6IKu6Ibu6IGe 6IXe6IO+6IcUpKI/BiANAzEIgzEEp2EohmE4RiAdIzEKozEGp+MMjMWZOAtn4xyMw7kYjwmYCA8m YTKmIANTMQ2Z8OI8nI8sTEc2cpCLC5CHfPhQgBmYiQsxC7MxB3NxES7GJZiH+bgUC3AZVmJhlJmZ /1UdL6MVhc9jFbcP4xE8itV4DGvwOJ7Ak3gKa7EO6/E0NuAZbMQmbMaz2IKteA7bsB3P4wXswIvY iZfwMl7Brijz+WiX8+8SF+5fVqNUDn98yq0GqGxu84xPjMpeNVW0q2haepMSf+38KctGvF514WG1 Sm1oeTDwscvHN415sGCH67Uo82dPV7ryqsnMt4A5ZxifYp1cJagIY/56d0bf/l971wJdZXGt938e ySEPzkkOIYgKf1EERSk+i9cHCQkBFEKEqMVnjkkgRwMnN0m1er2XgyBPURCFilRArQItt6h93HJX eYgvQFpAqUWppSxXy/Leu3psva3Ywrmzv5lNToYckxR6l13r/JC9Z/Y/s2fvPXvmn5n/nzmdZjDX vpZs4DKUzGVPhxVuVDLUY0Wta1dfNYlKtWfnOfSa6XAT9tMkJcE09S8C249VckxRNdIMSquyTgzr femuwUp/h/S6bXf057UAvqoU//ugMYeixgrlKlwLubRd0l+Djf27o/8mr95vxZf/pLK6Z4/hqnx2 pe6Uz+vbPPc4XVd39T/d16mVv7pYew+v8vOKOrdi4xxOUI0teNb2VXormIf7+/jBj/tB2p/9FhL+ OFhOvIpeT43qn6valK5JhtNVjUVA5Xq9S92L4MxEqccwCmJeavwxINRFXiNV7kaqo3E447MVfjvV 6CO8XMOrVPmOzkd/Ky+lt8jFPhgxKbrPayb5CksMr2p1dxr6PJcqFb5PYe6Np4E/dUGurMIqw+tm c7fOYO5Hu8PLgzWf54P8ZieO9x/JJM6yPK5G5MFCnfB7Q1W996KPaLhH953rguwzHPZgnFhCzwW5 ND8lj/H7FVUFeKfBl2C96qJzJZO/V6WJ/+LEVdOVuY4r3YNKr3NwuMbLcyYdjvv0MySoxqafX4I3 Uok/8Ksgykr0GaRqbXaYDvv0Gwg5yPNsg3sazG+M2K9zTNxoSkUG7zX4LINlZ6ek/9hg4Rc0OGRw lsEBK54O+6y45POlwan5+W9QF9LxFbCw0KVTjHja04XPKIMrDPZS+3TDDBY+dv7OsPATO4s9sw2W epT76fTqajkSF3kHGJxv4a7Kf6pY5L/Uoot/id52PvZHflPKbyD5bellHdxPjQu//y+9MjiDMziD MziDMziDMziDMziDMziDMziDM/jvg2W9TOLnW/GvWPHBBtv5ThXf6Wkfl3XEdHHBsk4n8vQwWNZn JV3YYHudy14vs+OSXtYXT7f9hX9n65LZFj7dcnRWn0eNoWUdtT+1j8u6uMQvMtg1WNZp063HzrLi Uo92ujor3ple6dbPhb+s9wu/dPb1W9j2I8kn5Vxgpbf52+nt8gYabNeLxCWfrNMKf9ufcixsr+vX WFh+l0zikq/K4K68n+CvK5k/f2FZmEJPxbad09lhvcHrDE7np5sNlnXtSy0s/YfkF/+U/uNs80JT +FVa8ZsNHm/w1w2W/EK35fqewWsNtu3vtfC5BoseQww+x+CvGdyZ3//Iiv+Hwb0svUZY8XRY7C/1 JPrY70lesOJi76csuuBSK90z1n15Hsn9QiPvMRO321N3sTzfJC72lvjlVlzk6W5c5P+LwfZzxcbd LUf6G7HboG5ieV6KnOenwcLffi/YmZ90xjcd7m2wjDvuNFjK/ycrfcSKp+s/pR76GCx2HGrFxS52 XN5jiv1Enm8b/KzB1xh/LTC4yGD7eWLjdHa09bDb03nW/dXW/acNtu0j/YJj8Km2qwutuO2v8nxL Fxe7povbz0fhP6SLWOpd8h83uLN2KX5oyyXjiXTxzvxf7kv6i6241F+xwfeYeupr4l81+Ewrvfi5 8F9p8BiDpf890a7NOFz8+UqDf2DwDDu9FfcYuexxmySw6RJfl+Y5JO/Xxd6S7wILS/pwF59nNk7X nrqa/lTjMr7qavp02H4edxdLfaQrz/7eQb5jkXg6xlutepH53u1p6qu79VFr8NUWPd343+5vxb86 k8PmI+PTzuzXmV1HG1xjpS9Ik94eV3eWXrA832z64DT1YMtty/81U48Pmbj4g3wRKumk3Up+GXdJ /yLpZF6Zzv7S73fVLxjzl/5i3xvSpDvDwp3xvcbg6wyW/rS7fttdLPa1n1NiX/v7M3ueatN/YrDM ZzjdBMdJ8M4hD2UnzqWOrpM/Iv0ypJ1o0vr9H2xet3H9gDn5k3+6+7ndew9/nqREj7ZvuPj6csn7 i41339T7nz8qeuVPjd4+2Vm3JOkHH+pPHRNmIPG38b1tXenKPy39zoNzX/zX3/rWHatL0vJDHvB9 /oid9ujE2TsLb+qx+Lr/7Fe6unnv4iSdd4YXaa/a4bXS3jTutlvn3/t2YfGFAzdcWFZ6f5KunKvl jRzWPcY/mu/8/ev42gWxB7f+teb40qkvTek97fzVSRqeo31yRVS3Ym8gN8EP8Jn03amO6lF/8Qqv i3F4NsIPI/XcE7+sos/e0CdVBCnP+VR1D3z6Ark9AePo02fyBu4A7+B3aBZ/iY9d/A728ZM7BwPA udsYzkP6+YALABcCPgK4CPBRwMcAFwMuAXwccCngE4BPAi4DXA7+30L4KcAVgE8DruQtpiVbnLOo nxonKFJgGyR8FdJuh5yvIeXrkPYNcHsTFP19+Q7AnYC7nMsH6p34AezF17vxiX6OXO/hl2ySThav nKFDcDzxeJw8nl27dmGPO7m8y90hv2e4GlRkAWYjpR4b98DdHIRzAfNAyUe4J2AQjSyEcAEg7yb3 Yj+13lGt6tfDz4pZnpUX633VvLM6cTQLe6t5d/WfFYN5kGeLGlQHsRdZ70bm/ch1pHck6z3Jeley 3pesdybrvcl6dzLvTx72Dd6hvKcwTG97hv3Pfyd3e0qq5/M+5Th2KseTSd6rfH9yr4c/kN7ncSt5 x3LVdr1nmXcthwbxvuWmJ3jn8sark8lfgn4A9PdBT3p6q+e3jw8KoVLv2vMd7JvlnbOMyr0Pbnaw e1bvLQ3SbFAeBmUOwnMRbskf8EmOn0+TYU6LaFi9g9MoSugZ7CRZBbgafrEGtfosKM8BPg/6d0B/ AZQXAfk8B5cOIPw+4AdIeRApfwXKh4C/Bv0Q6L8B5bDewaLoW6nQw8EwYC/UT9GrnLI3KMWAfUA/ A/S+oJwJOB9wAeBCpHkEaRaB8hi0XwwnXILw4whv8arO4KESDC1K/ew7I/0qOZUxxS0HfdQohhWv MxwNyhjAsYDXAV7v55Yxzs8tYzwolYATkKsK4RsAJ/IhLzQJsBrwRsCb+fAHmsylJ28BvBUy3AYO t4NyB+CdoNeAHgHlLsAZ/iyqpDhKmQldHoIus5B+NugPQ5c5yDsXlHmA8wEXAC6ELo9Al0WgPAr4 GHItRngJ4OOQfCngE4BPAi6HLk9BqhWAT0OGleDwbVCeAVwF+mrQ14DyLOAW6LIVpWyDLq9Cl+1I /xror0OXN5D3TVDeAtwBuBNwF3R5G7rsBuVngD9Hrj0I7wXcB8nfAXwXcD/ge9DlAKR6H/ADyHAQ HH4FyoeAvwb9EOi/AeUwYBK66OG+6hyVLp4s1sXLFNcHur+CYdYbDLNBCQD2AMwBzM1iXfKyWJd8 UHoCBpErhHABYCEfIkRhwF6ARYDFvNGEzuDSk30Bz4QMZ4HD2aD0A+wPugv6V0AZADgii3UpQSml 0GUkdClD+nLQR0GXCuQdDcoYwLGA1wFeD13GQZfxoFQCTkCuKoRvAJwIyScBVgPeCHgzdJkMqW4B vBUy3AYOt4NyB+CdoNeAHgHlLsAZWfykilPfT1y+pbTQO7gUnqJGh4kEJd9OYtxx5MgR1UP2+yRE ehyiyg8wjZ8j/SkR1PsJ/+jlNzx8VlfKzCJOKfceSbnnN/eCtCebz3noT0mkUVr58qjtYl37Uy+f 3gVT5OM0n703MIt2rrhq+/UzrmLMD/Ygfe6dijTHvbJSQce8/LKDj0+rS8F8bW0qdD5dFqaizXmy 3kqJY8nkTq5NClMT/cUrE5+mAJ2IszgluSxS2uKGmWIEc5ZA88nFTTyqeockd/3ti9uT2744XvDr T2Hf1Sll1Fl/7vIwrbknb1j1ujAd6S9vMlIuJ6x4BE6Nh5IzSPPCt8La88PngbYpyF4xUo1GS1XL KFOz1WqaoOaSm4LsdpfQFXQZUg81qXnVfYxKUU2TqAq4miar0CjkYZ0rsTuvHrmuNbl4nFuu0lTQ WHV/lAozrlRl3qRCoxXmUieCB88/K7AnrgVcFoQbDBf8zgD+Val/1Uo6/mUBXg9dGC4n1mpesbbQ /GJ5SyYXn6fDS9jsaw5jQ3+3tC1N3OMc4vL0yoO2TGp5F8MnFob1SkC+j7Vt+qH+I3qJjw4jZwQd COrC3w/qxjKEXMXMJW0a3rbnqgrTmxQHKXyv2VoYUyY4EMxrl/capVQiiB7DNEI+HIjvsT4NGGjx tSooDZNoNcqfiBLqlSFbUOIV6u9QwqVLlblZHfekFPwCcU2QVZSlYlkMAG+fLmy2XsjwBVPuhEz5 2qhr4TpVF5VNKqtgjrzgbxYjQnygIfpF5Woe9S+k8/hqyVH8vaAQrUdVZ5k/PipCqktVnM8siPLA S9acT8P1MbqBIH3m3ZHL1v29l18EoEo92T1OLFbjyhtWQ4lsl7D9EJRly5YB/7EgmyZPnozwc5s2 UVfS/duGQ5w6yI3F6WD74y0kVwmqIJv09keHZPsjH4rJ7ylCigtP/zreRCkv8NNxKTZcBvrNYpXv MxwR6VE5B/pNZurhvd+s5PNQLezm+B7AglAQ8QFuyB/3qSGC4ttH+dQXbersZ0Lj2skTPyEPWoKD 7HSOc44u1M9HbFV4JHy3926vhBf5FsEdq1SpY6htwU0eWg66YgdHB6L9IKat4TUxvUXUZ2JxZKxR /AqpzQfZKwcAN6k75e1KQir1n8vw8AEDiHEZHPMiVgN75ZN2ay6DLRxXvCra8fJQQTtuoXbcQu24 5bbjVsiTft+VAfZnT+LiAB+3FUiwD3N7ntTKk0Zv4p5svu9LDIbUPRKygJh6eSgH+fh8QJaM07MH Fxp6Pp8bmMNHQOYmaqj9QsRM3lwf4MMBKcBTrJCawrPP73J4YrsP5nwH8F3A/YDv4T1j0gmooZXD p8sFRkBfPnQroB5hAz7hPoGP4GGVQwlpmfHeB0Ms3cEU6cJGulmUm+B+jbsLv7L0mBcLHVu6ArPA kISb6JI7Lm2PM7RXfdFfPUHKT+jjBHTvp71sNZ9uh5dPa4LsJdpVXS1m0kE8Dm93SAZKv0zpvdcH +5L2NU7jPdH7SU/IOjJBdBxtdCxTNfBN8N7zfaUdeM0CnIsyeSnI02GdsNavgtK1mqEOa+YcZSvW h7nWWBb7gJb4vLkbHbZYOWRKtdiaIA8OUQQuB3/ZNFNBPH+Os1Xy6GQ78ID0ZZ+2wxhjh1pV1/yE mKEsESdfKfd6/m38DMqC/NnOSy//iLTud+GgCD7AoxVb8y+iqdjwPxVHDNRSAzbnN+PA3C/Sr4/z X97BvjcdlmlBikzXp8hUmSKTHzJdkCLT/EWLuyRTC4676Fyis53dBTmFOyCRN8Vbxp3kLSs3fSm8 xdcm+++ooXBe0ePwFv1yJtVb1gZ55DE+0lwbcxk2RFuiMXGiti6MQ+JE+s0Hm6JniinGn9Q5OOgc zt1sdw5OSufgdNI5bPD9xDmrqEwJWWA61O25MhNQHTOUmpeilGOU4rdFFZHmere2MVqLH1ueFquL TonWMm1qY9Rt4R9JduvqG93W+pbWmGt+F7m2oX5aJH9SfW1sel3MbYzey+R8omfRYPQ3MAWmnPU4 o4GnUXo4Js2IzwIWq1QaqyxVVrkixSrf3FbodNStd8c2bzqvOUOKlvts2xDk07apQyx1OLsWA8i0 tsGPQ0cb67Vp+MegY6w9ly5f8mm9OdZe77upralOkIah9ObhszRVfqvt38a+pZtqtZqvjFPzlZHk qsc/nz9Ui/MxuEGmaJ3izsWhVQXnFb2Mh9ML1GZph0vM46FNbiKu4nFe66ZZDi/2zClln527jTuv eViXXuo8umohPeF8+NMGetLh/N9ynHgy+RTgCsCnAbc4/Xg2joaX2uR8Xn5hNMLLc5+oOX+kWeGY mkddkiq9U6KaZKiLA1eeUbK9eN6kv+xJP2/Sj7uPh4rf87SIzzWvSDmjx0V3F6EpsG0MVmY5GetT nvRkKUIPmHNgouqenEzCZ0EJnWeQUcW9uVj3BSH67ZMOLVT4HT58l/4XPQZPoQ70IS//dt3zB/W8 8F8wzvrzfZS5vvDSfVr78//5fDNuZeyh7G/8AE93/r+ch5a5/jGv46pr8DueDv3i0MOr/nB0QkPo u0sCNGTQKwe4BxinOzzcbyDtO02kfWct6d75LdK+8y5p/zlC+ouWT0n7En+NyP7kGl58rjv7FZ/X zn7F57Az3498+rciuNyKWPO0SKs7tTminhkxPECamutb6qe3Rh6IxqZH3ah6grR+g8ORxqjOx5P/ 6vpG9Vyd5o5tVeSIO2lo09BS1q8fta2DchinW5nfu0y9f9nll53gNT5a2xxriU1pdati99U3V8Wi 0/EhTAnrUjf+Dj6HkMPxiTf6Z63f5nB4j2fDlpEbXkN44/Qwzr/jtnatKfuL7O/Zv3v/yqFnhpYu V/a/8Oi/sx34zOeQuc9jEOa1mLTd+Cs+lpntzk8BnkZxfXxEuj749wO4PqQe+PcA/g9QSwECFAAU AAAACAA0W6w0oWX9slz5AQAAoAkAJgAAAAAAAAAAACAAtoEAAAAAM0dQUCBDaGFyZ2luZyBhbmQg cG9saWN5IGV2b2x1dGlvbi5wcHRQSwUGAAAAAAEAAQBUAAAAoPkBAAAA ------_=_NextPart_001_01C675A6.9A4BCB7D Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime ------_=_NextPart_001_01C675A6.9A4BCB7D-- From dime-bounces@ietf.org Sat May 13 16:55:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff18k-0002qu-2J; Sat, 13 May 2006 16:55:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff18j-0002qp-2J for dime@ietf.org; Sat, 13 May 2006 16:55:05 -0400 Received: from ressweeper.openet.us ([65.207.84.115] helo=ressweeper.openet-dublin) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff18h-0002HZ-7F for dime@ietf.org; Sat, 13 May 2006 16:55:05 -0400 Received: from RESEXCHANGE.openet-dublin (resexchange.openet-dublin) by ressweeper.openet-dublin (Clearswift SMTPRS 5.0.4) with ESMTP id ; Sat, 13 May 2006 16:54:58 -0400 Received: from exc03.openet-telecom.lan ([10.0.2.193]) by RESEXCHANGE.openet-dublin with Microsoft SMTPSVC(6.0.3790.211); Sat, 13 May 2006 16:54:57 -0400 Subject: RE: [Dime] Policy based Applications and QoS Application Date: Sat, 13 May 2006 21:54:54 +0100 MIME-Version: 1.0 Message-ID: <8276FAA6D84AA54987B825CD51EDFAA60252D70A@exc03.openet-dublin> X-MS-Has-Attach: Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-TNEF-Correlator: Thread-Topic: [Dime] Policy based Applications and QoS Application Thread-Index: AcZsHR1DeOyBx6p+TtC2BSlyH0naHAGWaw2QAABc2IAApz6zQAAjuL8gAEoBLMA= From: "Alan McNamee" To: "Marchisio Marco Enzo" , X-OriginalArrivalTime: 13 May 2006 20:54:57.0975 (UTC) FILETIME=[7E876C70:01C676CF] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc3bb180a340b27ed09032e0ba4ec3ff Cc: isalekul@hotmail.com, "Tschofenig, Hannes" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1626919424==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1626919424== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C676CF.7D7B8022" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C676CF.7D7B8022 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marco, =20 Thanks for the slide I found it an excellent representation. =20 In regards to Avi's questions: =20 Question 1. I believe there is a need to create QoS application in Diameter. The 3GPP R7 spec for the PCRF although stating that it will define a unified Policy and Charging Rules node using Diameter interfaces it has yet to define any significant level detail on the QoS portion of the Gx or Rx interfaces. The Gx interface is an adaptation of the CCA, the Rx interface is an adaptation of a NASreq subset. Using CCA in this manner is questionable to me i.e. using CCA for a rules distribution application as opposed to a true credit control application like the OCS (accessed via Ro, Gy, Wy etc.). =20 Question 2. I would suggest that this work is done within IETF and seek for 3GPP et al to adopt it. This worked well for the CCA. =20 Question 3. I think that this would be a good starting point. =20 Regards, Alan. ________________________________ From: Marchisio Marco Enzo [mailto:marco.marchisio@telecomitalia.it]=20 Sent: 12 May 2006 10:30 To: dime@ietf.org Cc: isalekul@hotmail.com; Tschofenig, Hannes Subject: R: [Dime] Policy based Applications and QoS Application Hi All I send you a slide that summarizes and schematizes the 3GPP QoS evolution. Regarding the question 2:=20 =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3GPP Release 6 Introduces Flow Based Charging (FBC) and in Release 7 FBC and QoS are merged together with Diameter interface In Release 5, the QoS was COPS protocol based on =20 Marco =20 ________________________________ Da: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Inviato: Thursday, May 11, 2006 6:25 PM A: dime@ietf.org Cc: isalekul@hotmail.com; Tschofenig, Hannes Oggetto: [Dime] Policy based Applications and QoS Application =20 Hi All, =20 This email prompts me to start a discussion on Policy and QoS Application. =20 As some of you are aware IMS Rel 7.0 has an entity called PCRF. This PCRF is supposed to broker per flow based policy actions between the IMS infrastructure and the Network. Initially this policy was QoS and in release 7.0 it also brokers Charging Policy. In the future it will probably broker other per flow policy. For example, it may instruct the network to apply security policies to a flow or group of flows. =20 The QoS Application that is being developed by the IETF (IMO) was targeting the Policy entity in its IMS Rel 6.0 form when it was called the PDF instead of PCRF and when it was only serving QoS policies. Now in rel 7.0 the Diameter application being developed is serving both QoS and Charging information and is based on the Diameter Credit Control function. =20 =20 Also QoS policies are also delivered as part of Authentication. So EAP Application may be used to deliver initial QoS policies to the User session being authenticated and authorized. =20 So I am raising the following questions: =20 1) Is there any reason to create a QoS Application in Diameter? =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3) Perhaps we should just define QoS based attributes that can be pulled into various future Diameter Applications. =20 =20 Comments are welcome!!! =20 =20 =20 =09 ________________________________ From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Monday, May 08, 2006 4:23 AM To: john.loughney@nokia.com; dime@ietf.org Cc: isalekul@hotmail.com Subject: AW: [Dime] FW: [AAA-WG]: Policy representation for AAA server Hi Salekul,=20 =20 could you formulate your question in more detail?=20 What type of policies are you talking about? E.g., policies that represent the business logic at a AAA server or policies that are conveyed from the AAA server to the AAA client? Are you looking for a language to express these policies or rather for the content of these policies? Do you have a specific application in mind (e.g., policies regarding charging, QoS, location information) =20 Ciao Hannes =20 =20 =09 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 8. Mai 2006 10:10 An: dime@ietf.org Cc: isalekul@hotmail.com Betreff: [Dime] FW: [AAA-WG]: Policy representation for AAA server Forward to the DiME WG, in case any one has opinions for Diameter. =20 John =20 =09 ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul Islam Sent: 30 April, 2006 08:55 To: aaa-wg@merit.edu Cc: Salekul Islam Subject: [AAA-WG]: Policy representation for AAA server Hi, =20 I am interested in policy representation or policy server in Diameter architecture. Is there any Internet Draft or paper addressing the issues related to policy representation for AAA server? Is there any specific direction or goal of the WG regarding this issue? =20 Any sort of information will be very helpful for me. =20 regards, =20 Salekul Islam PhD candidate, Concordia University Montreal, Canada =20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you www.telecomitalia.it =20 -------------------------------------------------------------------- ------_=_NextPart_001_01C676CF.7D7B8022 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Marco,
 
Thanks for the slide I found it an excellent=20 representation.
 
In regards to Avi's = questions:
 
Question 1. I believe there is a need to create = QoS=20 application in Diameter. The 3GPP R7 spec for the PCRF although stating = that it=20 will define a unified Policy and Charging Rules node using Diameter = interfaces it has yet to define any significant level detail on the QoS=20 portion of the Gx or Rx interfaces. The Gx interface is an = adaptation of=20 the CCA, the Rx interface is an adaptation of a NASreq subset. Using CCA = in this=20 manner is questionable to me i.e. using CCA for a rules = distribution=20 application as opposed to a true credit control application like the OCS = (accessed via Ro, Gy, Wy etc.).
 
Question 2. I would suggest that this work is = done within=20 IETF and seek for 3GPP et al to adopt it. This worked well for the=20 CCA.
 
Question 3. I think that this would be a good = starting=20 point.
 
Regards,
Alan.

From: Marchisio Marco Enzo=20 [mailto:marco.marchisio@telecomitalia.it]
Sent: 12 May 2006=20 10:30
To: dime@ietf.org
Cc: isalekul@hotmail.com;=20 Tschofenig, Hannes
Subject: R: [Dime] Policy based = Applications and=20 QoS Application

Hi=20 All

I send you a = slide that=20 summarizes and schematizes the 3GPP QoS evolution.

Regarding the = question=20 2:

 

2) Should we = work on a=20 Diameter Flow-based Policy Application that is able to deliver = QoS/Charging and=20 in the future other flow based application?

-Should this = work be=20 done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to = work on=20 this within the IETF.  Or perhaps we can agree to work on this = together=20 outside the IETF?

 

3GPP Release = 6=20 Introduces Flow Based Charging (FBC) and in Release 7 FBC and QoS are = merged=20 together with Diameter interface

In Release 5, = the QoS=20 was COPS protocol based on

 

Marco

 

Da:=20 Avi Lior [mailto:avi@bridgewatersystems.com]
Inviato: Thursday, May 11, 2006 = 6:25=20 PM
A: = dime@ietf.org
Cc: isalekul@hotmail.com; = Tschofenig,=20 Hannes
Oggetto: = [Dime] Policy=20 based Applications and QoS Application

 

Hi=20 All,

 

This email = prompts me=20 to start a discussion on Policy and QoS Application.

 

As some of = you are=20 aware IMS Rel 7.0 has an entity called PCRF.  This PCRF is supposed = to=20 broker per flow based policy actions between the IMS infrastructure and = the=20 Network.  Initially this policy was QoS and in release 7.0 it also = brokers=20 Charging Policy.  In the future it will probably broker other per = flow=20 policy.  For example, it may instruct the network to apply security = policies to a flow or group of flows.

 

The QoS = Application=20 that is being developed by the IETF (IMO) was targeting the Policy = entity=20 in its IMS Rel 6.0 form when it was called the PDF instead of PCRF and = when it=20 was only serving QoS policies.  Now in rel 7.0 the Diameter = application=20 being developed is serving both QoS and Charging information and is = based on the=20 Diameter Credit Control function. 

 

Also QoS = policies are=20 also delivered as part of Authentication.  So EAP Application may = be used=20 to deliver initial QoS policies to the User session being authenticated = and=20 authorized.

 

So I am = raising the=20 following questions:

 

1) Is there = any reason=20 to create a QoS Application in Diameter?

 

2) Should we = work on a=20 Diameter Flow-based Policy Application that is able to deliver = QoS/Charging and=20 in the future other flow based application?

-Should this = work be=20 done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to = work on=20 this within the IETF.  Or perhaps we can agree to work on this = together=20 outside the IETF?

 

3) Perhaps we = should=20 just define QoS based attributes that can be pulled into various future = Diameter=20 Applications.

 

 

Comments are=20 welcome!!!

 

 

 

From:=20 Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, May 08, 2006 4:23 = AM
To:=20 john.loughney@nokia.com; dime@ietf.org
Cc: = isalekul@hotmail.com
Subject: AW: [Dime] FW: = [AAA-WG]: Policy=20 representation for AAA server

Hi=20 Salekul,=20

 

could you = formulate=20 your question in more detail?

What type = of=20 policies are you talking about? E.g., policies that represent the = business=20 logic at a AAA server or policies that are conveyed from the AAA = server to the=20 AAA client? Are you looking for a language to express these policies = or rather=20 for the content of these policies? Do you have a specific application = in mind=20 (e.g., policies regarding charging, QoS, location=20 information)

 

Ciao

Hannes

 

 

Von: = john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 8. Mai 2006 = 10:10
An:=20 dime@ietf.org
Cc: = isalekul@hotmail.com
Betreff: [Dime] FW: [AAA-WG]: = Policy=20 representation for AAA server

Forward = to the DiME=20 WG, in case any one has opinions for Diameter.

 

John

 

From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul=20 Islam
Sent: 30 = April,=20 2006 08:55
To:=20 aaa-wg@merit.edu
Cc:=20 Salekul Islam
Subject:=20 [AAA-WG]: Policy representation for AAA server

Hi,

 

I am interested in = policy=20 representation or policy server in Diameter architecture. Is there = any=20 Internet Draft or paper addressing the issues related to policy=20 representation for AAA server? Is there any specific = direction or=20 goal of the WG regarding this issue?

 

Any sort of = information will=20 be very helpful for me.

 

regards,

 

Salekul=20 Islam

PhD candidate, = Concordia=20 University

Montreal, Canada

 

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C676CF.7D7B8022-- --===============1626919424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1626919424==-- From dime-bounces@ietf.org Sat May 13 20:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff4C8-00030w-R4; Sat, 13 May 2006 20:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ff4C7-00030r-Vb for dime@ietf.org; Sat, 13 May 2006 20:10:47 -0400 Received: from ressweeper.openet.us ([65.207.84.115] helo=ressweeper.openet-dublin) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ff4C6-0004j0-3j for dime@ietf.org; Sat, 13 May 2006 20:10:47 -0400 Received: from RESEXCHANGE.openet-dublin (resexchange.openet-dublin) by ressweeper.openet-dublin (Clearswift SMTPRS 5.0.4) with ESMTP id ; Sat, 13 May 2006 20:10:45 -0400 Received: from exc03.openet-telecom.lan ([10.0.2.193]) by RESEXCHANGE.openet-dublin with Microsoft SMTPSVC(6.0.3790.211); Sat, 13 May 2006 20:10:45 -0400 Content-class: urn:content-classes:message Subject: FW: [Dime] Policy based Applications and QoS Application Date: Sun, 14 May 2006 01:10:40 +0100 MIME-Version: 1.0 Message-ID: <8276FAA6D84AA54987B825CD51EDFAA60252D70F@exc03.openet-dublin> X-MS-Has-Attach: X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-TNEF-Correlator: Thread-Topic: [Dime] Policy based Applications and QoS Application Thread-Index: AcZsHR1DeOyBx6p+TtC2BSlyH0naHAGWaw2QAABc2IAApz6zQAAjuL8gAEoBLMAAB5qQMA== From: "Alan McNamee" To: X-OriginalArrivalTime: 14 May 2006 00:10:45.0103 (UTC) FILETIME=[D85CE7F0:01C676EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b46f883d051ec9bb02ad32011a213d1 Cc: Alan McNamee X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1134168095==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1134168095== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C676EA.D734EFF0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C676EA.D734EFF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Resend. Didn't get through first time. ________________________________ From: Alan McNamee=20 Sent: 13 May 2006 21:55 To: 'Marchisio Marco Enzo'; dime@ietf.org Cc: isalekul@hotmail.com; Tschofenig, Hannes Subject: RE: [Dime] Policy based Applications and QoS Application Hi Marco, =20 Thanks for the slide I found it an excellent representation. =20 In regards to Avi's questions: =20 Question 1. I believe there is a need to create QoS application in Diameter. The 3GPP R7 spec for the PCRF although stating that it will define a unified Policy and Charging Rules node using Diameter interfaces it has yet to define any significant level detail on the QoS portion of the Gx or Rx interfaces. The Gx interface is an adaptation of the CCA, the Rx interface is an adaptation of a NASreq subset. Using CCA in this manner is questionable to me i.e. using CCA for a rules distribution application as opposed to a true credit control application like the OCS (accessed via Ro, Gy, Wy etc.). =20 Question 2. I would suggest that this work is done within IETF and seek for 3GPP et al to adopt it. This worked well for the CCA. =20 Question 3. I think that this would be a good starting point. =20 Regards, Alan. ________________________________ From: Marchisio Marco Enzo [mailto:marco.marchisio@telecomitalia.it]=20 Sent: 12 May 2006 10:30 To: dime@ietf.org Cc: isalekul@hotmail.com; Tschofenig, Hannes Subject: R: [Dime] Policy based Applications and QoS Application Hi All I send you a slide that summarizes and schematizes the 3GPP QoS evolution. Regarding the question 2:=20 =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3GPP Release 6 Introduces Flow Based Charging (FBC) and in Release 7 FBC and QoS are merged together with Diameter interface In Release 5, the QoS was COPS protocol based on =20 Marco =20 ________________________________ Da: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Inviato: Thursday, May 11, 2006 6:25 PM A: dime@ietf.org Cc: isalekul@hotmail.com; Tschofenig, Hannes Oggetto: [Dime] Policy based Applications and QoS Application =20 Hi All, =20 This email prompts me to start a discussion on Policy and QoS Application. =20 As some of you are aware IMS Rel 7.0 has an entity called PCRF. This PCRF is supposed to broker per flow based policy actions between the IMS infrastructure and the Network. Initially this policy was QoS and in release 7.0 it also brokers Charging Policy. In the future it will probably broker other per flow policy. For example, it may instruct the network to apply security policies to a flow or group of flows. =20 The QoS Application that is being developed by the IETF (IMO) was targeting the Policy entity in its IMS Rel 6.0 form when it was called the PDF instead of PCRF and when it was only serving QoS policies. Now in rel 7.0 the Diameter application being developed is serving both QoS and Charging information and is based on the Diameter Credit Control function. =20 =20 Also QoS policies are also delivered as part of Authentication. So EAP Application may be used to deliver initial QoS policies to the User session being authenticated and authorized. =20 So I am raising the following questions: =20 1) Is there any reason to create a QoS Application in Diameter? =20 2) Should we work on a Diameter Flow-based Policy Application that is able to deliver QoS/Charging and in the future other flow based application? -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to work on this within the IETF. Or perhaps we can agree to work on this together outside the IETF? =20 3) Perhaps we should just define QoS based attributes that can be pulled into various future Diameter Applications. =20 =20 Comments are welcome!!! =20 =20 =20 =09 ________________________________ From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Monday, May 08, 2006 4:23 AM To: john.loughney@nokia.com; dime@ietf.org Cc: isalekul@hotmail.com Subject: AW: [Dime] FW: [AAA-WG]: Policy representation for AAA server Hi Salekul,=20 =20 could you formulate your question in more detail?=20 What type of policies are you talking about? E.g., policies that represent the business logic at a AAA server or policies that are conveyed from the AAA server to the AAA client? Are you looking for a language to express these policies or rather for the content of these policies? Do you have a specific application in mind (e.g., policies regarding charging, QoS, location information) =20 Ciao Hannes =20 =20 =09 ________________________________ Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 8. Mai 2006 10:10 An: dime@ietf.org Cc: isalekul@hotmail.com Betreff: [Dime] FW: [AAA-WG]: Policy representation for AAA server Forward to the DiME WG, in case any one has opinions for Diameter. =20 John =20 =09 ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul Islam Sent: 30 April, 2006 08:55 To: aaa-wg@merit.edu Cc: Salekul Islam Subject: [AAA-WG]: Policy representation for AAA server Hi, =20 I am interested in policy representation or policy server in Diameter architecture. Is there any Internet Draft or paper addressing the issues related to policy representation for AAA server? Is there any specific direction or goal of the WG regarding this issue? =20 Any sort of information will be very helpful for me. =20 regards, =20 Salekul Islam PhD candidate, Concordia University Montreal, Canada =20 -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you www.telecomitalia.it =20 -------------------------------------------------------------------- ------_=_NextPart_001_01C676EA.D734EFF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Resend. Didn't get through first=20 time.

From: Alan McNamee
Sent: = 13 May 2006=20 21:55
To: 'Marchisio Marco Enzo'; dime@ietf.org
Cc:=20 isalekul@hotmail.com; Tschofenig, Hannes
Subject: RE: [Dime] = Policy=20 based Applications and QoS Application

Hi Marco,
 
Thanks for the slide I found it an excellent=20 representation.
 
In regards to Avi's = questions:
 
Question 1. I believe there is a need to create = QoS=20 application in Diameter. The 3GPP R7 spec for the PCRF although stating = that it=20 will define a unified Policy and Charging Rules node using Diameter = interfaces it has yet to define any significant level detail on the QoS=20 portion of the Gx or Rx interfaces. The Gx interface is an = adaptation of=20 the CCA, the Rx interface is an adaptation of a NASreq subset. Using CCA = in this=20 manner is questionable to me i.e. using CCA for a rules = distribution=20 application as opposed to a true credit control application like the OCS = (accessed via Ro, Gy, Wy etc.).
 
Question 2. I would suggest that this work is = done within=20 IETF and seek for 3GPP et al to adopt it. This worked well for the=20 CCA.
 
Question 3. I think that this would be a good = starting=20 point.
 
Regards,
Alan.

From: Marchisio Marco Enzo=20 [mailto:marco.marchisio@telecomitalia.it]
Sent: 12 May 2006=20 10:30
To: dime@ietf.org
Cc: isalekul@hotmail.com;=20 Tschofenig, Hannes
Subject: R: [Dime] Policy based = Applications and=20 QoS Application

Hi=20 All

I send you a = slide that=20 summarizes and schematizes the 3GPP QoS evolution.

Regarding the = question=20 2:

 

2) Should we = work on a=20 Diameter Flow-based Policy Application that is able to deliver = QoS/Charging and=20 in the future other flow based application?

-Should this = work be=20 done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to = work on=20 this within the IETF.  Or perhaps we can agree to work on this = together=20 outside the IETF?

 

3GPP Release = 6=20 Introduces Flow Based Charging (FBC) and in Release 7 FBC and QoS are = merged=20 together with Diameter interface

In Release 5, = the QoS=20 was COPS protocol based on

 

Marco

 

Da:=20 Avi Lior [mailto:avi@bridgewatersystems.com]
Inviato: Thursday, May 11, 2006 = 6:25=20 PM
A: = dime@ietf.org
Cc: isalekul@hotmail.com; = Tschofenig,=20 Hannes
Oggetto: = [Dime] Policy=20 based Applications and QoS Application

 

Hi=20 All,

 

This email = prompts me=20 to start a discussion on Policy and QoS Application.

 

As some of = you are=20 aware IMS Rel 7.0 has an entity called PCRF.  This PCRF is supposed = to=20 broker per flow based policy actions between the IMS infrastructure and = the=20 Network.  Initially this policy was QoS and in release 7.0 it also = brokers=20 Charging Policy.  In the future it will probably broker other per = flow=20 policy.  For example, it may instruct the network to apply security = policies to a flow or group of flows.

 

The QoS = Application=20 that is being developed by the IETF (IMO) was targeting the Policy = entity=20 in its IMS Rel 6.0 form when it was called the PDF instead of PCRF and = when it=20 was only serving QoS policies.  Now in rel 7.0 the Diameter = application=20 being developed is serving both QoS and Charging information and is = based on the=20 Diameter Credit Control function. 

 

Also QoS = policies are=20 also delivered as part of Authentication.  So EAP Application may = be used=20 to deliver initial QoS policies to the User session being authenticated = and=20 authorized.

 

So I am = raising the=20 following questions:

 

1) Is there = any reason=20 to create a QoS Application in Diameter?

 

2) Should we = work on a=20 Diameter Flow-based Policy Application that is able to deliver = QoS/Charging and=20 in the future other flow based application?

-Should this = work be=20 done in the IETF? Do we get folks in 3GPP/3GPP2 and WiMAX to agree to = work on=20 this within the IETF.  Or perhaps we can agree to work on this = together=20 outside the IETF?

 

3) Perhaps we = should=20 just define QoS based attributes that can be pulled into various future = Diameter=20 Applications.

 

 

Comments are=20 welcome!!!

 

 

 

From:=20 Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
Sent: Monday, May 08, 2006 4:23 = AM
To:=20 john.loughney@nokia.com; dime@ietf.org
Cc: = isalekul@hotmail.com
Subject: AW: [Dime] FW: = [AAA-WG]: Policy=20 representation for AAA server

Hi=20 Salekul,=20

 

could you = formulate=20 your question in more detail?

What type = of=20 policies are you talking about? E.g., policies that represent the = business=20 logic at a AAA server or policies that are conveyed from the AAA = server to the=20 AAA client? Are you looking for a language to express these policies = or rather=20 for the content of these policies? Do you have a specific application = in mind=20 (e.g., policies regarding charging, QoS, location=20 information)

 

Ciao

Hannes

 

 

Von: = john.loughney@nokia.com=20 [mailto:john.loughney@nokia.com]
Gesendet: Montag, 8. Mai 2006 = 10:10
An:=20 dime@ietf.org
Cc: = isalekul@hotmail.com
Betreff: [Dime] FW: [AAA-WG]: = Policy=20 representation for AAA server

Forward = to the DiME=20 WG, in case any one has opinions for Diameter.

 

John

 

From:=20 owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Salekul=20 Islam
Sent: 30 = April,=20 2006 08:55
To:=20 aaa-wg@merit.edu
Cc:=20 Salekul Islam
Subject:=20 [AAA-WG]: Policy representation for AAA server

Hi,

 

I am interested in = policy=20 representation or policy server in Diameter architecture. Is there = any=20 Internet Draft or paper addressing the issues related to policy=20 representation for AAA server? Is there any specific = direction or=20 goal of the WG regarding this issue?

 

Any sort of = information will=20 be very helpful for me.

 

regards,

 

Salekul=20 Islam

PhD candidate, = Concordia=20 University

Montreal, Canada

 

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C676EA.D734EFF0-- --===============1134168095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1134168095==-- From dime-bounces@ietf.org Mon May 15 14:40:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffhza-0008Fo-Ob; Mon, 15 May 2006 14:40:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfhzZ-0008Fg-J3 for dime@ietf.org; Mon, 15 May 2006 14:40:29 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfhzY-0001cb-GO for dime@ietf.org; Mon, 15 May 2006 14:40:29 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4FIeI40007923; Mon, 15 May 2006 21:40:22 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 21:40:21 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 21:40:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 15 May 2006 21:40:20 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB407814@esebe100.NOE.Nokia.com> In-Reply-To: <75D349FBF7C131408F5061B7168072C302CF35F5@INOAVREX06.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Diameter Error Handling Thread-Index: AcZ0/kjHHz8XnRDpSBG88BvnyDlL1gDM4KGQAAdBdpA= From: To: , X-OriginalArrivalTime: 15 May 2006 18:40:20.0516 (UTC) FILETIME=[04D07E40:01C6784F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8136d1e28e0aab8a4e130297ed2e1fc4 Cc: est-r-gomes@ptinovacao.pt Subject: [Dime] RE: [AAA-WG]: Diameter Error Handling X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0512232876==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0512232876== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6784F.04911EB3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6784F.04911EB3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paulo, =20 I'm forwarding this to the DiME (Diameter Maintainance and Extensions WG), that's the correct WG for this. =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Paulo Rolo Sent: 15 May, 2006 18:28 To: aaa-wg@merit.edu Cc: selina; Rui Miguel Gomes Subject: [AAA-WG]: Diameter Error Handling =09 =09 Hello all, =20 I have some questions regarding diameter error handling behavior, which I was unable to check on rfc 3588: - should diameter server, when replying with a message with E bit set, include all the AVPs from received request? (as far as I know, some diameter implementations do this on redirect messages) - this applies both to redirect and protocol and application errors?=20 - what is the meaning of *[AVP] on answer-message format? =20 ::=3D < Diameter Header: code, ERR [PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Reporting-Host ] [ Proxy-Info ] * [ AVP ] =20 Regards, Paulo Rolo =20 =20 =20 =20 =20 =20 =09 ________________________________ From: selina [mailto:zhangkewei@huawei.com]=20 Sent: quinta-feira, 11 de Maio de 2006 14:03 To: Paulo Rolo Subject: RE: [AAA-WG]: Diameter Redirect Behaviour =20 Hi,Paulo: =20 Please see my comments in line. =20 > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Paulo Rolo > Sent: Thursday, May 11, 2006 1:34 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter Redirect Behaviour >=20 > Hello,=20 > I have some questions regarding diameter redirect behavior:=20 > 1) Redirect reply message should be of the type request or reply? For example, if redirect agent receives an UAR it =20 > should reply with a UAR or with a UAA, performing the redirect actions?=20 =20 I think redirect reply message should be of the type reply,I mean reply message is the answer message,you can read the RFC3588,section 6.1.7 =20 > 2) If Redirect-Host-Usage AVP is used with a value of ALL_USER, how this is reflected on diameter routing table? As =20 > routing table only concerns realms and apps, should this routing entry be cached in an implementation specific table=20 > and this table used prior checking diameter routing table?=20 =20 If the Redirect-Host-Usage AVP's value is ALL_USER,I think it means all message from any user should be sent to the host specified in the Redirect-Host AVP.This is my consideration,and how do you think? =20 Selina Thanks =20 >=20 > Thanks in advance,=20 > Paulo Rolo ------_=_NextPart_001_01C6784F.04911EB3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 邮件</TI= TLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.2876" name=3DGENERATOR><!--[if !mso]> <STYLE>v\:* { BEHAVIOR: url(#default#VML) } o\:* { BEHAVIOR: url(#default#VML) } w\:* { BEHAVIOR: url(#default#VML) } .shape { BEHAVIOR: url(#default#VML) } </STYLE> <![endif]--> <STYLE>@font-face { font-family: SimSun; } @font-face { font-family: Tahoma; } @font-face { font-family: Verdana; } @font-face { font-family: @SimSun; } @page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt = 90.0pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } SPAN.EmailStyle17 { FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; = FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal } SPAN.EmailStyle19 { FONT-WEIGHT: bold; COLOR: blue; FONT-STYLE: normal; FONT-FAMILY: = Verdana; TEXT-DECORATION: none; mso-style-type: personal-reply } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D902533818-15052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi Paulo,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D902533818-15052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D902533818-15052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I'm forwarding this to the DiME (Diameter = Maintainance and=20 Extensions WG), that's the correct WG for this.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D902533818-15052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D902533818-15052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>John</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] <B>On Behalf Of </B>ext Paulo=20 Rolo<BR><B>Sent:</B> 15 May, 2006 18:28<BR><B>To:</B>=20 aaa-wg@merit.edu<BR><B>Cc:</B> selina; Rui Miguel = Gomes<BR><B>Subject:</B>=20 [AAA-WG]: Diameter Error Handling<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">Hello=20 all,<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">I=20 have some questions regarding diameter error handling behavior, which = I was=20 unable to check on rfc 3588:<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">-=20 should diameter server, when replying with a message with E bit set, = include=20 all the AVPs from received request? (as far as I know, some diameter=20 implementations do this on redirect = messages)<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">-=20 this applies both to redirect and protocol and application errors?=20 <o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">-=20 what is the meaning of *[AVP] on answer-message=20 format?<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">  <o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">  =20          = <answer-message> ::=3D=20 < Diameter Header: code, ERR [PXY] = ><o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;         =20 0*1< Session-Id ><o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;            = ;=20 { Origin-Host }<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;            = ;=20 { Origin-Realm }<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;            = ;=20 { Result-Code }<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;            = ;=20 [ Origin-State-Id ]<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;            = ;=20 [ Error-Reporting-Host ]<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;            = ;=20 [ Proxy-Info ]<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">          &nbs= p;          =20 * [ AVP ]<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">Regards,<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana">Paulo=20 Rolo<o:p></o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <P class=3DMsoNormal><B><FONT face=3DVerdana color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></B></P> <DIV> <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" = align=3Dcenter><FONT=20 face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt"> <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D2> </SPAN></FONT></DIV> <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20 style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma">From:</SPAN></FONT></B><FONT=20 face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: = Tahoma"> selina=20 [mailto:zhangkewei@huawei.com] <BR><B><SPAN=20 style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> quinta-feira, 11 de Maio = de 2006=20 14:03<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Paulo=20 Rolo<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> RE: = [AAA-WG]:=20 Diameter Redirect Behaviour</SPAN></FONT><o:p></o:p></P></DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"><o:p> </o:p></SPAN></FONT></P> <DIV> <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">Hi,Paulo:</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Please see my = comments in=20 line.</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">-----Original=20 Message-----<BR></SPAN></FONT><FONT face=3D"Courier New" = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">></SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><STRONG><B><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">From:</SPAN></FONT></B></STRONG><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] <B><SPAN style=3D"FONT-WEIGHT: = bold">On Behalf=20 Of </SPAN></B>Paulo Rolo<BR>></SPAN></FONT><FONT face=3D"Courier = New"=20 color=3Dblue size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><STRONG><B><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">Sent:</SPAN></FONT></B></STRONG><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> Thursday, May = 11, 2006=20 1:34 AM<BR>></SPAN></FONT><FONT face=3D"Courier New" color=3Dblue = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><STRONG><B><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">To:</SPAN></FONT></B></STRONG><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">=20 aaa-wg@merit.edu<BR>></SPAN></FONT><FONT face=3D"Courier New" = color=3Dblue=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><STRONG><B><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">Subject:</SPAN></FONT></B></STRONG><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"> [AAA-WG]: = Diameter=20 Redirect Behaviour<BR></SPAN></FONT><FONT face=3DSimSun size=3D2><SPAN = style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"><BR>>=20 Hello, </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">I have some = questions=20 regarding diameter redirect = behavior: </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">1) Redirect = reply message=20 should be of the type request or reply? For example, if redirect agent = receives an UAR it </SPAN></FONT><FONT face=3D"Courier New" = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">should reply = with a UAR or=20 with a UAA, performing the redirect=20 actions? </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">I think redirect = reply=20 message should be of the type reply,I mean reply message is the answer = message,you can read the RFC3588,section=20 6.1.7</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">2) If = Redirect-Host-Usage=20 AVP is used with a value of ALL_USER, how this is reflected on = diameter=20 routing table? As </SPAN></FONT><FONT face=3D"Courier New" = size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">routing table = only=20 concerns realms and apps, should this routing entry be cached in an=20 implementation specific table</SPAN></FONT><FONT face=3D"Courier New"=20 size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">and this table = used prior=20 checking diameter routing = table? </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">If the = Redirect-Host-Usage=20 AVP's value is ALL_USER,I think it means all message from = any user=20 should be sent to the host specified in the Redirect-Host AVP.This is = my=20 consideration,and how do you think?</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">Selina</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'">Thanks</SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20 style=3D"FONT-SIZE: 12pt"> <o:p></o:p></SPAN></FONT></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Thanks in=20 advance, </SPAN></FONT><o:p></o:p></P></DIV> <DIV> <P class=3DMsoNormal><FONT face=3DSimSun size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: SimSun">></SPAN></FONT><FONT = face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier = New'"> </SPAN></FONT><FONT=20 face=3D"Courier New" size=3D2><SPAN=20 style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Paulo=20 = Rolo<o:p></o:p></SPAN></FONT></P></DIV></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C6784F.04911EB3-- --===============0512232876== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0512232876==-- From dime-bounces@ietf.org Tue May 16 14:38:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4Ra-00035Y-Td; Tue, 16 May 2006 14:38:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4RZ-00035T-Fi for dime@ietf.org; Tue, 16 May 2006 14:38:53 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4RY-0005lU-Uu for dime@ietf.org; Tue, 16 May 2006 14:38:53 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4GIclJN013457; Tue, 16 May 2006 21:38:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 21:38:48 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 21:38:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 16 May 2006 21:38:46 +0300 Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C41E@esebe100.NOE.Nokia.com> In-Reply-To: <75D349FBF7C131408F5061B7168072C302CF2C02@INOAVREX06.ptin.corpPT.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: Diameter Redirect Behaviour Thread-Index: AcZ0V/R1V9V0DYrQRKaw3BfILAP/2wEv96Ag From: <john.loughney@nokia.com> To: <paulo-j-rolo@ptinovacao.pt>, <dime@ietf.org> X-OriginalArrivalTime: 16 May 2006 18:38:47.0394 (UTC) FILETIME=[F7B8F420:01C67917] X-Spam-Score: 0.2 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Subject: [Dime] RE: [AAA-WG]: Diameter Redirect Behaviour X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1541767087==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1541767087== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67917.F70827B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67917.F70827B4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paulo, =20 I'm forwarding this to the DiME (Diameter Maintanence and Extensions WG), so see if anyone can comment on this. =20 John ________________________________ From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of ext Paulo Rolo Sent: 10 May, 2006 20:34 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Redirect Behaviour =09 =09 Hello, =20 I have some questions regarding diameter redirect behavior: 1) Redirect reply message should be of the type request or reply? For example, if redirect agent receives an UAR it should reply with a UAR or with a UAA, performing the redirect actions? 2) If Redirect-Host-Usage AVP is used with a value of ALL_USER, how this is reflected on diameter routing table? As routing table only concerns realms and apps, should this routing entry be cached in an implementation specific table and this table used prior checking diameter routing table? =20 Thanks in advance, Paulo Rolo ------_=_NextPart_001_01C67917.F70827B4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word"><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.2876" name=3DGENERATOR> <STYLE>@font-face { font-family: Verdana; } @page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt = 90.0pt; } P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman" } A:link { COLOR: blue; TEXT-DECORATION: underline } SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline } A:visited { COLOR: purple; TEXT-DECORATION: underline } SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline } SPAN.EmailStyle17 { FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; = FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: = personal-compose } DIV.Section1 { page: Section1 } </STYLE> </HEAD> <BODY lang=3DEN-US vLink=3Dpurple link=3Dblue> <DIV dir=3Dltr align=3Dleft><SPAN class=3D717453718-16052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Paulo,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D717453718-16052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D717453718-16052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>I'm forwarding this to the DiME (Diameter = Maintanence and=20 Extensions WG), so see if anyone can comment on = this.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D717453718-16052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D717453718-16052006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>John</FONT></SPAN></DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] <B>On Behalf Of </B>ext Paulo=20 Rolo<BR><B>Sent:</B> 10 May, 2006 20:34<BR><B>To:</B>=20 aaa-wg@merit.edu<BR><B>Subject:</B> [AAA-WG]: Diameter Redirect=20 Behaviour<BR></FONT><BR></DIV> <DIV></DIV> <DIV class=3DSection1> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: = Verdana">Hello,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Verdana">I have some questions = regarding=20 diameter redirect behavior:<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Verdana">1) Redirect reply = message should=20 be of the type request or reply? For example, if redirect agent = receives an=20 UAR it should reply with a UAR or with a UAA, performing the redirect=20 actions?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Verdana">2) If = Redirect-Host-Usage AVP is=20 used with a value of ALL_USER, how this is reflected on diameter = routing=20 table? As routing table only concerns realms and apps, should this = routing=20 entry be cached in an implementation specific table and this table = used prior=20 checking diameter routing table?<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: = Verdana"><o:p> </o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Verdana">Thanks in=20 advance,<o:p></o:p></SPAN></FONT></P> <P class=3DMsoNormal><FONT face=3DVerdana size=3D2><SPAN=20 style=3D"FONT-SIZE: 11pt; FONT-FAMILY: Verdana">Paulo=20 Rolo<o:p></o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C67917.F70827B4-- --===============1541767087== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1541767087==-- From dime-bounces@ietf.org Thu May 18 05:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgf2I-0001Or-8B; Thu, 18 May 2006 05:43:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgf2G-0001Ol-Md for dime@ietf.org; Thu, 18 May 2006 05:43:12 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgf2D-0003VF-Lw for dime@ietf.org; Thu, 18 May 2006 05:43:11 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 03934808F; Thu, 18 May 2006 11:42:50 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1Fge5Q-0005h0-VV; Thu, 18 May 2006 10:42:24 +0200 Date: Thu, 18 May 2006 10:42:24 +0200 From: Julien Bournelle <julien.bournelle@int-evry.fr> To: dime@ietf.org Message-ID: <20060518084224.GA21878@ipv6-3.int-evry.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: hannes.tschofenig@gmx.net Subject: [Dime] Defining a new Application for mip6-split ? X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi all, we're in the process of updating/writing the document describing use of Diameter for the Mobile IPv6 split scenario. In the split scenario, the Mobile Node (MN) uses IKEv2 with the HA to setup IPsec SAs. This exchange is also used by the HA to authenticate the MN using EAP. The HA may rely on a AAA/EAP server for this. So we have the following scheme: MN <-- IKEv2-EAP --> HA <--------> AAA A priori Diameter EAP (RFC 4072) can be used between HA and AAA. The problem is that Diameter EAP is normally used for Network Access authentication. In our case, the AAA server must perform AAA functionality for the Mobile IPv6 service. The AAA server must know that it has to authorize the mip6 service and the accounting (ASR/ASA) is also for mip6 and not for network access. For the above reason, it seems that we should define a new Diameter Application. However, in the same time, the messages defined in Diameter EAP could be reused. So I'd like to hear opinions concerning this issue. Thanks, - Julien B. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 06:51:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgg6T-0008E7-HD; Thu, 18 May 2006 06:51:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgg6S-0008E2-GR for dime@ietf.org; Thu, 18 May 2006 06:51:36 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgg6R-0007F3-4I for dime@ietf.org; Thu, 18 May 2006 06:51:36 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 12:51:29 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Thu, 18 May 2006 12:51:04 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026036ED4A3@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ6X6rfyXH0Bq6ZRQ6DLXe2HDuohAABpBHw From: "MORAND Lionel RD-CORE-ISS" <lionel.morand@francetelecom.com> To: "Julien Bournelle" <julien.bournelle@int-evry.fr>, <dime@ietf.org> X-OriginalArrivalTime: 18 May 2006 10:51:29.0694 (UTC) FILETIME=[04C6F3E0:01C67A69] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: hannes.tschofenig@gmx.net X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi Julien, >From my point of view, if there is no backward incompatible change in = the Diameter application itself, there is no reason to assign a new = application ID. Lionel -----Message d'origine----- De : Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 Envoy=E9 : jeudi 18 mai 2006 10:42 =C0 : dime@ietf.org Cc : hannes.tschofenig@gmx.net Objet : [Dime] Defining a new Application for mip6-split ? Hi all, we're in the process of updating/writing the document describing use of = Diameter for the Mobile IPv6 split scenario. In the split scenario, the Mobile Node (MN) uses IKEv2 with the HA to = setup IPsec SAs. This exchange is also used by the HA to authenticate = the MN using EAP. The HA may rely on a AAA/EAP server for this. So we = have the following scheme: MN <-- IKEv2-EAP --> HA <--------> AAA A priori Diameter EAP (RFC 4072) can be used between HA and AAA.=20 The problem is that Diameter EAP is normally used for Network Access = authentication.=20 In our case, the AAA server must perform AAA functionality for the = Mobile IPv6 service. The AAA server must know that it has to authorize = the mip6 service and the accounting (ASR/ASA) is also for mip6 and not = for network access. For the above reason, it seems that we should define a new Diameter = Application. However, in the same time, the messages defined in = Diameter EAP could be reused. So I'd like to hear opinions concerning this issue. Thanks, - Julien B. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 06:58:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggCx-0001dF-HR; Thu, 18 May 2006 06:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggCv-0001d9-Na for dime@ietf.org; Thu, 18 May 2006 06:58:18 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FggCq-0007nM-NF for dime@ietf.org; Thu, 18 May 2006 06:58:15 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 7AD79808F; Thu, 18 May 2006 12:58:05 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FgfGG-0005iV-D2; Thu, 18 May 2006 11:57:40 +0200 Date: Thu, 18 May 2006 11:57:40 +0200 From: Julien Bournelle <julien.bournelle@int-evry.fr> To: MORAND Lionel RD-CORE-ISS <lionel.morand@francetelecom.com> Subject: Re: [Dime] Defining a new Application for mip6-split ? Message-ID: <20060518095740.GA21970@ipv6-3.int-evry.fr> References: <7DBAFEC6A76F3E42817DF1EBE64CB026036ED4A3@FTRDMEL2.rd.francetelecom.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB026036ED4A3@FTRDMEL2.rd.francetelecom.fr> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: hannes.tschofenig@gmx.net, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi lionel, On Thu, May 18, 2006 at 12:51:04PM +0200, MORAND Lionel RD-CORE-ISS wrote= : > Hi Julien, >=20 > From my point of view, if there is no backward incompatible change in t= he Diameter application itself, there is no reason to assign a new applic= ation ID. but the problem is: how do the AAA server know that it is performing AAA functionalities for mip6 service and not for network access ? This AAA server may be used both for network access and mip6 service. Julien >=20 > Lionel > -----Message d'origine----- > De : Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Envoy=E9 : jeudi 18 mai 2006 10:42 > =C0 : dime@ietf.org > Cc : hannes.tschofenig@gmx.net > Objet : [Dime] Defining a new Application for mip6-split ? >=20 > Hi all, >=20 > we're in the process of updating/writing the document describing use o= f Diameter for the Mobile IPv6 split scenario. >=20 > In the split scenario, the Mobile Node (MN) uses IKEv2 with the HA to = setup IPsec SAs. This exchange is also used by the HA to authenticate t= he MN using EAP. The HA may rely on a AAA/EAP server for this. So we hav= e the following scheme: >=20 > MN <-- IKEv2-EAP --> HA <--------> AAA >=20 > A priori Diameter EAP (RFC 4072) can be used between HA and AAA.=20 >=20 > The problem is that Diameter EAP is normally used for Network Access = authentication.=20 >=20 > In our case, the AAA server must perform AAA functionality for the Mo= bile IPv6 service. The AAA server must know that it has to authorize the= mip6 service and the accounting (ASR/ASA) is also for mip6 and not for = network access. >=20 > For the above reason, it seems that we should define a new Diameter A= pplication. However, in the same time, the messages defined in Diameter = EAP could be reused. >=20 > So I'd like to hear opinions concerning this issue. >=20 > Thanks, >=20 >=20 > - Julien B. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime --=20 julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 07:46:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggxH-0001pC-SD; Thu, 18 May 2006 07:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggxH-0001p2-5X for dime@ietf.org; Thu, 18 May 2006 07:46:11 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FggxE-0004s9-MK for dime@ietf.org; Thu, 18 May 2006 07:46:11 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4IBk2vs003110; Thu, 18 May 2006 14:46:03 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 14:45:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 14:45:01 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Thu, 18 May 2006 14:45:00 +0300 Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2402AAD05D@esebe105.NOE.Nokia.com> In-Reply-To: <20060518084224.GA21878@ipv6-3.int-evry.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ6YCCpLFAQA1xJTTiJ0e02Jv/PUQAD8k9g From: <Pasi.Eronen@nokia.com> To: <julien.bournelle@int-evry.fr>, <dime@ietf.org> X-OriginalArrivalTime: 18 May 2006 11:45:01.0118 (UTC) FILETIME=[7EEF5DE0:01C67A70] X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: hannes.tschofenig@gmx.net X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi Julien, There's nothing in RFC 4072 that would limit its use to, say, PPP=20 or 802.1X -- it works for IKEv2 as well (which can be considered a special kind of network access, where the "link" is a tunnel over IP). The details (MIP6 or 802.11 WLAN or something else) can be sent to the AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. Best regards, Pasi > -----Original Message----- > From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: 18 May, 2006 11:42 > To: dime@ietf.org > Cc: hannes.tschofenig@gmx.net > Subject: [Dime] Defining a new Application for mip6-split ? >=20 > Hi all, >=20 > we're in the process of updating/writing the document=20 > describing use of > Diameter for the Mobile IPv6 split scenario. >=20 > In the split scenario, the Mobile Node (MN) uses IKEv2 with the HA to > setup IPsec SAs. This exchange is also used by the HA to authenticate > the MN using EAP. The HA may rely on a AAA/EAP server for this. So we > have the following scheme: >=20 > MN <-- IKEv2-EAP --> HA <--------> AAA >=20 > A priori Diameter EAP (RFC 4072) can be used between HA and AAA.=20 >=20 > The problem is that Diameter EAP is normally used for Network Access > authentication.=20 >=20 > In our case, the AAA server must perform AAA functionality for the > Mobile IPv6 service. The AAA server must know that it has to=20 > authorize the mip6 service and the accounting (ASR/ASA) is also for=20 > mip6 and not for network access. >=20 > For the above reason, it seems that we should define a new Diameter > Application. However, in the same time, the messages defined in > Diameter EAP could be reused. >=20 > So I'd like to hear opinions concerning this issue. >=20 > Thanks, >=20 >=20 > - Julien B. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 08:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghGX-0008RY-2I; Thu, 18 May 2006 08:06:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghGV-0008RT-NT for dime@ietf.org; Thu, 18 May 2006 08:06:03 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghGT-0005th-8p for dime@ietf.org; Thu, 18 May 2006 08:06:03 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id B68AA80D5; Thu, 18 May 2006 14:05:55 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FggJu-0005js-Ix; Thu, 18 May 2006 13:05:30 +0200 Date: Thu, 18 May 2006 13:05:30 +0200 From: Julien Bournelle <julien.bournelle@int-evry.fr> To: Pasi.Eronen@nokia.com Subject: Re: [Dime] Defining a new Application for mip6-split ? Message-ID: <20060518110530.GB22048@ipv6-3.int-evry.fr> References: <20060518084224.GA21878@ipv6-3.int-evry.fr> <B356D8F434D20B40A8CEDAEC305A1F2402AAD05D@esebe105.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <B356D8F434D20B40A8CEDAEC305A1F2402AAD05D@esebe105.NOE.Nokia.com> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: hannes.tschofenig@gmx.net, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi Pasi, On Thu, May 18, 2006 at 02:45:00PM +0300, Pasi.Eronen@nokia.com wrote: > Hi Julien, > > There's nothing in RFC 4072 that would limit its use to, say, PPP > or 802.1X -- it works for IKEv2 as well (which can be considered > a special kind of network access, where the "link" is a tunnel > over IP). I'm not saying that we can't use IKEv2 with Diameter EAP. I had just a doubt due to the fact that in our case, we're doing AAA for the mip6 service and not for network access. (So I wanted to know opinion from the group before starting to write) > The details (MIP6 or 802.11 WLAN or something else) can be sent > to the AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. ok. I forgot the Service-Type AVP which seems to be what we need. thanks, Best regards, Julien > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: 18 May, 2006 11:42 > > To: dime@ietf.org > > Cc: hannes.tschofenig@gmx.net > > Subject: [Dime] Defining a new Application for mip6-split ? > > > > Hi all, > > > > we're in the process of updating/writing the document > > describing use of > > Diameter for the Mobile IPv6 split scenario. > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 with the HA to > > setup IPsec SAs. This exchange is also used by the HA to authenticate > > the MN using EAP. The HA may rely on a AAA/EAP server for this. So we > > have the following scheme: > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > A priori Diameter EAP (RFC 4072) can be used between HA and AAA. > > > > The problem is that Diameter EAP is normally used for Network Access > > authentication. > > > > In our case, the AAA server must perform AAA functionality for the > > Mobile IPv6 service. The AAA server must know that it has to > > authorize the mip6 service and the accounting (ASR/ASA) is also for > > mip6 and not for network access. > > > > For the above reason, it seems that we should define a new Diameter > > Application. However, in the same time, the messages defined in > > Diameter EAP could be reused. > > > > So I'd like to hear opinions concerning this issue. > > > > Thanks, > > > > > > - Julien B. > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 10:06:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgj98-0001TI-Np; Thu, 18 May 2006 10:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgj96-0001Sn-FG for dime@ietf.org; Thu, 18 May 2006 10:06:32 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgj94-0003G2-1m for dime@ietf.org; Thu, 18 May 2006 10:06:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Thu, 18 May 2006 10:10:26 -0400 Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A0051027A7@exchange.bridgewatersys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ6dCjgSyquDsIQSgipdVt7FAwsWQADdjUw From: "Avi Lior" <avi@bridgewatersystems.com> To: "Julien Bournelle" <julien.bournelle@int-evry.fr>, <Pasi.Eronen@nokia.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: hannes.tschofenig@gmx.net, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org The problem is that neither Service-Type or Port-Type is mandatory. =20 O fcourse, if we need to make it mandatory we need to create an new Application. Also, if we add a new enumeration to either Port-Type or Service-Type wouldn't we have to create a new Application. BTW, this has been an issue even in RADIUS. How does the AAA know this its authenticating for Mobile IP. Traditionaly it would know that NAS-IP or NAS-Identifier is coming from an HA. But that doesn't scale at all. I was trying to decide whether Service-Type or Port-Type is the correct way to go. Service Type seems to be the correct way but in RADIUS and Diameter service-type also can be authenticate-only or authorize-only. So what if the HA wanted to authenticate-only or authorize-only for the MIP service? I would lose the ability to also indicate that this is an HA. So Port-Type seems to be the way to go.... > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Sent: Thursday, May 18, 2006 7:06 AM > To: Pasi.Eronen@nokia.com > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > Hi Pasi, >=20 > On Thu, May 18, 2006 at 02:45:00PM +0300, Pasi.Eronen@nokia.com wrote: > > Hi Julien, > >=20 > > There's nothing in RFC 4072 that would limit its use to,=20 > say, PPP or=20 > > 802.1X -- it works for IKEv2 as well (which can be considered a=20 > > special kind of network access, where the "link" is a=20 > tunnel over IP). >=20 > I'm not saying that we can't use IKEv2 with Diameter EAP. I=20 > had just a doubt due to the fact that in our case, we're=20 > doing AAA for the mip6 service and not for network access.=20 > (So I wanted to know opinion from the group before starting to write) >=20 > > The details (MIP6 or 802.11 WLAN or something else) can be=20 > sent to the=20 > > AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. >=20 > ok. I forgot the Service-Type AVP which seems to be what we need. >=20 > thanks, >=20 > Best regards, >=20 > Julien >=20 > >=20 > > Best regards, > > Pasi > >=20 > > > -----Original Message----- > > > From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > Sent: 18 May, 2006 11:42 > > > To: dime@ietf.org > > > Cc: hannes.tschofenig@gmx.net > > > Subject: [Dime] Defining a new Application for mip6-split ? > > >=20 > > > Hi all, > > >=20 > > > we're in the process of updating/writing the document describing=20 > > > use of Diameter for the Mobile IPv6 split scenario. > > >=20 > > > In the split scenario, the Mobile Node (MN) uses IKEv2=20 > with the HA=20 > > > to setup IPsec SAs. This exchange is also used by the HA to=20 > > > authenticate the MN using EAP. The HA may rely on a=20 > AAA/EAP server=20 > > > for this. So we have the following scheme: > > >=20 > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > >=20 > > > A priori Diameter EAP (RFC 4072) can be used between HA and AAA.=20 > > >=20 > > > The problem is that Diameter EAP is normally used for Network=20 > > > Access authentication. > > >=20 > > > In our case, the AAA server must perform AAA=20 > functionality for the =20 > > > Mobile IPv6 service. The AAA server must know that it has to =20 > > > authorize the mip6 service and the accounting (ASR/ASA)=20 > is also for > > > mip6 and not for network access. > > >=20 > > > For the above reason, it seems that we should define a=20 > new Diameter =20 > > > Application. However, in the same time, the messages defined in =20 > > > Diameter EAP could be reused. > > >=20 > > > So I'd like to hear opinions concerning this issue. > > >=20 > > > Thanks, > > >=20 > > >=20 > > > - Julien B. > > >=20 > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 >=20 > -- > julien.bournelle at int-evry.fr >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 13:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmgB-0002X0-0F; Thu, 18 May 2006 13:52:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmgA-0002Wv-B6 for dime@ietf.org; Thu, 18 May 2006 13:52:54 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgmg7-0000Ch-Uh for dime@ietf.org; Thu, 18 May 2006 13:52:54 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k4IHqRAF029584; Thu, 18 May 2006 13:52:28 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Thu, 18 May 2006 13:52:25 -0400 To: Avi Lior <avi@bridgewatersystems.com> Subject: Re: [Dime] Defining a new Application for mip6-split ? Message-ID: <20060518175225.GJ22172@steelhead> References: <E7CCE8A83907104ABEE91AC3AE3709A0051027A7@exchange.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <E7CCE8A83907104ABEE91AC3AE3709A0051027A7@exchange.bridgewatersys.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba <yohba@tari.toshiba.com> X-Dispatcher: imput version 20050308(IM148) Lines: 140 X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote: > > The problem is that neither Service-Type or Port-Type is mandatory. > > O fcourse, if we need to make it mandatory we need to create an new > Application. If those AVPs are defined in an existing application, we don't need to create a new application just because the AVPs that appear in "optional" portion of the ABNF of the existing application need to appear in "required" portion. Yoshihiro Ohba > > Also, if we add a new enumeration to either Port-Type or Service-Type > wouldn't we have to create a new Application. > > BTW, this has been an issue even in RADIUS. How does the AAA know this > its authenticating for Mobile IP. Traditionaly it would know that NAS-IP > or NAS-Identifier is coming from an HA. But that doesn't scale at all. > > I was trying to decide whether Service-Type or Port-Type is the correct > way to go. Service Type seems to be the correct way but in RADIUS and > Diameter service-type also can be authenticate-only or authorize-only. > So what if the HA wanted to authenticate-only or authorize-only for the > MIP service? I would lose the ability to also indicate that this is an > HA. > > So Port-Type seems to be the way to go.... > > > > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > Sent: Thursday, May 18, 2006 7:06 AM > > To: Pasi.Eronen@nokia.com > > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > > > Hi Pasi, > > > > On Thu, May 18, 2006 at 02:45:00PM +0300, Pasi.Eronen@nokia.com wrote: > > > Hi Julien, > > > > > > There's nothing in RFC 4072 that would limit its use to, > > say, PPP or > > > 802.1X -- it works for IKEv2 as well (which can be considered a > > > special kind of network access, where the "link" is a > > tunnel over IP). > > > > I'm not saying that we can't use IKEv2 with Diameter EAP. I > > had just a doubt due to the fact that in our case, we're > > doing AAA for the mip6 service and not for network access. > > (So I wanted to know opinion from the group before starting to write) > > > > > The details (MIP6 or 802.11 WLAN or something else) can be > > sent to the > > > AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. > > > > ok. I forgot the Service-Type AVP which seems to be what we need. > > > > thanks, > > > > Best regards, > > > > Julien > > > > > > > > Best regards, > > > Pasi > > > > > > > -----Original Message----- > > > > From: ext Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > Sent: 18 May, 2006 11:42 > > > > To: dime@ietf.org > > > > Cc: hannes.tschofenig@gmx.net > > > > Subject: [Dime] Defining a new Application for mip6-split ? > > > > > > > > Hi all, > > > > > > > > we're in the process of updating/writing the document describing > > > > use of Diameter for the Mobile IPv6 split scenario. > > > > > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 > > with the HA > > > > to setup IPsec SAs. This exchange is also used by the HA to > > > > authenticate the MN using EAP. The HA may rely on a > > AAA/EAP server > > > > for this. So we have the following scheme: > > > > > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > > > > > A priori Diameter EAP (RFC 4072) can be used between HA and AAA. > > > > > > > > The problem is that Diameter EAP is normally used for Network > > > > Access authentication. > > > > > > > > In our case, the AAA server must perform AAA > > functionality for the > > > > Mobile IPv6 service. The AAA server must know that it has to > > > > authorize the mip6 service and the accounting (ASR/ASA) > > is also for > > > > mip6 and not for network access. > > > > > > > > For the above reason, it seems that we should define a > > new Diameter > > > > Application. However, in the same time, the messages defined in > > > > Diameter EAP could be reused. > > > > > > > > So I'd like to hear opinions concerning this issue. > > > > > > > > Thanks, > > > > > > > > > > > > - Julien B. > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > -- > > julien.bournelle at int-evry.fr > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 16:36:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpEW-0007Gi-Qs; Thu, 18 May 2006 16:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgpEV-0007Ga-N9 for dime@ietf.org; Thu, 18 May 2006 16:36:31 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgpER-0004L7-89 for dime@ietf.org; Thu, 18 May 2006 16:36:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Thu, 18 May 2006 16:40:25 -0400 Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A005102AE6@exchange.bridgewatersys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ6pHPJnjNo3OmKRSCY0EkdYKgtgAAEl4sw From: "Avi Lior" <avi@bridgewatersystems.com> To: "Yoshihiro Ohba" <yohba@tari.toshiba.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi Yoshi, =20 Based on your repsonse we don't have to create a new application id. So how do I express that Service-Type (or NAS-Port-Type) is required? So do I create a new ABNF for the DER and DEA commands in the EAP-Application to show that these attributes are required now? Under what context do I put this new ABNF? I don't have a new Application ID nor do I have a new Command? > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Thursday, May 18, 2006 1:52 PM > To: Avi Lior > Cc: Julien Bournelle; Pasi.Eronen@nokia.com;=20 > hannes.tschofenig@gmx.net; dime@ietf.org > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote: > >=20 > > The problem is that neither Service-Type or Port-Type is=20 > mandatory. =20 > >=20 > > O fcourse, if we need to make it mandatory we need to create an new=20 > > Application. >=20 > If those AVPs are defined in an existing application, we=20 > don't need to create a new application just because the AVPs=20 > that appear in "optional" portion of the ABNF of the existing=20 > application need to appear in "required" portion. >=20 > Yoshihiro Ohba >=20 >=20 > >=20 > > Also, if we add a new enumeration to either Port-Type or=20 > Service-Type=20 > > wouldn't we have to create a new Application. > >=20 > > BTW, this has been an issue even in RADIUS. How does the AAA know=20 > > this its authenticating for Mobile IP. Traditionaly it=20 > would know that=20 > > NAS-IP or NAS-Identifier is coming from an HA. But that=20 > doesn't scale at all. > >=20 > > I was trying to decide whether Service-Type or Port-Type is the=20 > > correct way to go. Service Type seems to be the correct way but in=20 > > RADIUS and Diameter service-type also can be=20 > authenticate-only or authorize-only. > > So what if the HA wanted to authenticate-only or authorize-only for=20 > > the MIP service? I would lose the ability to also indicate=20 > that this=20 > > is an HA. > >=20 > > So Port-Type seems to be the way to go.... > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > Sent: Thursday, May 18, 2006 7:06 AM > > > To: Pasi.Eronen@nokia.com > > > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > >=20 > > > Hi Pasi, > > >=20 > > > On Thu, May 18, 2006 at 02:45:00PM +0300,=20 > Pasi.Eronen@nokia.com wrote: > > > > Hi Julien, > > > >=20 > > > > There's nothing in RFC 4072 that would limit its use to, > > > say, PPP or > > > > 802.1X -- it works for IKEv2 as well (which can be considered a=20 > > > > special kind of network access, where the "link" is a > > > tunnel over IP). > > >=20 > > > I'm not saying that we can't use IKEv2 with Diameter EAP. I had=20 > > > just a doubt due to the fact that in our case, we're=20 > doing AAA for=20 > > > the mip6 service and not for network access. > > > (So I wanted to know opinion from the group before starting to=20 > > > write) > > >=20 > > > > The details (MIP6 or 802.11 WLAN or something else) can be > > > sent to the > > > > AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. > > >=20 > > > ok. I forgot the Service-Type AVP which seems to be what we need. > > >=20 > > > thanks, > > >=20 > > > Best regards, > > >=20 > > > Julien > > >=20 > > > >=20 > > > > Best regards, > > > > Pasi > > > >=20 > > > > > -----Original Message----- > > > > > From: ext Julien Bournelle=20 > [mailto:julien.bournelle@int-evry.fr] > > > > > Sent: 18 May, 2006 11:42 > > > > > To: dime@ietf.org > > > > > Cc: hannes.tschofenig@gmx.net > > > > > Subject: [Dime] Defining a new Application for mip6-split ? > > > > >=20 > > > > > Hi all, > > > > >=20 > > > > > we're in the process of updating/writing the document=20 > > > > > describing use of Diameter for the Mobile IPv6 split=20 > scenario. > > > > >=20 > > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 > > > with the HA > > > > > to setup IPsec SAs. This exchange is also used by the HA to=20 > > > > > authenticate the MN using EAP. The HA may rely on a > > > AAA/EAP server > > > > > for this. So we have the following scheme: > > > > >=20 > > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > >=20 > > > > > A priori Diameter EAP (RFC 4072) can be used between=20 > HA and AAA.=20 > > > > >=20 > > > > > The problem is that Diameter EAP is normally used=20 > for Network=20 > > > > > Access authentication. > > > > >=20 > > > > > In our case, the AAA server must perform AAA > > > functionality for the > > > > > Mobile IPv6 service. The AAA server must know that it has to=20 > > > > > authorize the mip6 service and the accounting (ASR/ASA) > > > is also for > > > > > mip6 and not for network access. > > > > >=20 > > > > > For the above reason, it seems that we should define a > > > new Diameter > > > > > Application. However, in the same time, the messages=20 > defined in=20 > > > > > Diameter EAP could be reused. > > > > >=20 > > > > > So I'd like to hear opinions concerning this issue. > > > > >=20 > > > > > Thanks, > > > > >=20 > > > > >=20 > > > > > - Julien B. > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > >=20 > > > -- > > > julien.bournelle at int-evry.fr > > >=20 > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 17:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqLb-0006Hm-R5; Thu, 18 May 2006 17:47:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgqLa-0006Hd-DQ for dime@ietf.org; Thu, 18 May 2006 17:47:54 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgqLX-0000n8-W7 for dime@ietf.org; Thu, 18 May 2006 17:47:54 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id k4ILlSZT030809; Thu, 18 May 2006 17:47:29 -0400 (EDT) (envelope-from yohba@tari.toshiba.com) Date: Thu, 18 May 2006 17:47:26 -0400 To: Avi Lior <avi@bridgewatersystems.com> Subject: Re: [Dime] Defining a new Application for mip6-split ? Message-ID: <20060518214726.GP22172@steelhead> References: <E7CCE8A83907104ABEE91AC3AE3709A005102AE6@exchange.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <E7CCE8A83907104ABEE91AC3AE3709A005102AE6@exchange.bridgewatersys.com> User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba <yohba@tari.toshiba.com> X-Dispatcher: imput version 20050308(IM148) Lines: 198 X-Spam-Score: 0.1 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org On Thu, May 18, 2006 at 04:40:25PM -0400, Avi Lior wrote: > Hi Yoshi, > > Based on your repsonse we don't have to create a new application id. So > how do I express that Service-Type (or NAS-Port-Type) is required? My response was based on my reading of RFC 3588. On the other hand, RFC 3588 does not describe how to deal with the situation. > > So do I create a new ABNF for the DER and DEA commands in the > EAP-Application to show that these attributes are required now? > > Under what context do I put this new ABNF? I don't have a new > Application ID nor do I have a new Command? I think defining a revised ABNF to supersede the existing ABNF for an existing message is NOT a good idea, since it affects existing Diameter message parser implementations. Rather than that, I'd suggest keeping the current ABNF for DER and DEA as it is, and define additional processing rules for the AVPs that are defined as optional but required only by a specific service in a new standard track RFC. I mean, the message parser does not reject the message even when those AVPs are missing (because it is defined as optional in the ABNF), but the implementation of the service-specific Diameter EAP application must rejects the message if the AVPs are missing or do not contain information required by the service. Yoshihiro Ohba > > > > > -----Original Message----- > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: Thursday, May 18, 2006 1:52 PM > > To: Avi Lior > > Cc: Julien Bournelle; Pasi.Eronen@nokia.com; > > hannes.tschofenig@gmx.net; dime@ietf.org > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > > > On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote: > > > > > > The problem is that neither Service-Type or Port-Type is > > mandatory. > > > > > > O fcourse, if we need to make it mandatory we need to create an new > > > Application. > > > > If those AVPs are defined in an existing application, we > > don't need to create a new application just because the AVPs > > that appear in "optional" portion of the ABNF of the existing > > application need to appear in "required" portion. > > > > Yoshihiro Ohba > > > > > > > > > > Also, if we add a new enumeration to either Port-Type or > > Service-Type > > > wouldn't we have to create a new Application. > > > > > > BTW, this has been an issue even in RADIUS. How does the AAA know > > > this its authenticating for Mobile IP. Traditionaly it > > would know that > > > NAS-IP or NAS-Identifier is coming from an HA. But that > > doesn't scale at all. > > > > > > I was trying to decide whether Service-Type or Port-Type is the > > > correct way to go. Service Type seems to be the correct way but in > > > RADIUS and Diameter service-type also can be > > authenticate-only or authorize-only. > > > So what if the HA wanted to authenticate-only or authorize-only for > > > the MIP service? I would lose the ability to also indicate > > that this > > > is an HA. > > > > > > So Port-Type seems to be the way to go.... > > > > > > > > > > > > > -----Original Message----- > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > Sent: Thursday, May 18, 2006 7:06 AM > > > > To: Pasi.Eronen@nokia.com > > > > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > > > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > > > > > > > Hi Pasi, > > > > > > > > On Thu, May 18, 2006 at 02:45:00PM +0300, > > Pasi.Eronen@nokia.com wrote: > > > > > Hi Julien, > > > > > > > > > > There's nothing in RFC 4072 that would limit its use to, > > > > say, PPP or > > > > > 802.1X -- it works for IKEv2 as well (which can be considered a > > > > > special kind of network access, where the "link" is a > > > > tunnel over IP). > > > > > > > > I'm not saying that we can't use IKEv2 with Diameter EAP. I had > > > > just a doubt due to the fact that in our case, we're > > doing AAA for > > > > the mip6 service and not for network access. > > > > (So I wanted to know opinion from the group before starting to > > > > write) > > > > > > > > > The details (MIP6 or 802.11 WLAN or something else) can be > > > > sent to the > > > > > AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. > > > > > > > > ok. I forgot the Service-Type AVP which seems to be what we need. > > > > > > > > thanks, > > > > > > > > Best regards, > > > > > > > > Julien > > > > > > > > > > > > > > Best regards, > > > > > Pasi > > > > > > > > > > > -----Original Message----- > > > > > > From: ext Julien Bournelle > > [mailto:julien.bournelle@int-evry.fr] > > > > > > Sent: 18 May, 2006 11:42 > > > > > > To: dime@ietf.org > > > > > > Cc: hannes.tschofenig@gmx.net > > > > > > Subject: [Dime] Defining a new Application for mip6-split ? > > > > > > > > > > > > Hi all, > > > > > > > > > > > > we're in the process of updating/writing the document > > > > > > describing use of Diameter for the Mobile IPv6 split > > scenario. > > > > > > > > > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 > > > > with the HA > > > > > > to setup IPsec SAs. This exchange is also used by the HA to > > > > > > authenticate the MN using EAP. The HA may rely on a > > > > AAA/EAP server > > > > > > for this. So we have the following scheme: > > > > > > > > > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > > > > > > > > > A priori Diameter EAP (RFC 4072) can be used between > > HA and AAA. > > > > > > > > > > > > The problem is that Diameter EAP is normally used > > for Network > > > > > > Access authentication. > > > > > > > > > > > > In our case, the AAA server must perform AAA > > > > functionality for the > > > > > > Mobile IPv6 service. The AAA server must know that it has to > > > > > > authorize the mip6 service and the accounting (ASR/ASA) > > > > is also for > > > > > > mip6 and not for network access. > > > > > > > > > > > > For the above reason, it seems that we should define a > > > > new Diameter > > > > > > Application. However, in the same time, the messages > > defined in > > > > > > Diameter EAP could be reused. > > > > > > > > > > > > So I'd like to hear opinions concerning this issue. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > - Julien B. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > -- > > > > julien.bournelle at int-evry.fr > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu May 18 23:55:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgw52-0004j6-Gb; Thu, 18 May 2006 23:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgw51-0004it-Vv for DiME@ietf.org; Thu, 18 May 2006 23:55:11 -0400 Received: from web8505.mail.in.yahoo.com ([202.43.219.167]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fgw4y-0005bx-Sm for DiME@ietf.org; Thu, 18 May 2006 23:55:11 -0400 Received: (qmail 39749 invoked by uid 60001); 19 May 2006 03:55:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=lYq4alKoKtIrTn57cCcD05a4HOiemMFUTJJyxcn8TKg08DWV+lvu7iq6ngYzrIQcfAp+CvKXyRSGqzjJZMZZHA/O5dzhPt08ITx2LqoPxU526/thxjFpR++n8C6Y8lFX/krHyFUkLhCkCYzJ7YnNqhb+xM7HK7gDEXRG7wobbvc= ; Message-ID: <20060519035506.39747.qmail@web8505.mail.in.yahoo.com> Received: from [61.95.205.153] by web8505.mail.in.yahoo.com via HTTP; Fri, 19 May 2006 04:55:06 BST Date: Fri, 19 May 2006 04:55:06 +0100 (BST) From: pradeep kumar <pradeep_asani141@yahoo.co.in> To: DiME@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.0 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Dime] Diameter client query for SMS billing X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1128648929==" Errors-To: dime-bounces@ietf.org --===============1128648929== Content-Type: multipart/alternative; boundary="0-1164655534-1148010906=:39302" Content-Transfer-Encoding: 8bit --0-1164655534-1148010906=:39302 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit hi I want information from where(which network element) diameter client will take the data for sending requests to diameter server in a GSM network for SMSC billing. To which network element(MSC or SMSC) of GSM network does the diameter client will be connected for the SMS billing context. Where does the diameter client will be residing in GSM network for SMS billing. Please give me the flow how the request will be send from mobile station to GSM network and then to diameter client, diameter server for SMS billing. I need it urgently. Thanks and Regards, A.Pradeep Kumar --------------------------------- Why was V. Sehwag warned by the BCCI? Share your knowledge on Yahoo! Answers India Send instant messages to your online friends - NOW --0-1164655534-1148010906=:39302 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit <div>hi</div> <div> </div> <div>I want information from where(which network element) diameter client will take </div> <div> </div> <div>the data for sending requests to diameter server in a GSM network for SMSC </div> <div> </div> <div>billing.</div> <div> </div> <div>To which network element(MSC or SMSC) of GSM network does the diameter </div> <div> </div> <div>client will be connected for the SMS billing context.</div> <div> </div> <div>Where does the diameter client will be residing in GSM network for SMS </div> <div> </div> <div>billing.</div> <div> </div> <div>Please give me the flow how the request will be send from mobile station to </div> <div> </div> <div>GSM network and then to diameter client, diameter server for SMS billing.</div> <div> </div> <div>I need it urgently.</div> <div> </div> <div> </div> <div>Thanks and Regards,</div> <div>A.Pradeep Kumar</div><p> <hr size=1></hr> Why was V. Sehwag warned by the BCCI? Share your knowledge on <a href="http://us.rd.yahoo.com/mail/in/mailanswerssehwag/*http://in.answers.yahoo.com/question/index?qid=1006051032589">Yahoo! Answers India</a><br> Send instant messages to your online friends - <a href="http://us.rd.yahoo.com/mail/in/messengerbeta/*http://messenger.yahoo.com/download.php;_ylt=Ah5_.LTcbbJtYrNKnfM5e6xwMMIF">NOW</a> --0-1164655534-1148010906=:39302-- --===============1128648929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1128648929==-- From dime-bounces@ietf.org Fri May 19 05:47:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Zt-0002Wo-Dz; Fri, 19 May 2006 05:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Zr-0002Ti-PN for dime@ietf.org; Fri, 19 May 2006 05:47:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh0P9-0004sA-4q for dime@ietf.org; Fri, 19 May 2006 04:32:15 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fh0AN-0005P3-BI for dime@ietf.org; Fri, 19 May 2006 04:17:04 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 87ECE898ED; Fri, 19 May 2006 11:16:57 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 35D83898EB; Fri, 19 May 2006 11:16:57 +0300 (EEST) Message-ID: <446D7F30.8070407@piuha.net> Date: Fri, 19 May 2006 11:17:52 +0300 From: Jari Arkko <jari.arkko@piuha.net> User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior <avi@bridgewatersystems.com> Subject: Re: [Dime] Defining a new Application for mip6-split ? References: <E7CCE8A83907104ABEE91AC3AE3709A005102AE6@exchange.bridgewatersys.com> In-Reply-To: <E7CCE8A83907104ABEE91AC3AE3709A005102AE6@exchange.bridgewatersys.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.4 (--) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Pasi.Eronen@nokia.com, hannes.tschofenig@gmx.net, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org I would prefer using the existing application, and adding optional AVPs to carry information related to the IKEv2 (and possibly MIPv6) service, and possibly some additional values for the NAS-Port-Type field. One of the reasons why an existing application would be preferred is that then a AAA server that does not care about the type of service can be used without changes. Yet servers that do care can look at the AVPs and make more detailed authorization decisions. RFC 3588 states that "Creation of a new application should be viewed as a last resort." and that "In order to justify allocation of a new application identifier, Diameter applications MUST define one Command Code, or add new mandatory AVPs to the ABNF." Note that mandatory AVPs can be viewed in different ways, and that we should not be too strict about them. For instance, Framed-Protocol is an optional AVP in RFCs 4005 and 4072. Yet, you could argue that if you are doing PPP then you need to use this attribute and set it to PPP. But that didn't make the attribute mandatory. Do we have a similar situation for the IKEv2/MIPv6 attributes and values? They are not necessary from the NASREQ/EAP perspective, but in the specific context you need to use the attributes. In my mind, this does not make the attributes mandatory from a Diameter application point of view. If we start creating new applications for every different situation, we'll have lots of applications and interoperability problems. Its better to add new optional AVPs and describe in text when they should be used. The only exception that I see is security related AVPs that must be understood by the other side or else the session should be terminated. See also http://www.arkko.com/publications/draft-arkko-radext-multi-service-decisions-02.txt for related discussion about Service-Type, NAS-Port-Type, and so on. --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 05:47:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Zy-0002kp-Mm; Fri, 19 May 2006 05:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh1Zx-0002kj-OG for dime@ietf.org; Fri, 19 May 2006 05:47:29 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh1Zv-0008Rr-37 for dime@ietf.org; Fri, 19 May 2006 05:47:29 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id ADF918164; Fri, 19 May 2006 11:47:15 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1Fh1Yc-00064a-89; Fri, 19 May 2006 11:46:06 +0200 Date: Fri, 19 May 2006 11:46:06 +0200 From: Julien Bournelle <julien.bournelle@int-evry.fr> To: Yoshihiro Ohba <yohba@tari.toshiba.com> Subject: Re: [Dime] Defining a new Application for mip6-split ? Message-ID: <20060519094606.GA23328@ipv6-3.int-evry.fr> References: <E7CCE8A83907104ABEE91AC3AE3709A005102AE6@exchange.bridgewatersys.com> <20060518214726.GP22172@steelhead> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060518214726.GP22172@steelhead> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Errors-To: dime-bounces@ietf.org Hi, On Thu, May 18, 2006 at 05:47:26PM -0400, Yoshihiro Ohba wrote: > On Thu, May 18, 2006 at 04:40:25PM -0400, Avi Lior wrote: > > Hi Yoshi, > > > > Based on your repsonse we don't have to create a new application id. So > > how do I express that Service-Type (or NAS-Port-Type) is required? > > My response was based on my reading of RFC 3588. On the other hand, > RFC 3588 does not describe how to deal with the situation. > > > > > So do I create a new ABNF for the DER and DEA commands in the > > EAP-Application to show that these attributes are required now? > > > > Under what context do I put this new ABNF? I don't have a new > > Application ID nor do I have a new Command? > > I think defining a revised ABNF to supersede the existing ABNF for an > existing message is NOT a good idea, since it affects existing > Diameter message parser implementations. Rather than that, I'd > suggest keeping the current ABNF for DER and DEA as it is, and define > additional processing rules for the AVPs that are defined as optional > but required only by a specific service in a new standard track RFC. > I mean, the message parser does not reject the message even when those > AVPs are missing (because it is defined as optional in the ABNF), but > the implementation of the service-specific Diameter EAP application > must rejects the message if the AVPs are missing or do not contain > information required by the service. so you mean that, if we take mip6-split scenario, I could just add a sentence saying that the HA MUST/SHOULD add the NAS-Port-Type AVP (TBD for mip6-split) and that the AAA server MUST/SHOULD check if this AVP is present ? But what happens if the HA put the AVP and the AAA does not check it ? If the AAA server is not compliant with this, it may still continue to "think" that it's an authentication for network access. Julien B. > > Yoshihiro Ohba > > > > > > > > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Thursday, May 18, 2006 1:52 PM > > > To: Avi Lior > > > Cc: Julien Bournelle; Pasi.Eronen@nokia.com; > > > hannes.tschofenig@gmx.net; dime@ietf.org > > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > > > > > On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote: > > > > > > > > The problem is that neither Service-Type or Port-Type is > > > mandatory. > > > > > > > > O fcourse, if we need to make it mandatory we need to create an new > > > > Application. > > > > > > If those AVPs are defined in an existing application, we > > > don't need to create a new application just because the AVPs > > > that appear in "optional" portion of the ABNF of the existing > > > application need to appear in "required" portion. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > Also, if we add a new enumeration to either Port-Type or > > > Service-Type > > > > wouldn't we have to create a new Application. > > > > > > > > BTW, this has been an issue even in RADIUS. How does the AAA know > > > > this its authenticating for Mobile IP. Traditionaly it > > > would know that > > > > NAS-IP or NAS-Identifier is coming from an HA. But that > > > doesn't scale at all. > > > > > > > > I was trying to decide whether Service-Type or Port-Type is the > > > > correct way to go. Service Type seems to be the correct way but in > > > > RADIUS and Diameter service-type also can be > > > authenticate-only or authorize-only. > > > > So what if the HA wanted to authenticate-only or authorize-only for > > > > the MIP service? I would lose the ability to also indicate > > > that this > > > > is an HA. > > > > > > > > So Port-Type seems to be the way to go.... > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > > Sent: Thursday, May 18, 2006 7:06 AM > > > > > To: Pasi.Eronen@nokia.com > > > > > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > > > > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > > > > > > > > > Hi Pasi, > > > > > > > > > > On Thu, May 18, 2006 at 02:45:00PM +0300, > > > Pasi.Eronen@nokia.com wrote: > > > > > > Hi Julien, > > > > > > > > > > > > There's nothing in RFC 4072 that would limit its use to, > > > > > say, PPP or > > > > > > 802.1X -- it works for IKEv2 as well (which can be considered a > > > > > > special kind of network access, where the "link" is a > > > > > tunnel over IP). > > > > > > > > > > I'm not saying that we can't use IKEv2 with Diameter EAP. I had > > > > > just a doubt due to the fact that in our case, we're > > > doing AAA for > > > > > the mip6 service and not for network access. > > > > > (So I wanted to know opinion from the group before starting to > > > > > write) > > > > > > > > > > > The details (MIP6 or 802.11 WLAN or something else) can be > > > > > sent to the > > > > > > AAA server using e.g. Service-Type and/or NAS-Port-Type AVPs. > > > > > > > > > > ok. I forgot the Service-Type AVP which seems to be what we need. > > > > > > > > > > thanks, > > > > > > > > > > Best regards, > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > Best regards, > > > > > > Pasi > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: ext Julien Bournelle > > > [mailto:julien.bournelle@int-evry.fr] > > > > > > > Sent: 18 May, 2006 11:42 > > > > > > > To: dime@ietf.org > > > > > > > Cc: hannes.tschofenig@gmx.net > > > > > > > Subject: [Dime] Defining a new Application for mip6-split ? > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > we're in the process of updating/writing the document > > > > > > > describing use of Diameter for the Mobile IPv6 split > > > scenario. > > > > > > > > > > > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 > > > > > with the HA > > > > > > > to setup IPsec SAs. This exchange is also used by the HA to > > > > > > > authenticate the MN using EAP. The HA may rely on a > > > > > AAA/EAP server > > > > > > > for this. So we have the following scheme: > > > > > > > > > > > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > > > > > > > > > > > A priori Diameter EAP (RFC 4072) can be used between > > > HA and AAA. > > > > > > > > > > > > > > The problem is that Diameter EAP is normally used > > > for Network > > > > > > > Access authentication. > > > > > > > > > > > > > > In our case, the AAA server must perform AAA > > > > > functionality for the > > > > > > > Mobile IPv6 service. The AAA server must know that it has to > > > > > > > authorize the mip6 service and the accounting (ASR/ASA) > > > > > is also for > > > > > > > mip6 and not for network access. > > > > > > > > > > > > > > For the above reason, it seems that we should define a > > > > > new Diameter > > > > > > > Application. However, in the same time, the messages > > > defined in > > > > > > > Diameter EAP could be reused. > > > > > > > > > > > > > > So I'd like to hear opinions concerning this issue. > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > - Julien B. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > -- > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > -- julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 08:08:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3mK-0004oB-0M; Fri, 19 May 2006 08:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh3mJ-0004o6-Bk for DiME@ietf.org; Fri, 19 May 2006 08:08:23 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh3mH-0002dT-UM for DiME@ietf.org; Fri, 19 May 2006 08:08:23 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k4JC8Fc6001228 for <DiME@ietf.org>; Fri, 19 May 2006 05:08:15 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k4JC88Ax012145 for <DiME@ietf.org>; Fri, 19 May 2006 07:08:12 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] Diameter client query for SMS billing Date: Fri, 19 May 2006 20:08:07 +0800 Message-ID: <C82A9B11BE247C4E952DC733EA98DAA1016F8B2B@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Diameter client query for SMS billing Thread-Index: AcZ6+B/fia3NxXSsSA2srWZ8MA2DowAFso5Q From: "Ram O V Vishnu-A14676" <vishnu@motorola.com> To: "pradeep kumar" <pradeep_asani141@yahoo.co.in>, <DiME@ietf.org> X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org> List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe> List-Archive: <http://www1.ietf.org/pipermail/dime> List-Post: <mailto:dime@ietf.org> List-Help: <mailto:dime-request@ietf.org?subject=help> List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============1618178267==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1618178267== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67B3C.E3A5AF67" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67B3C.E3A5AF67 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pradeep, =20 Thanks for emailing this list. But you might get better answers for these questions in a 3GPP emailing list.=20 =20 >From my limited knowledge, 3GPP TS 32240-630 might give you some ideas. Regards, Vishnu. Motorola India Electronics Pvt Ltd +91 9844178052 [*] Motorola Internal Use Only -----Original Message----- From: pradeep kumar [mailto:pradeep_asani141@yahoo.co.in]=20 Sent: Friday, May 19, 2006 9:25 AM To: DiME@ietf.org Subject: [Dime] Diameter client query for SMS billing =09 =09 hi =20 I want information from where(which network element) diameter client will take=20 =20 the data for sending requests to diameter server in a GSM network for SMSC=20 =20 billing. =20 To which network element(MSC or SMSC) of GSM network does the diameter=20 =20 client will be connected for the SMS billing context. =20 Where does the diameter client will be residing in GSM network for SMS=20 =20 billing. =20 Please give me the flow how the request will be send from mobile station to=20 =20 GSM network and then to diameter client, diameter server for SMS billing. =20 I need it urgently. =20 =20 Thanks and Regards, A.Pradeep Kumar =09 ________________________________ Why was V. Sehwag warned by the BCCI? Share your knowledge on Yahoo! Answers India <http://us.rd.yahoo.com/mail/in/mailanswerssehwag/*http://in.answers.yah oo.com/question/index?qid=3D1006051032589>=20 Send instant messages to your online friends - NOW <http://us.rd.yahoo.com/mail/in/messengerbeta/*http://messenger.yahoo.co m/download.php;_ylt=3DAh5_.LTcbbJtYrNKnfM5e6xwMMIF>=20 ------_=_NextPart_001_01C67B3C.E3A5AF67 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Message
Pradeep,
 
Thanks=20 for emailing this list. But you might get better answers for these = questions in=20 a 3GPP emailing list.
 
From=20 my limited knowledge, 3GPP TS 32240-630 might give you some=20 ideas.

Regards,
Vishnu.

Motorola India Electronics = Pvt=20 Ltd
+91 9844178052
[*] Motorola Internal Use = Only

-----Original Message-----
From: = pradeep kumar=20 [mailto:pradeep_asani141@yahoo.co.in]
Sent: Friday, May 19, = 2006=20 9:25 AM
To: DiME@ietf.org
Subject: [Dime] Diameter = client=20 query for SMS billing

hi
 
I want information from where(which network=20 element) diameter client will take
 
the data for sending requests to diameter server in a = GSM=20 network for SMSC
 
billing.
 
To which network element(MSC or SMSC) of GSM network does = the=20 diameter
 
client will be connected for the SMS billing context.
 
Where does the diameter client will be residing in GSM network = for SMS=20
 
billing.
 
Please give me the flow how the request will be send from mobile = station=20 to
 
GSM network and then to diameter client, diameter server for = SMS=20 billing.
 
I need it urgently.
 
 
Thanks and Regards,
A.Pradeep Kumar

Why was V. Sehwag warned by the BCCI? Share your knowledge on Yahoo!=20 Answers India
Send instant messages to your online friends - NOW ------_=_NextPart_001_01C67B3C.E3A5AF67-- --===============1618178267== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============1618178267==-- From dime-bounces@ietf.org Fri May 19 08:30:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh47X-000615-Cn; Fri, 19 May 2006 08:30:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh47V-00060d-RM for dime@ietf.org; Fri, 19 May 2006 08:30:17 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh47T-0003sa-EA for dime@ietf.org; Fri, 19 May 2006 08:30:17 -0400 Received: by nf-out-0910.google.com with SMTP id h2so376402nfe for ; Fri, 19 May 2006 05:30:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nftfhE/Z9mg1CivSPQzpcE0olS4BSiAjsSCdU8x7PbEf9D8Rw1EexJc9E93itVgBtTWwfIL1otmHlxe4+oVUz8VnEtSiQ6aQS7EX+VuOBFM5VN1Y/lqLcbIsuYzvo1a+NvUWJ5QU4BJcipS4MlrtPt5AvCaEvES/q5mimSpEfEg= Received: by 10.48.162.16 with SMTP id k16mr1402471nfe; Fri, 19 May 2006 05:30:05 -0700 (PDT) Received: by 10.48.214.10 with HTTP; Fri, 19 May 2006 05:30:04 -0700 (PDT) Message-ID: Date: Fri, 19 May 2006 14:30:04 +0200 From: "Gerardo Giaretta" To: "Jari Arkko" Subject: Re: [Dime] Defining a new Application for mip6-split ? In-Reply-To: <446D7F30.8070407@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <446D7F30.8070407@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Jari. The most important thing we need for MIPv6 is that the AAA server understands that the authentication/authorization request is performed through Diameter EAP application but it is related to the mobility service and not to network access service. This is a clear requirement for an operator. But the presence of some optional AVPs may be sufficient to fulfill this requirement, imo. --Gerardo On 5/19/06, Jari Arkko wrote: > I would prefer using the existing application, and > adding optional AVPs to carry information related > to the IKEv2 (and possibly MIPv6) service, and possibly > some additional values for the NAS-Port-Type field. > > One of the reasons why an existing application would > be preferred is that then a AAA server that does not > care about the type of service can be used without > changes. Yet servers that do care can look at the > AVPs and make more detailed authorization > decisions. > > RFC 3588 states that "Creation of a new application > should be viewed as a last resort." and that "In order > to justify allocation of a new application identifier, > Diameter applications MUST define one Command Code, > or add new mandatory AVPs to the ABNF." Note that > mandatory AVPs can be viewed in different ways, > and that we should not be too strict about them. > For instance, Framed-Protocol is an optional AVP in > RFCs 4005 and 4072. Yet, you could argue that if you > are doing PPP then you need to use this attribute and > set it to PPP. But that didn't make the attribute mandatory. > Do we have a similar situation for the IKEv2/MIPv6 > attributes and values? They are not necessary from > the NASREQ/EAP perspective, but in the specific context > you need to use the attributes. In my mind, this does not > make the attributes mandatory from a Diameter > application point of view. If we start creating > new applications for every different situation, > we'll have lots of applications and interoperability > problems. Its better to add new optional AVPs and > describe in text when they should be used. The > only exception that I see is security related AVPs > that must be understood by the other side or else > the session should be terminated. > > See also > http://www.arkko.com/publications/draft-arkko-radext-multi-service-decisi= ons-02.txt > for related discussion about Service-Type, NAS-Port-Type, > and so on. > > --Jari > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 10:54:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6N9-0006yb-7g; Fri, 19 May 2006 10:54:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh6N7-0006yW-Uj for dime@ietf.org; Fri, 19 May 2006 10:54:33 -0400 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fh6N5-0005kS-H8 for dime@ietf.org; Fri, 19 May 2006 10:54:33 -0400 Received: (qmail invoked by alias); 19 May 2006 14:54:30 -0000 Received: from ip-80-226-209-133.vodafone-net.de (EHLO [10.226.216.206]) [80.226.209.133] by mail.gmx.net (mp024) with SMTP; 19 May 2006 16:54:30 +0200 X-Authenticated: #29516787 Message-ID: <446DDC22.5070305@gmx.net> Date: Fri, 19 May 2006 16:54:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Dime] Diameter Interop Report X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, A Diameter Interop Event hosted by Ulticom took place April 24-28, 2006. Thanks to Ulticom for the excellent meeting organization. We had a very nice and fruitful meeting. Victor Fajardo took some meeting minutes. Please find them here: http://www.tschofenig.priv.at/dime-interop-2006/meeting-minutes.txt Here is a short summary of the tests we did: * Diameter Base Protocol * Diameter Credit Control * Diameter NASREQ * Diameter Accounting * 3GPP specs Two folks tried to get Diameter EAP to work but they failed due to some serious implementation bugs that they couldn't fix during the meeting. They promised me todo some remote tests. I will keep the list up-to-date. Since our main focus was on the base protocol I would like to provide a bit more details about it: TLS: 5 companies provided TLS support. We performed some tests but it took us a long time because of the different certificate formats. SCTP: 2 companies supported SCTP and performed tests. No problems showed up. Next, I would like to go through the test cases from Section 3 of http://www.ietf.org/internet-drafts/draft-fajardo-dime-interop-test-suite-00.txt. Y=Implemented/Tested I=Implemented/Not Tested N=Not Implemented NA=Not Available 3.1.1.1: 13 Y 3.1.1.2: 9 Y, 3 I, 1 N 3.1.1.3: 13 Y 3.1.1.4: 12 Y, 1 I 3.1.1.5: 3 Y, 6 I, 4 N 3.1.2.1: 7 Y, 2 I, 3 N, 1 NA 3.1.2.2: 7 Y, 3 I, 2 N, 1 NA 3.1.2.3: 9 Y, 1 I, 2 N, 1 NA 3.1.2.4: 5 Y, 4 I, 4 N 3.1.3 (Relay): 6 Y, 6 N, 1 NA 3.1.3 (Proxy): 1 Y, 2 I, 9 N, 1 NA 3.1.3.1: 1 Y, 2 I, 10 N 3.2.1.1: 6 Y, 5 I, 2 N 3.2.1.2: 1 I, 12 N It turned out that the test suite document was quite useful for executing the tests. However, we also noticed that the test suite document should focus more on the protocol specific tests rather than describing the interaction with protocols that trigger the Diameter interaction. We might want to update the document. Protocol specific issues have been collected in an issue tracker. Please find it at: http://www.tschofenig.priv.at:8080/diameter-interop/ During our meeting a number of folks expressed interest in having another interop event. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 12:34:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7vU-0008V4-70; Fri, 19 May 2006 12:34:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh7vT-0008Uv-Dj for dime@ietf.org; Fri, 19 May 2006 12:34:07 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh7vQ-0002gY-VB for dime@ietf.org; Fri, 19 May 2006 12:34:07 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 18:34:02 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 18:33:27 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02603745389@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7QAzzp5UWv98bTYWe3IVjIj5rfAACOPaA From: "MORAND Lionel RD-CORE-ISS" To: "Gerardo Giaretta" , "Jari Arkko" X-OriginalArrivalTime: 19 May 2006 16:34:02.0414 (UTC) FILETIME=[0990E4E0:01C67B62] X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: Pasi.Eronen@nokia.com, hannes.tschofenig@gmx.net, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Jari also ;) Year after year, we have the same discussion on this specific topic. = And, as I said in previous discussions, as soon as the use of optional = AVPs at the Diameter protocol level is enough to fulfil service = requirements, even if those optional AVPs are required at the service = level - I said "service" and not "application", we should avoid = resorting to systematically allocate a new application id while we reuse = the same functionalities of an existing diameter application. Lionel=20 -----Message d'origine----- De : Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 Envoy=E9 : vendredi 19 mai 2006 14:30 =C0 : Jari Arkko Cc : dime@ietf.org; hannes.tschofenig@gmx.net; Pasi.Eronen@nokia.com Objet : Re: [Dime] Defining a new Application for mip6-split ? I agree with Jari. The most important thing we need for MIPv6 is that the AAA server = understands that the authentication/authorization request is performed = through Diameter EAP application but it is related to the mobility = service and not to network access service. This is a clear requirement = for an operator. But the presence of some optional AVPs may be = sufficient to fulfill this requirement, imo. --Gerardo On 5/19/06, Jari Arkko wrote: > I would prefer using the existing application, and adding optional=20 > AVPs to carry information related to the IKEv2 (and possibly MIPv6)=20 > service, and possibly some additional values for the NAS-Port-Type=20 > field. > > One of the reasons why an existing application would be preferred is=20 > that then a AAA server that does not care about the type of service=20 > can be used without changes. Yet servers that do care can look at the=20 > AVPs and make more detailed authorization decisions. > > RFC 3588 states that "Creation of a new application should be viewed=20 > as a last resort." and that "In order to justify allocation of a new=20 > application identifier, Diameter applications MUST define one Command=20 > Code, or add new mandatory AVPs to the ABNF." Note that mandatory AVPs = > can be viewed in different ways, and that we should not be too strict=20 > about them. > For instance, Framed-Protocol is an optional AVP in RFCs 4005 and=20 > 4072. Yet, you could argue that if you are doing PPP then you need to=20 > use this attribute and set it to PPP. But that didn't make the=20 > attribute mandatory. > Do we have a similar situation for the IKEv2/MIPv6 attributes and=20 > values? They are not necessary from the NASREQ/EAP perspective, but in = > the specific context you need to use the attributes. In my mind, this=20 > does not make the attributes mandatory from a Diameter application=20 > point of view. If we start creating new applications for every=20 > different situation, we'll have lots of applications and=20 > interoperability problems. Its better to add new optional AVPs and=20 > describe in text when they should be used. The only exception that I=20 > see is security related AVPs that must be understood by the other side = > or else the session should be terminated. > > See also > http://www.arkko.com/publications/draft-arkko-radext-multi-service-dec > isions-02.txt for related discussion about Service-Type,=20 > NAS-Port-Type, and so on. > > --Jari > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 14:11:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9S8-0007st-8V; Fri, 19 May 2006 14:11:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9S6-0007mu-U4 for dime@ietf.org; Fri, 19 May 2006 14:11:54 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9S4-0001Ml-4z for dime@ietf.org; Fri, 19 May 2006 14:11:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 14:15:52 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7QAzzp5UWv98bTYWe3IVjIj5rfAACOPaAAAnUkqw= From: "Avi Lior" To: , , X-Spam-Score: 0.6 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0701794205==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0701794205== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C67B70.4356544F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C67B70.4356544F Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SXQgbWF5IG5vdCBiZSB0aGF0IHNpbXBsZS4NCg0KSWYgSSBoYXZlIHR3byBFQVAgYmFzZWQgYXBw bGljYXRpb24gaW4gbXkgbmV0d29yaywgb25lIHRoYXQgaXMgaGFuZGxpbmcgcHVyZSBFQVAgYXBw bGljYXRpb24sIHRoZSBvdGhlciBpcyBleHRlbmRlZCB0byBoYW5kbGUgdGhlIG5ldyBiZWhhdmlv ciB0aGVuIEkgbmVlZCBhIHdheSB0byByb3V0ZSB0aGUgKHNhbWUpIGNvbW1hbmQgY29ycmVjdGx5 Lg0KDQpIb3cgd2lsbCBJIGFjaGlldmUgdGhhdD8NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KQXZpIExpb3IgIEJyaWRnZXdhdGVyIFN5c3RlbXMNCmNlbGwgKzEgNjEzIDc5Ni00MTgz DQp3b3JrICsxIDYxMyA1OTEtOTEwNCB4IDY0MTcNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBNT1JBTkQgTGlvbmVsIFJELUNPUkUtSVNTIDxsaW9uZWwubW9yYW5kQGZy YW5jZXRlbGVjb20uY29tPg0KVG86IEdlcmFyZG8gR2lhcmV0dGEgPGdlcmFyZG8uZ2lhcmV0dGFA Z21haWwuY29tPjsgSmFyaSBBcmtrbyA8amFyaS5hcmtrb0BwaXVoYS5uZXQ+DQpDQzogUGFzaS5F cm9uZW5Abm9raWEuY29tIDxQYXNpLkVyb25lbkBub2tpYS5jb20+OyBoYW5uZXMudHNjaG9mZW5p Z0BnbXgubmV0IDxoYW5uZXMudHNjaG9mZW5pZ0BnbXgubmV0PjsgZGltZUBpZXRmLm9yZyA8ZGlt ZUBpZXRmLm9yZz4NClNlbnQ6IEZyaSBNYXkgMTkgMTI6MzM6MjcgMjAwNg0KU3ViamVjdDogUkU6 IFtEaW1lXSBEZWZpbmluZyBhIG5ldyBBcHBsaWNhdGlvbiBmb3IgbWlwNi1zcGxpdCA/DQoNCkkg YWdyZWUgd2l0aCBKYXJpIGFsc28gOykNCg0KWWVhciBhZnRlciB5ZWFyLCB3ZSBoYXZlIHRoZSBz YW1lIGRpc2N1c3Npb24gb24gdGhpcyBzcGVjaWZpYyB0b3BpYy4gQW5kLCBhcyBJIHNhaWQgaW4g cHJldmlvdXMgZGlzY3Vzc2lvbnMsIGFzIHNvb24gYXMgdGhlIHVzZSBvZiBvcHRpb25hbCBBVlBz IGF0IHRoZSBEaWFtZXRlciBwcm90b2NvbCBsZXZlbCBpcyAgZW5vdWdoIHRvIGZ1bGZpbCBzZXJ2 aWNlIHJlcXVpcmVtZW50cywgZXZlbiBpZiB0aG9zZSBvcHRpb25hbCBBVlBzIGFyZSByZXF1aXJl ZCBhdCB0aGUgc2VydmljZSBsZXZlbCAtIEkgc2FpZCAic2VydmljZSIgYW5kIG5vdCAiYXBwbGlj YXRpb24iLCB3ZSBzaG91bGQgYXZvaWQgcmVzb3J0aW5nIHRvIHN5c3RlbWF0aWNhbGx5IGFsbG9j YXRlIGEgbmV3IGFwcGxpY2F0aW9uIGlkIHdoaWxlIHdlIHJldXNlIHRoZSBzYW1lIGZ1bmN0aW9u YWxpdGllcyBvZiBhbiBleGlzdGluZyBkaWFtZXRlciBhcHBsaWNhdGlvbi4NCg0KTGlvbmVsIA0K DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlIDogR2VyYXJkbyBHaWFyZXR0YSBbbWFp bHRvOmdlcmFyZG8uZ2lhcmV0dGFAZ21haWwuY29tXSANCkVudm95w6kgOiB2ZW5kcmVkaSAxOSBt YWkgMjAwNiAxNDozMA0Kw4AgOiBKYXJpIEFya2tvDQpDYyA6IGRpbWVAaWV0Zi5vcmc7IGhhbm5l cy50c2Nob2ZlbmlnQGdteC5uZXQ7IFBhc2kuRXJvbmVuQG5va2lhLmNvbQ0KT2JqZXQgOiBSZTog W0RpbWVdIERlZmluaW5nIGEgbmV3IEFwcGxpY2F0aW9uIGZvciBtaXA2LXNwbGl0ID8NCg0KSSBh Z3JlZSB3aXRoIEphcmkuDQoNClRoZSBtb3N0IGltcG9ydGFudCB0aGluZyB3ZSBuZWVkIGZvciBN SVB2NiBpcyB0aGF0IHRoZSBBQUEgc2VydmVyIHVuZGVyc3RhbmRzIHRoYXQgdGhlIGF1dGhlbnRp Y2F0aW9uL2F1dGhvcml6YXRpb24gcmVxdWVzdCBpcyBwZXJmb3JtZWQgdGhyb3VnaCBEaWFtZXRl ciBFQVAgYXBwbGljYXRpb24gYnV0IGl0IGlzIHJlbGF0ZWQgdG8gdGhlIG1vYmlsaXR5IHNlcnZp Y2UgYW5kIG5vdCB0byBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlLiBUaGlzIGlzIGEgY2xlYXIgcmVx dWlyZW1lbnQgZm9yIGFuIG9wZXJhdG9yLiBCdXQgdGhlIHByZXNlbmNlIG9mIHNvbWUgb3B0aW9u YWwgQVZQcyBtYXkgYmUgc3VmZmljaWVudCB0byBmdWxmaWxsIHRoaXMgcmVxdWlyZW1lbnQsIGlt by4NCg0KLS1HZXJhcmRvDQoNCk9uIDUvMTkvMDYsIEphcmkgQXJra28gPGphcmkuYXJra29AcGl1 aGEubmV0PiB3cm90ZToNCj4gSSB3b3VsZCBwcmVmZXIgdXNpbmcgdGhlIGV4aXN0aW5nIGFwcGxp Y2F0aW9uLCBhbmQgYWRkaW5nIG9wdGlvbmFsIA0KPiBBVlBzIHRvIGNhcnJ5IGluZm9ybWF0aW9u IHJlbGF0ZWQgdG8gdGhlIElLRXYyIChhbmQgcG9zc2libHkgTUlQdjYpIA0KPiBzZXJ2aWNlLCBh bmQgcG9zc2libHkgc29tZSBhZGRpdGlvbmFsIHZhbHVlcyBmb3IgdGhlIE5BUy1Qb3J0LVR5cGUg DQo+IGZpZWxkLg0KPg0KPiBPbmUgb2YgdGhlIHJlYXNvbnMgd2h5IGFuIGV4aXN0aW5nIGFwcGxp Y2F0aW9uIHdvdWxkIGJlIHByZWZlcnJlZCBpcyANCj4gdGhhdCB0aGVuIGEgQUFBIHNlcnZlciB0 aGF0IGRvZXMgbm90IGNhcmUgYWJvdXQgdGhlIHR5cGUgb2Ygc2VydmljZSANCj4gY2FuIGJlIHVz ZWQgd2l0aG91dCBjaGFuZ2VzLiBZZXQgc2VydmVycyB0aGF0IGRvIGNhcmUgY2FuIGxvb2sgYXQg dGhlIA0KPiBBVlBzIGFuZCBtYWtlIG1vcmUgZGV0YWlsZWQgYXV0aG9yaXphdGlvbiBkZWNpc2lv bnMuDQo+DQo+IFJGQyAzNTg4IHN0YXRlcyB0aGF0ICAiQ3JlYXRpb24gb2YgYSBuZXcgYXBwbGlj YXRpb24gc2hvdWxkIGJlIHZpZXdlZCANCj4gYXMgYSBsYXN0IHJlc29ydC4iIGFuZCB0aGF0ICJJ biBvcmRlciB0byBqdXN0aWZ5IGFsbG9jYXRpb24gb2YgYSBuZXcgDQo+IGFwcGxpY2F0aW9uIGlk ZW50aWZpZXIsIERpYW1ldGVyIGFwcGxpY2F0aW9ucyBNVVNUIGRlZmluZSBvbmUgQ29tbWFuZCAN Cj4gQ29kZSwgb3IgYWRkIG5ldyBtYW5kYXRvcnkgQVZQcyB0byB0aGUgQUJORi4iIE5vdGUgdGhh dCBtYW5kYXRvcnkgQVZQcyANCj4gY2FuIGJlIHZpZXdlZCBpbiBkaWZmZXJlbnQgd2F5cywgYW5k IHRoYXQgd2Ugc2hvdWxkIG5vdCBiZSB0b28gc3RyaWN0IA0KPiBhYm91dCB0aGVtLg0KPiBGb3Ig aW5zdGFuY2UsIEZyYW1lZC1Qcm90b2NvbCBpcyBhbiBvcHRpb25hbCBBVlAgaW4gUkZDcyA0MDA1 IGFuZCANCj4gNDA3Mi4gWWV0LCB5b3UgY291bGQgYXJndWUgdGhhdCBpZiB5b3UgYXJlIGRvaW5n IFBQUCB0aGVuIHlvdSBuZWVkIHRvIA0KPiB1c2UgdGhpcyBhdHRyaWJ1dGUgYW5kIHNldCBpdCB0 byBQUFAuIEJ1dCB0aGF0IGRpZG4ndCBtYWtlIHRoZSANCj4gYXR0cmlidXRlIG1hbmRhdG9yeS4N Cj4gRG8gd2UgaGF2ZSBhIHNpbWlsYXIgc2l0dWF0aW9uIGZvciB0aGUgSUtFdjIvTUlQdjYgYXR0 cmlidXRlcyBhbmQgDQo+IHZhbHVlcz8gVGhleSBhcmUgbm90IG5lY2Vzc2FyeSBmcm9tIHRoZSBO QVNSRVEvRUFQIHBlcnNwZWN0aXZlLCBidXQgaW4gDQo+IHRoZSBzcGVjaWZpYyBjb250ZXh0IHlv dSBuZWVkIHRvIHVzZSB0aGUgYXR0cmlidXRlcy4gSW4gbXkgbWluZCwgdGhpcyANCj4gZG9lcyBu b3QgbWFrZSB0aGUgYXR0cmlidXRlcyBtYW5kYXRvcnkgZnJvbSBhIERpYW1ldGVyIGFwcGxpY2F0 aW9uIA0KPiBwb2ludCBvZiB2aWV3LiBJZiB3ZSBzdGFydCBjcmVhdGluZyBuZXcgYXBwbGljYXRp b25zIGZvciBldmVyeSANCj4gZGlmZmVyZW50IHNpdHVhdGlvbiwgd2UnbGwgaGF2ZSBsb3RzIG9m IGFwcGxpY2F0aW9ucyBhbmQgDQo+IGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMuIEl0cyBiZXR0 ZXIgdG8gYWRkIG5ldyBvcHRpb25hbCBBVlBzIGFuZCANCj4gZGVzY3JpYmUgaW4gdGV4dCB3aGVu IHRoZXkgc2hvdWxkIGJlIHVzZWQuIFRoZSBvbmx5IGV4Y2VwdGlvbiB0aGF0IEkgDQo+IHNlZSBp cyBzZWN1cml0eSByZWxhdGVkIEFWUHMgdGhhdCBtdXN0IGJlIHVuZGVyc3Rvb2QgYnkgdGhlIG90 aGVyIHNpZGUgDQo+IG9yIGVsc2UgdGhlIHNlc3Npb24gc2hvdWxkIGJlIHRlcm1pbmF0ZWQuDQo+ DQo+IFNlZSBhbHNvDQo+IGh0dHA6Ly93d3cuYXJra28uY29tL3B1YmxpY2F0aW9ucy9kcmFmdC1h cmtrby1yYWRleHQtbXVsdGktc2VydmljZS1kZWMNCj4gaXNpb25zLTAyLnR4dCBmb3IgcmVsYXRl ZCBkaXNjdXNzaW9uIGFib3V0IFNlcnZpY2UtVHlwZSwgDQo+IE5BUy1Qb3J0LVR5cGUsIGFuZCBz byBvbi4NCj4NCj4gLS1KYXJpDQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IERpTUUgbWFpbGluZyBsaXN0DQo+IERpTUVAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KPg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5n IGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2RpbWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQo= ------_=_NextPart_001_01C67B70.4356544F Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2MzguMSI+DQo8VElUTEU+UmU6IFtEaW1lXSBE ZWZpbmluZyBhIG5ldyBBcHBsaWNhdGlvbiBmb3IgbWlwNi1zcGxpdCA/PC9USVRMRT4NCjwvSEVB RD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZvcm1hdCAtLT4NCg0K PFA+PEZPTlQgU0laRT0yPkl0IG1heSBub3QgYmUgdGhhdCBzaW1wbGUuPEJSPg0KPEJSPg0KSWYg SSBoYXZlIHR3byBFQVAgYmFzZWQgYXBwbGljYXRpb24gaW4gbXkgbmV0d29yaywgb25lIHRoYXQg aXMgaGFuZGxpbmcgcHVyZSBFQVAgYXBwbGljYXRpb24sIHRoZSBvdGhlciBpcyBleHRlbmRlZCB0 byBoYW5kbGUgdGhlIG5ldyBiZWhhdmlvciB0aGVuIEkgbmVlZCBhIHdheSB0byByb3V0ZSB0aGUg KHNhbWUpIGNvbW1hbmQgY29ycmVjdGx5LjxCUj4NCjxCUj4NCkhvdyB3aWxsIEkgYWNoaWV2ZSB0 aGF0PzxCUj4NCjxCUj4NCjxCUj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPEJSPg0KQXZp IExpb3ImbmJzcDsgQnJpZGdld2F0ZXIgU3lzdGVtczxCUj4NCmNlbGwgKzEgNjEzIDc5Ni00MTgz PEJSPg0Kd29yayArMSA2MTMgNTkxLTkxMDQgeCA2NDE3PEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQpGcm9tOiBNT1JBTkQgTGlvbmVsIFJELUNP UkUtSVNTICZsdDtsaW9uZWwubW9yYW5kQGZyYW5jZXRlbGVjb20uY29tJmd0OzxCUj4NClRvOiBH ZXJhcmRvIEdpYXJldHRhICZsdDtnZXJhcmRvLmdpYXJldHRhQGdtYWlsLmNvbSZndDs7IEphcmkg QXJra28gJmx0O2phcmkuYXJra29AcGl1aGEubmV0Jmd0OzxCUj4NCkNDOiBQYXNpLkVyb25lbkBu b2tpYS5jb20gJmx0O1Bhc2kuRXJvbmVuQG5va2lhLmNvbSZndDs7IGhhbm5lcy50c2Nob2Zlbmln QGdteC5uZXQgJmx0O2hhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQmZ3Q7OyBkaW1lQGlldGYub3Jn ICZsdDtkaW1lQGlldGYub3JnJmd0OzxCUj4NClNlbnQ6IEZyaSBNYXkgMTkgMTI6MzM6MjcgMjAw NjxCUj4NClN1YmplY3Q6IFJFOiBbRGltZV0gRGVmaW5pbmcgYSBuZXcgQXBwbGljYXRpb24gZm9y IG1pcDYtc3BsaXQgPzxCUj4NCjxCUj4NCkkgYWdyZWUgd2l0aCBKYXJpIGFsc28gOyk8QlI+DQo8 QlI+DQpZZWFyIGFmdGVyIHllYXIsIHdlIGhhdmUgdGhlIHNhbWUgZGlzY3Vzc2lvbiBvbiB0aGlz IHNwZWNpZmljIHRvcGljLiBBbmQsIGFzIEkgc2FpZCBpbiBwcmV2aW91cyBkaXNjdXNzaW9ucywg YXMgc29vbiBhcyB0aGUgdXNlIG9mIG9wdGlvbmFsIEFWUHMgYXQgdGhlIERpYW1ldGVyIHByb3Rv Y29sIGxldmVsIGlzJm5ic3A7IGVub3VnaCB0byBmdWxmaWwgc2VydmljZSByZXF1aXJlbWVudHMs IGV2ZW4gaWYgdGhvc2Ugb3B0aW9uYWwgQVZQcyBhcmUgcmVxdWlyZWQgYXQgdGhlIHNlcnZpY2Ug bGV2ZWwgLSBJIHNhaWQgJnF1b3Q7c2VydmljZSZxdW90OyBhbmQgbm90ICZxdW90O2FwcGxpY2F0 aW9uJnF1b3Q7LCB3ZSBzaG91bGQgYXZvaWQgcmVzb3J0aW5nIHRvIHN5c3RlbWF0aWNhbGx5IGFs bG9jYXRlIGEgbmV3IGFwcGxpY2F0aW9uIGlkIHdoaWxlIHdlIHJldXNlIHRoZSBzYW1lIGZ1bmN0 aW9uYWxpdGllcyBvZiBhbiBleGlzdGluZyBkaWFtZXRlciBhcHBsaWNhdGlvbi48QlI+DQo8QlI+ DQpMaW9uZWw8QlI+DQo8QlI+DQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08QlI+DQpEZSA6 IEdlcmFyZG8gR2lhcmV0dGEgWzxBIEhSRUY9Im1haWx0bzpnZXJhcmRvLmdpYXJldHRhQGdtYWls LmNvbSI+bWFpbHRvOmdlcmFyZG8uZ2lhcmV0dGFAZ21haWwuY29tPC9BPl08QlI+DQpFbnZvecOp IDogdmVuZHJlZGkgMTkgbWFpIDIwMDYgMTQ6MzA8QlI+DQrDgCA6IEphcmkgQXJra288QlI+DQpD YyA6IGRpbWVAaWV0Zi5vcmc7IGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQ7IFBhc2kuRXJvbmVu QG5va2lhLmNvbTxCUj4NCk9iamV0IDogUmU6IFtEaW1lXSBEZWZpbmluZyBhIG5ldyBBcHBsaWNh dGlvbiBmb3IgbWlwNi1zcGxpdCA/PEJSPg0KPEJSPg0KSSBhZ3JlZSB3aXRoIEphcmkuPEJSPg0K PEJSPg0KVGhlIG1vc3QgaW1wb3J0YW50IHRoaW5nIHdlIG5lZWQgZm9yIE1JUHY2IGlzIHRoYXQg dGhlIEFBQSBzZXJ2ZXIgdW5kZXJzdGFuZHMgdGhhdCB0aGUgYXV0aGVudGljYXRpb24vYXV0aG9y aXphdGlvbiByZXF1ZXN0IGlzIHBlcmZvcm1lZCB0aHJvdWdoIERpYW1ldGVyIEVBUCBhcHBsaWNh dGlvbiBidXQgaXQgaXMgcmVsYXRlZCB0byB0aGUgbW9iaWxpdHkgc2VydmljZSBhbmQgbm90IHRv IG5ldHdvcmsgYWNjZXNzIHNlcnZpY2UuIFRoaXMgaXMgYSBjbGVhciByZXF1aXJlbWVudCBmb3Ig YW4gb3BlcmF0b3IuIEJ1dCB0aGUgcHJlc2VuY2Ugb2Ygc29tZSBvcHRpb25hbCBBVlBzIG1heSBi ZSBzdWZmaWNpZW50IHRvIGZ1bGZpbGwgdGhpcyByZXF1aXJlbWVudCwgaW1vLjxCUj4NCjxCUj4N Ci0tR2VyYXJkbzxCUj4NCjxCUj4NCk9uIDUvMTkvMDYsIEphcmkgQXJra28gJmx0O2phcmkuYXJr a29AcGl1aGEubmV0Jmd0OyB3cm90ZTo8QlI+DQomZ3Q7IEkgd291bGQgcHJlZmVyIHVzaW5nIHRo ZSBleGlzdGluZyBhcHBsaWNhdGlvbiwgYW5kIGFkZGluZyBvcHRpb25hbDxCUj4NCiZndDsgQVZQ cyB0byBjYXJyeSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBJS0V2MiAoYW5kIHBvc3NpYmx5 IE1JUHY2KTxCUj4NCiZndDsgc2VydmljZSwgYW5kIHBvc3NpYmx5IHNvbWUgYWRkaXRpb25hbCB2 YWx1ZXMgZm9yIHRoZSBOQVMtUG9ydC1UeXBlPEJSPg0KJmd0OyBmaWVsZC48QlI+DQomZ3Q7PEJS Pg0KJmd0OyBPbmUgb2YgdGhlIHJlYXNvbnMgd2h5IGFuIGV4aXN0aW5nIGFwcGxpY2F0aW9uIHdv dWxkIGJlIHByZWZlcnJlZCBpczxCUj4NCiZndDsgdGhhdCB0aGVuIGEgQUFBIHNlcnZlciB0aGF0 IGRvZXMgbm90IGNhcmUgYWJvdXQgdGhlIHR5cGUgb2Ygc2VydmljZTxCUj4NCiZndDsgY2FuIGJl IHVzZWQgd2l0aG91dCBjaGFuZ2VzLiBZZXQgc2VydmVycyB0aGF0IGRvIGNhcmUgY2FuIGxvb2sg YXQgdGhlPEJSPg0KJmd0OyBBVlBzIGFuZCBtYWtlIG1vcmUgZGV0YWlsZWQgYXV0aG9yaXphdGlv biBkZWNpc2lvbnMuPEJSPg0KJmd0OzxCUj4NCiZndDsgUkZDIDM1ODggc3RhdGVzIHRoYXQmbmJz cDsgJnF1b3Q7Q3JlYXRpb24gb2YgYSBuZXcgYXBwbGljYXRpb24gc2hvdWxkIGJlIHZpZXdlZDxC Uj4NCiZndDsgYXMgYSBsYXN0IHJlc29ydC4mcXVvdDsgYW5kIHRoYXQgJnF1b3Q7SW4gb3JkZXIg dG8ganVzdGlmeSBhbGxvY2F0aW9uIG9mIGEgbmV3PEJSPg0KJmd0OyBhcHBsaWNhdGlvbiBpZGVu dGlmaWVyLCBEaWFtZXRlciBhcHBsaWNhdGlvbnMgTVVTVCBkZWZpbmUgb25lIENvbW1hbmQ8QlI+ DQomZ3Q7IENvZGUsIG9yIGFkZCBuZXcgbWFuZGF0b3J5IEFWUHMgdG8gdGhlIEFCTkYuJnF1b3Q7 IE5vdGUgdGhhdCBtYW5kYXRvcnkgQVZQczxCUj4NCiZndDsgY2FuIGJlIHZpZXdlZCBpbiBkaWZm ZXJlbnQgd2F5cywgYW5kIHRoYXQgd2Ugc2hvdWxkIG5vdCBiZSB0b28gc3RyaWN0PEJSPg0KJmd0 OyBhYm91dCB0aGVtLjxCUj4NCiZndDsgRm9yIGluc3RhbmNlLCBGcmFtZWQtUHJvdG9jb2wgaXMg YW4gb3B0aW9uYWwgQVZQIGluIFJGQ3MgNDAwNSBhbmQ8QlI+DQomZ3Q7IDQwNzIuIFlldCwgeW91 IGNvdWxkIGFyZ3VlIHRoYXQgaWYgeW91IGFyZSBkb2luZyBQUFAgdGhlbiB5b3UgbmVlZCB0bzxC Uj4NCiZndDsgdXNlIHRoaXMgYXR0cmlidXRlIGFuZCBzZXQgaXQgdG8gUFBQLiBCdXQgdGhhdCBk aWRuJ3QgbWFrZSB0aGU8QlI+DQomZ3Q7IGF0dHJpYnV0ZSBtYW5kYXRvcnkuPEJSPg0KJmd0OyBE byB3ZSBoYXZlIGEgc2ltaWxhciBzaXR1YXRpb24gZm9yIHRoZSBJS0V2Mi9NSVB2NiBhdHRyaWJ1 dGVzIGFuZDxCUj4NCiZndDsgdmFsdWVzPyBUaGV5IGFyZSBub3QgbmVjZXNzYXJ5IGZyb20gdGhl IE5BU1JFUS9FQVAgcGVyc3BlY3RpdmUsIGJ1dCBpbjxCUj4NCiZndDsgdGhlIHNwZWNpZmljIGNv bnRleHQgeW91IG5lZWQgdG8gdXNlIHRoZSBhdHRyaWJ1dGVzLiBJbiBteSBtaW5kLCB0aGlzPEJS Pg0KJmd0OyBkb2VzIG5vdCBtYWtlIHRoZSBhdHRyaWJ1dGVzIG1hbmRhdG9yeSBmcm9tIGEgRGlh bWV0ZXIgYXBwbGljYXRpb248QlI+DQomZ3Q7IHBvaW50IG9mIHZpZXcuIElmIHdlIHN0YXJ0IGNy ZWF0aW5nIG5ldyBhcHBsaWNhdGlvbnMgZm9yIGV2ZXJ5PEJSPg0KJmd0OyBkaWZmZXJlbnQgc2l0 dWF0aW9uLCB3ZSdsbCBoYXZlIGxvdHMgb2YgYXBwbGljYXRpb25zIGFuZDxCUj4NCiZndDsgaW50 ZXJvcGVyYWJpbGl0eSBwcm9ibGVtcy4gSXRzIGJldHRlciB0byBhZGQgbmV3IG9wdGlvbmFsIEFW UHMgYW5kPEJSPg0KJmd0OyBkZXNjcmliZSBpbiB0ZXh0IHdoZW4gdGhleSBzaG91bGQgYmUgdXNl ZC4gVGhlIG9ubHkgZXhjZXB0aW9uIHRoYXQgSTxCUj4NCiZndDsgc2VlIGlzIHNlY3VyaXR5IHJl bGF0ZWQgQVZQcyB0aGF0IG11c3QgYmUgdW5kZXJzdG9vZCBieSB0aGUgb3RoZXIgc2lkZTxCUj4N CiZndDsgb3IgZWxzZSB0aGUgc2Vzc2lvbiBzaG91bGQgYmUgdGVybWluYXRlZC48QlI+DQomZ3Q7 PEJSPg0KJmd0OyBTZWUgYWxzbzxCUj4NCiZndDsgPEEgSFJFRj0iaHR0cDovL3d3dy5hcmtrby5j b20vcHVibGljYXRpb25zL2RyYWZ0LWFya2tvLXJhZGV4dC1tdWx0aS1zZXJ2aWNlLWRlYyI+aHR0 cDovL3d3dy5hcmtrby5jb20vcHVibGljYXRpb25zL2RyYWZ0LWFya2tvLXJhZGV4dC1tdWx0aS1z ZXJ2aWNlLWRlYzwvQT48QlI+DQomZ3Q7IGlzaW9ucy0wMi50eHQgZm9yIHJlbGF0ZWQgZGlzY3Vz c2lvbiBhYm91dCBTZXJ2aWNlLVR5cGUsPEJSPg0KJmd0OyBOQVMtUG9ydC1UeXBlLCBhbmQgc28g b24uPEJSPg0KJmd0OzxCUj4NCiZndDsgLS1KYXJpPEJSPg0KJmd0OzxCUj4NCiZndDs8QlI+DQom Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0K Jmd0OyBEaU1FIG1haWxpbmcgbGlzdDxCUj4NCiZndDsgRGlNRUBpZXRmLm9yZzxCUj4NCiZndDsg PEEgSFJFRj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvQT48QlI+DQomZ3Q7PEJS Pg0KPEJSPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 QlI+DQpEaU1FIG1haWxpbmcgbGlzdDxCUj4NCkRpTUVAaWV0Zi5vcmc8QlI+DQo8QSBIUkVGPSJo dHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIj5odHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC9BPjxCUj4NCjxCUj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KRGlNRSBtYWlsaW5nIGxp c3Q8QlI+DQpEaU1FQGlldGYub3JnPEJSPg0KPEEgSFJFRj0iaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZSI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGltZTwvQT48QlI+DQo8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4= ------_=_NextPart_001_01C67B70.4356544F-- --===============0701794205== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime --===============0701794205==-- From dime-bounces@ietf.org Fri May 19 14:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9rL-0008WU-U9; Fri, 19 May 2006 14:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9rK-0008WP-RE for dime@ietf.org; Fri, 19 May 2006 14:37:58 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9rJ-0002nK-De for dime@ietf.org; Fri, 19 May 2006 14:37:58 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C483E898ED; Fri, 19 May 2006 21:37:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 736BF898EB; Fri, 19 May 2006 21:37:53 +0300 (EEST) Message-ID: <446E10B8.40601@piuha.net> Date: Fri, 19 May 2006 21:38:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Dime] Defining a new Application for mip6-split ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Avi, > If I have two EAP based application in my network, one that is > handling pure EAP application, the other is extended to handle the new > behavior then I need a way to route the (same) command correctly. > Ah, but that is a new requirement. If you believe that you need to route EAP authentication from a 802.11 AP differently than from IKEv2/MIPv6, then you need one of these: - Use different user/domain names for the users of the different services. - Point to different servers from the AP and SGW (but this works less well if you have proxies and roaming). - New application ID. - Some weird form of Diameter and RADIUS source routing based on what type of node sent the message. However, it is far from clear to me why you would really need to route the authentication differently *for the same user*. Many authentication mechanisms can also have state, which would imply that at the end they need to end up in the same device anyhow. Can you expand on why you need to handle the same users in different authentication servers? --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 14:43:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9wY-0002Bj-Fp; Fri, 19 May 2006 14:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9wX-0002Be-AD for dime@ietf.org; Fri, 19 May 2006 14:43:21 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9wV-0003UV-1A for dime@ietf.org; Fri, 19 May 2006 14:43:21 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 5B250A0DDC for ; Fri, 19 May 2006 14:43:18 -0400 (EDT) Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55]) by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k4JIhINE003886 for ; Fri, 19 May 2006 14:43:18 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 14:21:22 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <446E10B8.40601@piuha.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org [.. snip ..] > Ah, but that is a new requirement. If you believe that you need > to route EAP authentication from a 802.11 AP differently > than from IKEv2/MIPv6, then you need one of these: > > - Use different user/domain names for the users of > the different services. > > - Point to different servers from the AP and SGW (but > this works less well if you have proxies and roaming). > > - New application ID. > > - Some weird form of Diameter and RADIUS source routing > based on what type of node sent the message. [TOLGA]Or a proxy, which would route the initial requests for sessions based on the absence/presence of certain AVPs -in addition to applicationId-. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 14:47:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA0s-00049e-6Z; Fri, 19 May 2006 14:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA0q-000482-Rr for dime@ietf.org; Fri, 19 May 2006 14:47:48 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhA0q-0003v6-CZ for dime@ietf.org; Fri, 19 May 2006 14:47:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 14:51:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ6xUiAGBNw7otvTsOKlIW1UhF1MQAkdkzA From: "Avi Lior" To: "Yoshihiro Ohba" X-Spam-Score: 0.1 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Yoshi, Please see inline....=20 > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Sent: Thursday, May 18, 2006 5:47 PM > To: Avi Lior > Cc: Yoshihiro Ohba; Julien Bournelle; Pasi.Eronen@nokia.com;=20 > hannes.tschofenig@gmx.net; dime@ietf.org > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > On Thu, May 18, 2006 at 04:40:25PM -0400, Avi Lior wrote: > > Hi Yoshi, > > =20 > > Based on your repsonse we don't have to create a new=20 > application id. =20 > > So how do I express that Service-Type (or NAS-Port-Type) is=20 > required? >=20 > My response was based on my reading of RFC 3588. On the=20 > other hand, RFC 3588 does not describe how to deal with the situation. Yes. I realize that. Also, I do agree about your assement of 3588. We need to fix that. > >=20 > > So do I create a new ABNF for the DER and DEA commands in the=20 > > EAP-Application to show that these attributes are required now? > >=20 > > Under what context do I put this new ABNF? I don't have a new=20 > > Application ID nor do I have a new Command? >=20 > I think defining a revised ABNF to supersede the existing=20 > ABNF for an existing message is NOT a good idea, since it=20 > affects existing Diameter message parser implementations. I agree. =20 =20 > Rather than that, I'd suggest keeping the current ABNF for=20 > DER and DEA as it is, and define additional processing rules=20 > for the AVPs that are defined as optional but required only=20 > by a specific service in a new standard track RFC. > I mean, the message parser does not reject the message even=20 > when those AVPs are missing (because it is defined as=20 > optional in the ABNF), but the implementation of the=20 > service-specific Diameter EAP application must rejects the=20 > message if the AVPs are missing or do not contain information=20 > required by the service. I have a problem with your recommendations. Consider the case here I have to support both standard EAP Application and HA based eap application using two different Implementation. One can support the EAP Application the other supports the HA based Application. How do I route the message? The application id is the same and the command is the same. Futhermore, assume we use the NAS-Port-Type and set it to HA-MIPv4-Port. The EAP Application will not understand that value (since its new).. Seems to me that as a minimum we need a new Application id here. Do you agree? > Yoshihiro Ohba >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: Thursday, May 18, 2006 1:52 PM > > > To: Avi Lior > > > Cc: Julien Bournelle; Pasi.Eronen@nokia.com;=20 > > > hannes.tschofenig@gmx.net; dime@ietf.org > > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > >=20 > > > On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote: > > > >=20 > > > > The problem is that neither Service-Type or Port-Type is > > > mandatory. =20 > > > >=20 > > > > O fcourse, if we need to make it mandatory we need to create an=20 > > > > new Application. > > >=20 > > > If those AVPs are defined in an existing application, we=20 > don't need=20 > > > to create a new application just because the AVPs that appear in=20 > > > "optional" portion of the ABNF of the existing=20 > application need to=20 > > > appear in "required" portion. > > >=20 > > > Yoshihiro Ohba > > >=20 > > >=20 > > > >=20 > > > > Also, if we add a new enumeration to either Port-Type or > > > Service-Type > > > > wouldn't we have to create a new Application. > > > >=20 > > > > BTW, this has been an issue even in RADIUS. How does=20 > the AAA know=20 > > > > this its authenticating for Mobile IP. Traditionaly it > > > would know that > > > > NAS-IP or NAS-Identifier is coming from an HA. But that > > > doesn't scale at all. > > > >=20 > > > > I was trying to decide whether Service-Type or Port-Type is the=20 > > > > correct way to go. Service Type seems to be the=20 > correct way but=20 > > > > in RADIUS and Diameter service-type also can be > > > authenticate-only or authorize-only. > > > > So what if the HA wanted to authenticate-only or authorize-only=20 > > > > for the MIP service? I would lose the ability to also indicate > > > that this > > > > is an HA. > > > >=20 > > > > So Port-Type seems to be the way to go.... > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > > Sent: Thursday, May 18, 2006 7:06 AM > > > > > To: Pasi.Eronen@nokia.com > > > > > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > > > > > Subject: Re: [Dime] Defining a new Application for=20 > mip6-split ? > > > > >=20 > > > > > Hi Pasi, > > > > >=20 > > > > > On Thu, May 18, 2006 at 02:45:00PM +0300, > > > Pasi.Eronen@nokia.com wrote: > > > > > > Hi Julien, > > > > > >=20 > > > > > > There's nothing in RFC 4072 that would limit its use to, > > > > > say, PPP or > > > > > > 802.1X -- it works for IKEv2 as well (which can be=20 > considered=20 > > > > > > a special kind of network access, where the "link" is a > > > > > tunnel over IP). > > > > >=20 > > > > > I'm not saying that we can't use IKEv2 with Diameter=20 > EAP. I had=20 > > > > > just a doubt due to the fact that in our case, we're > > > doing AAA for > > > > > the mip6 service and not for network access. > > > > > (So I wanted to know opinion from the group before=20 > starting to > > > > > write) > > > > >=20 > > > > > > The details (MIP6 or 802.11 WLAN or something else) can be > > > > > sent to the > > > > > > AAA server using e.g. Service-Type and/or=20 > NAS-Port-Type AVPs. > > > > >=20 > > > > > ok. I forgot the Service-Type AVP which seems to be=20 > what we need. > > > > >=20 > > > > > thanks, > > > > >=20 > > > > > Best regards, > > > > >=20 > > > > > Julien > > > > >=20 > > > > > >=20 > > > > > > Best regards, > > > > > > Pasi > > > > > >=20 > > > > > > > -----Original Message----- > > > > > > > From: ext Julien Bournelle > > > [mailto:julien.bournelle@int-evry.fr] > > > > > > > Sent: 18 May, 2006 11:42 > > > > > > > To: dime@ietf.org > > > > > > > Cc: hannes.tschofenig@gmx.net > > > > > > > Subject: [Dime] Defining a new Application for=20 > mip6-split ? > > > > > > >=20 > > > > > > > Hi all, > > > > > > >=20 > > > > > > > we're in the process of updating/writing the document=20 > > > > > > > describing use of Diameter for the Mobile IPv6 split > > > scenario. > > > > > > >=20 > > > > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 > > > > > with the HA > > > > > > > to setup IPsec SAs. This exchange is also used=20 > by the HA to=20 > > > > > > > authenticate the MN using EAP. The HA may rely on a > > > > > AAA/EAP server > > > > > > > for this. So we have the following scheme: > > > > > > >=20 > > > > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > > > >=20 > > > > > > > A priori Diameter EAP (RFC 4072) can be used between > > > HA and AAA.=20 > > > > > > >=20 > > > > > > > The problem is that Diameter EAP is normally used > > > for Network > > > > > > > Access authentication. > > > > > > >=20 > > > > > > > In our case, the AAA server must perform AAA > > > > > functionality for the > > > > > > > Mobile IPv6 service. The AAA server must know=20 > that it has to=20 > > > > > > > authorize the mip6 service and the accounting (ASR/ASA) > > > > > is also for > > > > > > > mip6 and not for network access. > > > > > > >=20 > > > > > > > For the above reason, it seems that we should define a > > > > > new Diameter > > > > > > > Application. However, in the same time, the messages > > > defined in > > > > > > > Diameter EAP could be reused. > > > > > > >=20 > > > > > > > So I'd like to hear opinions concerning this issue. > > > > > > >=20 > > > > > > > Thanks, > > > > > > >=20 > > > > > > >=20 > > > > > > > - Julien B. > > > > > > >=20 > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > DiME mailing list > > > > > > > DiME@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > >=20 > > > > >=20 > > > > > -- > > > > > julien.bournelle at int-evry.fr > > > > >=20 > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > >=20 > > > >=20 > > >=20 > >=20 > >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 14:52:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA5O-0006mT-4j; Fri, 19 May 2006 14:52:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhA5N-0006mN-I0 for dime@ietf.org; Fri, 19 May 2006 14:52:29 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhA5N-0004VP-Az for dime@ietf.org; Fri, 19 May 2006 14:52:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 14:56:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7c/IHarPc2paBSQubHD3sWnKBnAAAVyWg From: "Avi Lior" To: "Jari Arkko" X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Jari, See inline...=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, May 19, 2006 2:39 PM > To: Avi Lior > Cc: dime@ietf.org > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > Avi, >=20 > > If I have two EAP based application in my network, one that is=20 > > handling pure EAP application, the other is extended to=20 > handle the new=20 > > behavior then I need a way to route the (same) command correctly. > > > Ah, but that is a new requirement. If you believe that you=20 > need to route EAP authentication from a 802.11 AP differently=20 > than from IKEv2/MIPv6, then you need one of these: >=20 > - Use different user/domain names for the users of > the different services. This is unacceptable. >=20 > - Point to different servers from the AP and SGW (but > this works less well if you have proxies and roaming). Good, cause this is unaccpetable. =20 > - New application ID. I thought that that was what an application ID is for. No? > - Some weird form of Diameter and RADIUS source routing > based on what type of node sent the message. Good again. This is unacceptable. > However, it is far from clear to me why you would really need=20 > to route the authentication differently *for the same user*. We want to use common user credentials. That is a big plus. =20 > Many authentication mechanisms can also have state, which=20 > would imply that at the end they need to end up in the same=20 > device anyhow. Can you expand on why you need to handle the=20 > same users in different authentication servers? See above. Can you please explain why we are not using Diamter Application Id the way they ought to be used? > --Jari >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 14:58:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAAt-0000GN-O1; Fri, 19 May 2006 14:58:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAAs-0000GH-GU for dime@ietf.org; Fri, 19 May 2006 14:58:10 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAAr-0004iN-6y for dime@ietf.org; Fri, 19 May 2006 14:58:10 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 82D77898ED; Fri, 19 May 2006 21:58:08 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4179B898EB; Fri, 19 May 2006 21:58:08 +0300 (EEST) Message-ID: <446E1577.9060202@piuha.net> Date: Fri, 19 May 2006 21:59:03 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Dime] Defining a new Application for mip6-split ? References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Avi Lior wrote: >>However, it is far from clear to me why you would really need >>to route the authentication differently *for the same user*. >> >> > >We want to use common user credentials. That is a big plus. > > > >>Many authentication mechanisms can also have state, which >>would imply that at the end they need to end up in the same >>device anyhow. Can you expand on why you need to handle the >>same users in different authentication servers? >> >> > >See above. > >Can you please explain why we are not using Diamter Application Id the >way they ought to be used? > > The application ID is indeed designed for routing. Not questioning that. And I also agree with you about the undesirability of the other options. And yes, we want common user credentials. However, what I was asking about is why this leads to the need to use different authentication servers. --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 14:58:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAAz-0000HN-Tl; Fri, 19 May 2006 14:58:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhAAy-0000HI-GU for dime@ietf.org; Fri, 19 May 2006 14:58:16 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhAAx-0004iT-8n for dime@ietf.org; Fri, 19 May 2006 14:58:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 15:02:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7c/IHarPc2paBSQubHD3sWnKBnAAApCNw From: "Avi Lior" To: "Jari Arkko" X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Jari, One more thing....(in addition to my previous reply to this email) What you are suggesting really is that I use the username as a sort of application id. Seems to me that that is backwards right? We should use Application Ids to help route messages in diameter to correct applications and correct application versions. I will respond to other emails shortly. Avi=20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, May 19, 2006 2:39 PM > To: Avi Lior > Cc: dime@ietf.org > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > Avi, >=20 > > If I have two EAP based application in my network, one that is=20 > > handling pure EAP application, the other is extended to=20 > handle the new=20 > > behavior then I need a way to route the (same) command correctly. > > > Ah, but that is a new requirement. If you believe that you=20 > need to route EAP authentication from a 802.11 AP differently=20 > than from IKEv2/MIPv6, then you need one of these: >=20 > - Use different user/domain names for the users of > the different services. >=20 > - Point to different servers from the AP and SGW (but > this works less well if you have proxies and roaming). >=20 > - New application ID. >=20 > - Some weird form of Diameter and RADIUS source routing > based on what type of node sent the message. >=20 > However, it is far from clear to me why you would really need=20 > to route the authentication differently *for the same user*.=20 > Many authentication mechanisms can also have state, which=20 > would imply that at the end they need to end up in the same=20 > device anyhow. Can you expand on why you need to handle the=20 > same users in different authentication servers? >=20 > --Jari >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 15:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhADR-0001VK-1R; Fri, 19 May 2006 15:00:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhADP-0001VE-SZ for dime@ietf.org; Fri, 19 May 2006 15:00:47 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhADN-0004ns-Du for dime@ietf.org; Fri, 19 May 2006 15:00:47 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 21:00:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 21:00:41 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03F1D857@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7c/IHarPc2paBSQubHD3sWnKBnAAAVyWgAAAiqbA= From: To: , X-OriginalArrivalTime: 19 May 2006 19:00:41.0936 (UTC) FILETIME=[867D6500:01C67B76] X-Spam-Score: 0.2 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Avi,=20 Some questions inline. /Jouni > Jari, >=20 >=20 > See inline...=20 >=20 > > Avi, > >=20 > > > If I have two EAP based application in my network, one that is=20 > > > handling pure EAP application, the other is extended to=20 > > handle the new=20 > > > behavior then I need a way to route the (same) command correctly. > > > > > Ah, but that is a new requirement. If you believe that you=20 > > need to route EAP authentication from a 802.11 AP differently=20 > > than from IKEv2/MIPv6, then you need one of these: > >=20 > > - Use different user/domain names for the users of > > the different services. >=20 > This is unacceptable. Just for my clarification why would this (e.g. different realms) be unacceptable? > > - Point to different servers from the AP and SGW (but > > this works less well if you have proxies and roaming). >=20 > Good, cause this is unaccpetable. > =20 > > - New application ID. >=20 > I thought that that was what an application ID is for. No? >=20 > > - Some weird form of Diameter and RADIUS source routing > > based on what type of node sent the message. >=20 > Good again. This is unacceptable. >=20 > > However, it is far from clear to me why you would really need=20 > > to route the authentication differently *for the same user*. >=20 > We want to use common user credentials. That is a big plus. > =20 > > Many authentication mechanisms can also have state, which=20 > > would imply that at the end they need to end up in the same=20 > > device anyhow. Can you expand on why you need to handle the=20 > > same users in different authentication servers? >=20 > See above. >=20 > Can you please explain why we are not using Diamter Application Id the > way they ought to be used? >=20 > > --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 17:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCYm-0002OJ-Qw; Fri, 19 May 2006 17:31:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCYl-0002OE-Om for dime@ietf.org; Fri, 19 May 2006 17:30:59 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCYj-0007QL-Gt for dime@ietf.org; Fri, 19 May 2006 17:30:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 17:34:56 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7dsztqA3mjC37QL63NLq+Rr9TqgAFLRKw From: "Avi Lior" To: "Jari Arkko" X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jari, I may have to perform Network Access Authentication and MIP access authentication. The Network Access Authentication server is provided by Foobar.Inc and the MIP access authentication server is provided by Zot.Inc. But nevertheless, it seems there could be lots of different scenarios as well. We need to make sure the Diameter is used such that it does not prevent deployement problems. =20 The parameters presented in by the MIP scenarios need to be resolved correctly and provide guidelines in the future. To me the behavior of the two applications are different and therefore that calls for different applications ID. That is the intent of the Application ID as I understand it. =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, May 19, 2006 2:59 PM > To: Avi Lior > Cc: dime@ietf.org > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > Avi Lior wrote: >=20 > >>However, it is far from clear to me why you would really=20 > need to route=20 > >>the authentication differently *for the same user*. > >> =20 > >> > > > >We want to use common user credentials. That is a big plus. > >=20 > > =20 > > > >>Many authentication mechanisms can also have state, which=20 > would imply=20 > >>that at the end they need to end up in the same device=20 > anyhow. Can you=20 > >>expand on why you need to handle the same users in different=20 > >>authentication servers? > >> =20 > >> > > > >See above. > > > >Can you please explain why we are not using Diamter=20 > Application Id the=20 > >way they ought to be used? > > =20 > > > The application ID is indeed designed for routing. Not=20 > questioning that. And I also agree with you about the=20 > undesirability of the other options. And yes, we want common=20 > user credentials. However, what I was asking about is why=20 > this leads to the need to use different authentication servers. >=20 > --Jari >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 17:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCZX-0002Z7-58; Fri, 19 May 2006 17:31:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCZW-0002Z2-2P for dime@ietf.org; Fri, 19 May 2006 17:31:46 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCZU-0007Us-N0 for dime@ietf.org; Fri, 19 May 2006 17:31:46 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id A2F9E23CC98; Fri, 19 May 2006 23:31:43 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03905-01-54; Fri, 19 May 2006 23:31:43 +0200 (CEST) Received: from [192.168.123.125] (84-121-37-205.onocable.ono.com [84.121.37.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 28A0823CCB7; Fri, 19 May 2006 23:31:42 +0200 (CEST) Message-ID: <446E3936.5090805@dif.um.es> Date: Fri, 19 May 2006 23:31:34 +0200 From: Santiago Zapata Hernandez User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Dime] Defining a new Application for mip6-split ? References: <446E1577.9060202@piuha.net> In-Reply-To: <446E1577.9060202@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Jari Arkko escribi=F3: [...snip...] > The application ID is indeed designed for routing. Not > questioning that. And I also agree with you about the > undesirability of the other options. And yes, we want > common user credentials. However, what I was asking > about is why this leads to the need to use different > authentication servers. > > =20 The idea of using different authentication servers is coming from the=20 requirement of implementing a specific MIPv6 bootstrapping split=20 scenario: Access Service Authorizer (ASA) <> Mobility Service Authorizer=20 (MSA). (draft-ietf-mip6-bootstrapping-split-02). I think we should use the same application ID, but routing by: - having two different paths (Peers from different paths would not be=20 interconnected). - some proxy should change route (is it RFC compliant?), based in the=20 value of a (optional) AVP. - use different realms (changed by the HA, for example, acting as a=20 proxy). I don't understand why it would not be possible (HA could change=20 this realm, and boostrapping server could restore it (if it is required))= . Only my two cents, Santiago > --Jari > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 17:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCim-0005SM-Ct; Fri, 19 May 2006 17:41:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCik-0005SH-Ja for dime@ietf.org; Fri, 19 May 2006 17:41:18 -0400 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCij-0000D9-Re for dime@ietf.org; Fri, 19 May 2006 17:41:18 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id k4JLf9qo012384; Sat, 20 May 2006 06:41:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id k4JLfA8S006976; Sat, 20 May 2006 06:41:10 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id GAA06963; Sat, 20 May 2006 06:41:10 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id k4JLf8bU019525; Sat, 20 May 2006 06:41:08 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k4JLf8tR027639; Sat, 20 May 2006 06:41:08 +0900 (JST) Received: from steelhead ([172.30.24.104]) by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built Apr 28 2004)) with ESMTPSA id <0IZJ00J1H88EDN00@mail.po.toshiba.co.jp>; Sat, 20 May 2006 06:41:08 +0900 (JST) Received: from ohba by steelhead with local (Exim 4.61) (envelope-from ) id 1FhCiH-0001HE-T3; Fri, 19 May 2006 14:40:49 -0700 Date: Fri, 19 May 2006 17:40:49 -0400 From: Yoshihiro Ohba Subject: Re: [Dime] Defining a new Application for mip6-split ? In-reply-to: To: Avi Lior Message-id: <20060519214049.GA2499@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline References: User-Agent: Mutt/1.5.11+cvs20060403 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: dime@ietf.org, hannes.tschofenig@gmx.net, Pasi.Eronen@nokia.com X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Avi, On Fri, May 19, 2006 at 02:51:51PM -0400, Avi Lior wrote: > > > Rather than that, I'd suggest keeping the current ABNF for > > DER and DEA as it is, and define additional processing rules > > for the AVPs that are defined as optional but required only > > by a specific service in a new standard track RFC. > > I mean, the message parser does not reject the message even > > when those AVPs are missing (because it is defined as > > optional in the ABNF), but the implementation of the > > service-specific Diameter EAP application must rejects the > > message if the AVPs are missing or do not contain information > > required by the service. > > I have a problem with your recommendations. Consider the case here I > have to support both standard EAP Application and HA based eap > application using two different Implementation. One can support the EAP > Application the other supports the HA based Application. How do I route > the message? The application id is the same and the command is the > same. Your scenario rather creates another issue as Jari already mentioned: why do you need different authentication servers for the same user? If what is important is service-specific routing (I am not convinced with it yet), I'd suggest defining a new authorization-only application used only for carrying service-specific attributes (analogous to NASREQ usage in RFC 4072). The downside is that it needs another message roundtrip than carrying the attributes in DER/DEA. > > Futhermore, assume we use the NAS-Port-Type and set it to HA-MIPv4-Port. > The EAP Application will not understand that value (since its new).. Julien asked similar question. If an AVP is defined as "M" bit set and the server supports the AVP, but the server does not understand the value, then an error should be returned. If the server understands the value, it must process the AVP based on the rule defined for the value. > > Seems to me that as a minimum we need a new Application id here. Do you > agree? I think we need to explore a bit more... Yoshihiro Ohba > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: Thursday, May 18, 2006 1:52 PM > > > > To: Avi Lior > > > > Cc: Julien Bournelle; Pasi.Eronen@nokia.com; > > > > hannes.tschofenig@gmx.net; dime@ietf.org > > > > Subject: Re: [Dime] Defining a new Application for mip6-split ? > > > > > > > > On Thu, May 18, 2006 at 10:10:26AM -0400, Avi Lior wrote: > > > > > > > > > > The problem is that neither Service-Type or Port-Type is > > > > mandatory. > > > > > > > > > > O fcourse, if we need to make it mandatory we need to create an > > > > > new Application. > > > > > > > > If those AVPs are defined in an existing application, we > > don't need > > > > to create a new application just because the AVPs that appear in > > > > "optional" portion of the ABNF of the existing > > application need to > > > > appear in "required" portion. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > Also, if we add a new enumeration to either Port-Type or > > > > Service-Type > > > > > wouldn't we have to create a new Application. > > > > > > > > > > BTW, this has been an issue even in RADIUS. How does > > the AAA know > > > > > this its authenticating for Mobile IP. Traditionaly it > > > > would know that > > > > > NAS-IP or NAS-Identifier is coming from an HA. But that > > > > doesn't scale at all. > > > > > > > > > > I was trying to decide whether Service-Type or Port-Type is the > > > > > correct way to go. Service Type seems to be the > > correct way but > > > > > in RADIUS and Diameter service-type also can be > > > > authenticate-only or authorize-only. > > > > > So what if the HA wanted to authenticate-only or authorize-only > > > > > for the MIP service? I would lose the ability to also indicate > > > > that this > > > > > is an HA. > > > > > > > > > > So Port-Type seems to be the way to go.... > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] > > > > > > Sent: Thursday, May 18, 2006 7:06 AM > > > > > > To: Pasi.Eronen@nokia.com > > > > > > Cc: hannes.tschofenig@gmx.net; dime@ietf.org > > > > > > Subject: Re: [Dime] Defining a new Application for > > mip6-split ? > > > > > > > > > > > > Hi Pasi, > > > > > > > > > > > > On Thu, May 18, 2006 at 02:45:00PM +0300, > > > > Pasi.Eronen@nokia.com wrote: > > > > > > > Hi Julien, > > > > > > > > > > > > > > There's nothing in RFC 4072 that would limit its use to, > > > > > > say, PPP or > > > > > > > 802.1X -- it works for IKEv2 as well (which can be > > considered > > > > > > > a special kind of network access, where the "link" is a > > > > > > tunnel over IP). > > > > > > > > > > > > I'm not saying that we can't use IKEv2 with Diameter > > EAP. I had > > > > > > just a doubt due to the fact that in our case, we're > > > > doing AAA for > > > > > > the mip6 service and not for network access. > > > > > > (So I wanted to know opinion from the group before > > starting to > > > > > > write) > > > > > > > > > > > > > The details (MIP6 or 802.11 WLAN or something else) can be > > > > > > sent to the > > > > > > > AAA server using e.g. Service-Type and/or > > NAS-Port-Type AVPs. > > > > > > > > > > > > ok. I forgot the Service-Type AVP which seems to be > > what we need. > > > > > > > > > > > > thanks, > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Julien > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > Pasi > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: ext Julien Bournelle > > > > [mailto:julien.bournelle@int-evry.fr] > > > > > > > > Sent: 18 May, 2006 11:42 > > > > > > > > To: dime@ietf.org > > > > > > > > Cc: hannes.tschofenig@gmx.net > > > > > > > > Subject: [Dime] Defining a new Application for > > mip6-split ? > > > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > > > we're in the process of updating/writing the document > > > > > > > > describing use of Diameter for the Mobile IPv6 split > > > > scenario. > > > > > > > > > > > > > > > > In the split scenario, the Mobile Node (MN) uses IKEv2 > > > > > > with the HA > > > > > > > > to setup IPsec SAs. This exchange is also used > > by the HA to > > > > > > > > authenticate the MN using EAP. The HA may rely on a > > > > > > AAA/EAP server > > > > > > > > for this. So we have the following scheme: > > > > > > > > > > > > > > > > MN <-- IKEv2-EAP --> HA <--------> AAA > > > > > > > > > > > > > > > > A priori Diameter EAP (RFC 4072) can be used between > > > > HA and AAA. > > > > > > > > > > > > > > > > The problem is that Diameter EAP is normally used > > > > for Network > > > > > > > > Access authentication. > > > > > > > > > > > > > > > > In our case, the AAA server must perform AAA > > > > > > functionality for the > > > > > > > > Mobile IPv6 service. The AAA server must know > > that it has to > > > > > > > > authorize the mip6 service and the accounting (ASR/ASA) > > > > > > is also for > > > > > > > > mip6 and not for network access. > > > > > > > > > > > > > > > > For the above reason, it seems that we should define a > > > > > > new Diameter > > > > > > > > Application. However, in the same time, the messages > > > > defined in > > > > > > > > Diameter EAP could be reused. > > > > > > > > > > > > > > > > So I'd like to hear opinions concerning this issue. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > > > > > > > > > > - Julien B. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > DiME mailing list > > > > > > > > DiME@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > -- > > > > > > julien.bournelle at int-evry.fr > > > > > > > > > > > > _______________________________________________ > > > > > > DiME mailing list > > > > > > DiME@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri May 19 21:13:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhG2L-0005ve-Ea; Fri, 19 May 2006 21:13:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhG2J-0005vR-Qk for dime@ietf.org; Fri, 19 May 2006 21:13:43 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhG2I-00071C-GZ for dime@ietf.org; Fri, 19 May 2006 21:13:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Fri, 19 May 2006 21:17:40 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7HTN3Kta33bgVQcCAcVrCtKVJiQAgNiGQ From: "Avi Lior" To: "Jari Arkko" X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Pasi.Eronen@nokia.com, hannes.tschofenig@gmx.net, dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jari, I now want to respond to this email. Please see inline... > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Friday, May 19, 2006 4:18 AM > To: Avi Lior > Cc: Yoshihiro Ohba; dime@ietf.org; hannes.tschofenig@gmx.net;=20 > Pasi.Eronen@nokia.com > Subject: Re: [Dime] Defining a new Application for mip6-split ? >=20 > I would prefer using the existing application, and adding=20 > optional AVPs to carry information related to the IKEv2 (and=20 > possibly MIPv6) service, and possibly some additional values=20 > for the NAS-Port-Type field. BTW in the context of the original question raised, the attribute(s) will not be optional. Here is the snippet: >> In our case, the AAA server must perform AAA functionality for the =20 >> Mobile IPv6 service. The AAA server must know that it has to =20 >> authorize the mip6 service and the accounting (ASR/ASA) is also for >> mip6 and not for network access.=20 If the Diameter message comes from the HA then the HA MUST include the NAS-Port-type attribute. So the command ABNF is being changed. Also the behavior is being changed of the Server. It MUST recognize the (new) value of the NAS-Port-Type. > One of the reasons why an existing application would be=20 > preferred is that then a AAA server that does not care about=20 > the type of service can be used without changes. Yet servers=20 > that do care can look at the AVPs and make more detailed=20 > authorization decisions. Yes so if the behavior is optional then the attributes are optional then may be okay. But that is not the case here. =20 > RFC 3588 states that "Creation of a new application should=20 > be viewed as a last resort." and that "In order to justify=20 > allocation of a new application identifier, Diameter=20 > applications MUST define one Command Code, or add new=20 > mandatory AVPs to the ABNF."=20 BTW that should be cleaned up to say "...Diameter applications MUST define at least one new Command Code, or add new mandatory AVPs to the ABNF. We should clean the last ABNSF part to read: "or add new mandatory AVP(s) that may be included in any command used by the application." > Note that mandatory AVPs can be=20 > viewed in different ways, and that we should not be too=20 > strict about them. > For instance, Framed-Protocol is an optional AVP in RFCs 4005=20 > and 4072. Yet, you could argue that if you are doing PPP then=20 > you need to use this attribute and set it to PPP. But that=20 > didn't make the attribute mandatory. Mandatory does not mean required in the Command. It means that it must be understood by the receiver. We need to clarify that. > Do we have a similar situation for the IKEv2/MIPv6 attributes=20 > and values? They are not necessary from the NASREQ/EAP=20 > perspective, but in the specific context you need to use the=20 > attributes. In my mind, this does not make the attributes=20 > mandatory from a Diameter application point of view.=20 This is correct and is my understanding of 3588. But I think 3588 got it wrong. As I pointed out (in an email to Yoshi) for the MIPv6 Application (or HA application) we have to change the ABNF of the command. We have to make the NAS-Port-Type mandatory in the DEA answer. So under what context do we make that. > If we=20 > start creating new applications for every different=20 > situation, we'll have lots of applications and=20 > interoperability problems. Its better to add new optional=20 > AVPs and describe in text when they should be used. The only=20 > exception that I see is security related AVPs that must be=20 > understood by the other side or else the session should be terminated. I don't think that every situation requires a new application. I see other exceptions. In essence if the application has new "mandatory" behavior changed then we need to use a different application Id. As a minimum we need to make sure that we can route to the correct application -- the application that correctly acts on the command. We only have Application ID to do this with. While I agree that we could have lots of application ids fortunately it's a 32 bit unsigned int. Optional behavior is one case. But when the behavior difference is mandatory then we do need a new Application ID. If folks are concerned about too many application ids, perhaps Diameter should have used version numbers. =20 =20 > See also > http://www.arkko.com/publications/draft-arkko-radext-multi-ser vice-decisions-02.txt > for related discussion about Service-Type, NAS-Port-Type, and so on. >=20 > --Jari >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat May 20 10:21:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhSKl-0001gb-Bf; Sat, 20 May 2006 10:21:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhSKk-0001gW-G5 for dime@ietf.org; Sat, 20 May 2006 10:21:34 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhSKj-00048j-7o for dime@ietf.org; Sat, 20 May 2006 10:21:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Defining a new Application for mip6-split ? Date: Sat, 20 May 2006 10:25:27 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Defining a new Application for mip6-split ? Thread-Index: AcZ7c/IHarPc2paBSQubHD3sWnKBnAAAVyWgAAAiqbAAKIg4YA== From: "Avi Lior" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi see inline please....=20 > -----Original Message----- > From: jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Sent: Friday, May 19, 2006 3:01 PM > To: Avi Lior; jari.arkko@piuha.net > Cc: dime@ietf.org > Subject: RE: [Dime] Defining a new Application for mip6-split ? >=20 > Hi Avi,=20 >=20 > Some questions inline. >=20 > /Jouni >=20 >=20 > > Jari, > >=20 > >=20 > > See inline...=20 > >=20 > > > Avi, > > >=20 > > > > If I have two EAP based application in my network, one that is=20 > > > > handling pure EAP application, the other is extended to > > > handle the new > > > > behavior then I need a way to route the (same) command=20 > correctly. > > > > > > > Ah, but that is a new requirement. If you believe that=20 > you need to=20 > > > route EAP authentication from a 802.11 AP differently than from=20 > > > IKEv2/MIPv6, then you need one of these: > > >=20 > > > - Use different user/domain names for the users of > > > the different services. > >=20 > > This is unacceptable. >=20 > Just for my clarification why would this (e.g. different > realms) be unacceptable? If the service is offered by a different realm then sure. But if it is not then you ought not create different realms problems. If it is indeed a different user-identity, then okay use a different user identity. But if it is not then you ought not create different users to solve this problem. So an example of when this is unacceptable is Network Access Authentication and Mobile IP authentication. We must not create different user identities for each service. =20 In general, operators want to reduce the numbers of entities they have to manage. Having a different identity for each service is the WRONG way to solve these problems. We want to consolidate. >=20 > > > - Point to different servers from the AP and SGW (but > > > this works less well if you have proxies and roaming). > >=20 > > Good, cause this is unaccpetable. > > =20 > > > - New application ID. > >=20 > > I thought that that was what an application ID is for. No? > >=20 > > > - Some weird form of Diameter and RADIUS source routing > > > based on what type of node sent the message. > >=20 > > Good again. This is unacceptable. > >=20 > > > However, it is far from clear to me why you would really need to=20 > > > route the authentication differently *for the same user*. > >=20 > > We want to use common user credentials. That is a big plus. > > =20 > > > Many authentication mechanisms can also have state, which would=20 > > > imply that at the end they need to end up in the same=20 > device anyhow.=20 > > > Can you expand on why you need to handle the same users=20 > in different=20 > > > authentication servers? > >=20 > > See above. > >=20 > > Can you please explain why we are not using Diamter=20 > Application Id the=20 > > way they ought to be used? > >=20 > > > --Jari >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun May 21 06:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhkoq-0000iu-Cp; Sun, 21 May 2006 06:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhkoo-0000ip-Tn for dime@ietf.org; Sun, 21 May 2006 06:05:50 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhkon-0003Gz-KA for dime@ietf.org; Sun, 21 May 2006 06:05:50 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A6CA989852; Sun, 21 May 2006 13:05:35 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6179789832; Sun, 21 May 2006 13:05:35 +0300 (EEST) Message-ID: <44703BA5.8020007@piuha.net> Date: Sun, 21 May 2006 13:06:29 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Dime] Defining a new Application for mip6-split ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Avi Lior wrote: >In general, operators want to reduce the numbers of entities they have >to manage. Having a different identity for each service is the WRONG >way to solve these problems. We want to consolidate. > > Indeed. But wouldn't consolidation also apply to deployment of multiple authentication servers for the same credentials albeit different service (SIP, 802.11, VPN, ...)? I would assume that there are business and technical reasons to keep the number of servers down... --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun May 21 06:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhlIa-0002hW-SR; Sun, 21 May 2006 06:36:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhlIZ-0002hQ-Q1 for dime@ietf.org; Sun, 21 May 2006 06:36:35 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhlIY-0004tz-CD for dime@ietf.org; Sun, 21 May 2006 06:36:35 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 83AEB89852; Sun, 21 May 2006 13:36:33 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 408F389832; Sun, 21 May 2006 13:36:33 +0300 (EEST) Message-ID: <447042E7.4040301@piuha.net> Date: Sun, 21 May 2006 13:37:27 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Santiago Zapata Hernandez Subject: Re: [Dime] Defining a new Application for mip6-split ? References: <446E1577.9060202@piuha.net> <446E3936.5090805@dif.um.es> In-Reply-To: <446E3936.5090805@dif.um.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Santiago Zapata Hernandez wrote: > The idea of using different authentication servers is coming from the > requirement of implementing a specific MIPv6 bootstrapping split > scenario: Access Service Authorizer (ASA) <> Mobility Service > Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02). I have read the draft, but I do not see how it leads to the requirement that the same user identity needs to be routed in different ways for different applications. It seems that the essence of the split scenario is that the access and mobility services are independent, e.g., acquired from different providers with different identities. Or from the same provider (as in when you are in your home network), but the services are provided in an independent fashion. > I think we should use the same application ID, but routing by: > - having two different paths (Peers from different paths would not be > interconnected). > - some proxy should change route (is it RFC compliant?), based in the > value of a (optional) AVP. > - use different realms (changed by the HA, for example, acting as a > proxy). I don't understand why it would not be possible (HA could > change this realm, and boostrapping server could restore it (if it is > required)). Avi's new Application ID may be a better approach than these, because its directly supported by by Diameter as is. (If different routing is needed.) --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun May 21 06:36:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhlIf-0002i6-W2; Sun, 21 May 2006 06:36:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhlIe-0002i1-NJ for dime@ietf.org; Sun, 21 May 2006 06:36:40 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhlId-0004uE-9i for dime@ietf.org; Sun, 21 May 2006 06:36:40 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 9771189870; Sun, 21 May 2006 13:36:38 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 51CE08985B; Sun, 21 May 2006 13:36:38 +0300 (EEST) Message-ID: <447042EC.2050909@piuha.net> Date: Sun, 21 May 2006 13:37:32 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Dime] Defining a new Application for mip6-split ? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Avi Lior wrote: >Hi Jari, > >I may have to perform Network Access Authentication and MIP access >authentication. The Network Access Authentication server is provided by >Foobar.Inc and the MIP access authentication server is provided by >Zot.Inc > > OK. What are the identities of provided by the client in this example? joe@foobar.com and joe@zot.inc? Or joe@commondomain.com for both? If its the latter, can you explain how the credentials are managed and what routing effect you want to provide? >But nevertheless, it seems there could be lots of different scenarios as >well. > >We need to make sure the Diameter is used such that it does not prevent >deployement problems. > >The parameters presented in by the MIP scenarios need to be resolved >correctly and provide guidelines in the future. > >To me the behavior of the two applications are different and therefore >that calls for different applications ID. That is the intent of the >Application ID as I understand it. > > Sure. All I am saying is that there's a fine line between a mandatory attribute in an application designed for and the use of an optional AVP when in a more generic application. --Jari _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 22 05:04:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi6Kd-0001mf-RC; Mon, 22 May 2006 05:04:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi6Kc-0001ma-1m for dime@ietf.org; Mon, 22 May 2006 05:04:06 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi6KY-0005ud-7c for dime@ietf.org; Mon, 22 May 2006 05:04:06 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id C7A4F1FA9B6; Mon, 22 May 2006 11:04:00 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 04373-01-28; Mon, 22 May 2006 11:04:00 +0200 (CEST) Received: from [155.54.205.5] (unknown [155.54.205.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 766A61FA819; Mon, 22 May 2006 11:03:55 +0200 (CEST) Message-ID: <44717E7E.60204@dif.um.es> Date: Mon, 22 May 2006 11:03:58 +0200 From: Santiago Zapata Hernandez User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Dime] Defining a new Application for mip6-split ? References: <446E1577.9060202@piuha.net> <446E3936.5090805@dif.um.es> <447042E7.4040301@piuha.net> In-Reply-To: <447042E7.4040301@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, After thinking in this issue, I'm agree about the identity would be=20 different if we are in the scenario ASA <> MSA. In the other scenario (ASA =3D MSA), I think a new Application ID is not=20 the right solution, because we are managing the same kind of=20 functionality (EAP providing authentication/authorization). I propose to use virtual users for managing this scenarios. BR, Santiago Jari Arkko escribi=F3: > Santiago Zapata Hernandez wrote: > > =20 >> The idea of using different authentication servers is coming from the >> requirement of implementing a specific MIPv6 bootstrapping split >> scenario: Access Service Authorizer (ASA) <> Mobility Service >> Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02). >> =20 > > I have read the draft, but I do not see how it leads to the > requirement that the same user identity needs to be routed > in different ways for different applications. It seems that > the essence of the split scenario is that the access and > mobility services are independent, e.g., acquired from > different providers with different identities. Or from > the same provider (as in when you are in your home > network), but the services are provided in an independent > fashion. > > =20 >> I think we should use the same application ID, but routing by: >> - having two different paths (Peers from different paths would not be >> interconnected). >> - some proxy should change route (is it RFC compliant?), based in the >> value of a (optional) AVP. >> - use different realms (changed by the HA, for example, acting as a >> proxy). I don't understand why it would not be possible (HA could >> change this realm, and boostrapping server could restore it (if it is >> required)). >> =20 > > Avi's new Application ID may be a better approach than these, because > its directly supported by by Diameter as is. (If different routing is > needed.) > > --Jari > > > > > > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 22 05:57:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi79x-00082S-2g; Mon, 22 May 2006 05:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi79v-00082K-Eu for dime@ietf.org; Mon, 22 May 2006 05:57:07 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi79u-0007ul-0K for dime@ietf.org; Mon, 22 May 2006 05:57:07 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 82A8F81BD; Mon, 22 May 2006 11:57:03 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1Fi78g-0006dy-8h; Mon, 22 May 2006 11:55:50 +0200 Date: Mon, 22 May 2006 11:55:50 +0200 From: Julien Bournelle To: Santiago Zapata Hernandez Subject: Re: [Dime] Defining a new Application for mip6-split ? Message-ID: <20060522095550.GA25533@ipv6-3.int-evry.fr> References: <446E1577.9060202@piuha.net> <446E3936.5090805@dif.um.es> <447042E7.4040301@piuha.net> <44717E7E.60204@dif.um.es> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <44717E7E.60204@dif.um.es> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org hi all, On Mon, May 22, 2006 at 11:03:58AM +0200, Santiago Zapata Hernandez wrote= : > Hi all, >=20 > After thinking in this issue, I'm agree about the identity would be=20 > different if we are in the scenario ASA <> MSA. I don't think we should assume that it is different identity. In the Integrated scenario, we also use IKEv2-Diameter EAP and as the HA is allocated by the AAA, we'll probably reuse the same identity with same credentials. And if we do nothing, the AAA server may "think" that it is performing Diameter EAP two times for network access. > In the other scenario (ASA =3D MSA), I think a new Application ID is no= t=20 > the right solution, because we are managing the same kind of=20 > functionality (EAP providing authentication/authorization). EAP is used for authentication. However, Authorization and Accounting is different since in one case it is done for network access while in the other case it's for mip6 service.=20 regards, Julien > I propose to use virtual users for managing this scenarios. >=20 > BR, > Santiago >=20 >=20 >=20 > Jari Arkko escribi=F3: > >Santiago Zapata Hernandez wrote: > > > > =20 > >>The idea of using different authentication servers is coming from the > >>requirement of implementing a specific MIPv6 bootstrapping split > >>scenario: Access Service Authorizer (ASA) <> Mobility Service > >>Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02). > >> =20 > > > >I have read the draft, but I do not see how it leads to the > >requirement that the same user identity needs to be routed > >in different ways for different applications. It seems that > >the essence of the split scenario is that the access and > >mobility services are independent, e.g., acquired from > >different providers with different identities. Or from > >the same provider (as in when you are in your home > >network), but the services are provided in an independent > >fashion. > > > > =20 > >>I think we should use the same application ID, but routing by: > >>- having two different paths (Peers from different paths would not be > >>interconnected). > >>- some proxy should change route (is it RFC compliant?), based in the > >>value of a (optional) AVP. > >>- use different realms (changed by the HA, for example, acting as a > >>proxy). I don't understand why it would not be possible (HA could > >>change this realm, and boostrapping server could restore it (if it is > >>required)). > >> =20 > > > >Avi's new Application ID may be a better approach than these, because > >its directly supported by by Diameter as is. (If different routing is > >needed.) > > > >--Jari > > > > > > > > > > > > =20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime --=20 julien.bournelle at int-evry.fr _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon May 22 06:18:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi7Ub-0006Ds-FY; Mon, 22 May 2006 06:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi7Ub-0006Dn-8R for dime@ietf.org; Mon, 22 May 2006 06:18:29 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi7UZ-0000Al-Lu for dime@ietf.org; Mon, 22 May 2006 06:18:29 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 915C123CE2C; Mon, 22 May 2006 12:18:26 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28085-01-5; Mon, 22 May 2006 12:18:25 +0200 (CEST) Received: from [155.54.205.5] (unknown [155.54.205.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 83E1723CE29; Mon, 22 May 2006 12:18:25 +0200 (CEST) Message-ID: <44718FF4.6020201@dif.um.es> Date: Mon, 22 May 2006 12:18:28 +0200 From: Santiago Zapata Hernandez User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [Dime] Defining a new Application for mip6-split ? References: <446E1577.9060202@piuha.net> <446E3936.5090805@dif.um.es> <447042E7.4040301@piuha.net> <44717E7E.60204@dif.um.es> <20060522095550.GA25533@ipv6-3.int-evry.fr> In-Reply-To: <20060522095550.GA25533@ipv6-3.int-evry.fr> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 1.7 (+) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0581637114==" Errors-To: dime-bounces@ietf.org --===============0581637114== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Julien Bournelle escribió: 
hi all,

On Mon, May 22, 2006 at 11:03:58AM +0200, Santiago Zapata Hernandez wrote:
  
Hi all,

After thinking in this issue, I'm agree about the identity would be 
different if we are in the scenario ASA <> MSA.
    

 I don't think we should assume that it is different identity. In the
 Integrated scenario, we also use IKEv2-Diameter EAP and as the HA is
 allocated by the AAA, we'll probably reuse the same identity with same
 credentials. And if we do nothing, the AAA server may "think" that it
 is performing Diameter EAP two times for network access.
I mean the same user (same credentials) but different user's identifier (domain) because we are working (in split scenario) with different domains. In integrated scenario the server could detect that it is managing network access or mobility authentication by having a look to user's identifier (another sub-domain? or maybe by classifying the identifiers in the server side?)
My proposal is to use different users' identifiers in order to distinguish (in the servers) between the different EAP functionalities (Network access or Mobility).
I don't see any problem by using different identifiers but sharing the same credentials.
My interest is in not creating a new application for each new functionality to be deployed over Diameter-EAP.

BR,
Santiago


  

    
In the other scenario (ASA = MSA), I think a new Application ID is not 
the right solution, because we are managing the same kind of 
functionality (EAP providing authentication/authorization).
    

  

  

 EAP is used for authentication. However, Authorization and Accounting
 is different since in one case it is done for network access while in
 the other case it's for mip6 service. 

 regards,

 Julien

  

  

    
I propose to use virtual users for managing this scenarios.

BR,
Santiago



Jari Arkko escribió:
    

    

      
Santiago Zapata Hernandez wrote:

 
      

      

        
The idea of using different authentication servers is coming from the
requirement of implementing a specific MIPv6 bootstrapping split
scenario: Access Service Authorizer (ASA) <> Mobility Service
Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02).
   
        

      

      
I have read the draft, but I do not see how it leads to the
requirement that the same user identity needs to be routed
in different ways for different applications. It seems that
the essence of the split scenario is that the access and
mobility services are independent, e.g., acquired from
different providers with different identities. Or from
the same provider (as in when you are in your home
network), but the services are provided in an independent
fashion.

 
      

      

        
I think we should use the same application ID, but routing by:
- having two different paths (Peers from different paths would not be
interconnected).
- some proxy should change route (is it RFC compliant?), based in the
value of a (optional) AVP.
- use different realms (changed by the HA, for example, acting as a
proxy). I don't understand why it would not be possible (HA could
change this realm, and boostrapping server could restore it (if it is
required)).
   
        

      

      
Avi's new Application ID may be a better approach than these, because
its directly supported by by Diameter as is. (If different routing is
needed.)

--Jari





 
      

    

    
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime
    

  

  

  









--===============0581637114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime

--===============0581637114==--



From dime-bounces@ietf.org Mon May 22 06:55:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fi83x-0000F2-Ln; Mon, 22 May 2006 06:55:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi83v-0000Bw-W9
	for dime@ietf.org; Mon, 22 May 2006 06:54:59 -0400
Received: from mail.um.es ([155.54.212.109])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi83u-0001tH-Dj
	for dime@ietf.org; Mon, 22 May 2006 06:54:59 -0400
Received: from localhost (localhost [127.0.0.1])
	by mail.um.es (Postfix) with ESMTP id 5094623CE45;
	Mon, 22 May 2006 12:54:57 +0200 (CEST)
Received: from mail.um.es ([127.0.0.1])
	by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP
	id 31399-01-45; Mon, 22 May 2006 12:54:57 +0200 (CEST)
Received: from [155.54.205.5] (unknown [155.54.205.5])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.um.es (Postfix) with ESMTP id 87E2723CE2C;
	Mon, 22 May 2006 12:54:56 +0200 (CEST)
Message-ID: <44719883.1060605@dif.um.es>
Date: Mon, 22 May 2006 12:54:59 +0200
From: Santiago Zapata Hernandez 
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: Julien Bournelle 
Subject: Re: [Dime] Defining a new Application for mip6-split ?
References: 
	<446E1577.9060202@piuha.net> <446E3936.5090805@dif.um.es>
	<447042E7.4040301@piuha.net> <44717E7E.60204@dif.um.es>
	<20060522095550.GA25533@ipv6-3.int-evry.fr>
In-Reply-To: <20060522095550.GA25533@ipv6-3.int-evry.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi, (sorry for sending it again, but I sent it in HTML mode by error.=20
Doing again in text mode).

Julien Bournelle escribi=F3:
> hi all,
>
> On Mon, May 22, 2006 at 11:03:58AM +0200, Santiago Zapata Hernandez wro=
te:
>  =20
>> Hi all,
>>
>> After thinking in this issue, I'm agree about the identity would be=20
>> different if we are in the scenario ASA <> MSA.
>>    =20
>
>  I don't think we should assume that it is different identity. In the
>  Integrated scenario, we also use IKEv2-Diameter EAP and as the HA is
>  allocated by the AAA, we'll probably reuse the same identity with same
>  credentials. And if we do nothing, the AAA server may "think" that it
>  is performing Diameter EAP two times for network access.
>
>  =20
I mean the same user (same credentials) but different user's identifier=20
(domain) because we are working (in split scenario) with different=20
domains. In integrated scenario the server could detect that it is=20
managing network access or mobility authentication by having a look to=20
user's identifier (another sub-domain? or maybe by classifying the=20
identifiers in the server side?)
My proposal is to use different users' identifiers in order to=20
distinguish (in the servers) between the different EAP functionalities=20
(Network access or Mobility).
I don't see any problem by using different identifiers but sharing the=20
same credentials.
My interest is in not creating a new application for each new=20
functionality to be deployed over Diameter-EAP.

BR,
Santiago
>> In the other scenario (ASA =3D MSA), I think a new Application ID is n=
ot=20
>> the right solution, because we are managing the same kind of=20
>> functionality (EAP providing authentication/authorization).
>>    =20
>
>  EAP is used for authentication. However, Authorization and Accounting
>  is different since in one case it is done for network access while in
>  the other case it's for mip6 service.=20
>
>  regards,
>
>  Julien
>
>  =20
>> I propose to use virtual users for managing this scenarios.
>>
>> BR,
>> Santiago
>>
>>
>>
>> Jari Arkko escribi=F3:
>>    =20
>>> Santiago Zapata Hernandez wrote:
>>>
>>> =20
>>>      =20
>>>> The idea of using different authentication servers is coming from th=
e
>>>> requirement of implementing a specific MIPv6 bootstrapping split
>>>> scenario: Access Service Authorizer (ASA) <> Mobility Service
>>>> Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02).
>>>>   =20
>>>>        =20
>>> I have read the draft, but I do not see how it leads to the
>>> requirement that the same user identity needs to be routed
>>> in different ways for different applications. It seems that
>>> the essence of the split scenario is that the access and
>>> mobility services are independent, e.g., acquired from
>>> different providers with different identities. Or from
>>> the same provider (as in when you are in your home
>>> network), but the services are provided in an independent
>>> fashion.
>>>
>>> =20
>>>      =20
>>>> I think we should use the same application ID, but routing by:
>>>> - having two different paths (Peers from different paths would not b=
e
>>>> interconnected).
>>>> - some proxy should change route (is it RFC compliant?), based in th=
e
>>>> value of a (optional) AVP.
>>>> - use different realms (changed by the HA, for example, acting as a
>>>> proxy). I don't understand why it would not be possible (HA could
>>>> change this realm, and boostrapping server could restore it (if it i=
s
>>>> required)).
>>>>   =20
>>>>        =20
>>> Avi's new Application ID may be a better approach than these, because
>>> its directly supported by by Diameter as is. (If different routing is
>>> needed.)
>>>
>>> --Jari
>>>
>>>
>>>
>>>
>>>
>>> =20
>>>      =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>>    =20
>
>  =20


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 07:04:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fi8Co-00030l-7g; Mon, 22 May 2006 07:04:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8Cn-00030g-03
	for dime@ietf.org; Mon, 22 May 2006 07:04:09 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8Cl-0002JS-Gc
	for dime@ietf.org; Mon, 22 May 2006 07:04:08 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 88F2C8131;
	Mon, 22 May 2006 13:04:04 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1Fi8BX-0006gZ-7a; Mon, 22 May 2006 13:02:51 +0200
Date: Mon, 22 May 2006 13:02:51 +0200
From: Julien Bournelle 
To: Santiago Zapata Hernandez 
Subject: Re: [Dime] Defining a new Application for mip6-split ?
Message-ID: <20060522110251.GA25695@ipv6-3.int-evry.fr>
References: 
	<446E1577.9060202@piuha.net> <446E3936.5090805@dif.um.es>
	<447042E7.4040301@piuha.net> <44717E7E.60204@dif.um.es>
	<20060522095550.GA25533@ipv6-3.int-evry.fr>
	<44719883.1060605@dif.um.es>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
In-Reply-To: <44719883.1060605@dif.um.es>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi,

On Mon, May 22, 2006 at 12:54:59PM +0200, Santiago Zapata Hernandez wrote=
:
> Hi, (sorry for sending it again, but I sent it in HTML mode by error.=20
> Doing again in text mode).
>=20
> Julien Bournelle escribi=F3:
> >hi all,
> >
> >On Mon, May 22, 2006 at 11:03:58AM +0200, Santiago Zapata Hernandez wr=
ote:
> > =20
> >>Hi all,
> >>
> >>After thinking in this issue, I'm agree about the identity would be=20
> >>different if we are in the scenario ASA <> MSA.
> >>   =20
> >
> > I don't think we should assume that it is different identity. In the
> > Integrated scenario, we also use IKEv2-Diameter EAP and as the HA is
> > allocated by the AAA, we'll probably reuse the same identity with sam=
e
> > credentials. And if we do nothing, the AAA server may "think" that it
> > is performing Diameter EAP two times for network access.
> >
> > =20
> I mean the same user (same credentials) but different user's identifier=
=20
> (domain) because we are working (in split scenario) with different=20
> domains. In integrated scenario the server could detect that it is=20
> managing network access or mobility authentication by having a look to=20
> user's identifier (another sub-domain? or maybe by classifying the=20
> identifiers in the server side?)
> My proposal is to use different users' identifiers in order to=20
> distinguish (in the servers) between the different EAP functionalities=20
> (Network access or Mobility).

 I don't think it's clean to require use of different users'identifiers
 in order to distinguish which services is provided. For me, it looks
 like a 'hack'.

> I don't see any problem by using different identifiers but sharing the=20
> same credentials.
> My interest is in not creating a new application for each new=20
> functionality to be deployed over Diameter-EAP.

 I also don't have any interest in creating new application. But I don't
 see the issue with doing so if it seems necessary.

 regards,

 Julien

>=20
> BR,
> Santiago
> >>In the other scenario (ASA =3D MSA), I think a new Application ID is =
not=20
> >>the right solution, because we are managing the same kind of=20
> >>functionality (EAP providing authentication/authorization).
> >>   =20
> >
> > EAP is used for authentication. However, Authorization and Accounting
> > is different since in one case it is done for network access while in
> > the other case it's for mip6 service.=20
> >
> > regards,
> >
> > Julien
> >
> > =20
> >>I propose to use virtual users for managing this scenarios.
> >>
> >>BR,
> >>Santiago
> >>
> >>
> >>
> >>Jari Arkko escribi=F3:
> >>   =20
> >>>Santiago Zapata Hernandez wrote:
> >>>
> >>>=20
> >>>     =20
> >>>>The idea of using different authentication servers is coming from t=
he
> >>>>requirement of implementing a specific MIPv6 bootstrapping split
> >>>>scenario: Access Service Authorizer (ASA) <> Mobility Service
> >>>>Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02).
> >>>>  =20
> >>>>       =20
> >>>I have read the draft, but I do not see how it leads to the
> >>>requirement that the same user identity needs to be routed
> >>>in different ways for different applications. It seems that
> >>>the essence of the split scenario is that the access and
> >>>mobility services are independent, e.g., acquired from
> >>>different providers with different identities. Or from
> >>>the same provider (as in when you are in your home
> >>>network), but the services are provided in an independent
> >>>fashion.
> >>>
> >>>=20
> >>>     =20
> >>>>I think we should use the same application ID, but routing by:
> >>>>- having two different paths (Peers from different paths would not =
be
> >>>>interconnected).
> >>>>- some proxy should change route (is it RFC compliant?), based in t=
he
> >>>>value of a (optional) AVP.
> >>>>- use different realms (changed by the HA, for example, acting as a
> >>>>proxy). I don't understand why it would not be possible (HA could
> >>>>change this realm, and boostrapping server could restore it (if it =
is
> >>>>required)).
> >>>>  =20
> >>>>       =20
> >>>Avi's new Application ID may be a better approach than these, becaus=
e
> >>>its directly supported by by Diameter as is. (If different routing i=
s
> >>>needed.)
> >>>
> >>>--Jari
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>=20
> >>>     =20
> >>_______________________________________________
> >>DiME mailing list
> >>DiME@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/dime
> >>   =20
> >
> > =20
>=20

--=20
julien.bournelle at int-evry.fr

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 09:32:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiAW2-0005N3-9s; Mon, 22 May 2006 09:32:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiAW1-0005My-Vk
	for dime@ietf.org; Mon, 22 May 2006 09:32:09 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiAW0-0000NC-FL
	for dime@ietf.org; Mon, 22 May 2006 09:32:09 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k4MDV9rJ013879; Mon, 22 May 2006 16:32:03 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 May 2006 16:31:58 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 22 May 2006 16:31:58 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Mon, 22 May 2006 16:32:00 +0300
Message-ID: 
In-Reply-To: <20060522110251.GA25695@ipv6-3.int-evry.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ9mJgsaDQHp1RlTcqHCe94xzixxwACK8SA
From: 
To: 
X-OriginalArrivalTime: 22 May 2006 13:31:58.0967 (UTC)
	FILETIME=[19EC6870:01C67DA4]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Julien Bournelle wrote:
>=20
> I don't think it's clean to require use of different
> users'identifiers in order to distinguish which services is
> provided. For me, it looks like a 'hack'.

I fully agree -- but having separate user identifiers should not be
necessary. If, for example, an operator wants to perform different
authorizations for WiFi and WiMAX (e.g., some users can access only
WiFi but not WiMAX), that's simple to do: just check Service-Type,
NAS-Port-Type, and other relevant authorization AVPs.  There's
absolutely no need to create a new Diameter application.

If the AAA server is really strict about WiFi vs. WiMAX separation, it
can have a policy that requires the NAS-Port-Type AVP to be present
(if the request does not contain it, access is denied). Although this
in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"=20
in the sense that would require a new Diameter application.

While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are=20
any significant differences from Diameter point-of-view. There's a box=20
providing some service; authentication works with EAP; authorization=20
AVPs indicate what exactly is being authorized. What's missing is
a document describing how the different authorization AVPs are=20
used in this particular situation; sort of like RFC 3580 (IEEE 802.1X=20
RADIUS Usage Guidelines), but for Diameter with IKEv2.


> I also don't have any interest in creating new application. But I=20
> don't see the issue with doing so if it seems necessary.

One important reason NOT to create new applications: proxies. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value doesn't.

Best regards,
Pasi

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 11:14:38 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiC7B-0004qy-SS; Mon, 22 May 2006 11:14:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiC7A-0004oD-RH
	for dime@ietf.org; Mon, 22 May 2006 11:14:36 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiC76-0005S2-Gg
	for dime@ietf.org; Mon, 22 May 2006 11:14:36 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 22 May 2006 11:14:33 -0400
X-IronPort-AV: i="4.05,157,1146456000"; 
	d="scan'208"; a="89145727:sNHT32394992"
Received: from [161.44.55.215] (dhcp-161-44-55-215.cisco.com [161.44.55.215])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id
	k4MFEVvF008632; Mon, 22 May 2006 11:14:31 -0400 (EDT)
Message-ID: <4471D557.5070303@cisco.com>
Date: Mon, 22 May 2006 11:14:31 -0400
From: Anders Kristensen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Avi Lior 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: dime@ietf.org, Pasi.Eronen@nokia.com, hannes.tschofenig@gmx.net
Subject: [Dime] When to define a new application ID [was: Defining a new
 Application for mip6-split ?]
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

I don't have a strong opinion on the mip6 discussion but it seems to me 
that in general the bar for defining new application IDs has been set 
too high or that the 3588 recommendation cited by Jari has, in some 
cases, been taken to an extreme that's not really helpful.

Take the 3GPP's Gq spec as an example. It "reuses" the AAR/AAA NASREQ 
command but completely redefines the messages and does so without 
reusing *any* of the NASREQ AVPs and without reusing the semantics of 
the command (or at least only in a very loose sense). The Gq spec also 
defines its own app ID for use in the Auth-Application-Id AVP. AFAICT 
the only thing actually reused from the NASREQ version of the command is 
the app ID used in the message header (0) and the message names used in 
the specification. IMHO it would be much preferable if they just dropped 
the pretense and properly defined a new application and stuck the Gq app 
ID in the message header also.

Anders

Avi Lior wrote:
>>RFC 3588 states that  "Creation of a new application should 
>>be viewed as a last resort." and that "In order to justify 
>>allocation of a new application identifier, Diameter 
>>applications MUST define one Command Code, or add new 
>>mandatory AVPs to the ABNF." 
> 
> 
> BTW that should be cleaned up to say "...Diameter applications MUST
> define at least one new Command Code, or add new mandatory AVPs to the
> ABNF.
> 
> We should clean the last ABNSF part to read:
> "or add new mandatory AVP(s) that may be included in any command used by
> the application."
> 
> 
>>Note that mandatory AVPs can be 
>>viewed in different ways, and that we should not be too 
>>strict about them.
>>For instance, Framed-Protocol is an optional AVP in RFCs 4005 
>>and 4072. Yet, you could argue that if you are doing PPP then 
>>you need to use this attribute and set it to PPP. But that 
>>didn't make the attribute mandatory.
> 
> 
> Mandatory does not mean required in the Command.  It means that it must
> be understood by the receiver.  We need to clarify that.
> 
> 
>>Do we have a similar situation for the IKEv2/MIPv6 attributes 
>>and values? They are not necessary from the NASREQ/EAP 
>>perspective, but in the specific context you need to use the 
>>attributes. In my mind, this does not make the attributes 
>>mandatory from a Diameter application point of view. 
> 
> 
> This is correct and is my understanding of 3588.  But  I think 3588 got
> it wrong.
> 
> As I pointed out (in an email to Yoshi) for the MIPv6 Application (or HA
> application) we have to change the ABNF of the command.  We have to make
> the NAS-Port-Type mandatory in the DEA answer.  So under what context do
> we make that.
> 
> 
> 
>>If we 
>>start creating new applications for every different 
>>situation, we'll have lots of applications and 
>>interoperability problems. Its better to add new optional 
>>AVPs and describe in text when they should be used. The only 
>>exception that I see is security related AVPs that must be 
>>understood by the other side or else the session should be terminated.
> 
> 
> I don't think that every situation requires a new application. I see
> other exceptions.  In essence if the application has new "mandatory"
> behavior changed then we need to use a different application Id.  As a
> minimum we need to make sure that we can route to the correct
> application -- the application that correctly acts on the command.
> 
> We only have Application ID to do this with. While I agree that we could
> have lots of application ids fortunately it's a 32 bit unsigned int.
> 
>  Optional behavior is one case.  But when the behavior difference is
> mandatory then we do need a new Application ID.
> 
> If folks are concerned about too many application ids, perhaps Diameter
> should have used version numbers.  
> 
> 
>  
> 
>>See also
>>http://www.arkko.com/publications/draft-arkko-radext-multi-ser
> 
> vice-decisions-02.txt
> 
>>for related discussion about Service-Type, NAS-Port-Type, and so on.
>>
>>--Jari
>>
>>
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 11:14:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiC7I-0004zK-0z; Mon, 22 May 2006 11:14:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiC7G-0004zF-Pb
	for dime@ietf.org; Mon, 22 May 2006 11:14:42 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiC7F-0005S2-IG
	for dime@ietf.org; Mon, 22 May 2006 11:14:42 -0400
Received: from rtp-core-2.cisco.com ([64.102.124.13])
	by rtp-iport-2.cisco.com with ESMTP; 22 May 2006 11:14:42 -0400
X-IronPort-AV: i="4.05,157,1146456000"; 
	d="scan'208"; a="89145753:sNHT28431592"
Received: from [161.44.55.215] (dhcp-161-44-55-215.cisco.com [161.44.55.215])
	by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id
	k4MFEevF008684; Mon, 22 May 2006 11:14:41 -0400 (EDT)
Message-ID: <4471D560.8090009@cisco.com>
Date: Mon, 22 May 2006 11:14:40 -0400
From: Anders Kristensen 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jari Arkko 
Subject: Re: [Dime] Defining a new Application for mip6-split ?
References: 
	<44703BA5.8020007@piuha.net>
In-Reply-To: <44703BA5.8020007@piuha.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org



Jari Arkko wrote:

> Avi Lior wrote:
> 
> 
>>In general, operators want to reduce the numbers of entities they have
>>to manage.  Having a different identity for each service is the WRONG
>>way to solve these problems.  We want to consolidate.
>> 
>>
> 
> Indeed. But wouldn't consolidation also apply to deployment
> of multiple authentication servers for the same credentials
> albeit different service (SIP, 802.11, VPN, ...)? I would assume
> that there are business and technical reasons to keep the
> number of servers down...

Isn't it just a matter of having the same set of servers advertise an 
additional application ID?

Anders

> 
> --Jari
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 11:32:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiCOk-0004Gg-M1; Mon, 22 May 2006 11:32:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCOj-0004Gb-PD
	for dime@ietf.org; Mon, 22 May 2006 11:32:45 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCOi-0006K7-D7
	for dime@ietf.org; Mon, 22 May 2006 11:32:45 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Mon, 22 May 2006 11:36:42 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ9mJgsaDQHp1RlTcqHCe94xzixxwACK8SAAAS65LA=
From: "Avi Lior" 
To: ,
	
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Pasi,

Please see inline....=20

> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20
> Sent: Monday, May 22, 2006 9:32 AM
> To: julien.bournelle@int-evry.fr
> Cc: dime@ietf.org
> Subject: RE: [Dime] Defining a new Application for mip6-split ?
>=20
> Julien Bournelle wrote:
> >=20
> > I don't think it's clean to require use of different=20
> users'identifiers=20
> > in order to distinguish which services is provided. For me,=20
> it looks=20
> > like a 'hack'.
>=20
> I fully agree -- but having separate user identifiers should=20
> not be necessary. If, for example, an operator wants to=20
> perform different authorizations for WiFi and WiMAX (e.g.,=20
> some users can access only WiFi but not WiMAX), that's simple=20
> to do: just check Service-Type, NAS-Port-Type, and other=20
> relevant authorization AVPs.  There's absolutely no need to=20
> create a new Diameter application.

Well this is what is being debated.  So it seems to me that if I have an
server that is doing EAP based authentication as defined in RFC 4072 but
now I need to have some special processing for WiMAX or WiFi and because
of that I need to understand the meaning of Service-Type or
NAS-Port-type then I think I need a new Diameter Application to make
sure I can route to the Implementation that supports this functionality.
Note it can be on the same machine.

If its not imporant that I Hit the server with the correct code, that
is, that I don't need to hit the implementation that understands
NAS-Port-type =3D WiMAX or WiFi, the we don't need an new Application =
Id.

> If the AAA server is really strict about WiFi vs. WiMAX=20
> separation, it can have a policy that requires the=20
> NAS-Port-Type AVP to be present (if the request does not=20
> contain it, access is denied). Although this in some sense=20
> make NAS-Port-Type AVP "mandatory", it's not "mandatory"=20
> in the sense that would require a new Diameter application.

But if the above is true you have to make sure you route to the correct
implementation.  So how do you do that? I say with an Application ID.

=20
> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think=20
> there are any significant differences from Diameter=20
> point-of-view. There's a box providing some service;=20
> authentication works with EAP; authorization AVPs indicate=20
> what exactly is being authorized. What's missing is a=20
> document describing how the different authorization AVPs are=20
> used in this particular situation; sort of like RFC 3580=20
> (IEEE 802.1X RADIUS Usage Guidelines), but for Diameter with IKEv2.

It is true of MIPv6 split scenario you may not need to differentiate
because some people think that for Split MIPv6 scenario it is plain EAP
that you are doing. So 4072 the argument is that you don't need to do
any work at all.

> 
> > I also don't have any interest in creating new application. But I=20
> > don't see the issue with doing so if it seems necessary.
>=20
> One important reason NOT to create new applications: proxies.=20
> Every proxy on the path needs new code to handle the new=20
> application, while just adding an extra AVP or new=20
> Service-Type value doesn't.


> Best regards,
> Pasi
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 12:09:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiCyh-0001Pk-8m; Mon, 22 May 2006 12:09:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiCyf-0001Pa-Rn
	for dime@ietf.org; Mon, 22 May 2006 12:09:53 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiCye-0007z2-Kl
	for dime@ietf.org; Mon, 22 May 2006 12:09:53 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Mon, 22 May 2006 12:13:52 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ8vrU/5VQ5CN6QRKObF2I0HsSq8AA+8ZBw
From: "Avi Lior" 
To: "Jari Arkko" 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Jari,

I wasn't talking about how these things can be deployed. They can all be
deployed on the same server.

Lots of emails, I am waiting for that summarization email that you are
so famous for.
=20
Avi

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]=20
> Sent: Sunday, May 21, 2006 6:06 AM
> To: Avi Lior
> Cc: jouni.korhonen@teliasonera.com; dime@ietf.org
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
>=20
> Avi Lior wrote:
>=20
> >In general, operators want to reduce the numbers of entities=20
> they have=20
> >to manage.  Having a different identity for each service is=20
> the WRONG=20
> >way to solve these problems.  We want to consolidate.
> > =20
> >
> Indeed. But wouldn't consolidation also apply to deployment=20
> of multiple authentication servers for the same credentials=20
> albeit different service (SIP, 802.11, VPN, ...)? I would=20
> assume that there are business and technical reasons to keep=20
> the number of servers down...
>=20
> --Jari
>=20
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 22 13:18:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiE3U-0001xp-LD; Mon, 22 May 2006 13:18:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiE3T-0001xk-Az
	for dime@ietf.org; Mon, 22 May 2006 13:18:55 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiE3R-0002CJ-Uh
	for dime@ietf.org; Mon, 22 May 2006 13:18:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Mon, 22 May 2006 13:22:53 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ9js78oLH8HSR4RUalJFIou7Yv+QALALHw
From: "Avi Lior" 
To: "Santiago Zapata Hernandez" ,
	"Julien Bournelle" 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 0770535483960d190d4a0d020e7060bd
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

See below...=20

> -----Original Message-----
> From: Santiago Zapata Hernandez [mailto:canela@dif.um.es]=20
> Sent: Monday, May 22, 2006 6:55 AM
> To: Julien Bournelle
> Cc: dime@ietf.org
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
>=20
> Hi, (sorry for sending it again, but I sent it in HTML mode by error.=20
> Doing again in text mode).
>=20
> Julien Bournelle escribi=F3:
> > hi all,
> >
> > On Mon, May 22, 2006 at 11:03:58AM +0200, Santiago Zapata=20
> Hernandez wrote:
> >  =20
> >> Hi all,
> >>
> >> After thinking in this issue, I'm agree about the identity=20
> would be=20
> >> different if we are in the scenario ASA <> MSA.
> >>    =20
> >
> >  I don't think we should assume that it is different=20
> identity. In the =20
> > Integrated scenario, we also use IKEv2-Diameter EAP and as=20
> the HA is =20
> > allocated by the AAA, we'll probably reuse the same=20
> identity with same =20
> > credentials. And if we do nothing, the AAA server may=20
> "think" that it =20
> > is performing Diameter EAP two times for network access.
> >
> >  =20
> I mean the same user (same credentials) but different user's=20
> identifier
> (domain) because we are working (in split scenario) with=20
> different domains. In integrated scenario the server could=20
> detect that it is managing network access or mobility=20
> authentication by having a look to user's identifier (another=20
> sub-domain? or maybe by classifying the identifiers in the=20
> server side?) My proposal is to use different users'=20
> identifiers in order to distinguish (in the servers) between=20
> the different EAP functionalities (Network access or Mobility).
> I don't see any problem by using different identifiers but=20
> sharing the same credentials.
> My interest is in not creating a new application for each new=20
> functionality to be deployed over Diameter-EAP.

Again using different identifiers may work in the split scenario but it =
also may not. And in general it is not a good idea to select applicatons =
based on identities.  It could be the situation that initially a given =
domain provided one service, but it could happen that in the future that =
domain would provide another service.  Now you will have the problem.  =
So lets design this properly.
=20
> BR,
> Santiago
> >> In the other scenario (ASA =3D MSA), I think a new Application ID =
is=20
> >> not the right solution, because we are managing the same kind of=20
> >> functionality (EAP providing authentication/authorization).
> >>    =20
> >
> >  EAP is used for authentication. However, Authorization and=20
> Accounting =20
> > is different since in one case it is done for network=20
> access while in =20
> > the other case it's for mip6 service.
> >
> >  regards,
> >
> >  Julien
> >
> >  =20
> >> I propose to use virtual users for managing this scenarios.
> >>
> >> BR,
> >> Santiago
> >>
> >>
> >>
> >> Jari Arkko escribi=F3:
> >>    =20
> >>> Santiago Zapata Hernandez wrote:
> >>>
> >>> =20
> >>>      =20
> >>>> The idea of using different authentication servers is=20
> coming from=20
> >>>> the requirement of implementing a specific MIPv6 bootstrapping=20
> >>>> split
> >>>> scenario: Access Service Authorizer (ASA) <> Mobility Service=20
> >>>> Authorizer (MSA). (draft-ietf-mip6-bootstrapping-split-02).
> >>>>   =20
> >>>>        =20
> >>> I have read the draft, but I do not see how it leads to the=20
> >>> requirement that the same user identity needs to be routed in=20
> >>> different ways for different applications. It seems that=20
> the essence=20
> >>> of the split scenario is that the access and mobility=20
> services are=20
> >>> independent, e.g., acquired from different providers with=20
> different=20
> >>> identities. Or from the same provider (as in when you are in your=20
> >>> home network), but the services are provided in an independent=20
> >>> fashion.
> >>>
> >>> =20
> >>>      =20
> >>>> I think we should use the same application ID, but routing by:
> >>>> - having two different paths (Peers from different paths=20
> would not=20
> >>>> be interconnected).
> >>>> - some proxy should change route (is it RFC compliant?),=20
> based in=20
> >>>> the value of a (optional) AVP.
> >>>> - use different realms (changed by the HA, for example,=20
> acting as a=20
> >>>> proxy). I don't understand why it would not be possible=20
> (HA could=20
> >>>> change this realm, and boostrapping server could restore=20
> it (if it=20
> >>>> is required)).
> >>>>   =20
> >>>>        =20
> >>> Avi's new Application ID may be a better approach than these,=20
> >>> because its directly supported by by Diameter as is. (If=20
> different=20
> >>> routing is
> >>> needed.)
> >>>
> >>> --Jari
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> =20
> >>>      =20
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dime
> >>    =20
> >
> >  =20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 23 02:40:36 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiQZD-0006j3-W3; Tue, 23 May 2006 02:40:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiQZC-0006iy-Np
	for dime@ietf.org; Tue, 23 May 2006 02:40:30 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiQZB-0006cb-80
	for dime@ietf.org; Tue, 23 May 2006 02:40:30 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k4N6eR3T023102 for ; Tue, 23 May 2006 09:40:28 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 May 2006 09:40:22 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 May 2006 09:40:22 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Tue, 23 May 2006 09:40:19 +0300
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ9mJgsaDQHp1RlTcqHCe94xzixxwACK8SAAAS65LAAH5ETIA==
From: 
To: 
X-OriginalArrivalTime: 23 May 2006 06:40:22.0474 (UTC)
	FILETIME=[C41462A0:01C67E33]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Avi Lior wrote:

> Well this is what is being debated.  So it seems to me that if I
> have an server that is doing EAP based authentication as defined in
> RFC 4072 but now I need to have some special processing for WiMAX or
> WiFi and because of that I need to understand the meaning of
> Service-Type or NAS-Port-type then I think I need a new Diameter
> Application to make sure I can route to the Implementation that
> supports this functionality.  Note it can be on the same machine.

I think in most cases this "special processing" can (and should) be
thought of as a part of AAA server's policy. Or in other words: I
don't think the intention of NASREQ was that every time someone
defines a new value for Service-Type or NAS-Port-Type we would need=20
a new Diameter application....


> > If the AAA server is really strict about WiFi vs. WiMAX=20
> > separation, it can have a policy that requires the=20
> > NAS-Port-Type AVP to be present (if the request does not=20
> > contain it, access is denied). Although this in some sense=20
> > make NAS-Port-Type AVP "mandatory", it's not "mandatory"=20
> > in the sense that would require a new Diameter application.
>=20
> But if the above is true you have to make sure you route to the
> correct implementation.  So how do you do that? I say with an
> Application ID.

At least the RADIUS proxy implementations I know of can route=20
based on any attribute...

Best regards,
Pasi

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 23 02:54:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiQmy-0004WX-7R; Tue, 23 May 2006 02:54:44 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiQmw-0004RA-SC; Tue, 23 May 2006 02:54:42 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1FiQmv-0007HB-CJ; Tue, 23 May 2006 02:54:42 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k4N6sdME029287; Tue, 23 May 2006 09:54:40 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 May 2006 09:54:29 +0300
Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 May 2006 09:54:29 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Tue, 23 May 2006 09:54:28 +0300
Message-ID: <615BD9B54CB01B41838C323DB9E91AAB98C4BA@esebe100.NOE.Nokia.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ9mJgsaDQHp1RlTcqHCe94xzixxwACK8SAAAS65LAAH5ETIAAAxSPA
From: 
To: , 
X-OriginalArrivalTime: 23 May 2006 06:54:29.0494 (UTC)
	FILETIME=[BCF16160:01C67E35]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Having read through the thread, I tend to agree with Pasi on this;
if we use a new Application ID as a way to handle routing for new
service types or other AVPs, we will have a huge mess of applications,
and I don't see how this would aid interoperability.

John

>-----Original Message-----
>From: ext dime-bounces@ietf.org [mailto:dime-bounces@ietf.org]=20
>Sent: 23 May, 2006 09:40
>To: dime@ietf.org
>Subject: RE: [Dime] Defining a new Application for mip6-split ?
>
>Avi Lior wrote:
>
>> Well this is what is being debated.  So it seems to me that=20
>if I have=20
>> an server that is doing EAP based authentication as defined in RFC=20
>> 4072 but now I need to have some special processing for=20
>WiMAX or WiFi=20
>> and because of that I need to understand the meaning of Service-Type=20
>> or NAS-Port-type then I think I need a new Diameter Application to=20
>> make sure I can route to the Implementation that supports this=20
>> functionality.  Note it can be on the same machine.
>
>I think in most cases this "special processing" can (and=20
>should) be thought of as a part of AAA server's policy. Or in=20
>other words: I don't think the intention of NASREQ was that=20
>every time someone defines a new value for Service-Type or=20
>NAS-Port-Type we would need a new Diameter application....
>
>
>> > If the AAA server is really strict about WiFi vs. WiMAX=20
>separation,=20
>> > it can have a policy that requires the NAS-Port-Type AVP to be=20
>> > present (if the request does not contain it, access is denied).=20
>> > Although this in some sense make NAS-Port-Type AVP=20
>"mandatory", it's=20
>> > not "mandatory"
>> > in the sense that would require a new Diameter application.
>>=20
>> But if the above is true you have to make sure you route to the=20
>> correct implementation.  So how do you do that? I say with an=20
>> Application ID.
>
>At least the RADIUS proxy implementations I know of can route=20
>based on any attribute...
>
>Best regards,
>Pasi
>
>_______________________________________________
>DiME mailing list
>DiME@ietf.org
>https://www1.ietf.org/mailman/listinfo/dime
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 23 07:00:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiUcX-0004O9-2j; Tue, 23 May 2006 07:00:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUcW-0004Nz-1R
	for dime@ietf.org; Tue, 23 May 2006 07:00:12 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiUcU-0001Ct-Jp
	for dime@ietf.org; Tue, 23 May 2006 07:00:12 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 6D20581EF;
	Tue, 23 May 2006 13:00:02 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1FiUb9-00071T-Rh; Tue, 23 May 2006 12:58:47 +0200
Date: Tue, 23 May 2006 12:58:47 +0200
From: Julien Bournelle 
To: Pasi.Eronen@nokia.com
Subject: Re: [Dime] Defining a new Application for mip6-split ?
Message-ID: <20060523105847.GA26990@ipv6-3.int-evry.fr>
References: 
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi pasi,

On Tue, May 23, 2006 at 09:40:19AM +0300, Pasi.Eronen@nokia.com wrote:
> Avi Lior wrote:
> 
> > Well this is what is being debated.  So it seems to me that if I
> > have an server that is doing EAP based authentication as defined in
> > RFC 4072 but now I need to have some special processing for WiMAX or
> > WiFi and because of that I need to understand the meaning of
> > Service-Type or NAS-Port-type then I think I need a new Diameter
> > Application to make sure I can route to the Implementation that
> > supports this functionality.  Note it can be on the same machine.
> 
> I think in most cases this "special processing" can (and should) be
> thought of as a part of AAA server's policy. Or in other words: I
> don't think the intention of NASREQ was that every time someone
> defines a new value for Service-Type or NAS-Port-Type we would need 
> a new Diameter application....

 one could advocate that in the NASREQ case, we are still dealing with
 network access. And Service-Type or NAS-Port-TYpe help the AAA server
 to know what kind of access it is. Here it is not network access
 service, it is Mobile IPv6 service.

> 
> 
> > > If the AAA server is really strict about WiFi vs. WiMAX 
> > > separation, it can have a policy that requires the 
> > > NAS-Port-Type AVP to be present (if the request does not 
> > > contain it, access is denied). Although this in some sense 
> > > make NAS-Port-Type AVP "mandatory", it's not "mandatory" 
> > > in the sense that would require a new Diameter application.
> > 
> > But if the above is true you have to make sure you route to the
> > correct implementation.  So how do you do that? I say with an
> > Application ID.
> 
> At least the RADIUS proxy implementations I know of can route 
> based on any attribute...

 I think avi is talking about routing in the Diameter server between the
 different applications (SIP/EAP/CC...) not in the network. But I may be
 wrong :)

 Julien

> 
> Best regards,
> Pasi
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 23 08:00:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiVYb-0003NT-81; Tue, 23 May 2006 08:00:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiVYY-0003Mg-Mx
	for dime@ietf.org; Tue, 23 May 2006 08:00:10 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiVYX-0004MP-7i
	for dime@ietf.org; Tue, 23 May 2006 08:00:10 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k4NC07Ko001988; Tue, 23 May 2006 15:00:08 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 May 2006 15:00:08 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 23 May 2006 15:00:07 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Tue, 23 May 2006 15:00:07 +0300
Message-ID: 
In-Reply-To: <20060523105847.GA26990@ipv6-3.int-evry.fr>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ+WImTIMASJhc9TMSp4nlgpBbmZAABedRg
From: 
To: 
X-OriginalArrivalTime: 23 May 2006 12:00:07.0493 (UTC)
	FILETIME=[6F3DF750:01C67E60]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Julien Bournelle wrote:

> one could advocate that in the NASREQ case, we are still dealing with
> network access. And Service-Type or NAS-Port-TYpe help the AAA server
> to know what kind of access it is. Here it is not network access
> service, it is Mobile IPv6 service.

I don't think so; Service-Type and other authorization AVPs help the
AAA server to know what is the service being authorized. Given that
NASREQ and Diameter are already suitable for a wide range of services
(from dial-up PPP, fax, IAPP, normal IKEv2-based remote access VPNs to
administrative web interfaces, and so on), I don't think there's
anything so special in Mobile IPv6 that would set it apart from the
other Service-Types...

> > At least the RADIUS proxy implementations I know of can route=20
> > based on any attribute...
>=20
> I think avi is talking about routing in the Diameter server between=20
> the different applications (SIP/EAP/CC...) not in the network.=20
> But I may be  wrong :)

Exactly how a particular AAA server implementation is divided into
modules, components, libraries, DLLs, and so on is not traditionally
standardized in IETF...

Best regards,
Pasi

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 23 09:25:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiWtR-0001jI-2I; Tue, 23 May 2006 09:25:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWtQ-0001jD-5O
	for dime@ietf.org; Tue, 23 May 2006 09:25:48 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWtN-0007QD-RH
	for dime@ietf.org; Tue, 23 May 2006 09:25:48 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id BFC4A81A9;
	Tue, 23 May 2006 15:25:43 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1FiWs9-00078u-2I; Tue, 23 May 2006 15:24:29 +0200
Date: Tue, 23 May 2006 15:24:29 +0200
From: Julien Bournelle 
To: Pasi.Eronen@nokia.com
Subject: Re: [Dime] Defining a new Application for mip6-split ?
Message-ID: <20060523132429.GA27452@ipv6-3.int-evry.fr>
References: <20060523105847.GA26990@ipv6-3.int-evry.fr>
	
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi pasi,

On Tue, May 23, 2006 at 03:00:07PM +0300, Pasi.Eronen@nokia.com wrote:
> Julien Bournelle wrote:
> 
> > one could advocate that in the NASREQ case, we are still dealing with
> > network access. And Service-Type or NAS-Port-TYpe help the AAA server
> > to know what kind of access it is. Here it is not network access
> > service, it is Mobile IPv6 service.
> 
> I don't think so; Service-Type and other authorization AVPs help the
> AAA server to know what is the service being authorized. Given that
> NASREQ and Diameter are already suitable for a wide range of services
> (from dial-up PPP, fax, IAPP, normal IKEv2-based remote access VPNs to
> administrative web interfaces, and so on), I don't think there's
> anything so special in Mobile IPv6 that would set it apart from the
> other Service-Types...
> 
> > > At least the RADIUS proxy implementations I know of can route 
> > > based on any attribute...
> > 
> > I think avi is talking about routing in the Diameter server between 
> > the different applications (SIP/EAP/CC...) not in the network. 
> > But I may be  wrong :)
> 
> Exactly how a particular AAA server implementation is divided into
> modules, components, libraries, DLLs, and so on is not traditionally
> standardized in IETF...

 yep I know that. I was just saying that the App-Id field may be used by
 the Base Protocol to select the right Application in a Diameter server.

 regards,

 Julien

> 
> Best regards,
> Pasi


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Wed May 24 12:47:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiwVn-00041H-Bt; Wed, 24 May 2006 12:47:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwVm-000416-Bp
	for dime@ietf.org; Wed, 24 May 2006 12:47:06 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwVl-0000pg-0G
	for dime@ietf.org; Wed, 24 May 2006 12:47:06 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Wed, 24 May 2006 12:51:05 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ+WImTIMASJhc9TMSp4nlgpBbmZAABedRgADyHucA=
From: "Avi Lior" 
To: ,
	
X-Spam-Score: 0.1 (/)
X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Pasi,=20

> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20
> Sent: Tuesday, May 23, 2006 8:00 AM
> To: julien.bournelle@int-evry.fr
> Cc: dime@ietf.org
> Subject: RE: [Dime] Defining a new Application for mip6-split ?
>=20
> Julien Bournelle wrote:
>=20
> > one could advocate that in the NASREQ case, we are still=20
> dealing with=20
> > network access. And Service-Type or NAS-Port-TYpe help the=20
> AAA server=20
> > to know what kind of access it is. Here it is not network access=20
> > service, it is Mobile IPv6 service.
>=20
> I don't think so; Service-Type and other authorization AVPs=20
> help the AAA server to know what is the service being=20
> authorized. Given that NASREQ and Diameter are already=20
> suitable for a wide range of services (from dial-up PPP, fax,=20
> IAPP, normal IKEv2-based remote access VPNs to administrative=20
> web interfaces, and so on), I don't think there's anything so=20
> special in Mobile IPv6 that would set it apart from the other=20
> Service-Types...

I can say that for that for every other application that has been done
such as MIPv4 and Credit Control.  Lets just do them all under NASREQ.
This will solve lots of problems and in particular the Application ID.

Either we use the Application ID to route commands to where they will be
processed correctly -- or drop this concept entirely.  I am okay either
way.

A mandatory attribute (a must understand attribute) that has a new
enumeration is in my mind is like adding a new attribute that must be
understood.  There is no wigle room here.  The command carrying that
attribute must reach the implementation that knows how to interpret the
attribute.  This is  because an implmentation that does not understand
Service-Type =3D X must return an error.

It is obvious that the rules in 3588 are not sufficient to describe when
to use a new Application ID or not.  And we should not have to have a
debate on this topic.

BTW if we do what you say then in networks where I have NASREQ
performing Network Access and now I want to roll out MIPv6 I would have
to upgrade all my old NASREQ deployed applications.  This is wrong.  I
should be able to add a MIPv6 compliant diameter application without
having to force upgrading my NASREQ applications.


> > > At least the RADIUS proxy implementations I know of can=20
> route based=20
> > > on any attribute...
> >=20
> > I think avi is talking about routing in the Diameter server between=20
> > the different applications (SIP/EAP/CC...) not in the network.
> > But I may be  wrong :)
>=20
> Exactly how a particular AAA server implementation is divided=20
> into modules, components, libraries, DLLs, and so on is not=20
> traditionally standardized in IETF...
>=20
> Best regards,
> Pasi
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Wed May 24 12:49:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FiwXm-0005Sq-3k; Wed, 24 May 2006 12:49:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwXk-0005Si-Qe
	for dime@ietf.org; Wed, 24 May 2006 12:49:08 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiwXi-0000vi-EI
	for dime@ietf.org; Wed, 24 May 2006 12:49:08 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Wed, 24 May 2006 12:53:06 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ+bRnlRWKqDk/ARK6n0l/dkz5iuQA5TcDg
From: "Avi Lior" 
To: "Julien Bournelle" , 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Juliena and others

See inline...=20

> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20
> Sent: Tuesday, May 23, 2006 9:24 AM
> To: Pasi.Eronen@nokia.com
> Cc: dime@ietf.org
> Subject: Re: [Dime] Defining a new Application for mip6-split ?
>=20
> Hi pasi,
>=20
> On Tue, May 23, 2006 at 03:00:07PM +0300, Pasi.Eronen@nokia.com wrote:
> > Julien Bournelle wrote:
> >=20
> > > one could advocate that in the NASREQ case, we are still dealing=20
> > > with network access. And Service-Type or NAS-Port-TYpe=20
> help the AAA=20
> > > server to know what kind of access it is. Here it is not network=20
> > > access service, it is Mobile IPv6 service.
> >=20
> > I don't think so; Service-Type and other authorization AVPs=20
> help the=20
> > AAA server to know what is the service being authorized. Given that=20
> > NASREQ and Diameter are already suitable for a wide range=20
> of services=20
> > (from dial-up PPP, fax, IAPP, normal IKEv2-based remote=20
> access VPNs to=20
> > administrative web interfaces, and so on), I don't think there's=20
> > anything so special in Mobile IPv6 that would set it apart from the=20
> > other Service-Types...
> >=20
> > > > At least the RADIUS proxy implementations I know of can route=20
> > > > based on any attribute...
> > >=20
> > > I think avi is talking about routing in the Diameter=20
> server between=20
> > > the different applications (SIP/EAP/CC...) not in the network.
> > > But I may be  wrong :)
> >=20
> > Exactly how a particular AAA server implementation is divided into=20
> > modules, components, libraries, DLLs, and so on is not=20
> traditionally=20
> > standardized in IETF...
>=20
>  yep I know that. I was just saying that the App-Id field may=20
> be used by  the Base Protocol to select the right Application=20
> in a Diameter server.

Why "May"?  It is the primary method for doing that.  We should have a
very good reason why we shouldn't use the Application ID.

>  regards,
>=20
>  Julien
>=20
> >=20
> > Best regards,
> > Pasi
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Thu May 25 05:33:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjCDE-0000rW-0u; Thu, 25 May 2006 05:33:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FjCDC-0000p4-J1
	for dime@ietf.org; Thu, 25 May 2006 05:32:58 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjCDB-0007Ve-32
	for dime@ietf.org; Thu, 25 May 2006 05:32:58 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k4P9Wnba019952; Thu, 25 May 2006 12:32:51 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 25 May 2006 12:32:47 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 25 May 2006 12:32:45 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Thu, 25 May 2006 12:32:44 +0300
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ+WImTIMASJhc9TMSp4nlgpBbmZAABedRgADyHucAAINxM0A==
From: 
To: 
X-OriginalArrivalTime: 25 May 2006 09:32:45.0779 (UTC)
	FILETIME=[2DFEFA30:01C67FDE]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Avi Lior wrote:
> It is obvious that the rules in 3588 are not sufficient to describe
> when to use a new Application ID or not.  And we should not have to
> have a debate on this topic.

Here I fully agree with you: the rules in 3588 are not clear enough.

In particular, there are so many different meanings for "mandatory
AVP" that I can't probably even list them all. But let's try:

1) An AVP that is mandatory according to the command's ABNF;
   a command without this AVP always results in DIAMETER_MISSING_AVP.

2) An AVP not in category 1, but the specification of the AVP
   says the 'M' bit MUST be set if the AVP is included, and thus
   the command has to be rejected if the recipient does not=20
   understand this AVP; failure results in DIAMETER_AVP_UNSUPPORTED.

3) An AVP not in category 1 or 2, but the _sender_ of the command=20
   requires the command to be rejected if the recipient does not=20
   understand this AVP (and thus sets the 'M' bit); failure results=20
   in DIAMETER_AVP_UNSUPPORTED.

4) An AVP not in categories 1..3, but the _recipient_ of the command=20
   requires this AVP to be present; failure results in e.g.=20
   DIAMETER_AUTHORIZATION_REJECTED or some other error code.=20
   For example, an AAA server could reject all requests that=20
   don't have NAS-Port-Type AVP with value "802.11".

5) A "Diameter usage guidelines document" for a particular usage=20
   situation can specify that an implementation compliant
   with that document (in addition to relevant Diameter RFCs)
   must include some AVP in some particular command, even though
   the command AVP does not require it. This implies that the =20
   recipient of the command can safely use a policy meant in=20
   category 4.

   For example, 3GPP spec 29.234 specifies that when Diameter EAP
   application is used between a 3GPP WLAN-IW compliant 802.11 WLAN
   and 3G operator's AAA server, the Diameter-EAP-Request command must
   include the Calling-Station-Id AVP, and it must contain the STA's
   MAC address. (In RFC4072 the Calling-Station-Id AVP is optional,
   and there's no requirement that it contains an IEEE 802 MAC
   address).

6) Similarly, an usage guidelines document can specify that
   an implementation compliant with that document must understand
   some AVP in a particular message, and process it in a particular way.

   For example, the IRAP "Public WLAN Roaming Interface Specification"
   (which is for RADIUS, but a document with similar content for
   Diameter could be written) specifies that the WLAN AP must support=20
   the Idle-Timeout attribute, and use its contents in a particular way=20
   (disconnect uses if no IP packets for this time; L2 packets don't=20
   count; this AVP overrides local settings).

   RFC4005 specifies only that the Idle-Timeout AVP must have the 'M'
   bit set, but not what exactly is required by an implementation that
   "understands" the AVP (presumably, a compliant implementation could
   have a local policy that explicitly overrides the received value,
   could have a fixed non-configurable value for this timer, or could
   use a different interpretation of what "idle" means).

The challenge is that there is no clear-cut definition when any of
items 3...6 require a new application ID and when they don't.  The
examples I've given are more on the "no new application ID" side, but
once we're talking about more than one AVP, it seems we're left with a
subjective judgement whether we are still "close enough" to the old
application or not.

For example, defining how to use Diameter between in a "remote access"
type IKEv2 usage (between IKEv2 VPN gateway/home agent and AAA server)=20
could be done either as "Diameter usage guidelines for IKEv2 remote=20
access" or "Diameter remote-access-IKEv2-EAP Application" (BTW, I=20
consider it remote access no matter whether it supports mobility=20
or not, and whether mobility is supported using MOBIKE or MIPv6).

Best regards,
Pasi

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Thu May 25 19:48:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FjPYt-0008Do-5a; Thu, 25 May 2006 19:48:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPYs-0008Dj-5R
	for dime@ietf.org; Thu, 25 May 2006 19:48:14 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjPYq-0005pd-Nl
	for dime@ietf.org; Thu, 25 May 2006 19:48:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Defining a new Application for mip6-split ?
Date: Thu, 25 May 2006 19:52:07 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Defining a new Application for mip6-split ?
Thread-Index: AcZ+WImTIMASJhc9TMSp4nlgpBbmZAABedRgADyHucAAINxM0AAee6mA
From: "Avi Lior" 
To: 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Pasi,

Thank you for the list...we need to make sure we capture it somewhere.

Please see inline...=20

> -----Original Message-----
> From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20
> Sent: Thursday, May 25, 2006 5:33 AM
> To: Avi Lior
> Cc: dime@ietf.org
> Subject: RE: [Dime] Defining a new Application for mip6-split ?
>=20
> Avi Lior wrote:
> > It is obvious that the rules in 3588 are not sufficient to describe=20
> > when to use a new Application ID or not.  And we should not have to=20
> > have a debate on this topic.
>=20
> Here I fully agree with you: the rules in 3588 are not clear enough.
>=20
> In particular, there are so many different meanings for=20
> "mandatory AVP" that I can't probably even list them all. But=20
> let's try:
>=20
> 1) An AVP that is mandatory according to the command's ABNF;
>    a command without this AVP always results in DIAMETER_MISSING_AVP.

We call this MANDATORY TO INCLUDE.

> 2) An AVP not in category 1, but the specification of the AVP
>    says the 'M' bit MUST be set if the AVP is included, and thus
>    the command has to be rejected if the recipient does not=20
>    understand this AVP; failure results in DIAMETER_AVP_UNSUPPORTED.

=20
> 3) An AVP not in category 1 or 2, but the _sender_ of the command=20
>    requires the command to be rejected if the recipient does not=20
>    understand this AVP (and thus sets the 'M' bit); failure results=20
>    in DIAMETER_AVP_UNSUPPORTED.

We call this MANDATORY TO UNDERSTAND.

> 4) An AVP not in categories 1..3, but the _recipient_ of the command=20
>    requires this AVP to be present; failure results in e.g.=20
>    DIAMETER_AUTHORIZATION_REJECTED or some other error code.=20
>    For example, an AAA server could reject all requests that=20
>    don't have NAS-Port-Type AVP with value "802.11".

=20
> 5) A "Diameter usage guidelines document" for a particular usage=20
>    situation can specify that an implementation compliant
>    with that document (in addition to relevant Diameter RFCs)
>    must include some AVP in some particular command, even though
>    the command AVP does not require it. This implies that the =20
>    recipient of the command can safely use a policy meant in=20
>    category 4.
>=20
>    For example, 3GPP spec 29.234 specifies that when Diameter EAP
>    application is used between a 3GPP WLAN-IW compliant 802.11 WLAN
>    and 3G operator's AAA server, the Diameter-EAP-Request command must
>    include the Calling-Station-Id AVP, and it must contain the STA's
>    MAC address. (In RFC4072 the Calling-Station-Id AVP is optional,
>    and there's no requirement that it contains an IEEE 802 MAC
>    address).
>=20
> 6) Similarly, an usage guidelines document can specify that
>    an implementation compliant with that document must understand
>    some AVP in a particular message, and process it in a=20
> particular way.
>=20
>    For example, the IRAP "Public WLAN Roaming Interface Specification"
>    (which is for RADIUS, but a document with similar content for
>    Diameter could be written) specifies that the WLAN AP must support=20
>    the Idle-Timeout attribute, and use its contents in a=20
> particular way=20
>    (disconnect uses if no IP packets for this time; L2 packets don't=20
>    count; this AVP overrides local settings).
>=20
>    RFC4005 specifies only that the Idle-Timeout AVP must have the 'M'
>    bit set, but not what exactly is required by an implementation that
>    "understands" the AVP (presumably, a compliant implementation could
>    have a local policy that explicitly overrides the received value,
>    could have a fixed non-configurable value for this timer, or could
>    use a different interpretation of what "idle" means).
>=20
> The challenge is that there is no clear-cut definition when=20
> any of items 3...6 require a new application ID and when they=20
> don't.  The examples I've given are more on the "no new=20
> application ID" side, but once we're talking about more than=20
> one AVP, it seems we're left with a subjective judgement=20
> whether we are still "close enough" to the old application or not.
>=20
> For example, defining how to use Diameter between in a "remote access"
> type IKEv2 usage (between IKEv2 VPN gateway/home agent and=20
> AAA server) could be done either as "Diameter usage=20
> guidelines for IKEv2 remote access" or "Diameter=20
> remote-access-IKEv2-EAP Application" (BTW, I consider it=20
> remote access no matter whether it supports mobility or not,=20
> and whether mobility is supported using MOBIKE or MIPv6).

So I don't think that there is a difference between Usage Guidelines and
new Application in the sense that both require code changes.  Therefore,
each new Usage Guideline (even for an existing application) requires
that the command be routed to the correct server.  (You can have
multiple Servers on the same machine)

Application ID is supposed to be that mechansim. Yes there is some text
that says that other things can be used for routing.

As some folks told me, the Application ID was suppose to capture
applications versions as well.  After all it is 32 bit number.

So to re-iterate...i need to make sure the commands reach the correct
implementation where they will be handled correctly.  This needs to be
done without requiring me to upgrade all my servers just because I want
to implment new functionality in some places.

Here is a thought: if we are worried about Application ID explosion
perhaps we can divide the Application ID into two parts:

Part one can be the Application ID; and
Part two can be a version or revision part for a given application.

As we create new "Usage Guidelines" for a given application can
increment the revision part.  As we create new Applications we assign
new Applications Ids.




=20
> Best regards,
> Pasi
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Mon May 29 16:51:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FkoiC-0001fX-3L; Mon, 29 May 2006 16:51:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FkoiB-0001dg-3G
	for dime@ietf.org; Mon, 29 May 2006 16:51:39 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fkoi9-0001L3-KC
	for dime@ietf.org; Mon, 29 May 2006 16:51:39 -0400
Received: (qmail invoked by alias); 29 May 2006 20:51:35 -0000
Received: from p54986FC2.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.111.194]
	by mail.gmx.net (mp012) with SMTP; 29 May 2006 22:51:35 +0200
X-Authenticated: #29516787
Message-ID: <447B5ED9.1040103@gmx.net>
Date: Mon, 29 May 2006 22:51:37 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Avi Lior 
Subject: Re: [Dime] Policy based Applications and QoS Application
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: isalekul@hotmail.com, dime@ietf.org, "Tschofenig,
	Hannes" 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Avi,

thanks for raising this topic. Please find my response below;

Avi Lior wrote:
> Hi All,
>  
> This email prompts me to start a discussion on Policy and QoS Application.
>  
> As some of you are aware IMS Rel 7.0 has an entity called PCRF.  This 
> PCRF is supposed to broker per flow based policy actions between the IMS 
> infrastructure and the Network.  Initially this policy was QoS and in 
> release 7.0 it also brokers Charging Policy.  In the future it will 
> probably broker other per flow policy.  For example, it may instruct the 
> network to apply security policies to a flow or group of flows.
>  
> The QoS Application that is being developed by the IETF (IMO) was 
> targeting the Policy entity in its IMS Rel 6.0 form when it was called 
> the PDF instead of PCRF and when it was only serving QoS policies.  Now 
> in rel 7.0 the Diameter application being developed is serving both QoS 
> and Charging information and is based on the Diameter Credit Control 
> function. 
>  
> Also QoS policies are also delivered as part of Authentication.  So EAP 
> Application may be used to deliver initial QoS policies to the User 
> session being authenticated and authorized.

I agree with you.

>  
> So I am raising the following questions:
>  
> 1) Is there any reason to create a QoS Application in Diameter?

I guess your question is 'Does it need to be an application' and thereby 
referring to question 3. In some sense we also discussed this question 
in context of MIPv6 Bootstrapping as well.

Are you concerned about the additional messaging or more about the 
degree of flexbility.

>  
> 2) Should we work on a Diameter Flow-based Policy Application that is 
> able to deliver QoS/Charging and in the future other flow based application?
> -Should this work be done in the IETF? Do we get folks in 3GPP/3GPP2 and 
> WiMAX to agree to work on this within the IETF.  Or perhaps we can agree 
> to work on this together outside the IETF?
 >
> 3) Perhaps we should just define QoS based attributes that can be pulled 
> into various future Diameter Applications.

The last two approaches sound like interesting approaches we should 
investigate.


Ciao
Hannes

>  
>  
> Comments are welcome!!!
>  
>  
> 
>     ------------------------------------------------------------------------
>     *From:* Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]
>     *Sent:* Monday, May 08, 2006 4:23 AM
>     *To:* john.loughney@nokia.com; dime@ietf.org
>     *Cc:* isalekul@hotmail.com
>     *Subject:* AW: [Dime] FW: [AAA-WG]: Policy representation for AAA server
> 
>     Hi Salekul,
>      
>     could you formulate your question in more detail?
>     What type of policies are you talking about? E.g., policies that
>     represent the business logic at a AAA server or policies that are
>     conveyed from the AAA server to the AAA client? Are you looking for
>     a language to express these policies or rather for the content of
>     these policies? Do you have a specific application in mind (e.g.,
>     policies regarding charging, QoS, location information)
>      
>     Ciao
>     Hannes
>      
> 
>         ------------------------------------------------------------------------
>         *Von:* john.loughney@nokia.com [mailto:john.loughney@nokia.com]
>         *Gesendet:* Montag, 8. Mai 2006 10:10
>         *An:* dime@ietf.org
>         *Cc:* isalekul@hotmail.com
>         *Betreff:* [Dime] FW: [AAA-WG]: Policy representation for AAA server
> 
>         Forward to the DiME WG, in case any one has opinions for Diameter.
>          
>         John
> 
>             ------------------------------------------------------------------------
>             *From:* owner-aaa-wg@merit.edu
>             [mailto:owner-aaa-wg@merit.edu] *On Behalf Of *ext Salekul Islam
>             *Sent:* 30 April, 2006 08:55
>             *To:* aaa-wg@merit.edu
>             *Cc:* Salekul Islam
>             *Subject:* [AAA-WG]: Policy representation for AAA server
> 
>             Hi,
>              
>             I am interested in policy representation or policy server in
>             Diameter architecture. Is there any Internet Draft or paper
>             addressing the issues related to policy representation for
>             AAA server? Is there any specific direction or goal of the
>             WG regarding this issue?
>              
>             Any sort of information will be very helpful for me.
>              
>             regards,
>              
>             Salekul Islam
>             PhD candidate, Concordia University
>             Montreal, Canada
>              
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 30 09:57:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fl4iV-0000Ot-0u; Tue, 30 May 2006 09:57:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4iT-0000Oi-VU
	for dime@ietf.org; Tue, 30 May 2006 09:57:01 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4iT-0004ha-TN
	for dime@ietf.org; Tue, 30 May 2006 09:57:01 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fl4cK-0006DS-Uf
	for dime@ietf.org; Tue, 30 May 2006 09:50:43 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Policy based Applications and QoS Application
Date: Tue, 30 May 2006 09:54:51 -0400
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Policy based Applications and QoS Application
Thread-Index: AcaDYkxHbKUjP6P4T1G9yvulFHf5IwAeJSrg
From: "Avi Lior" 
To: "Hannes Tschofenig" 
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 43317e64100dd4d87214c51822b582d1
Cc: isalekul@hotmail.com, dime@ietf.org, "Tschofenig,
	Hannes" 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Hannes,

The discussion on MIPv6 bootstrapping is different.  We know that it is
an Application we were just debating whether or not we need to create a
new Application ID.

QoS may be an application and it may also be an attribute that is used
by various applications.

While it may be difficult for the IETF to come up with a QoS application
that would work across many SDOs, it may be good enough for DIME to
define a standerdized QoS blob and have SDOs pick it up as they work on
SDO specific applications.

For vendors like us, providing products across SDOs, having a
standerdized QoS blob is adventageous.  QoS Blob is relatively complex,
and requires a complex GUI for provisioning it and also complex API.

Avi

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Sent: Monday, May 29, 2006 4:52 PM
> To: Avi Lior
> Cc: dime@ietf.org; isalekul@hotmail.com; Tschofenig, Hannes
> Subject: Re: [Dime] Policy based Applications and QoS Application
>=20
> Hi Avi,
>=20
> thanks for raising this topic. Please find my response below;
>=20
> Avi Lior wrote:
> > Hi All,
> > =20
> > This email prompts me to start a discussion on Policy and=20
> QoS Application.
> > =20
> > As some of you are aware IMS Rel 7.0 has an entity called=20
> PCRF.  This=20
> > PCRF is supposed to broker per flow based policy actions=20
> between the=20
> > IMS infrastructure and the Network.  Initially this policy=20
> was QoS and=20
> > in release 7.0 it also brokers Charging Policy.  In the=20
> future it will=20
> > probably broker other per flow policy.  For example, it may=20
> instruct=20
> > the network to apply security policies to a flow or group of flows.
> > =20
> > The QoS Application that is being developed by the IETF (IMO) was=20
> > targeting the Policy entity in its IMS Rel 6.0 form when it=20
> was called=20
> > the PDF instead of PCRF and when it was only serving QoS policies. =20
> > Now in rel 7.0 the Diameter application being developed is serving=20
> > both QoS and Charging information and is based on the=20
> Diameter Credit=20
> > Control function.
> > =20
> > Also QoS policies are also delivered as part of Authentication.  So=20
> > EAP Application may be used to deliver initial QoS policies to the=20
> > User session being authenticated and authorized.
>=20
> I agree with you.
>=20
> > =20
> > So I am raising the following questions:
> > =20
> > 1) Is there any reason to create a QoS Application in Diameter?
>=20
> I guess your question is 'Does it need to be an application'=20
> and thereby referring to question 3. In some sense we also=20
> discussed this question in context of MIPv6 Bootstrapping as well.
>=20
> Are you concerned about the additional messaging or more=20
> about the degree of flexbility.
>=20
> > =20
> > 2) Should we work on a Diameter Flow-based Policy=20
> Application that is=20
> > able to deliver QoS/Charging and in the future other flow=20
> based application?
> > -Should this work be done in the IETF? Do we get folks in=20
> 3GPP/3GPP2=20
> > and WiMAX to agree to work on this within the IETF.  Or=20
> perhaps we can=20
> > agree to work on this together outside the IETF?
>  >
> > 3) Perhaps we should just define QoS based attributes that can be=20
> > pulled into various future Diameter Applications.
>=20
> The last two approaches sound like interesting approaches we=20
> should investigate.
>=20
>=20
> Ciao
> Hannes
>=20
> > =20
> > =20
> > Comments are welcome!!!
> > =20
> > =20
> >=20
> >    =20
> --------------------------------------------------------------
> ----------
> >     *From:* Tschofenig, Hannes=20
> [mailto:hannes.tschofenig@siemens.com]
> >     *Sent:* Monday, May 08, 2006 4:23 AM
> >     *To:* john.loughney@nokia.com; dime@ietf.org
> >     *Cc:* isalekul@hotmail.com
> >     *Subject:* AW: [Dime] FW: [AAA-WG]: Policy=20
> representation for AAA server
> >=20
> >     Hi Salekul,
> >     =20
> >     could you formulate your question in more detail?
> >     What type of policies are you talking about? E.g., policies that
> >     represent the business logic at a AAA server or=20
> policies that are
> >     conveyed from the AAA server to the AAA client? Are you=20
> looking for
> >     a language to express these policies or rather for the=20
> content of
> >     these policies? Do you have a specific application in=20
> mind (e.g.,
> >     policies regarding charging, QoS, location information)
> >     =20
> >     Ciao
> >     Hannes
> >     =20
> >=20
> >        =20
> --------------------------------------------------------------
> ----------
> >         *Von:* john.loughney@nokia.com=20
> [mailto:john.loughney@nokia.com]
> >         *Gesendet:* Montag, 8. Mai 2006 10:10
> >         *An:* dime@ietf.org
> >         *Cc:* isalekul@hotmail.com
> >         *Betreff:* [Dime] FW: [AAA-WG]: Policy=20
> representation for AAA server
> >=20
> >         Forward to the DiME WG, in case any one has=20
> opinions for Diameter.
> >         =20
> >         John
> >=20
> >            =20
> --------------------------------------------------------------
> ----------
> >             *From:* owner-aaa-wg@merit.edu
> >             [mailto:owner-aaa-wg@merit.edu] *On Behalf Of=20
> *ext Salekul Islam
> >             *Sent:* 30 April, 2006 08:55
> >             *To:* aaa-wg@merit.edu
> >             *Cc:* Salekul Islam
> >             *Subject:* [AAA-WG]: Policy representation for=20
> AAA server
> >=20
> >             Hi,
> >             =20
> >             I am interested in policy representation or=20
> policy server in
> >             Diameter architecture. Is there any Internet=20
> Draft or paper
> >             addressing the issues related to policy=20
> representation for
> >             AAA server? Is there any specific direction or=20
> goal of the
> >             WG regarding this issue?
> >             =20
> >             Any sort of information will be very helpful for me.
> >             =20
> >             regards,
> >             =20
> >             Salekul Islam
> >             PhD candidate, Concordia University
> >             Montreal, Canada
> >             =20
> >=20
> >=20
> >=20
> --------------------------------------------------------------
> ----------
> >=20
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>=20
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Tue May 30 10:08:10 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1Fl4tG-0003iR-6h; Tue, 30 May 2006 10:08:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4tE-0003iM-Qg
	for dime@ietf.org; Tue, 30 May 2006 10:08:08 -0400
Received: from co300216-ier2.net.avaya.com ([198.152.13.103])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4tD-0005MD-BW
	for dime@ietf.org; Tue, 30 May 2006 10:08:08 -0400
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com
	[135.64.105.51])
	by co300216-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP
	id k4UE6D8f007768
	for ; Tue, 30 May 2006 10:06:16 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Policy based Applications and QoS Application
Date: Tue, 30 May 2006 17:07:56 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Policy based Applications and QoS Application
Thread-Index: AcaDYkxHbKUjP6P4T1G9yvulFHf5IwAeJSrgAAXdlKA=
From: "Romascanu, Dan \(Dan\)" 
To: "Avi Lior" ,
	"Hannes Tschofenig" 
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32
Cc: isalekul@hotmail.com, dime@ietf.org, "Tschofenig,
	Hannes" 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Clarification question: What would a document defining a QoS BLOb
include?=20

Thanks,=20

Dan


=20
=20

> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
> Sent: Tuesday, May 30, 2006 4:55 PM
> To: Hannes Tschofenig
> Cc: isalekul@hotmail.com; dime@ietf.org; Tschofenig,Hannes
> Subject: RE: [Dime] Policy based Applications and QoS Application
>=20
> Hi Hannes,
>=20
> The discussion on MIPv6 bootstrapping is different.  We know=20
> that it is an Application we were just debating whether or=20
> not we need to create a new Application ID.
>=20
> QoS may be an application and it may also be an attribute=20
> that is used by various applications.
>=20
> While it may be difficult for the IETF to come up with a QoS=20
> application that would work across many SDOs, it may be good=20
> enough for DIME to define a standerdized QoS blob and have=20
> SDOs pick it up as they work on SDO specific applications.
>=20
> For vendors like us, providing products across SDOs, having a=20
> standerdized QoS blob is adventageous.  QoS Blob is=20
> relatively complex, and requires a complex GUI for=20
> provisioning it and also complex API.
>=20
> Avi
>=20
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Monday, May 29, 2006 4:52 PM
> > To: Avi Lior
> > Cc: dime@ietf.org; isalekul@hotmail.com; Tschofenig, Hannes
> > Subject: Re: [Dime] Policy based Applications and QoS Application
> >=20
> > Hi Avi,
> >=20
> > thanks for raising this topic. Please find my response below;
> >=20
> > Avi Lior wrote:
> > > Hi All,
> > > =20
> > > This email prompts me to start a discussion on Policy and
> > QoS Application.
> > > =20
> > > As some of you are aware IMS Rel 7.0 has an entity called
> > PCRF.  This
> > > PCRF is supposed to broker per flow based policy actions
> > between the
> > > IMS infrastructure and the Network.  Initially this policy
> > was QoS and
> > > in release 7.0 it also brokers Charging Policy.  In the
> > future it will
> > > probably broker other per flow policy.  For example, it may
> > instruct
> > > the network to apply security policies to a flow or group=20
> of flows.
> > > =20
> > > The QoS Application that is being developed by the IETF (IMO) was=20
> > > targeting the Policy entity in its IMS Rel 6.0 form when it
> > was called
> > > the PDF instead of PCRF and when it was only serving QoS=20
> policies. =20
> > > Now in rel 7.0 the Diameter application being developed=20
> is serving=20
> > > both QoS and Charging information and is based on the
> > Diameter Credit
> > > Control function.
> > > =20
> > > Also QoS policies are also delivered as part of=20
> Authentication.  So=20
> > > EAP Application may be used to deliver initial QoS=20
> policies to the=20
> > > User session being authenticated and authorized.
> >=20
> > I agree with you.
> >=20
> > > =20
> > > So I am raising the following questions:
> > > =20
> > > 1) Is there any reason to create a QoS Application in Diameter?
> >=20
> > I guess your question is 'Does it need to be an application'=20
> > and thereby referring to question 3. In some sense we also=20
> discussed=20
> > this question in context of MIPv6 Bootstrapping as well.
> >=20
> > Are you concerned about the additional messaging or more about the=20
> > degree of flexbility.
> >=20
> > > =20
> > > 2) Should we work on a Diameter Flow-based Policy
> > Application that is
> > > able to deliver QoS/Charging and in the future other flow
> > based application?
> > > -Should this work be done in the IETF? Do we get folks in
> > 3GPP/3GPP2
> > > and WiMAX to agree to work on this within the IETF.  Or
> > perhaps we can
> > > agree to work on this together outside the IETF?
> >  >
> > > 3) Perhaps we should just define QoS based attributes that can be=20
> > > pulled into various future Diameter Applications.
> >=20
> > The last two approaches sound like interesting approaches we should=20
> > investigate.
> >=20
> >=20
> > Ciao
> > Hannes
> >=20
> > > =20
> > > =20
> > > Comments are welcome!!!
> > > =20
> > > =20
> > >=20
> > >    =20
> > --------------------------------------------------------------
> > ----------
> > >     *From:* Tschofenig, Hannes
> > [mailto:hannes.tschofenig@siemens.com]
> > >     *Sent:* Monday, May 08, 2006 4:23 AM
> > >     *To:* john.loughney@nokia.com; dime@ietf.org
> > >     *Cc:* isalekul@hotmail.com
> > >     *Subject:* AW: [Dime] FW: [AAA-WG]: Policy
> > representation for AAA server
> > >=20
> > >     Hi Salekul,
> > >     =20
> > >     could you formulate your question in more detail?
> > >     What type of policies are you talking about? E.g.,=20
> policies that
> > >     represent the business logic at a AAA server or
> > policies that are
> > >     conveyed from the AAA server to the AAA client? Are you
> > looking for
> > >     a language to express these policies or rather for the
> > content of
> > >     these policies? Do you have a specific application in
> > mind (e.g.,
> > >     policies regarding charging, QoS, location information)
> > >     =20
> > >     Ciao
> > >     Hannes
> > >     =20
> > >=20
> > >        =20
> > --------------------------------------------------------------
> > ----------
> > >         *Von:* john.loughney@nokia.com
> > [mailto:john.loughney@nokia.com]
> > >         *Gesendet:* Montag, 8. Mai 2006 10:10
> > >         *An:* dime@ietf.org
> > >         *Cc:* isalekul@hotmail.com
> > >         *Betreff:* [Dime] FW: [AAA-WG]: Policy
> > representation for AAA server
> > >=20
> > >         Forward to the DiME WG, in case any one has
> > opinions for Diameter.
> > >         =20
> > >         John
> > >=20
> > >            =20
> > --------------------------------------------------------------
> > ----------
> > >             *From:* owner-aaa-wg@merit.edu
> > >             [mailto:owner-aaa-wg@merit.edu] *On Behalf Of
> > *ext Salekul Islam
> > >             *Sent:* 30 April, 2006 08:55
> > >             *To:* aaa-wg@merit.edu
> > >             *Cc:* Salekul Islam
> > >             *Subject:* [AAA-WG]: Policy representation for
> > AAA server
> > >=20
> > >             Hi,
> > >             =20
> > >             I am interested in policy representation or
> > policy server in
> > >             Diameter architecture. Is there any Internet
> > Draft or paper
> > >             addressing the issues related to policy
> > representation for
> > >             AAA server? Is there any specific direction or
> > goal of the
> > >             WG regarding this issue?
> > >             =20
> > >             Any sort of information will be very helpful for me.
> > >             =20
> > >             regards,
> > >             =20
> > >             Salekul Islam
> > >             PhD candidate, Concordia University
> > >             Montreal, Canada
> > >             =20
> > >=20
> > >=20
> > >=20
> > --------------------------------------------------------------
> > ----------
> > >=20
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> >=20
> >=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Wed May 31 08:36:51 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlPwR-0003kb-0I; Wed, 31 May 2006 08:36:51 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FlPwP-0003kW-Qj
	for dime@ietf.org; Wed, 31 May 2006 08:36:49 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlPwN-00084G-5v
	for dime@ietf.org; Wed, 31 May 2006 08:36:49 -0400
Received: (qmail invoked by alias); 31 May 2006 12:36:43 -0000
Received: from ip-80-226-249-75.vodafone-net.de (EHLO [10.226.220.24])
	[80.226.249.75]
	by mail.gmx.net (mp016) with SMTP; 31 May 2006 14:36:43 +0200
X-Authenticated: #29516787
Message-ID: <447D8DD9.4020002@gmx.net>
Date: Wed, 31 May 2006 14:36:41 +0200
From: Hannes Tschofenig 
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Romascanu, Dan \(Dan\)" 
Subject: Re: [Dime] Policy based Applications and QoS Application
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
Cc: isalekul@hotmail.com, "Tschofenig, Hannes" ,
	dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hi Dan,

Romascanu, Dan (Dan) wrote:
> Clarification question: What would a document defining a QoS BLOb
> include?


When Avi talks about the QoS Blob then he refers to a generic QoS 
description  similar to the one produced with the
http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-09.txt

Ciao
Hannes

> 
> Thanks, 
> 
> Dan
> 
> 
>  
>  
> 
> 
>>-----Original Message-----
>>From: Avi Lior [mailto:avi@bridgewatersystems.com] 
>>Sent: Tuesday, May 30, 2006 4:55 PM
>>To: Hannes Tschofenig
>>Cc: isalekul@hotmail.com; dime@ietf.org; Tschofenig,Hannes
>>Subject: RE: [Dime] Policy based Applications and QoS Application
>>
>>Hi Hannes,
>>
>>The discussion on MIPv6 bootstrapping is different.  We know 
>>that it is an Application we were just debating whether or 
>>not we need to create a new Application ID.
>>
>>QoS may be an application and it may also be an attribute 
>>that is used by various applications.
>>
>>While it may be difficult for the IETF to come up with a QoS 
>>application that would work across many SDOs, it may be good 
>>enough for DIME to define a standerdized QoS blob and have 
>>SDOs pick it up as they work on SDO specific applications.
>>
>>For vendors like us, providing products across SDOs, having a 
>>standerdized QoS blob is adventageous.  QoS Blob is 
>>relatively complex, and requires a complex GUI for 
>>provisioning it and also complex API.
>>
>>Avi
>>
>>
>>>-----Original Message-----
>>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
>>>Sent: Monday, May 29, 2006 4:52 PM
>>>To: Avi Lior
>>>Cc: dime@ietf.org; isalekul@hotmail.com; Tschofenig, Hannes
>>>Subject: Re: [Dime] Policy based Applications and QoS Application
>>>
>>>Hi Avi,
>>>
>>>thanks for raising this topic. Please find my response below;
>>>
>>>Avi Lior wrote:
>>>
>>>>Hi All,
>>>> 
>>>>This email prompts me to start a discussion on Policy and
>>>
>>>QoS Application.
>>>
>>>> 
>>>>As some of you are aware IMS Rel 7.0 has an entity called
>>>
>>>PCRF.  This
>>>
>>>>PCRF is supposed to broker per flow based policy actions
>>>
>>>between the
>>>
>>>>IMS infrastructure and the Network.  Initially this policy
>>>
>>>was QoS and
>>>
>>>>in release 7.0 it also brokers Charging Policy.  In the
>>>
>>>future it will
>>>
>>>>probably broker other per flow policy.  For example, it may
>>>
>>>instruct
>>>
>>>>the network to apply security policies to a flow or group 
>>
>>of flows.
>>
>>>> 
>>>>The QoS Application that is being developed by the IETF (IMO) was 
>>>>targeting the Policy entity in its IMS Rel 6.0 form when it
>>>
>>>was called
>>>
>>>>the PDF instead of PCRF and when it was only serving QoS 
>>
>>policies.  
>>
>>>>Now in rel 7.0 the Diameter application being developed 
>>
>>is serving 
>>
>>>>both QoS and Charging information and is based on the
>>>
>>>Diameter Credit
>>>
>>>>Control function.
>>>> 
>>>>Also QoS policies are also delivered as part of 
>>
>>Authentication.  So 
>>
>>>>EAP Application may be used to deliver initial QoS 
>>
>>policies to the 
>>
>>>>User session being authenticated and authorized.
>>>
>>>I agree with you.
>>>
>>>
>>>> 
>>>>So I am raising the following questions:
>>>> 
>>>>1) Is there any reason to create a QoS Application in Diameter?
>>>
>>>I guess your question is 'Does it need to be an application' 
>>>and thereby referring to question 3. In some sense we also 
>>
>>discussed 
>>
>>>this question in context of MIPv6 Bootstrapping as well.
>>>
>>>Are you concerned about the additional messaging or more about the 
>>>degree of flexbility.
>>>
>>>
>>>> 
>>>>2) Should we work on a Diameter Flow-based Policy
>>>
>>>Application that is
>>>
>>>>able to deliver QoS/Charging and in the future other flow
>>>
>>>based application?
>>>
>>>>-Should this work be done in the IETF? Do we get folks in
>>>
>>>3GPP/3GPP2
>>>
>>>>and WiMAX to agree to work on this within the IETF.  Or
>>>
>>>perhaps we can
>>>
>>>>agree to work on this together outside the IETF?
>>>
>>> >
>>>
>>>>3) Perhaps we should just define QoS based attributes that can be 
>>>>pulled into various future Diameter Applications.
>>>
>>>The last two approaches sound like interesting approaches we should 
>>>investigate.
>>>
>>>
>>>Ciao
>>>Hannes
>>>
>>>
>>>> 
>>>> 
>>>>Comments are welcome!!!
>>>> 
>>>> 
>>>>
>>>>    
>>>
>>>--------------------------------------------------------------
>>>----------
>>>
>>>>    *From:* Tschofenig, Hannes
>>>
>>>[mailto:hannes.tschofenig@siemens.com]
>>>
>>>>    *Sent:* Monday, May 08, 2006 4:23 AM
>>>>    *To:* john.loughney@nokia.com; dime@ietf.org
>>>>    *Cc:* isalekul@hotmail.com
>>>>    *Subject:* AW: [Dime] FW: [AAA-WG]: Policy
>>>
>>>representation for AAA server
>>>
>>>>    Hi Salekul,
>>>>     
>>>>    could you formulate your question in more detail?
>>>>    What type of policies are you talking about? E.g., 
>>
>>policies that
>>
>>>>    represent the business logic at a AAA server or
>>>
>>>policies that are
>>>
>>>>    conveyed from the AAA server to the AAA client? Are you
>>>
>>>looking for
>>>
>>>>    a language to express these policies or rather for the
>>>
>>>content of
>>>
>>>>    these policies? Do you have a specific application in
>>>
>>>mind (e.g.,
>>>
>>>>    policies regarding charging, QoS, location information)
>>>>     
>>>>    Ciao
>>>>    Hannes
>>>>     
>>>>
>>>>        
>>>
>>>--------------------------------------------------------------
>>>----------
>>>
>>>>        *Von:* john.loughney@nokia.com
>>>
>>>[mailto:john.loughney@nokia.com]
>>>
>>>>        *Gesendet:* Montag, 8. Mai 2006 10:10
>>>>        *An:* dime@ietf.org
>>>>        *Cc:* isalekul@hotmail.com
>>>>        *Betreff:* [Dime] FW: [AAA-WG]: Policy
>>>
>>>representation for AAA server
>>>
>>>>        Forward to the DiME WG, in case any one has
>>>
>>>opinions for Diameter.
>>>
>>>>         
>>>>        John
>>>>
>>>>            
>>>
>>>--------------------------------------------------------------
>>>----------
>>>
>>>>            *From:* owner-aaa-wg@merit.edu
>>>>            [mailto:owner-aaa-wg@merit.edu] *On Behalf Of
>>>
>>>*ext Salekul Islam
>>>
>>>>            *Sent:* 30 April, 2006 08:55
>>>>            *To:* aaa-wg@merit.edu
>>>>            *Cc:* Salekul Islam
>>>>            *Subject:* [AAA-WG]: Policy representation for
>>>
>>>AAA server
>>>
>>>>            Hi,
>>>>             
>>>>            I am interested in policy representation or
>>>
>>>policy server in
>>>
>>>>            Diameter architecture. Is there any Internet
>>>
>>>Draft or paper
>>>
>>>>            addressing the issues related to policy
>>>
>>>representation for
>>>
>>>>            AAA server? Is there any specific direction or
>>>
>>>goal of the
>>>
>>>>            WG regarding this issue?
>>>>             
>>>>            Any sort of information will be very helpful for me.
>>>>             
>>>>            regards,
>>>>             
>>>>            Salekul Islam
>>>>            PhD candidate, Concordia University
>>>>            Montreal, Canada
>>>>             
>>>>
>>>>
>>>>
>>>
>>>--------------------------------------------------------------
>>>----------
>>>
>>>>_______________________________________________
>>>>DiME mailing list
>>>>DiME@ietf.org
>>>>https://www1.ietf.org/mailman/listinfo/dime
>>>
>>>
>>_______________________________________________
>>DiME mailing list
>>DiME@ietf.org
>>https://www1.ietf.org/mailman/listinfo/dime
>>
> 
> 
> 


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Wed May 31 11:40:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlSo7-0007Lq-9S; Wed, 31 May 2006 11:40:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FlSo6-0007Ll-6V
	for dime@ietf.org; Wed, 31 May 2006 11:40:26 -0400
Received: from web38215.mail.mud.yahoo.com ([209.191.124.158])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlSo4-0001Qk-Tt
	for dime@ietf.org; Wed, 31 May 2006 11:40:26 -0400
Received: (qmail 65176 invoked by uid 60001); 31 May 2006 15:40:24 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
	h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
	b=zrkYYN7kqy4aj5l3SCiRi/k2QH8D3M2Y/Klc9snqiGWJNoHrUONavH3cZkYX/8xI3Vc7+yujB2fRpSunbMP1Oaz2sA56MjR629EzVXj5a8RYMHYnnirnfH5j0N4NxVfjh84/Kjfc/PjVVT65r/hsVJ03rYEjHr7RhviWbaRJSB8=
	; 
Message-ID: <20060531154024.65174.qmail@web38215.mail.mud.yahoo.com>
Received: from [193.49.124.107] by web38215.mail.mud.yahoo.com via HTTP;
	Wed, 31 May 2006 17:40:24 CEST
Date: Wed, 31 May 2006 17:40:24 +0200 (CEST)
From: "#:-\) seb" 
To: dime@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: 1.8 (+)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Dime] diameter AVPs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Hello, 
I'm new in diameter application development. I must
develop a diameter client and i ask me some questions
about some AVPs and how to fill them. Could you tell
me where can I find some ethereal trace about Diameter
exchange or other information dealing with my purpose?


thanks for your help 


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Wed May 31 12:11:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlTHm-0003CK-VB; Wed, 31 May 2006 12:11:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTHl-0003BG-Ov
	for dime@ietf.org; Wed, 31 May 2006 12:11:05 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTHj-00049h-Ei
	for dime@ietf.org; Wed, 31 May 2006 12:11:05 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-4.cisco.com with ESMTP; 31 May 2006 09:11:03 -0700
X-IronPort-AV: i="4.05,194,1146466800"; 
	d="scan'208"; a="1816367904:sNHT31920932"
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4VGB2eK019235; 
	Wed, 31 May 2006 09:11:02 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k4VGB2CU010883;
	Wed, 31 May 2006 09:11:02 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Wed, 31 May 2006 09:11:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 May 2006 09:11:01 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625021629D7@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [AAA-WG]: Diameter OriginHost and OriginRealm values
Thread-Index: AcaEjjFrkUhDFQCMTLK9S31QZeI2IgAPYhvg
From: "Glen Zorn \(gwz\)" 
To: "Gerard Tixier" 
X-OriginalArrivalTime: 31 May 2006 16:11:02.0751 (UTC)
	FILETIME=[D02E06F0:01C684CC]
DKIM-Signature: a=rsa-sha1; q=dns; l=984; t=1149091863; x=1149955863;
	c=relaxed/simple; s=sjdkim4001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20
	|Subject:RE=3A=20[AAA-WG]=3A=20Diameter=20OriginHost=20and=20OriginRealm=20values;
	X=v=3Dcisco.com=3B=20h=3DLOwAWZfxeXygEPMTzgMWZnSDbIs=3D;
	b=dL+bxc9fOEeTouhW4XNR/uB73lZpLaNtftajE0mD42860t04oitCzn9iUUeh3AcVF14hy7pw
	yPB4ibQyhIDu9dwmjjAcuaktrblsQ8tuLTtI5Fz1/0WV9bqi1QSj5fgt;
Authentication-Results: sj-dkim-4.cisco.com; header.From=gwz@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: dime@ietf.org, "Glen Zorn \(gwz\)" 
Subject: [Dime] RE: [AAA-WG]: Diameter OriginHost and OriginRealm values
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

Gerard Tixier <> supposedly scribbled:

> Hello,
>=20
> i could not find the answer to my question in rfc 3588 or in the mail
> archive, so here it is:=20
>=20
> does the Origin-Host value has to include the Origin-Realm ?
>=20
> for example is the following correct ?
> Origin-Host : myclient
> Origin-Realm : acme.com
>=20
> or does it have to be :
> Origin-Host : myclient.acme.com
> Origin-Realm : acme.com
>=20

Actually, it appears to be neither.  Since both the Origin-Host & the =
Origin-Realm AVPs are of type DiameterIdentity & DiameterIdentity is =
defined as FQDN, the right answer is #3:

 Origin-Host : myclient.acme.com
 Origin-Realm : myclient.acme.com

> all the examples in rfc 3588 seem to favour the second solution.
> but is it normative ?
>=20
> Thank you and best regards
> Gerard.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime



From dime-bounces@ietf.org Wed May 31 15:18:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1FlWCW-0001GK-Nq; Wed, 31 May 2006 15:17:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1FlWCV-0001GF-WC
	for dime@ietf.org; Wed, 31 May 2006 15:17:52 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlWCU-0005M4-GX
	for dime@ietf.org; Wed, 31 May 2006 15:17:51 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213])
	by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id
	k4VJHlD0010695; Wed, 31 May 2006 22:17:48 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 May 2006 22:17:47 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Wed, 31 May 2006 22:17:47 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 31 May 2006 22:17:46 +0300
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Protocol Action: 'Diameter Session Initiation Protocol (SIP)
	Application' to Proposed Standard 
Thread-Index: AcaE0/EdhvGZN+drTxGtun+yVatn+wAEuf6g
From: 
To: , 
X-OriginalArrivalTime: 31 May 2006 19:17:47.0005 (UTC)
	FILETIME=[E66F82D0:01C684E6]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc: 
Subject: [Dime] FW: Protocol Action: 'Diameter Session Initiation Protocol
	(SIP) Application' to Proposed Standard 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Errors-To: dime-bounces@ietf.org

FYI - thanks Miguel for the final push to get this out.

John=20

>-----Original Message-----
>From: ext The IESG [mailto:iesg-secretary@ietf.org]=20
>Sent: 31 May, 2006 20:01
>To: IETF-Announce
>Cc: Internet Architecture Board; RFC Editor; aaa mailing list;=20
>aaa chair; aaa chair; Loughney John (Nokia-NRC/Helsinki)
>Subject: Protocol Action: 'Diameter Session Initiation=20
>Protocol (SIP) Application' to Proposed Standard=20
>
>The IESG has approved the following document:
>
>- 'Diameter Session Initiation Protocol (SIP) Application '
>    as a Proposed Standard
>
>This document is the product of the Authentication,=20
>Authorization and Accounting Working Group.=20
>
>The IESG contact persons are Dan Romascanu and David Kessens.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip
-app-12.txt
>
>Technical Summary
>=20
>  This draft proposes Diameter application to allow SIP-based services
>  to be used within a AAA deployment, for authentication of users and
>  authorization of SIP resources usages.  The document defines the
>  overall framework for this as well as the Diameter AVPs and Command
>  Codes to be used.=09
>
>Working Group Summary
>
>  There have been 3 WGLC on the document. Effort was made to align this
>  with the RADIUS Extension for Digest Authentication draft.  There is
>  strong WG consensus behind this document, and some WG members have
>  indicated that they are implementing the draft.
>
>Protocol Quality
>
>  This document was reviewed by the working group chairs as well as
>  key Diameter and RADIUS experts.  They feel that this document is
>  ready.
>
>  The document was also reviewed by the SIPPING WG, which produced
>  RFC 3701 - "Authentication, Authorization, and Accounting
>  Requirements for the Session Initiation Protocol (SIP)".
>
>  Further, people participating from 3GPP have also reviewed this
>  document.
>
>  Additionally, this document has participated in the Early
>  Copy-Edit experiment.
>
>  This document was reviewed for the IESG by Bert Wijnen
>
>Note to RFC Editor
>=20
>  For your info: revision 08 of this document was reviewed by the
>  RFC-Editor (Alice) as part of the "early-copy-editing" experiment.
>
>

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listinfo/dime