From ecrit-bounces@ietf.org Tue Jul 03 08:57:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hwh-00055V-T7; Tue, 03 Jul 2007 08:57:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5hwg-00055B-Qo for ecrit@ietf.org; Tue, 03 Jul 2007 08:57:30 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5hwc-0001Zy-Ad for ecrit@ietf.org; Tue, 03 Jul 2007 08:57:30 -0400 Received: (qmail invoked by alias); 03 Jul 2007 12:57:25 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp053) with SMTP; 03 Jul 2007 14:57:25 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/SAnFb2MbSluziaPbNsa4QLaj5fcwyKN94pCoq6x Vj/TGoQLJCJJIt Message-ID: <468A47B3.1010402@gmx.net> Date: Tue, 03 Jul 2007 14:57:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: 97adf591118a232206bdb5a27b217034 Cc: Subject: [Ecrit] Authority-to-Individuals Bar-BOF X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, a year ago Steve gave a presentation about requirements regarding authority-to-citizen communication, see http://www3.ietf.org/proceedings/06mar/slides/ecrit-1/sld1.htm There was interest in the topic but it is clearly outside the scope of the scope of the ECRIT working group. Now, Steve, Henning, Brian and I worked on two documents to provide more details and to have a basis for a discussion: * Requirements for Authority-to-Individuals Communication for Emergency Situations http://www.tschofenig.priv.at/svn/draft-norreys-ecrit-authority2individuals/draft-norreys-ecrit-authority2individuals-requirements-00.txt * Session Initiation Protocol (SIP) Event Package for the Common Alerting Protocol (CAP) http://www.tschofenig.priv.at/svn/draft-rosen-sipping-cap/draft-rosen-sipping-cap-00.txt We could use the upcoming IETF meeting to brainstorm a bit about this topic. We would like to get feedback! * Do you think that this is useful work? * Would you be willing to work on this subject? * Is it the right time to start something soon? I would suggest to meet on MONDAY, July 23, 2007 during the lunch break (1130-1300). Please let me know if you plan to attend. I need a head count to reserve a room. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 03 13:22:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5m4z-0007ee-Up; Tue, 03 Jul 2007 13:22:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5m4y-0007eT-EG for ecrit@ietf.org; Tue, 03 Jul 2007 13:22:20 -0400 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5m4x-00023q-V9 for ecrit@ietf.org; Tue, 03 Jul 2007 13:22:20 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Tue, 3 Jul 2007 10:21:45 -0700 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: [Ecrit] Authority-to-Individuals Bar-BOF Date: Tue, 3 Jul 2007 10:21:43 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657507C99160@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <468A47B3.1010402@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Authority-to-Individuals Bar-BOF thread-index: Ace9cb+KNOtiA1cxQ+eUMd2ykKzitgAJNcGg References: <468A47B3.1010402@gmx.net> From: "Roger Marshall" To: "Hannes Tschofenig" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes: I'd like to attend the BOF. Thanks. -roger.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Tuesday, July 03, 2007 5:57 AM > To: ECRIT > Subject: [Ecrit] Authority-to-Individuals Bar-BOF >=20 > Hi all, >=20 > a year ago Steve gave a presentation about requirements=20 > regarding authority-to-citizen communication, see=20 > http://www3.ietf.org/proceedings/06mar/slides/ecrit-1/sld1.htm > There was interest in the topic but it is clearly outside the=20 > scope of the scope of the ECRIT working group. >=20 > Now, Steve, Henning, Brian and I worked on two documents to=20 > provide more details and to have a basis for a discussion: >=20 > * Requirements for Authority-to-Individuals Communication for=20 > Emergency Situations=20 > http://www.tschofenig.priv.at/svn/draft-norreys-ecrit-authority2in > dividuals/draft-norreys-ecrit-authority2individuals-requiremen > ts-00.txt >=20 > * Session Initiation Protocol (SIP) Event Package for the=20 > Common Alerting Protocol (CAP)=20 > http://www.tschofenig.priv.at/svn/draft-rosen-sipping-cap/draft-ro > sen-sipping-cap-00.txt >=20 > We could use the upcoming IETF meeting to brainstorm a bit=20 > about this topic. We would like to get feedback! > * Do you think that this is useful work? > * Would you be willing to work on this subject? > * Is it the right time to start something soon? >=20 > I would suggest to meet on MONDAY, July 23, 2007 during the=20 > lunch break (1130-1300). >=20 > Please let me know if you plan to attend. I need a head count=20 > to reserve a room. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 03 21:23:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5taW-0002HM-B8; Tue, 03 Jul 2007 21:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5taV-0002HG-G2 for ecrit@ietf.org; Tue, 03 Jul 2007 21:23:23 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5taQ-0006mA-Fn for ecrit@ietf.org; Tue, 03 Jul 2007 21:23:23 -0400 X-SEF-Processed: 5_0_0_910__2007_07_03_20_31_17 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 03 Jul 2007 20:31:17 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Jul 2007 20:23:13 -0500 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, 3 Jul 2007 20:23:12 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: U-NAPTR Thread-Index: Ace92eNqDkNlnOHGQ4iQJiuGmoCEsQ== From: "Winterbottom, James" To: "ECRIT" X-OriginalArrivalTime: 04 Jul 2007 01:23:13.0818 (UTC) FILETIME=[E43E27A0:01C7BDD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] U-NAPTR X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi All,=0D=0A=0D=0AI missed the notification of this becoming RFC-4848. So = just in case=0D=0Aanybody else did, U-NAPTR is now an RFC.=0D=0A=0D=0ACheer= s=0D=0AJames=0D=0A---------------------------------------------------------= ---------------------------------------=0D=0AThis message is for the design= ated recipient only and may=0D=0Acontain privileged, proprietary, or otherw= ise private information. =20=0D=0AIf you have received it in error, please = notify the sender=0D=0Aimmediately and delete the original. Any unauthoriz= ed use of=0D=0Athis email is prohibited.=0D=0A-----------------------------= -------------------------------------------------------------------=0D=0A[m= f2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 04 03:48:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zbJ-0008FE-4Y; Wed, 04 Jul 2007 03:48:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5zY6-0001Tw-HX for ecrit@ietf.org; Wed, 04 Jul 2007 03:45:18 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5zXp-0005EU-AN for ecrit@ietf.org; Wed, 04 Jul 2007 03:45:18 -0400 Received: (qmail invoked by alias); 04 Jul 2007 07:44:58 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp054) with SMTP; 04 Jul 2007 09:44:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19RQ7UQoUtR46tB9BjzedYhDxtc2GChrCmiSXbgxa H6JI+37dfgcefo Message-ID: <468B4FFA.2030104@gmx.net> Date: Wed, 04 Jul 2007 09:44:58 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/mixed; boundary="------------020702020604030609040207" X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a1835daefdc74d111ed9e06d7a2b756 X-Mailman-Approved-At: Wed, 04 Jul 2007 03:48:35 -0400 Cc: Subject: [Ecrit] LoST pre-06 review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --------------020702020604030609040207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, James did a review of the LoST draft. Here is the document he sent to me. Thank you James. Ciao Hannes --------------020702020604030609040207 Content-Type: application/msword; name="draft-ietf-ecrit-lost-06.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="draft-ietf-ecrit-lost-06.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAGAAAA+gIAAAAA AAAAEAAA/AIAAAEAAAD+////AAAAAPACAADxAgAA8gIAAPMCAAD0AgAA+wIAAP////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAI2AJBAAA8BK/AAAAAAAAEAAAAAAABgAA hdcBAA4AYmpiaqEVoRUAAAAAAAAAAAAAAAAAAAAAAAAJBBYANAgDAMN/AADDfwAA9roBAAAA AAAAAAAAAAAAAI4UAAAAAAAAAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAPgEAAAAAAAA+AQAAPgEAAAAAAAA+AQAAAAAAAAMBQAA 8AIAAIgJAABgAAAA6AkAABQAAAAAAAAAAAAAAPwJAAAAAAAA5CoCAAAAAADkKgIAAAAAAOQq AgAAAAAA5CoCACQAAAAIKwIAnAQAAPwJAAAAAAAAWaACACwBAACwLwIAAAAAALAvAgAAAAAA sC8CAAAAAACwLwIAAAAAALAvAgAAAAAAsC8CAAAAAACwLwIAAAAAALAvAgAAAAAAuJ8CAAIA AAC6nwIAAAAAALqfAgAAAAAAup8CAAAAAAC6nwIAAAAAALqfAgAAAAAAup8CACQAAACFoQIA aAIAAO2jAgDOAAAA3p8CABUAAAAAAAAAAAAAAAAAAAAAAAAA+AQAABQAAAA8OAIADgEAAAAA AAAAAAAAAAAAAAAAAACwLwIAAAAAALAvAgAAAAAASjkCALQAAAD+OQIAXAAAAN6fAgAAAAAA AAAAAAAAAAD4BAAAAAAAAPgEAAAAAAAAsC8CAAAAAAAAAAAAAAAAALAvAgAAAAAA858CACoA AABQnwIAAAAAAFCfAgAAAAAAUJ8CAAAAAABaOgIA9DAAAPgEAAAAAAAAsC8CAAAAAAD4BAAA AAAAALAvAgAAAAAAuJ8CAAAAAAAAAAAAAAAAAFCfAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPDgCAAAAAAC4nwIAAAAAAAAAAAAAAAAA UJ8CAAAAAAAAAAAAAAAAAFCfAgAAAAAA+AQAAAAAAAD4BAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUJ8CAAAAAACwLwIA AAAAAKQvAgAMAAAAQNRxpU68xwEAAAAAAAAAAOQqAgAAAAAATmsCAAgyAABQnwIAAAAAAAAA AAAAAAAAuJ8CAAAAAAAdoAIAPAAAAFmgAgAAAAAAUJ8CAAAAAAC7pAIAAAAAAFadAgDqAQAA u6QCAAAAAABQnwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALukAgAAAAAAAAAAAAAAAAD8BwAA jAEAAFCfAgBoAAAAsC8CAHwCAAAsMgIAxgEAAFCfAgAAAAAA8jMCAGwBAABeNQIA3gIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsC8CAAAAAACwLwIAAAAAALAvAgAAAAAA 3p8CAAAAAADenwIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQJ8CABAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAvAgAAAAAAsC8CAAAAAACwLwIA AAAAAFmgAgAAAAAAPDgCAAAAAAA8OAIAAAAAADw4AgAAAAAAPDgCAAAAAAAAAAAAAAAAAPwJ AAAAAAAA/AkAAAAAAAD8CQAAJAoCACAUAgDEFgAA/AkAAAAAAAD8CQAAAAAAAPwJAAAAAAAA IBQCAAAAAAD8CQAAAAAAAPwJAAAAAAAA/AkAAAAAAAD4BAAAAAAAAPgEAAAAAAAA+AQAAAAA AAD4BAAAAAAAAPgEAAAAAAAA+AQAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0NDUVDUklUICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFQuIEhhcmRpZQ1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUXVhbGNv bW0sIEluYy4NSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgQS4gTmV3dG9uDUV4cGlyZXM6IERlY2VtYmVyIDI1LCAyMDA3 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN1blJvY2tldA0gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSC4g U2NodWx6cmlubmUNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIENvbHVtYmlhIFUuDSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSC4gVHNjaG9mZW5pZw0gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2llbWVucyBOZXR3b3Jr cyBHbWJIICYgQ28gS0cNICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIzLCAyMDA3DQ0NICAgICAgICAgICAgTG9TVDog QSBMb2NhdGlvbi10by1TZXJ2aWNlIFRyYW5zbGF0aW9uIFByb3RvY29sDSAgICAgICAgICAg ICAgICAgICAgICBkcmFmdC1pZXRmLWVjcml0LWxvc3QtMDYudHh0DQ1TdGF0dXMgb2YgdGhp cyBNZW1vDQ0gICBCeSBzdWJtaXR0aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0 aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkNICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIg SVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUgaXMgYXdhcmUNICAgaGF2ZSBiZWVuIG9y IHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNvbWVz DSAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBpbiBhY2NvcmRhbmNlIHdpdGggU2VjdGlv biA2IG9mIEJDUCA3OS4NDSAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDSAgIFRhc2sgRm9yY2UgKElFVEYpLCBp dHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBOb3RlIHRoYXQNICAgb3RoZXIg Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJu ZXQtDSAgIERyYWZ0cy4NDSAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRz IHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0gICBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0g ICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFz IHJlZmVyZW5jZQ0gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAi d29yayBpbiBwcm9ncmVzcy4iDQ0gICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURy YWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFp ZC1hYnN0cmFjdHMudHh0Lg0NICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93 IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0gICBodHRwOi8vd3d3LmlldGYub3Jn L3NoYWRvdy5odG1sLg0NICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBE ZWNlbWJlciAyNSwgMjAwNy4NDUNvcHlyaWdodCBOb3RpY2UNDSAgIENvcHlyaWdodCAoQykg VGhlIElFVEYgVHJ1c3QgKDIwMDcpLg0NDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICAgW1BhZ2UgMV0NDA1J bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMDcNDQ1BYnN0cmFjdA0NICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgYW4gWE1MLWJhc2VkIHByb3RvY29sIGZvciBtYXBwaW5nIHNlcnZpY2UNICAgaWRlbnRp ZmllcnMgYW5kIGdlb2RldGljIG9yIGNpdmljIGxvY2F0aW9uIGluZm9ybWF0aW9uIHRvIHNl cnZpY2UNICAgY29udGFjdCBVUklzLiAgSW4gcGFydGljdWxhciwgaXQgY2FuIGJlIHVzZWQg dG8gZGV0ZXJtaW5lIHRoZQ0gICBsb2NhdGlvbi1hcHByb3ByaWF0ZSBQU0FQIGZvciBlbWVy Z2VuY3kgc2VydmljZXMuDQ0NVGFibGUgb2YgQ29udGVudHMNDSAgIDEuICBJbnRyb2R1Y3Rp b24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg NA0gICAyLiAgVGVybWlub2xvZ3kgYW5kIFJlcXVpcmVtZW50cyBOb3RhdGlvbiAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDYNICAgMy4gIE92ZXJ2aWV3IG9mIFByb3RvY29sIFVzYWdl IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DSAgIDQuICBMb1NUIFNl cnZlcnMgYW5kIFRoZWlyIFJlc29sdXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgOQ0gICA1LiAgVGhlIDxtYXBwaW5nPiBFbGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANICAgICA1LjEuICBUaGUgTWFwcGluZyBEYXRhIFNv dXJjZTogICdzb3VyY2UnLCAnc291cmNlSWQnIGFuZA0gICAgICAgICAgICdsYXN0VXBkYXRl ZCcgQXR0cmlidXRlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTANICAg ICA1LjIuICBNYXBwaW5nIFZhbGlkaXR5OiAgVGhlICdleHBpcmVzJyBBdHRyaWJ1dGUgLiAu IC4gLiAuIC4gLiAuIDEwDSAgICAgNS4zLiAgRGVzY3JpYmluZyB0aGUgU2VydmljZSB3aXRo IHRoZSA8ZGlzcGxheU5hbWU+IEVsZW1lbnQgIC4gLiAxMQ0gICAgIDUuNC4gIFRoZSBNYXBw ZWQgU2VydmljZTogIHRoZSA8c2VydmljZT4gRWxlbWVudCAuIC4gLiAuIC4gLiAuIC4gMTEN ICAgICA1LjUuICBEZWZpbmluZyB0aGUgU2VydmljZSBSZWdpb24gd2l0aCB0aGUgPHNlcnZp Y2VCb3VuZGFyeT4NICAgICAgICAgICBFbGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDSAgICAgNS42LiAgU2VydmljZSBCb3Vu ZGFyaWVzIGJ5IFJlZmVyZW5jZTogdGhlDSAgICAgICAgICAgPHNlcnZpY2VCb3VuZGFyeVJl ZmVyZW5jZT4gRWxlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0gICAgIDUuNy4g IFRoZSBTZXJ2aWNlIE51bWJlcjogIHRoZSA8c2VydmljZU51bWJlcj4gRWxlbWVudCAuIC4g LiAuIC4gMTMNICAgICA1LjguICBTZXJ2aWNlIFVSTHM6IHRoZSA8dXJpPiBFbGVtZW50ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDSAgIDYuICBQYXRoIG9mIGEgUmVxdWVzdDog dGhlIDxwYXRoPiBFbGVtZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0gICA3LiAg SWRlbnRpZnlpbmcgdGhlIExvY2F0aW9uIEVsZW1lbnQgVXNlZCBmb3IgTWFwcGluZzoNICAg ICAgIDxsb2NhdGlvblVzZWQ+IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE1DSAgIDguICBNYXBwaW5nIGEgTG9jYXRpb24gYW5kIFNlcnZpY2Ug dG8gVVJMczogPGZpbmRTZXJ2aWNlPiAgLiAuIC4gLiAxNg0gICAgIDguMS4gIE92ZXJ2aWV3 IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTYN ICAgICA4LjIuICBFeGFtcGxlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE2DSAgICAgICA4LjIuMS4gIEV4YW1wbGUgVXNpbmcgR2VvZGV0 aWMgQ29vcmRpbmF0ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0gICAgICAgOC4yLjIuICBD aXZpYyBBZGRyZXNzIE1hcHBpbmcgRXhhbXBsZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTcNICAgICA4LjMuICBDb21wb25lbnRzIG9mIHRoZSA8ZmluZFNlcnZpY2U+IFJlcXVlc3Qg IC4gLiAuIC4gLiAuIC4gLiAuIDE5DSAgICAgICA4LjMuMS4gIFRoZSA8bG9jYXRpb24+IEVs ZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOQ0gICAgICAgOC4zLjIu ICBJZGVudGlmeWluZyB0aGUgU2VydmljZTogIFRoZSA8c2VydmljZT4gRWxlbWVudCAgLiAu IC4gMjANICAgICAgIDguMy4zLiAgUmVjdXJzaW9uIGFuZCBJdGVyYXRpb24gIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDSAgICAgICA4LjMuNC4gIFNlcnZpY2UgQm91bmRh cnkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0gICAgICAgOC4z LjUuICBSZXF1ZXN0aW5nIENpdmljIExvY2F0aW9uIFZhbGlkYXRpb24gLiAuIC4gLiAuIC4g LiAuIC4gMjANICAgICA4LjQuICBDb21wb25lbnRzIG9mIHRoZSBNYXBwaW5nIFJlc3BvbnNl DSAgICAgICAgICAgPGZpbmRTZXJ2aWNlUmVzcG9uc2U+ICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAyMg0gICAgICAgOC40LjEuICBPdmVydmlldyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINICAgICAgIDguNC4yLiAg Q2l2aWMgQWRkcmVzcyBWYWxpZGF0aW9uOiAgdGhlDSAgICAgICAgICAgICAgIDxsb2NhdGlv blZhbGlkYXRpb24+IEVsZW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMw0gICA5 LiAgUmV0cmlldmluZyB0aGUgU2VydmljZSBCb3VuZGFyeSB2aWEgPGdldFNlcnZpY2VCb3Vu ZGFyeT4gLiAuIC4gMjQNICAgMTAuIExpc3QgU2VydmljZXM6IDxsaXN0U2VydmljZXM+ICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI3DSAgIDExLiBMaXN0IFNlcnZpY2Vz IEJ5IExvY2F0aW9uOiA8bGlzdFNlcnZpY2VzQnlMb2NhdGlvbj4gIC4gLiAuIC4gLiAyOA0N DQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAg ICAgICAgICAgICAgW1BhZ2UgMl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICAxMi4gTG9j YXRpb24gUHJvZmlsZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMzANICAgICAxMi4xLiBMb2NhdGlvbiBQcm9maWxlIFVzYWdlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDMxDSAgICAgMTIuMi4gVHdvIERpbWVuc2lvbmFs IEdlb2RldGljIFByb2ZpbGUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNA0gICAgIDEy LjMuIFR3byBEaW1lbnNpb25hbCBQb2x5Z29uIEdlb2RldGljIFByb2ZpbGUgLiAuIC4gLiAu IC4gLiAuIC4gMzUNICAgICAxMi40LiBCYXNpYyBDaXZpYyBQcm9maWxlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM1DSAgIDEzLiBFcnJvcnMsIFdhcm5pbmdz LCBhbmQgUmVkaXJlY3RzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzNg0gICAg IDEzLjEuIEVycm9ycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gMzYNICAgICAxMy4yLiBXYXJuaW5ncyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDM4DSAgICAgMTMuMy4gUmVkaXJlY3Rz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAzOA0g ICAxNC4gTG9TVCBUcmFuc3BvcnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMzkNICAgMTUuIFJlbGF4IE5HIFNjaGVtYSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQwDSAgIDE2LiBJbnRlcm5hdGlv bmFsaXphdGlvbiBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiA0 Nw0gICAxNy4gSUFOQSBDb25zaWRlcmF0aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gNDgNICAgICAxNy4xLiBVLU5BUFRSIFJlZ2lzdHJhdGlvbnMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQ4DSAgICAgMTcuMi4gQ29u dGVudC10eXBlIHJlZ2lzdHJhdGlvbiBmb3IgJ2FwcGxpY2F0aW9uL2xvc3QreG1sJyAuIC4g LiA0OA0gICAgIDE3LjMuIExvU1QgUmVsYXggTkcgU2NoZW1hIFJlZ2lzdHJhdGlvbiAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gNTANICAgICAxNy40LiBMb1NUIE5hbWVzcGFjZSBSZWdp c3RyYXRpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUwDSAgICAgMTcuNS4g TG9TVCBMb2NhdGlvbiBQcm9maWxlIFJlZ2lzdHJ5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiA1MQ0gICAxOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTINICAgMTkuIEFja25vd2xlZGdtZW50cyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUzDSAgIDIwLiBP cGVuIElzc3VlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiA1NQ0gICAyMS4gUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNTYNICAgICAyMS4xLiBOb3JtYXRpdmUgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDU2DSAgICAg MjEuMi4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiA1Nw0gICBBcHBlbmRpeCBBLiAgTm9uLU5vcm1hdGl2ZSBSRUxBWCBORyBT Y2hlbWEgaW4gWE1MIFN5bnRheCAuIC4gLiAuIC4gNTgNICAgQXV0aG9ycycgQWRkcmVzc2Vz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDcyDSAg IEludGVsbGVjdHVhbCBQcm9wZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4g LiAuIC4gLiAuIC4gLiA3Mw0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICAgW1Bh Z2UgM10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAg ICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0xLiAgSW50cm9kdWN0aW9uDQ0gICBQcm90 b2NvbHMgc3VjaCBhcyBOQVBUUiByZWNvcmRzIGFuZCB0aGUgU2VydmljZSBMb2NhdGlvbiBQ cm90b2NvbA0gICAoU0xQKSBjYW4gYmUgdXNlZCB0byBkaXNjb3ZlciBzZXJ2ZXJzIG9mZmVy aW5nIGEgcGFydGljdWxhciBzZXJ2aWNlLg0gICBIb3dldmVyLCBmb3IgYW4gaW1wb3J0YW50 IGNsYXNzIG9mIHNlcnZpY2VzIHRoZSBhcHByb3ByaWF0ZSBzcGVjaWZpYw0gICBzZXJ2aWNl IGluc3RhbmNlIGRlcGVuZHMgYm90aCBvbiB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlcnZpY2Ug YW5kIHRoZQ0gICBnZW9ncmFwaGljIGxvY2F0aW9uIG9mIHRoZSBlbnRpdHkgdGhhdCBuZWVk cyB0byByZWFjaCBpdC4gIEVtZXJnZW5jeQ0gICB0ZWxlY29tbXVuaWNhdGlvbnMgc2Vydmlj ZXMgYXJlIGFuIGltcG9ydGFudCBleGFtcGxlOyBoZXJlLCB0aGUNICAgc2VydmljZSBpbnN0 YW5jZSBpcyBhIFB1YmxpYyBTYWZldHkgQW5zd2VyaW5nIFBvaW50IChQU0FQKSB0aGF0IGhh cw0gICBqdXJpc2RpY3Rpb24gb3ZlciB0aGUgbG9jYXRpb24gb2YgdGhlIHVzZXIgbWFraW5n IHRoZSBjYWxsLiAgVGhlDSAgIGRlc2lyZWQgUFNBUCBpc24ndCBuZWNlc3NhcmlseSB0aGUg b25lIHRoYXQgaXMgdG9wb2xvZ2ljYWxseSBvciBldmVuDSAgIGxpbmUtb2Ytc2lnaHQgY2xv c2VzdCB0byB0aGUgY2FsbGVyOyByYXRoZXIsIGl0IGlzIHRoZSBvbmUgdGhhdA0gICBzZXJ2 ZXMgdGhlIGNhbGxlcnMgbG9jYXRpb24gYmFzZWQgb24ganVyaXNkaWN0aW9uYWwgYm91bmRh cmllcy4NDSAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgcHJvdG9jb2wgZm9yIG1hcHBp bmcgYSBzZXJ2aWNlIGlkZW50aWZpZXINICAgKHNlcnZpY2UgVVJOcykgWzhdIGFuZCBsb2Nh dGlvbiBpbmZvcm1hdGlvbiBjb21wYXRpYmxlIHdpdGggUElERi1MTw0gICBbNl0sIG5hbWVs eSByZXZpc2VkIGNpdmljIGxvY2F0aW9uIGluZm9ybWF0aW9uIFs5XSBhbmQgR01MIFsxMV0F KSB0bw0gICBvbmUgb3IgbW9yZSBzZXJ2aWNlIFVSTHMuICBFeGFtcGxlIHNlcnZpY2UgVVJM IHNjaGVtZXMgaW5jbHVkZSBzaXANICAgWzEzXSwgeG1wcCBbMTRdLCBhbmQgdGVsIFsxNV0u ICBXaGlsZSB0aGUgaW5pdGlhbCBmb2N1cyBpcyBvbg0gICBwcm92aWRpbmcgbWFwcGluZyBm dW5jdGlvbnMgZm9yIGVtZXJnZW5jeSBzZXJ2aWNlcywgaXQgaXMgbGlrZWx5IHRoYXQNICAg dGhlIHByb3RvY29sIGlzIGFwcGxpY2FibGUgdG8gb3RoZXIgc2VydmljZSBVUk5zLiAgRm9y IGV4YW1wbGUsIGluDSAgIHRoZSBVbml0ZWQgU3RhdGVzLCB0aGUgIjItMS0xIiBhbmQgIjMt MS0xIiBzZXJ2aWNlIG51bWJlcnMgZm9sbG93IGENICAgc2ltaWxhciBsb2NhdGlvbi10by1z ZXJ2aWNlIGJlaGF2aW9yIGFzIGVtZXJnZW5jeSBzZXJ2aWNlcy4NDSAgIFRoaXMgZG9jdW1l bnQgbmFtZXMgdGhpcyBwcm90b2NvbCAiTG9TVCIsIGZvciBMb2NhdGlvbi10by1TZXJ2aWNl DSAgIFRyYW5zbGF0aW9uLiAgTG9TVCBTYXRpc2ZpZXMgdGhlIHJlcXVpcmVtZW50cyBbMTdd IGZvciBtYXBwaW5nDSAgIHByb3RvY29scy4gIExvU1QgcHJvdmlkZXMgYSBudW1iZXIgb2Yg b3BlcmF0aW9ucywgY2VudGVyZWQgYXJvdW5kDSAgIG1hcHBpbmcgbG9jYXRpb25zIGFuZCBz ZXJ2aWNlIFVSTnMgdG8gc2VydmljZSBVUkxzIGFuZCBhc3NvY2lhdGVkDSAgIGluZm9ybWF0 aW9uLiAgTG9TVCBtYXBwaW5nIHF1ZXJpZXMgY2FuIGNvbnRhaW4gZWl0aGVyIGNpdmljIG9y DSAgIGdlb2RldGljIGxvY2F0aW9uIGluZm9ybWF0aW9uLiAgRm9yIGNpdmljIGFkZHJlc3Nl cywgTG9TVCBjYW4NICAgaW5kaWNhdGUgd2hpY2ggcGFydHMgb2YgdGhlIGNpdmljIGFkZHJl c3MgYXJlIGtub3duIHRvIGJlIHZhbGlkIG9yDSAgIGludmFsaWQsIHRodXMgcHJvdmlkaW5n IGFkZHJlc3MgdmFsaWRhdGlvbiwgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24NICAgMy41IG9m IFsxN10uICBMb1NUIGluZGljYXRlcyBlcnJvcnMgaW4gdGhlIGxvY2F0aW9uIGRhdGEgdG8N ICAgZmFjaWxpdGF0ZSBkZWJ1Z2dpbmcgYW5kIHByb3BlciB1c2VyIGZlZWRiYWNrLCBidXQg YWxzbyBwcm92aWRlcw0gICBiZXN0LWVmZm9ydCBhbnN3ZXJzLg0NICAgTG9TVCBxdWVyaWVz IGNhbiBiZSByZXNvbHZlZCByZWN1cnNpdmVseSBvciBpdGVyYXRpdmVseS4gIFRvIG1pbmlt aXplDSAgIHJvdW5kIHRyaXBzIGFuZCB0byBwcm92aWRlIHJvYnVzdG5lc3MgYWdhaW5zdCBu ZXR3b3JrIGZhaWx1cmVzLCBMb1NUDSAgIHN1cHBvcnRzIGNhY2hpbmcgb2YgaW5kaXZpZHVh bCBtYXBwaW5ncyBhbmQgaW5kaWNhdGVzIHRoZSByZWdpb24gZm9yDSAgIHdoaWNoIHRoZSBz YW1lIGFuc3dlciB3b3VsZCBiZSByZXR1cm5lZCAoInNlcnZpY2UgcmVnaW9uIikuDQ0gICBB cyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQsIExvU1QgbWVzc2FnZXMgYXJlIGNhcnJpZWQg aW4gSFRUUCBhbmQNICAgSFRUUFMgcHJvdG9jb2wgZXhjaGFuZ2VzLCBmYWNpbGl0YXRpbmcg dXNlIG9mIFRMUyBmb3IgcHJvdGVjdGluZyB0aGUNICAgaW50ZWdyaXR5IGFuZCBjb25maWRl bnRpYWxpdHkgb2YgcmVxdWVzdHMgYW5kIHJlc3BvbnNlcy4NDSAgIFRoaXMgZG9jdW1lbnQg Zm9jdXNlcyBvbiB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIHByb3RvY29sIGJldHdlZW4gdGhl DSAgIG1hcHBpbmcgY2xpZW50IGFuZCB0aGUgbWFwcGluZyBzZXJ2ZXIuICBPdGhlciBmdW5j dGlvbnMsIHN1Y2ggYXMNICAgZGlzY292ZXJ5IG9mIG1hcHBpbmcgc2VydmVycywgZGF0YSBy ZXBsaWNhdGlvbiBhbmQgdGhlIG92ZXJhbGwNDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDRdDQwNSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyMDA3DQ0NICAgbWFwcGluZyBzZXJ2ZXIgYXJjaGl0ZWN0dXJlIGFyZSBk ZXNjcmliZWQgaW4gYSBzZXBhcmF0ZSBkb2N1bWVudA0gICBbMThdLg0NICAgVGhlIHF1ZXJ5 IG1lc3NhZ2UgY2FycmllcyBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhbmQgYSBzZXJ2aWNlDSAg IGlkZW50aWZpZXIgZW5jb2RlZCBhcyBhIFVuaWZvcm0gUmVzb3VyY2UgTmFtZSAoVVJOKSAo c2VlIFs4XSkgZnJvbQ0gICB0aGUgTG9TVCBjbGllbnQgdG8gdGhlIExvU1Qgc2VydmVyLiAg VGhlIExvU1Qgc2VydmVyIHVzZXMgaXRzDSAgIGRhdGFiYXNlIHRvIG1hcCB0aGUgaW5wdXQg dmFsdWVzIHRvIG9uZSBvciBtb3JlIFVuaWZvcm0gUmVzb3VyY2UNICAgSWRlbnRpZmllcnMg KFVSSSkgYW5kIHJldHVybnMgdGhvc2UgVVJJcyBhbG9uZyB3aXRoIG9wdGlvbmFsDSAgIGlu Zm9ybWF0aW9uLCBzdWNoIGFzIGhpbnRzIGFib3V0IHRoZSBzZXJ2aWNlIGJvdW5kYXJ5LCBp biBhIHJlc3BvbnNlDSAgIG1lc3NhZ2UgdG8gdGhlIExvU1QgY2xpZW50LiAgSWYgdGhlIHNl cnZlciBjYW5ub3QgcmVzb2x2ZSB0aGUgcXVlcnkNICAgaXRzZWxmLCBpdCBtYXkgaW4gdHVy biBxdWVyeSBhbm90aGVyIHNlcnZlciBvciByZXR1cm4gdGhlIGFkZHJlc3Mgb2YNICAgYW5v dGhlciBMb1NUIHNlcnZlciwgaWRlbnRpZmllZCBieSBhIExvU1Qgc2VydmVyIG5hbWUuICBJ biBhZGRpdGlvbg0gICB0byB0aGUgbWFwcGluZyBmdW5jdGlvbiBkZXNjcmliZWQgaW4gU2Vj dGlvbiA4LCB0aGUgcHJvdG9jb2wgYWxzbw0gICBhbGxvd3MgdG8gcmV0cmlldmUgdGhlIHNl cnZpY2UgYm91bmRhcnkgKHNlZSBTZWN0aW9uIDkpIGFuZCB0byBsaXN0DSAgIHRoZSBzZXJ2 aWNlcyBhdmFpbGFibGUgZm9yIGEgcGFydGljdWxhciBsb2NhdGlvbiAoc2VlIFNlY3Rpb24g MTEpIG9yDSAgIHN1cHBvcnRlZCBieSBhIHBhcnRpY3VsYXIgc2VydmVyIChzZWUgU2VjdGlv biAxMCkuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NSGFyZGllLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgIFtQ YWdlIDVdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NMi4gIFRlcm1pbm9sb2d5IGFuZCBSZXF1 aXJlbWVudHMgTm90YXRpb24NDSAgIFRoZSBrZXkgd29yZHMgIk1VU1QiLCAiTVVTVCBOT1Qi LCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNICAgIlNIT1VMRCIsICJTSE9V TEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMN ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbMV0u DQ0gICBUaGlzIGRvY3VtZW50IHVzZXMgdGhlIGZvbGxvd2luZyB0ZXJtczoNDSAgIE1hcHBp bmc6ICBNYXBwaW5nIGlzIGEgcHJvY2VzcyB0aGF0IHRha2VzIGEgbG9jYXRpb24gYW5kIGEg c2VydmljZQ0gICAgICBpZGVudGlmaWVyIGFzIGlucHV0cyBhbmQgcmV0dXJucyBvbmUgb3Ig bW9yZSBVUklzLiAgVGhvc2UgVVJJcyBjYW4NICAgICAgZWl0aGVyIHBvaW50IHRvIGEgaG9z dCBwcm92aWRpbmcgdGhhdCBzZXJ2aWNlIG9yIHRvIGEgaG9zdCB0aGF0IGluDSAgICAgIHR1 cm4gcm91dGVzIHRoZSByZXF1ZXN0IHRvIHRoZSBmaW5hbCBkZXN0aW5hdGlvbi4gIFRoaXMg ZGVmaW5pdGlvbg0gICAgICBpcyBhIGdlbmVyYWxpemF0aW9uIG9mIHRoZSB0ZXJtICJtYXBw aW5nIiBhcyB1c2VkIGluIFsxN10sIGJlY2F1c2UNICAgICAgTG9TVCBjYW4gYmUgdXNlZCBm b3Igbm9uLWVtZXJnZW5jeSBzZXJ2aWNlcy4NDQ0gICBMb1NUIGNsaWVudDogIEEgaG9zdCBh Y3RzIGFzIGEgTG9TVCBjbGllbnQgaWYgaXQgc2VuZHMgTG9TVCBxdWVyeQ0gICAgICBtZXNz YWdlcyBhbmQgcmVjZWl2ZXMgTG9TVCByZXNwb25zZSBtZXNzYWdlcy4NDQ0gICBMb1NUIHNl cnZlcjogIEEgaG9zdCBhY3RzIGFzIGEgTG9TVCBzZXJ2ZXIgaWYgaXQgcmVjZWl2ZXMgTG9T VCBxdWVyeQ0gICAgICBtZXNzYWdlcyBhbmQgc2VuZHMgTG9TVCByZXNwb25zZSBtZXNzYWdl cy4gIEluIHJlY3Vyc2l2ZQ0gICAgICBvcGVyYXRpb24sIHRoZSBzYW1lIGVudGl0eSBtYXkg YmUgYm90aCBhIGNsaWVudCBhbmQgYSBzZXJ2ZXIuDQ0NICAgQXV0aG9yaXRhdGl2ZSBMb1NU IHNlcnZlcjogIEFuIGF1dGhvcml0YXRpdmUgc2VydmVyIGFjdHMgb25seSBhcyBhcw0gICAg ICBzZXJ2ZXIgYW5kIHN1Y2Nlc3NmdWxseSByZXNvbHZlcyB0aGUgaW5wdXQgbG9jYXRpb24g YW5kIHNlcnZpY2UNICAgICAgaWRlbnRpZmllciB0byBhIFVSSSBvciBzZXQgb2YgVVJJcy4N DQ0gICBTZXJ2aWNlIGJvdW5kYXJ5OiAgQSBzZXJ2aWNlIGJvdW5kYXJ5IGNpcmN1bXNjcmli ZXMgdGhlIHJlZ2lvbiB3aXRoaW4NICAgICAgd2hpY2ggYWxsIGxvY2F0aW9ucyBtYXAgdG8g dGhlIHNhbWUgc2VydmljZSBVUkkgb3Igc2V0IG9mIFVSSXMgZm9yDSAgICAgIGEgZ2l2ZW4g c2VydmljZS4gIEEgc2VydmljZSBib3VuZGFyeSBtYXkgY29uc2lzdCBvZiBzZXZlcmFsIG5v bi0NICAgICAgY29udGlndW91cyBnZW9tZXRyaWMgc2hhcGVzLg0NDSAgIFZhbGlkYXRpb246 DQ0gICAgICBUaGUgdGVybSAidmFsaWRhdGlvbiIgZGVzY3JpYmVzIHRoZSBiZWhhdmlvciBk ZWZpbmVkIGFzICJsb2NhdGlvbg0gICAgICB2YWxpZGF0aW9uIiBpbiBTZWN0aW9uIDMuNSBv ZiBbMTddLg0NICAgQWRkaXRpb25hbCBlbWVyZ2VuY3kgc2VydmljZSB0ZXJtaW5vbG9neSBj YW4gYmUgZm91bmQgaW4gWzE3XS4NDQ0NDQ0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDZdDQwNSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyMDA3DQ0NMy4gIE92ZXJ2aWV3IG9mIFByb3RvY29sIFVzYWdlDQ0gICBU aGUgTG9TVCBwcm90b2NvbCBzdXBwb3J0cyB0aGUgZm9sbG93aW5nIHR5cGUgb2YgcXVlcmll cyBhbmQNICAgcmVzcG9uc2VzOg0NICAgPGZpbmRTZXJ2aWNlPiBhbmQgPGZpbmRTZXJ2aWNl UmVzcG9uc2U+DQ0gICAgICBBIExvU1QgY2xpZW50IHJldHJpZXZlcyBjb250YWN0IFVSSXMg YmFzZWQgb24gbG9jYXRpb24gaW5mb3JtYXRpb24NICAgICAgYW5kIGEgc2VydmljZSBpZGVu dGlmaWVyIHdpdGggdGhpcyByZXF1ZXN0IGFuZCByZXNwb25zZS4gIFRoZSBzYW1lDSAgICAg IHF1ZXJ5IHR5cGUgbWF5IGFsc28gYXNrIGZvciBsb2NhdGlvbiB2YWxpZGF0aW9uIGFuZCBm b3Igc2VydmljZQ0gICAgICBudW1iZXJzLCBlaXRoZXIgY29tYmluZWQgd2l0aCBhIG1hcHBp bmcgcmVxdWVzdCBvciBzZXBhcmF0ZWx5Lg0gICAgICBUaGUgZGV0YWlscyBjYW4gYmUgZm91 bmQgaW4gU2VjdGlvbiA4IGFuZCBTZWN0aW9uIDguNC4NDQ0gICA8Z2V0U2VydmljZUJvdW5k YXJ5PiBhbmQgPGdldFNlcnZpY2VCb3VuZGFyeVJlc3BvbnNlPg0NICAgICAgQSBMb1NUIGNs aWVudCBvYnRhaW5zIGEgc2VydmljZSBib3VuZGFyeSB3aXRoIHRoaXMgcmVxdWVzdCBhbmQN ICAgICAgcmVzcG9uc2UsIGFzIGRlc2NyaWJlZCBpbiBpbiBTZWN0aW9uIDkuDQ0NICAgPGxp c3RTZXJ2aWNlcz4gYW5kIDxsaXN0U2VydmljZXNSZXNwb25zZT4NDSAgICAgIFdpdGggdGhp cyByZXF1ZXN0IGFuZCByZXNwb25zZSwgYSBMb1NUIGNsaWVudCBjYW4gZmluZCBvdXQgd2hp Y2gNICAgICAgc2VydmljZXMgYSBMb1NUIHNlcnZlciBzdXBwb3J0cywgYXMgZGVzY3JpYmVk IGluIFNlY3Rpb24gMTAuDQ0NICAgPGxpc3RTZXJ2aWNlc0J5TG9jYXRpb24+IGFuZCA8bGlz dFNlcnZpY2VzQnlMb2NhdGlvblJlc3BvbnNlPg0NICAgICAgQSBMb1NUIGNsaWVudCBjYW4g ZGV0ZXJtaW5lIHdpdGggdGhpcyByZXF1ZXN0IGFuZCByZXNwb25zZSB3aGljaA0gICAgICBz ZXJ2aWNlcyBhcmUgYXZhaWxhYmxlIGZvciBhIHNwZWNpZmljIGxvY2F0aW9uIHJlZ2lvbi4g IFNlY3Rpb24gMTENICAgICAgZGVzY3JpYmVzIHRoZSBkZXRhaWxzLg0NICAgTG9TVCBjbGll bnRzIG1heSBpbml0aWF0ZSBhbnkgb2YgdGhlIGFib3ZlIHF1ZXJpZXMgYXQgYW55IHRpbWUu DSAgIEFtb25nIHRoZSBjb21tb24gdHJpZ2dlcnMgYXJlOg0NICAgMS4gIFdoZW4gdGhlIGNs aWVudCBpbml0aWFsbHkgc3RhcnRzIHVwIG9yIGF0dGFjaGVzIHRvIGEgbmV0d29yazsNDSAg IDIuICB3aGVuIHRoZSBjbGllbnQgZGV0ZWN0cyB0aGF0IGl0cyBsb2NhdGlvbiBoYXMgY2hh bmdlZA0gICAgICAgc3VmZmljaWVudGx5IHRoYXQgaXQgaXMgb3V0c2lkZSB0aGUgYm91bmRz IG9mIHRoZSBzZXJ2aWNlIHJlZ2lvbjsNDSAgIDMuICB3aGVuIGEgU0lQIG1lc3NhZ2UgYXJy aXZlcyBhdCBhIFNJUCBwcm94eSBwZXJmb3JtaW5nIGxvY2F0aW9uLQ0gICAgICAgYmFzZWQg Y2FsbCByb3V0aW5nOw0NICAgNC4gIHdoZW4gY2FjaGVkIG1hcHBpbmcgaW5mb3JtYXRpb24g aGFzIGV4cGlyZWQ7DQ0gICA1LiAgd2hlbiBpbnZva2luZyBhIHBhcnRpY3VsYXIgc2Vydmlj ZS4gIEF0IHRoYXQgdGltZSwgYSBjbGllbnQgbWF5DSAgICAgICBvbWl0IHJlcXVlc3RzIGZv ciBzZXJ2aWNlIGJvdW5kYXJpZXMgb3Igb3RoZXIgYXV4aWxpYXJ5DSAgICAgICBpbmZvcm1h dGlvbi4NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwg MjAwNyAgICAgICAgICAgICAgIFtQYWdlIDddDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NICAg QSBzZXJ2aWNlLXNwZWNpZmljIEJlc3QgQ3VycmVudCBQcmFjdGljZSAoQkNQKSBkb2N1bWVu dCwgc3VjaCBhcw0gICBbMTldLCBnb3Zlcm5zIHdoZXRoZXIgYSBjbGllbnQgaXMgZXhwZWN0 ZWQgdG8gaW52b2tlIHRoZSBtYXBwaW5nDSAgIHNlcnZpY2UganVzdCBiZWZvcmUgbmVlZGlu ZyB0aGUgc2VydmljZSBvciB3aGV0aGVyIHRvIHJlbHkgb24gY2FjaGVkDSAgIGFuc3dlcnMu ICBDYWNoZSBlbnRyaWVzIGV4cGlyZSBhdCB0aGVpciBleHBpcmF0aW9uIHRpbWUgKHNlZQ0g ICBTZWN0aW9uIDUuMiksIG9yIHRoZXkgYmVjb21lIGludmFsaWQgaWYgdGhlIGNhbGxlcidz IGRldmljZSBtb3Zlcw0gICBiZXlvbmQgdGhlIGJvdW5kYXJpZXMgb2YgdGhlIHNlcnZpY2Ug cmVnaW9uLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1I YXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAg ICAgICAgICAgW1BhZ2UgOF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg TG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ00LiAgTG9TVCBTZXJ2 ZXJzIGFuZCBUaGVpciBSZXNvbHV0aW9uDQ0gICBMb1NUIHNlcnZlcnMgYXJlIGlkZW50aWZp ZWQgYnkgVS1OQVBUUi9ERERTIFsxMF0gYXBwbGljYXRpb24gdW5pcXVlDSAgIHN0cmluZ3Ms IGluIHRoZSBmb3JtIG9mIGEgRE5TIG5hbWUuICBBbiBleGFtcGxlIGlzDSAgICdsb3N0c2Vy dmVyLmV4YW1wbGUuY29tJy4NDSAgIENsaWVudHMgbmVlZCB0byB1c2UgdGhlIFUtTkFQVFIg WzEwXSBzcGVjaWZpY2F0aW9uIGRlc2NyaWJlZCBiZWxvdyB0bw0gICBvYnRhaW4gYSBVUkkg KGluZGljYXRpbmcgaG9zdCBhbmQgcHJvdG9jb2wpIGZvciB0aGUgYXBwbGljYWJsZSBMb1NU DSAgIHNlcnZpY2UuICBJbiB0aGlzIGRvY3VtZW50LCBvbmx5IHRoZSBIVFRQIGFuZCBIVFRQ UyBVUkwgc2NoZW1lcyBhcmUNICAgZGVmaW5lZC4gIE5vdGUgdGhhdCB0aGUgSFRUUCBVUkwg Y2FuIGJlIGFueSB2YWxpZCBIVFRQIFVSTCwgaW5jbHVkaW5nDSAgIHRob3NlIGNvbnRhaW5p bmcgcGF0aCBlbGVtZW50cy4NDSAgIFRoZSBmb2xsb3dpbmcgdHdvIEROUyBlbnRyaWVzIHNo b3cgdGhlIFUtTkFQVFIgcmVzb2x1dGlvbiBmb3INICAgImV4YW1wbGUuY29tIiB0byB0aGUg SFRUUFMgVVJMIGh0dHBzOi8vbG9zdHNlcnYuZXhhbXBsZS5jb20vc2VjdXJlIG9yDSAgIHRo ZSBIVFRQIFVSTCBodHRwOi8vbG9zdHNlcnZlci5leGFtcGxlLmNvbSwgd2l0aCB0aGUgZm9y bWVyIGJlaW5nDSAgIHByZWZlcnJlZC4NDQ0gICAgICAgZXhhbXBsZS5jb20uDQ0gICAgICAg SU4gTkFQVFIgMTAwICAxMCAgICJ1IiAgICAiTG9TVDpodHRwcyINICAgICAgICAgICAgIiEu KiFodHRwczovL2xvc3RzZXJ2ZXIuZXhhbXBsZS5jb20vc2VjdXJlISIgICIiDQ0gICAgICAg SU4gTkFQVFIgMjAwICAxMCAgICJ1IiAgICAiTG9TVDpodHRwIg0gICAgICAgICAgICAiIS4q IWh0dHA6Ly9sb3N0c2VydmVyLmV4YW1wbGUuY29tISIgICIiDQ0gICBDbGllbnRzIGxlYXJu IHRoZSBMb1NUIHNlcnZlcidzIGhvc3QgbmFtZSBieSBtZWFucyBiZXlvbmQgdGhlIHNjb3Bl DSAgIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiwgc3VjaCBhcyBTSVAgY29uZmlndXJhdGlvbiBh bmQgREhDUC4NBQ0NDQ0NRXh0cmEgTm90ZToNSXMgaXQgdHJ1ZSB0byBzYXkgdGhhdCBhIGhv c3Qgd2lsbCBnZW5lcmFsbHkgYmUgcHJvdmlzaW9uZWQgd2l0aCB0aGUgTG9TVCBzZXJ2ZXIg YWRkcmVzcyBwZXJ0YWluaW5nIHRvIGl0cyBob21lIG5ldHdvcms/IExvU1Qgc2VydmVyIGlu dGVyYWN0aW9uIGlzIHN1YnNlcXVlbnRseSBtYW5hZ2VkIGJ5IGZvcmVzdCBndWlkZXMuLiBz ZWUgWFhYLiAgRGlzY292ZXJ5IG9mIGxvY2FsIExvU1Qgc2VydmVycyBpcyBvdXQgb2Ygc2Nv cGUgZm9yIHRoaXMgZG9jdW1lbnQuIExvY2FsIHNlcnZpY2UgZGlzY292ZXJ5IHRlY2huaXF1 ZXMgbWF5IGluY2x1ZGUgRE5TIHVzaW5nIFUtTkFQVFIvRERTLCBESENQLCBvciBzb21lIGFz IHlldCB0byBiZSBkZXRlcm1pbmVkIG1lY2hhbmlzbS4NDUVuZC1Qb2ludHMgTVVTVCBzdXBw b3J0IG9uZSBtZWNoYW5pc20gZm9yIGRpc2NvdmVyaW5nIGEgbG9jYWwgTG9TVCBzZXJ2ZXIg dG8gYWRkcmVzcyB0aGUgaXNzdWUgb2Ygbm9uLXRvdGFsbHkgY29ubmVjdGVkIExvU1Qgc2Vy dmVyIG5ldHdvcmsuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgIFtQYWdlIDldDQwNSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyMDA3DQ0NNS4gIFRoZSA8bWFwcGluZz4gRWxlbWVudA0NICAgVGhlIDxt YXBwaW5nPiBlbGVtZW50IGlzIHRoZSBjb3JlIGRhdGEgZWxlbWVudCBpbiBMb1NULCBkZXNj cmliaW5nIGENICAgc2VydmljZSByZWdpb24gYW5kIHRoZSBhc3NvY2lhdGVkIHNlcnZpY2Ug VVJMcy4gIEl0cyBhdHRyaWJ1dGVzIGFuZA0gICBlbGVtZW50cyBhcmUgZGVzY3JpYmVkIGlu IHN1YnNlY3Rpb25zIGJlbG93Lg0NNS4xLiAgVGhlIE1hcHBpbmcgRGF0YSBTb3VyY2U6ICAn c291cmNlJywgJ3NvdXJjZUlkJyBhbmQgJ2xhc3RVcGRhdGVkJw0gICAgICBBdHRyaWJ1dGVz DQ0gICBUaGUgJ3NvdXJjZScsIHRoZSAnc291cmNlSWQnIGFuZCB0aGUgJ2xhc3RVcGRhdGVk JyBhdHRyaWJ1dGVzDSAgIHVuaXF1ZWx5IGlkZW50aWZ5IGEgcGFydGljdWxhciBtYXBwaW5n IHJlY29yZC4gIFRoZXkgYXJlIGNyZWF0ZWQgYnkNICAgdGhlIGF1dGhvcml0YXRpdmUgc291 cmNlIGZvciBhIG1hcHBpbmcgYW5kIGFyZSBuZXZlciBtb2RpZmllZCB3aGVuIGENICAgbWFw cGluZyBpcyBzZXJ2ZWQgZnJvbSBhIGNhY2hlLiAgQWxsIHRocmVlIGF0dHJpYnV0ZXMgYXJl IFJFUVVJUkVEDSAgIGZvciBhbGwgPG1hcHBpbmc+IGVsZW1lbnRzLiAgQSByZWNlaXZlciBj YW4gcmVwbGFjZSBhIG1hcHBpbmcgd2l0aA0gICBhbm90aGVyIG9uZSBoYXZpbmcgdGhlIHNh bWUgJ3NvdXJjZScgYW5kICdzb3VyY2VJZCcgYW5kIGEgbW9yZSByZWNlbnQNICAgdGltZSBp biAnbGFzdFVwZGF0ZWQnLg0NICAgVGhlICdzb3VyY2UnIGF0dHJpYnV0ZSBjb250YWlucyBh IExvU1QgYXBwbGljYXRpb24gdW5pcXVlIHN0cmluZw0gICBpZGVudGlmeWluZyB0aGUgYXV0 aG9yaXRhdGl2ZSBnZW5lcmF0b3Igb2YgdGhlIG1hcHBpbmcgKFNlY3Rpb24gNCkuDQ0gICBU aGUgJ3NvdXJjZUlkJyBhdHRyaWJ1dGUgaWRlbnRpZmllcyBhIHBhcnRpY3VsYXIgbWFwcGlu ZyBhbmQgY29udGFpbnMNICAgYW4gb3BhcXVlIHRva2VuIHRoYXQgTVVTVCBiZSB1bmlxdWUg YW1vbmcgYWxsIGRpZmZlcmVudCBtYXBwaW5ncw0gICBtYWludGFpbmVkIGJ5IHRoZSBhdXRo b3JpdGF0aXZlIHNvdXJjZSBmb3IgdGhhdCBwYXJ0aWN1bGFyIHNlcnZpY2UuDSAgIEZvciBl eGFtcGxlLCBhIFVuaXZlcnNhbGx5IFVuaXF1ZSBJZGVudGlmaWVyIChVVUlEKSBpcyBhIHN1 aXRhYmxlDSAgIGZvcm1hdC4NDSAgIFRoZSAnbGFzdFVwZGF0ZWQnIGF0dHJpYnV0ZSBkZXNj cmliZXMgd2hlbiBhIHNwZWNpZmljIGluc3RhbmNlIG9mDSAgIG1hcHBpbmcsIGlkZW50aWZp ZWQgYnkgdGhlIGNvbWJpbmF0aW9uIG9mICdzb3VyY2UnIGFuZCAnc291cmNlSWQnLA0gICB3 YXMgbGFzdCBjaGFuZ2VkLiAgVGhlIGNvbnRlbnRzIG9mIHRoaXMgYXR0cmlidXRlIGhhcyB0 aGUgWE1MIGRhdGENICAgdHlwZSBkYXRlVGltZSBpbiBpdHMgdGltZXpvbmVkIGZvcm0sIHVz aW5nIGNhbm9uaWNhbCBVVEMNICAgcmVwcmVzZW50YXRpb24gd2l0aCB0aGUgbGV0dGVyICda JyBhcyB0aGUgdGltZXpvbmUgaW5kaWNhdG9yLg0NNS4yLiAgTWFwcGluZyBWYWxpZGl0eTog IFRoZSAnZXhwaXJlcycgQXR0cmlidXRlDQ0gICBUaGUgJ2V4cGlyZXMnIGF0dHJpYnV0ZSBj b250YWlucyB0aGUgYWJzb2x1dGUgdGltZSBhdCB3aGljaCB0aGUNICAgbWFwcGluZyBiZWNv bWVzIGludmFsaWQuICBUaGUgY29udGVudHMgb2YgdGhpcyBhdHRyaWJ1dGUgaXMgYQ0gICB0 aW1lem9uZWQgWE1MIHR5cGUgZGF0ZVRpbWUsIGluIGNhbm9uaWNhbCByZXByZXNlbnRhdGlv bi4gIFNlZQ0gICBTZWN0aW9uIDMgcmVnYXJkaW5nIGhvdyB0aGlzIHZhbHVlIGlzIHRvIGJl IHV0aWxpemVkIHdpdGggYSBjYWNoZS4NICAgVGhlICdleHBpcmVzJyBhdHRyaWJ1dGUgaXMg UkVRVUlSRUQgdG8gYmUgaW5jbHVkZWQgaW4gdGhlIDxtYXBwaW5nPg0gICBlbGVtZW50Lg0N ICAgT3B0aW9uYWxseSwgdGhpcyBhdHRyaWJ1dGUgbWF5IGNvbnRhaW4gdGhlIHZhbHVlcyBv ZiAnTk8tQ0FDSEUnIGFuZA0gICAnTk8tRVhQSVJBVElPTicgaW5zdGVhZCBvZiBhIGRhdGVU aW1lIHZhbHVlLiAgVGhlIHZhbHVlICdOTy1DQUNIRScgaXMNICAgYW4gaW5kaWNhdGlvbiB0 aGF0IHRoZSBtYXBwaW5nIHNob3VsZCBub3QgYmUgY2FjaGVkLiAgVGhlIHZhbHVlIG9mDSAg ICdOTy1FWFBJUkFUSU9OJyBpcyBhbiBpbmRpY2F0aW9uIHRoYXQgdGhlIG1hcHBpbmcgZG9l cyBub3QgZXhwaXJlLg0NICAgT24gb2NjYXNpb24sIGEgc2VydmVyIG1heSBiZSBmb3JjZWQg dG8gcmV0dXJuIGFuIGV4cGlyZWQgbWFwcGluZyBpZg0gICBpdCBjYW5ub3QgcmVhY2ggdGhl IGF1dGhvcml0YXRpdmUgc2VydmVyIG9yIHRoZSBzZXJ2ZXIgZmFpbHMgdG8NDQ0NSGFyZGll LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAg ICAgW1BhZ2UgMTBdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1Qg ICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NICAgcmV0dXJuIGEgdXNhYmxl IGFuc3dlci4gIENsaWVudHMgYW5kIHNlcnZlcnMgTUFZIGNhY2hlIHRoZSBtYXBwaW5nIHNv DSAgIHRoYXQgdGhleSBoYXZlIGF0IGxlYXN0IHNvbWUgaW5mb3JtYXRpb24gYXZhaWxhYmxl LiAgQ2FjaGluZyBzZXJ2ZXJzDSAgIHRoYXQgaGF2ZSBzdWNoIHN0YWxlIGluZm9ybWF0aW9u IFNIT1VMRCByZS1hdHRlbXB0IHRoZSBxdWVyeSBlYWNoDSAgIHRpbWUgYSBjbGllbnQgcmVx dWVzdHMgYSBtYXBwaW5nLiAgU2luY2UgdGhlIGV4cGlyZWQgbWFwcGluZyB3aWxsIGJlDSAg IHJldHVybmVkIHRvIHRoZSBjbGllbnQgYXMgYSBub24tZXJyb3Ivbm9uLXdhcm5pbmcgcmVz cG9uc2UgaXQgaXMgdGhlDSAgIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBjbGllbnQgdG8gY2hl Y2sgdGhlICdleHBpcmVzJyBhdHRyaWJ1dGUNICAgYXNzb2NpYXRlZCB3aXRoIG1hcHBpbmcg ZGF0YSByZXR1cm5lZCBpbiBhIExvU1QgcmVzcG9uc2UgdG8gZGV0ZW1pbmUNICAgd2hldGhl ciB0aGUgbWFwcGluZyBpcyBmcmVzaAUuDQ01LjMuICBEZXNjcmliaW5nIHRoZSBTZXJ2aWNl IHdpdGggdGhlIDxkaXNwbGF5TmFtZT4gRWxlbWVudA0NICAgWmVybyBvciBtb3JlIDxkaXNw bGF5TmFtZT4gZWxlbWVudHMgZGVzY3JpYmUgdGhlIHNlcnZpY2Ugd2l0aCBhDSAgIHN0cmlu ZyB0aGF0IGlzIHN1aXRhYmxlIGZvciBkaXNwbGF5IHRvIGh1bWFuIHVzZXJzLCBlYWNoIGFu bm90YXRlZA0gICB3aXRoIHRoZSAneG1sOmxhbmcnIGF0dHJpYnV0ZSB0aGF0IGNvbnRhaW5z IGEgbGFuZ3VhZ2UgdGFnIHRvIGFpZCBpbg0gICB0aGUgcmVuZGVyaW5nIG9mIHRleHQuDQ01 LjQuICBUaGUgTWFwcGVkIFNlcnZpY2U6ICB0aGUgPHNlcnZpY2U+IEVsZW1lbnQNDSAgIFRo ZSBtYW5kYXRvcnkgPHNlcnZpY2U+IGVsZW1lbnQgaWRlbnRpZmllcyB0aGUgc2VydmljZSBm b3Igd2hpY2ggdGhpcw0gICBtYXBwaW5nIGFwcGxpZXMuICBUd28gY2FzZXMgbmVlZCB0byBi ZSBkaXN0aW5ndWlzaGVkIHdoZW4gdGhlIExvU1QNICAgc2VydmVyIHNldHMgdGhlIDxzZXJ2 aWNlPiBlbGVtZW50IGluIHRoZSByZXNwb25zZSBtZXNzYWdlOg0NICAgMS4gIElmIHRoZSBy ZXF1ZXN0ZWQgc2VydmljZSwgaWRlbnRpZmllZCBieSB0aGUgc2VydmljZSBVUk4gWzhdIGlu DSAgICAgICB0aGUgPHNlcnZpY2U+IGVsZW1lbnQgb2YgdGhlIHJlcXVlc3QsIGV4aXN0cyBm b3IgdGhlIGxvY2F0aW9uDSAgICAgICBpbmRpY2F0ZWQsIHRoZW4gdGhlIExvU1Qgc2VydmVy IGNvcGllcyB0aGUgc2VydmljZSBVUk4gZnJvbSB0aGUNICAgICAgIHJlcXVlc3QgaW50byB0 aGUgPHNlcnZpY2U+IGVsZW1lbnQuDQ0gICAyLiAgSWYsIGhvd2V2ZXIsIHRoZSByZXF1ZXN0 ZWQgc2VydmljZSwgaWRlbnRpZmllZCBieSB0aGUgc2VydmljZSBVUk4NICAgICAgIFs4XSBp biB0aGUgPHNlcnZpY2U+IGVsZW1lbnQgaW4gdGhlIHJlcXVlc3QsIGRvZXMgbm90IGV4aXN0 IGZvcg0gICAgICAgdGhlIGxvY2F0aW9uIGluZGljYXRlZCwgdGhlIHNlcnZlciBjYW4gZWl0 aGVyIHJldHVybiBhbg0gICAgICAgPHNlcnZpY2VOb3RJbXBsZW1lbnRlZD4gKFNlY3Rpb24g MTMuMSkgZXJyb3Igb3IgY2FuIHByb3ZpZGUgYW4NICAgICAgIGFsdGVybmF0ZSBzZXJ2aWNl IHRoYXQgYXBwcm94aW1hdGVzIHRoZSBkZXNpcmVkIHNlcnZpY2UgZm9yIHRoYXQFDSAgICAg ICBsb2NhdGlvbi4gIEluIHRoZSBsYXR0ZXIgY2FzZSwgdGhlIHNlcnZlciBNVVNUIGluY2x1 ZGUgYQ0gICAgICAgPHNlcnZpY2U+IGVsZW1lbnQgd2l0aCB0aGUgYWx0ZXJuYXRpdmUgc2Vy dmljZSBVUk4uICBUaGUgY2hvaWNlDSAgICAgICBvZiBzZXJ2aWNlIFVSTiBpcyBsZWZ0IHRv IGxvY2FsIHBvbGljeSwgYnV0IHRoZSBhbHRlcm5hdGUgc2VydmljZQ0gICAgICAgc2hvdWxk IGJlIGFibGUgdG8gc2F0aXNmeSB0aGUgb3JpZ2luYWwgc2VydmljZSByZXF1ZXN0Lg0NNS41 LiAgRGVmaW5pbmcgdGhlIFNlcnZpY2UgUmVnaW9uIHdpdGggdGhlIDxzZXJ2aWNlQm91bmRh cnk+IEVsZW1lbnQFDQ0gICBBIHJlc3BvbnNlIE1BWSBpbmRpY2F0ZSB0aGUgcmVnaW9uIGZv ciB3aGljaCB0aGUgc2VydmljZSBVUkwgcmV0dXJuZWQNICAgd291bGQgYmUgdGhlIHNhbWUg YXMgaW4gdGhlIGFjdHVhbCBxdWVyeSwgdGhlIHNvLWNhbGxlZCBfc2VydmljZQ0gICByZWdp b25fLiAgVGhlIHNlcnZpY2UgcmVnaW9uIGNhbiBiZSBpbmRpY2F0ZWQgYnkgdmFsdWUgb3Ig YnkNICAgcmVmZXJlbmNlIChzZWUgU2VjdGlvbiA1LjYpLiAgSWYgYSBjbGllbnQgbW92ZXMg b3V0c2lkZSB0aGUgc2VydmljZQ0gICBhcmVhIGFuZCB3aXNoZXMgdG8gb2J0YWluIGN1cnJl bnQgc2VydmljZSBkYXRhLCBpdCBzZW5kcyBhIG5ldyBxdWVyeQ0gICB3aXRoIGl0cyBjdXJy ZW50IGxvY2F0aW9uLiAgVGhlIHNlcnZpY2UgcmVnaW9uIGlzIGRlc2NyaWJlZCBieSB2YWx1 ZQ0gICBpbiBvbmUgb3IgbW9yZSA8c2VydmljZUJvdW5kYXJ5PiBlbGVtZW50cywgZWFjaCBm b3JtYXR0ZWQgYWNjb3JkaW5nDSAgIHRvIGEgZGlmZmVyZW50IGxvY2F0aW9uIHByb2ZpbGUs IGlkZW50aWZpZWQgYnkgdGhlICdwcm9maWxlJyBhdHJpYnV0ZQ0gICAoc2VlIFNlY3Rpb24g MTIpLiAgSWYgaW5jbHVkZWQgaW4gYSByZXNwb25zZSwgdGhlIDxzZXJ2aWNlQm91bmRhcnk+ DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcg ICAgICAgICAgICAgIFtQYWdlIDExXQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgIGVsZW1l bnQgTVVTVCBjb250YWluIGF0IGxlYXN0IG9uZSBzZXJ2aWNlIGJvdW5kYXJ5IHRoYXQgdXNl cyB0aGUgc2FtZQ0gICBwcm9maWxlIGFzIHRoZSByZXF1ZXN0LiAgVGhlIGNsaWVudCBvbmx5 IHByb2Nlc3NlcyB0aGUgZmlyc3QgZWxlbWVudA0gICB0aGF0IGl0IGNhbiB1bmRlcnN0YW5k IGFjY29yZGluZyB0byBpdHMgbGlzdCBvZiBzdXBwb3J0ZWQgbG9jYXRpb24NICAgcHJvZmls ZXMuICBUaHVzLCBlbGVtZW50cyB3aXRoIGdlb3NwYXRpYWwgY29vcmRpbmF0ZXMgYXJlIGFs dGVybmF0aXZlDSAgIGRlc2NyaXB0aW9ucyBvZiB0aGUgc2FtZSBzZXJ2aWNlIHJlZ2lvbiwg bm90IGFkZGl0aXZlIGdlb21ldHJpZXMuDQ0gICBBIHNlcnZpY2UgYm91bmRhcnkgaXMgcmVx dWVzdGVkIGJ5IHRoZSBjbGllbnQsIHVzaW5nIHRoZQ0gICAnc2VydmljZUJvdW5kYXJ5JyBh dHRyaWJ1dGUgaW4gdGhlIHJlcXVlc3Qgd2l0aCB0aGUgdmFsdWUgc2V0IHRvDSAgICJ2YWx1 ZSIuDQ0gICBBIHJlc3BvbnNlIE1BWSBjb250YWluIG1vcmUgdGhhbiBvbmUgPHNlcnZpY2VC b3VuZGFyeT4gZWxlbWVudCB3aXRoDSAgIHByb2ZpbGUgJ2NpdmljJy4gIEVhY2ggPHNlcnZp Y2VCb3VuZGFyeT4gZWxlbWVudCBkZXNjcmliZXMgYSBzZXQgb2YNICAgY2l2aWMgYWRkcmVz c2VzIHRoYXQgZmFsbCB3aXRoaW4gdGhlIHNlcnZpY2UgYm91bmRhcnksIG5hbWVseSBhbGwN ICAgYWRkcmVzc2VzIHRoYXQgdGV4dHVhbGx5IG1hdGNoIHRoZSBjaXZpYyBhZGRyZXNzIGVs ZW1lbnRzIHByb3ZpZGVkLA0gICByZWdhcmRsZXNzIG9mIHRoZSB2YWx1ZSBvZiBvdGhlciBh ZGRyZXNzIGVsZW1lbnRzLiAgQSBsb2NhdGlvbiBmYWxscw0gICB3aXRoaW4gdGhlIG1hcHBp bmcncyBzZXJ2aWNlIGJvdW5kYXJ5IGlmIGl0IG1hdGNoZXMgYW55IG9mIHRoZQ0gICA8c2Vy dmljZUJvdW5kYXJ5PiBlbGVtZW50cy4NDTUuNi4gIFNlcnZpY2UgQm91bmRhcmllcyBieSBS ZWZlcmVuY2U6IHRoZSA8c2VydmljZUJvdW5kYXJ5UmVmZXJlbmNlPg0gICAgICBFbGVtZW50 DQ0gICBTaW5jZSBnZW9kZXRpYyBzZXJ2aWNlIGJvdW5kYXJpZXMgbWF5IGNvbnRhaW4gdGhv dXNhbmRzIG9mIHBvaW50cyBhbmQNICAgY2FuIHRodXMgYmUgcXVpdGUgbGFyZ2UsIGNsaWVu dHMgbWF5IHdpc2ggdG8gY29uc2VydmUgYmFuZHdpZHRoIGJ5DSAgIHJlcXVlc3RpbmcgYSBy ZWZlcmVuY2UgdG8gdGhlIHNlcnZpY2UgYm91bmRhcnkgaW5zdGVhZCBvZiB0aGUgdmFsdWUN ICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNS41BS4gIFRoZSBpZGVudGlmaWVyIG9mIHRoZSBz ZXJ2aWNlIGJvdW5kYXJ5IGlzDSAgIHJldHVybmVkIGFzIGFuIGF0dHJpYnV0ZSBvZiB0aGUg PHNlcnZpY2VCb3VuZGFyeVJlZmVyZW5jZT4gZWxlbWVudCwNICAgYWxvbmcgd2l0aCBhIExv U1QgYXBwbGljYXRpb24gdW5pcXVlIHN0cmluZyAoc2VlIFNlY3Rpb24gNCkNICAgaWRlbnRp ZnlpbmcgdGhlIHNlcnZlciBmcm9tIHdoZXJlIGl0IGNhbiBiZSByZXRyaWV2ZWQuICBUaGUg YWN0dWFsDSAgIHZhbHVlIG9mIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IGlzIHRoZW4gcmV0cmll dmVkIHdpdGggdGhlDSAgIGdldFNlcnZpY2VCb3VuZGFyeSAoU2VjdGlvbiA5KSByZXF1ZXN0 Lg0NICAgQSByZWZlcmVuY2UgdG8gYSBzZXJ2aWNlIGJvdW5kYXJ5IGlzIHJlcXVlc3RlZCBi eSB0aGUgY2xpZW50ICh1c2luZw0gICB0aGUgJ3NlcnZpY2VCb3VuZGFyeScgYXR0cmlidXRl IGluIHRoZSByZXF1ZXN0IHdpdGggdGhlIHZhbHVlIHNldCB0bw0gICAicmVmZXJlbmNlIiku ICBBIExvU1Qgc2VydmVyIG1heSBkZWNpZGUsIGJhc2VkIG9uIGxvY2FsIHBvbGljeSwgdG8N ICAgcmV0dXJuIHRoZSBzZXJ2aWNlIGJvdW5kYXJ5IHBlciB2YWx1ZSBvciB0byBvbWl0IHRo ZQ0gICA8c2VydmljZUJvdW5kYXJ5UmVmZXJlbmNlPiBlbGVtZW50IGluIHRoZSByZXNwb25z ZS4NDSAgIFRoZSBpZGVudGlmaWVyIGlzIGEgcmFuZG9tIHRva2VuIHdpdGggYXQgbGVhc3Qg MTI4IGJpdHMgb2YgZW50cm9weQ0gICBhbmQgY2FuIGJlIGFzc3VtZWQgdG8gYmUgZ2xvYmFs bHkgdW5pcXVlLiAgSXQgdW5pcXVlbHkgcmVmZXJlbmNlcyBhDSAgIHBhcnRpY3VsYXIgYm91 bmRhcnkuICBJZiB0aGUgYm91bmRhcnkgY2hhbmdlcywgYSBuZXcgaWRlbnRpZmllciBNVVNU DSAgIGJlIGNob3NlbgUuICBCZWNhdXNlIG9mIHRoZXNlIHByb3BlcnRpZXMsIGEgY2xpZW50 IHJlY2VpdmluZyBhIG1hcHBpbmcNICAgcmVzcG9uc2UgY2FuIHNpbXBseSBjaGVjayBpZiBp dCBhbHJlYWR5IGhhcyBhIGNvcHkgb2YgdGhlIGJvdW5kYXJ5DSAgIHdpdGggdGhhdCBpZGVu dGlmaWVyLiAgSWYgc28sIGl0IGNhbiBza2lwIGNoZWNraW5nIHdpdGggdGhlIHNlcnZlcg0g ICB3aGV0aGVyIHRoZSBib3VuZGFyeSBoYXMgYmVlbiB1cGRhdGVkLiAgU2luY2Ugc2Vydmlj ZSBib3VuZGFyaWVzIGFyZQ0gICBsaWtlbHkgdG8gcmVtYWluIHVuY2hhbmdlZCBmb3IgZXh0 ZW5kZWQgcGVyaW9kcyBvZiB0aW1lLCBwb3NzaWJseQ0gICBleGNlZWRpbmcgdGhlIG5vcm1h bCBsaWZldGltZSBvZiB0aGUgc2VydmljZSBVUkwsIHRoaXMgYXBwcm9hY2gNICAgYXZvaWRz IHVubmVjZXNzYXJpbHkgcmVmcmVzaGluZyB0aGUgYm91bmRhcnkgaW5mb3JtYXRpb24ganVz dCBiZWNhdXNlDSAgIHRoZSByZW1haW5kZXIgb2YgdGhlIG1hcHBpbmcgaGFzIGJlY29tZSBp bnZhbGlkLg0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1 LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAxMl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ01 LjcuICBUaGUgU2VydmljZSBOdW1iZXI6ICB0aGUgPHNlcnZpY2VOdW1iZXI+IEVsZW1lbnQN DSAgIFRoZSBzZXJ2aWNlIG51bWJlciBpcyByZXR1cm5lZCBpbiB0aGUgb3B0aW9uYWwgPHNl cnZpY2VOdW1iZXI+DSAgIGVsZW1lbnQuICBJdCBjb250YWlucyBhIHN0cmluZyBvZiBkaWdp dHMsICogYW5kICMgdGhhdCBhIHVzZXIgb24gYQ0gICBkZXZpY2Ugd2l0aCBhIDEyLWtleSBk aWFsIHBhZCBjb3VsZCB1c2UgdG8gcmVhY2ggdGhhdCBwYXJ0aWN1bGFyDSAgIHNlcnZpY2Uu DQ01LjguICBTZXJ2aWNlIFVSTHM6IHRoZSA8dXJpPiBFbGVtZW50DQ0gICBUaGUgcmVzcG9u c2UgcmV0dXJucyB0aGUgc2VydmljZSBVUkxzIGluIG9uZSBvciBtb3JlIDx1cmk+IGVsZW1l bnRzLg0gICBUaGUgVVJMcyBNVVNUIGJlIGFic29sdXRlIFVSTHMuICBUaGUgb3JkZXJpbmcg b2YgdGhlIFVSTHMgaGFzIG5vDSAgIHBhcnRpY3VsYXIgc2lnbmlmaWNhbmNlLiAgRWFjaCBV Ukwgc2NoZW1lIE1VU1Qgb25seSBhcHBlYXIgYXQgbW9zdA0gICBvbmNlLCBidXQgaXQgaXMg cGVybWlzc2libGUgdG8gaW5jbHVkZSBib3RoIHNlY3VyZWQgYW5kIHJlZ3VsYXINICAgdmVy c2lvbnMgb2YgYSBwcm90b2NvbCwgc3VjaCBhcyBib3RoICdodHRwJyBhbmQgJ2h0dHBzJyBv ciAnc2lwJyBhbmQNICAgJ3NpcHMnLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3 ICAgICAgICAgICAgICBbUGFnZSAxM10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ02LiAgUGF0 aCBvZiBhIFJlcXVlc3Q6IHRoZSA8cGF0aD4gRWxlbWVudA0NICAgVG8gcHJldmVudCBsb29w cyBhbmQgdG8gYWxsb3cgdHJhY2luZyBvZiByZXF1ZXN0IGFuZCByZXNwb25zZSBwYXRocywN ICAgYWxsIHJlcXVlc3RzIHRoYXQgYWxsb3cgcmVjdXJzaW9uIGluY2x1ZGUgYSA8cGF0aD4g ZWxlbWVudCB0aGF0DSAgIGNvbnRhaW5zIG9uZSBvciBtb3JlIDx2aWE+IGVsZW1lbnRzLCBl YWNoIHBvc3Nlc3NpbmcgYW4gYXR0cmlidXRlDSAgIGNvbnRhaW5pbmcgYSBMb1NUIGFwcGxp Y2F0aW9uIHVuaXF1ZSBzdHJpbmcgKHNlZSBTZWN0aW9uIDQpLiAgVGhlDSAgIG9yZGVyIG9m IDx2aWE+IGVsZW1lbnRzIGNvcnJlc3BvbmRzIHRvIHRoZSBvcmRlciBvZiBMb1NUIHNlcnZl cnMsDSAgIGkuZS4sIHRoZSBmaXJzdCA8dmlhPiBlbGVtZW50IGlkZW50aWZpZXMgdGhlIHNl cnZlciB0aGF0IGluaXRpYWxseQ0gICByZWNlaXZlZCB0aGUgcmVxdWVzdCBmcm9tIHRoZSBj bGllbnQgaXNzdWluZyB0aGUgcmVxdWVzdC4gIFRoZSA8dmlhPg0gICBlbGVtZW50IGlzIGlu c2VydGVkIGxvZ2ljYWxseSBvbiByZWNlaXB0IG9mIHRoZSByZXF1ZXN0LCBzbyB0aGF0DSAg IGV2ZXJ5IHNlcnZlciBpbiBhIHJlY3Vyc2l2ZSBxdWVyeSBvcGVyYXRpb24gaXMgaW5jbHVk ZWQgaW4gdGhlIDxwYXRoPg0gICBlbGVtZW50Lg0NICAgVGhlIHNlcnZlciB0aGF0IGFuc3dl cnMgdGhlIHJlcXVlc3QgaW5zdGVhZCBvZiBmb3J3YXJkaW5nIGl0LCBzdWNoIGFzDSAgIHRo ZSBhdXRob3JpdGF0aXZlIHNlcnZlciwgY29waWVzIHRoZSA8cGF0aD4gZWxlbWVudCB2ZXJi YXRpbSBpbnRvIHRoZQ0gICByZXNwb25zZS4gIFRoZSA8cGF0aD4gZWxlbWVudCBpcyBub3Qg bW9kaWZpZWQgaW4gcmVzcG9uc2VzIGFzIHRoZQ0gICByZXNwb25zZXMgdHJhdmVyc2VzIHRo ZSBzZXJ2ZXIgY2hhaW4gYmFjayB0byB0aGUgcXVlcnlpbmcgY2xpZW50Lg0NICAgSWYgYSBx dWVyeSBpcyBhbnN3ZXJlZCBpdGVyYXRpdmVseSwgdGhlIHF1ZXJpZXIgaW5jbHVkZXMgYWxs IHNlcnZlcnMNICAgdGhhdCBpdCBoYXMgYWxyZWFkeSBjb250YWN0ZWQFLg0NICAgVGhlIGV4 YW1wbGUgaW4gRmlndXJlIDUgaW5kaWNhdGVzIHRoYXQgdGhlIGFuc3dlciB3YXMgZ2l2ZW4g dG8gdGhlDSAgIGNsaWVudCBieSB0aGUgTG9TVCBzZXJ2ZXIgYXQgZXNndy51ZWJlci0xMTAu ZGUuZXhhbXBsZSwgd2hpY2ggZ290IHRoZQ0gICBhbnN3ZXIgZnJvbSB0aGUgKGF1dGhvcml0 YXRpdmUpIExvU1Qgc2VydmVyIGF0DSAgIHBvbGl6ZWkubXVlbmNoZW4uZGUuZXhhbXBsZS4N DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAxNF0NDA1JbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIwMDcNDQ03LiAgSWRlbnRpZnlpbmcgdGhlIExvY2F0aW9uIEVsZW1lbnQgVXNl ZCBmb3IgTWFwcGluZzogPGxvY2F0aW9uVXNlZD4NDSAgIFNldmVyYWwgb2YgdGhlIHJlcXVl c3RzIGNhbiBwcm92aWRlIG9uZSBvciBtb3JlIDxsb2NhdGlvbj4gZWxlbWVudHMsDSAgIGFt b25nIHdoaWNoIHRoZSBzZXJ2ZXIgZ2V0cyB0byBjaG9vc2UuICBJdCBpcyB1c2VmdWwgZm9y IHRoZSBjbGllbnQNICAgdG8gYmUgYWJsZSB0byBkZXRlcm1pbmUgd2hpY2ggb25lIHdhcyBh Y3R1YWxseSB1c2VkIGluIHByb2R1Y2luZyB0aGUNICAgcmVzdWx0LiAgRm9yIHRoYXQgcHVy cG9zZSwgdGhlIDxsb2NhdGlvbj4gdGFnIE1VU1QgY29udGFpbiBhbiAnaWQnDSAgIGF0dHJp YnV0ZSB0aGF0IHVuaXF1ZWx5IGlkZW50aWZpZXMgdGhlIDxsb2NhdGlvbj4gZWxlbWVudAUu ICBUaGUNICAgZm9ybWF0IG9mIHRoZSBpZGVudGlmaWVyIGlzIGxlZnQgdG8gdGhlIGNsaWVu dDsgaXQgY291bGQsIGZvcg0gICBleGFtcGxlLCB1c2UgYSBoYXNoIG9mIHRoZSBsb2NhdGlv biBpbmZvcm1hdGlvbi4gIFRoZSBzZXJ2ZXIgcmV0dXJucw0gICB0aGUgaWRlbnRpZmllciBm b3IgdGhlIDxsb2NhdGlvbj4gZWxlbWVudCBpdCB1c2VkIGluIHRoZQ0gICA8bG9jYXRpb25V c2VkPiB0YWcuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJk aWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAg ICAgICBbUGFnZSAxNV0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9T VCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ04LiAgTWFwcGluZyBhIExv Y2F0aW9uIGFuZCBTZXJ2aWNlIHRvIFVSTHM6IDxmaW5kU2VydmljZT4NDTguMS4gIE92ZXJ2 aWV3DQ0gICBUaGUgPGZpbmRTZXJ2aWNlPiBxdWVyeSBjb25zdGl0dXRlcyB0aGUgY29yZSBv ZiB0aGUgTG9TVA0gICBmdW5jdGlvbmFsaXR5LCBtYXBwaW5nIGNpdmljIG9yIGdlb2RldGlj IGxvY2F0aW9ucyB0byBVUkxzIGFuZA0gICBhc3NvY2lhdGVkIGRhdGEuICBBZnRlciBnaXZp bmcgYW4gZXhhbXBsZSwgd2UgZW51bWVyYXRlIHRoZSBlbGVtZW50cw0gICBvZiB0aGUgcXVl cnkgYW5kIHJlc3BvbnNlLg0NOC4yLiAgRXhhbXBsZXMFDQ04LjIuMS4gIEV4YW1wbGUgVXNp bmcgR2VvZGV0aWMgQ29vcmRpbmF0ZXMNDSAgIFRoZSBmb2xsb3dpbmcgaXMgYW4gZXhhbXBs ZSBvZiBtYXBwaW5nIGEgc2VydmljZSB0byBhIGxvY2F0aW9uIHVzaW5nDSAgIGdlb2RldGlj IGNvb3JkaW5hdGVzLCBmb3IgdGhlIHNlcnZpY2UgYXNzb2NpYXRlZCB3aXRoIHRoZSBwb2xp Y2UNICAgKHVybjpzZXJ2aWNlOnNvcy5wb2xpY2UpLg0NDSAgIDw/eG1sIHZlcnNpb249IjEu MCIgZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxmaW5kU2VydmljZQ0gICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIg0gICAgIHhtbG5zOnAyPSJodHRwOi8vd3d3Lm9w ZW5naXMubmV0L2dtbCINICAgICBzZXJ2aWNlQm91bmRhcnk9InZhbHVlIg0gICAgIHJlY3Vy c2l2ZT0idHJ1ZSI+DQ0gICAgIDxsb2NhdGlvbiBpZD0iNjAyMDY4OGYxY2UxODk2ZCIgcHJv ZmlsZT0iZ2VvZGV0aWMtMmQiPg0gICAgICAgPHAyOlBvaW50IGlkPSJwb2ludDEiIHNyc05h bWU9InVybjpvZ2M6ZGVmOmNyczpFUFNHOjo0MzI2Ij4NICAgICAgICAgIDxwMjpwb3M+Mzcu Nzc1IC0xMjIuNDIyPC9wMjpwb3M+DSAgICAgICA8L3AyOlBvaW50Pg0gICAgIDwvbG9jYXRp b24+DSAgICAgPHNlcnZpY2U+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc2VydmljZT4NDSAg IDwvZmluZFNlcnZpY2U+DQ0gICAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBBIDxmaW5kU2Vy dmljZT4gZ2VvZGV0aWMgcXVlcnkNDSAgIEdpdmVuIHRoZSBxdWVyeSBhYm92ZSwgYSBzZXJ2 ZXIgd291bGQgcmVzcG9uZCB3aXRoIGEgc2VydmljZSwgYW5kDSAgIGluZm9ybWF0aW9uIHJl bGF0ZWQgdG8gdGhhdCBzZXJ2aWNlLiAgSW4gdGhlIGV4YW1wbGUgYmVsb3csIHRoZQ0gICBz ZXJ2ZXIgaGFzIG1hcHBlZCB0aGUgbG9jYXRpb24gZ2l2ZW4gYnkgdGhlIGNsaWVudCBmb3Ig YSBwb2xpY2UNICAgc2VydmljZSB0byB0aGUgTmV3IFlvcmsgQ2l0eSBQb2xpY2UgRGVwYXJ0 bWVudCwgaW5zdHJ1Y3RpbmcgdGhlDSAgIGNsaWVudCB0aGF0IGl0IG1heSBjb250YWN0IHRo ZW0gdmlhIHRoZSBVUklzICJzaXA6bnlwZEBleGFtcGxlLmNvbSINICAgYW5kICJ4bXBwOm55 cGRAZXhhbXBsZS5jb20iLiAgVGhlIHNlcnZlciBoYXMgYWxzbyBnaXZlbiB0aGUgY2xpZW50 IGENICAgZ2VvZGV0aWMsIHR3by1kaW1lbnNpb25hbCBib3VuZGFyeSBmb3IgdGhpcyBzZXJ2 aWNlLiAgVGhlIG1hcHBpbmcgd2FzDSAgIGxhc3QgdXBkYXRlZCBvbiBOb3ZlbWJlciAxLCAy MDA2IGFuZCBleHBpcmVzIG9uIEphbnVhcnkgMSwgMjAwNy4gIElmDSAgIHRoZSBjbGllbnQn cyBsb2NhdGlvbiBjaGFuZ2VzIGJleW9uZCB0aGUgZ2l2ZW4gc2VydmljZSBib3VuZGFyeSBv cg0gICB0aGUgZXhwaXJhdGlvbiB0aW1lIGhhcyBiZWVuIHJlYWNoZWQsIGl0IG1heSB3YW50 IHRvIHJlcXVlcnkgZm9yIHRoaXMNICAgaW5mb3JtYXRpb24sIGRlcGVuZGluZyBvbiB0aGUg dXNhZ2UgZW52aXJvbm1lbnQgb2YgTG9TVC4NDQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDE2XQ0MDUlu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAg ICAgICAgIEp1bmUgMjAwNw0NDSAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVU Ri04Ij8+DSAgIDxmaW5kU2VydmljZVJlc3BvbnNlIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6 eG1sOm5zOmxvc3QxIg0gICAgIHhtbG5zOnAyPSJodHRwOi8vd3d3Lm9wZW5naXMubmV0L2dt bCI+DSAgICAgPG1hcHBpbmcNICAgICAgIGV4cGlyZXM9IjIwMDctMDEtMDFUMDE6NDQ6MzNa Ig0gICAgICAgbGFzdFVwZGF0ZWQ9IjIwMDYtMTEtMDFUMDE6MDA6MDBaIg0gICAgICAgc291 cmNlPSJhdXRob3JpdGF0aXZlLmV4YW1wbGUiDSAgICAgICBzb3VyY2VJZD0iN2UzZjQwYjA5 OGM3MTFkYmI2MDYwODAwMjAwYzlhNjYiPg0gICAgICAgPGRpc3BsYXlOYW1lIHhtbDpsYW5n PSJlbiI+DSAgICAgICAgIE5ldyBZb3JrIENpdHkgUG9saWNlIERlcGFydG1lbnQNICAgICAg IDwvZGlzcGxheU5hbWU+DSAgICAgICA8c2VydmljZT51cm46c2VydmljZTpzb3MucG9saWNl PC9zZXJ2aWNlPg0gICAgICAgPHNlcnZpY2VCb3VuZGFyeSBwcm9maWxlPSJnZW9kZXRpYy0y ZCI+DSAgICAgICAgIDxwMjpQb2x5Z29uIHNyc05hbWU9InVybjpvZ2M6ZGVmOjpjcnM6RVBT Rzo6NDMyNiI+DSAgICAgICAgICAgPHAyOmV4dGVyaW9yPg0gICAgICAgICAgICAgPHAyOkxp bmVhclJpbmc+DSAgICAgICAgICAgICAgIDxwMjpwb3M+MzcuNzc1IC0xMjIuNDE5NDwvcDI6 cG9zPg0gICAgICAgICAgICAgICA8cDI6cG9zPjM3LjU1NSAtMTIyLjQxOTQ8L3AyOnBvcz4N ICAgICAgICAgICAgICAgPHAyOnBvcz4zNy41NTUgLTEyMi40MjY0PC9wMjpwb3M+DSAgICAg ICAgICAgICAgIDxwMjpwb3M+MzcuNzc1IC0xMjIuNDI2NDwvcDI6cG9zPg0gICAgICAgICAg ICAgICA8cDI6cG9zPjM3Ljc3NSAtMTIyLjQxOTQ8L3AyOnBvcz4NICAgICAgICAgICAgIDwv cDI6TGluZWFyUmluZz4NICAgICAgICAgICA8L3AyOmV4dGVyaW9yPg0gICAgICAgICA8L3Ay OlBvbHlnb24+DSAgICAgICA8L3NlcnZpY2VCb3VuZGFyeT4NICAgICAgIDx1cmk+c2lwOm55 cGRAZXhhbXBsZS5jb208L3VyaT4NICAgICAgIDx1cmk+eG1wcDpueXBkQGV4YW1wbGUuY29t PC91cmk+DSAgICAgICA8c2VydmljZU51bWJlcj45MTE8L3NlcnZpY2VOdW1iZXI+DSAgICAg PC9tYXBwaW5nPg0gICAgIDxwYXRoPg0gICAgICAgPHZpYSBzb3VyY2U9ImF1dGhvcml0YXRp dmUuZXhhbXBsZSIvPg0gICAgICAgPHZpYSBzb3VyY2U9InJlc29sdmVyLmV4YW1wbGUiLz4N ICAgICA8L3BhdGg+DSAgICAgPGxvY2F0aW9uVXNlZCBpZD0iNjAyMDY4OGYxY2UxODk2ZCIv Pg0gICA8L2ZpbmRTZXJ2aWNlUmVzcG9uc2U+DQ0gICAgICAgICAgICAgRmlndXJlIDM6IEEg PGZpbmRTZXJ2aWNlUmVzcG9uc2U+IGdlb2RldGljIGFuc3dlcg0NOC4yLjIuICBDaXZpYyBB ZGRyZXNzIE1hcHBpbmcgRXhhbXBsZQ0NICAgVGhlIGV4YW1wbGUgYmVsb3cgc2hvd3MgaG93 IHRvIG1hcCBhIHNlcnZpY2UgdG8gYSBsb2NhdGlvbiBtdWNoIGxpa2UNICAgdGhlIGV4YW1w bGUgaW4gU2VjdGlvbiA4LjIuMSwgYnV0IHVzaW5nIGNpdmljIGFkZHJlc3MgbG9jYXRpb24N ICAgaW5mb3JtYXRpb24uICBJbiB0aGlzIGV4YW1wbGUsIHRoZSBjbGllbnQgcmVxdWVzdHMg dGhlIHNlcnZpY2UNICAgYXNzb2NpYXRlZCB3aXRoIHBvbGljZSAodXJuOnNlcnZpY2U6c29z LnBvbGljZSkgYWxvbmcgd2l0aCBhIHNwZWNpZmljDSAgIGNpdmljIGFkZHJlc3MgKGhvdXNl IG51bWJlciA2IG9uIGEgc3RyZWV0IG5hbWVkIE90dG8tSGFobi1SaW5nIGluDSAgIE11bmlj aCwgR2VybWFueSkuDQ0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNl bWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgMTddDQwNSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAy MDA3DQ0NICAgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NICAgPGZp bmRTZXJ2aWNlIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIg0gICAgIHJl Y3Vyc2l2ZT0idHJ1ZSIgc2VydmljZUJvdW5kYXJ5PSJ2YWx1ZSI+DSAgICAgPGxvY2F0aW9u IGlkPSI2MjdiOGJmODE5ZDBiYWQ0ZCIgcHJvZmlsZT0iY2l2aWMiPg0gICAgICAgPGNpdmlj QWRkcmVzcw0gICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpwaWRmOmdl b3ByaXYxMDpjaXZpY0FkZHIiPg0gICAgICAgICA8Y291bnRyeT5HZXJtYW55PC9jb3VudHJ5 Pg0gICAgICAgICA8QTE+QmF2YXJpYTwvQTE+DSAgICAgICAgIDxBMz5NdW5pY2g8L0EzPg0g ICAgICAgICA8QTY+T3R0by1IYWhuLVJpbmc8L0E2Pg0gICAgICAgICA8SE5PPjY8L0hOTz4N ICAgICAgICAgPFBDPjgxNjc1PC9QQz4NICAgICAgIDwvY2l2aWNBZGRyZXNzPg0gICAgIDwv bG9jYXRpb24+DSAgICAgPHNlcnZpY2U+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc2Vydmlj ZT4NICAgPC9maW5kU2VydmljZT4NDSAgICAgICAgICAgICAgIEZpZ3VyZSA0OiBBIDxmaW5k U2VydmljZT4gY2l2aWMgYWRkcmVzcyBxdWVyeQ0NICAgR2l2ZW4gdGhlIHF1ZXJ5IGFib3Zl LCBhIHNlcnZlciB3b3VsZCByZXNwb25kIHdpdGggYSBzZXJ2aWNlLCBhbmQNICAgaW5mb3Jt YXRpb24gcmVsYXRlZCB0byB0aGF0IHNlcnZpY2UuICBJbiB0aGUgZXhhbXBsZSBiZWxvdywg dGhlDSAgIHNlcnZlciBoYXMgbWFwcGVkIHRoZSBsb2NhdGlvbiBnaXZlbiBieSB0aGUgY2xp ZW50IGZvciBhIHBvbGljZQ0gICBzZXJ2aWNlIHRvIHRoZSBNdWVuY2hlbiBQb2xpemVpLUFi dGVpbHVuZywgaW5zdHJ1Y3RpbmcgdGhlIGNsaWVudA0gICB0aGF0IGl0IG1heSBjb250YWN0 IHRoZW0gdmlhIHRoZSBVUklzIHNpcDptdW5pY2gtcG9saWNlQGV4YW1wbGUuY29tDSAgIGFu ZCB4bXBwOm11bmljaC1wb2xpY2VAZXhhbXBsZS5jb20uICBUaGUgc2VydmVyIGhhcyBhbHNv IGdpdmVuIHRoZQ0gICBjbGllbnQgYSBjaXZpYyBhZGRyZXNzIGJvdW5kYXJ5ICh0aGUgY2l0 eSBvZiBNdW5pY2gpIGZvciB0aGlzDSAgIHNlcnZpY2UuICBUaGUgbWFwcGluZyB3YXMgbGFz dCB1cGRhdGVkIG9uIE5vdmVtYmVyIDEsIDIwMDYgYnkgdGhlDSAgIGF1dGhvcml0YXRpdmUg c291cmNlICJwb2xpemVpLm11ZW5jaGVuLmRlLmV4YW1wbGUiIGFuZCBleHBpcmVzIG9uDSAg IEphbnVhcnkgMSwgMjAwNy4gIFRoaXMgaW5zdHJ1Y3RzIHRoZSBjbGllbnQgdG8gcmVxdWVy eSBmb3IgdGhlDSAgIGluZm9ybWF0aW9uIGlmIGl0cyBsb2NhdGlvbiBjaGFuZ2VzIGJleW9u ZCB0aGUgZ2l2ZW4gc2VydmljZSBib3VuZGFyeQ0gICAoaS5lLiwgYmV5b25kIHRoZSBjaXR5 IG9mIE11bmljaCkgb3IgYWZ0ZXIgSmFudWFyeSAxLCAyMDA3Lg0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcg ICAgICAgICAgICAgIFtQYWdlIDE4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgIDw/eG1s IHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxmaW5kU2VydmljZVJlc3Bv bnNlIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIj4NICAgICA8bWFwcGlu Zw0gICAgICAgZXhwaXJlcz0iMjAwNy0wMS0wMVQwMTo0NDozM1oiDSAgICAgICBsYXN0VXBk YXRlZD0iMjAwNi0xMS0wMVQwMTowMDowMFoiDSAgICAgICBzb3VyY2U9ImVzZ3cudWViZXIt MTEwLmRlLmV4YW1wbGUiDSAgICAgICBzb3VyY2VJZD0iZThiMDVhNDFkOGQxNDE1YjgwZjJj ZGJiOTZjY2YxMDkiPg0gICAgICAgPGRpc3BsYXlOYW1lIHhtbDpsYW5nPSJkZSI+DSAgICAg ICAgIE11ZW5jaGVuIFBvbGl6ZWktQWJ0ZWlsdW5nDSAgICAgICA8L2Rpc3BsYXlOYW1lPg0g ICAgICAgPHNlcnZpY2U+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc2VydmljZT4NICAgICAg IDxzZXJ2aWNlQm91bmRhcnkNICAgICAgICAgcHJvZmlsZT0idXJuOmlldGY6cGFyYW1zOmxv c3Q6bG9jYXRpb24tcHJvZmlsZTpiYXNpYy1jaXZpYyI+DSAgICAgICAgIDxjaXZpY0FkZHJl c3MNICAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpwaWRmOmdlb3By aXYxMDpjaXZpY0FkZHIiPg0gICAgICAgICAgIDxjb3VudHJ5Pkdlcm1hbnk8L2NvdW50cnk+ DSAgICAgICAgICAgPEExPkJhdmFyaWE8L0ExPg0gICAgICAgICAgIDxBMz5NdW5pY2g8L0Ez Pg0gICAgICAgICAgIDxQQz44MTY3NTwvUEM+DSAgICAgICAgIDwvY2l2aWNBZGRyZXNzPg0g ICAgICAgPC9zZXJ2aWNlQm91bmRhcnk+DSAgICAgICA8dXJpPnNpcDptdW5pY2gtcG9saWNl QGV4YW1wbGUuY29tPC91cmk+DSAgICAgICA8dXJpPnhtcHA6bXVuaWNoLXBvbGljZUBleGFt cGxlLmNvbTwvdXJpPg0gICAgICAgPHNlcnZpY2VOdW1iZXI+MTEwPC9zZXJ2aWNlTnVtYmVy Pg0gICAgIDwvbWFwcGluZz4NICAgICA8cGF0aD4NICAgICAgIDx2aWEgc291cmNlPSJlc2d3 LnVlYmVyLTExMC5kZS5leGFtcGxlIi8+DSAgICAgICA8dmlhIHNvdXJjZT0icG9saXplaS5t dWVuY2hlbi5kZS5leGFtcGxlIi8+DSAgICAgPC9wYXRoPg0gICAgIDxsb2NhdGlvblVzZWQg aWQ9IjYyN2I4YmY4MTlkMGJhZDRkIi8+DSAgIDwvZmluZFNlcnZpY2VSZXNwb25zZT4NDSAg ICAgICAgICBGaWd1cmUgNTogQSA8ZmluZFNlcnZpY2VSZXNwb25zZT4gY2l2aWMgYWRkcmVz cyBhbnN3ZXINDTguMy4gIENvbXBvbmVudHMgb2YgdGhlIDxmaW5kU2VydmljZT4gUmVxdWVz dA0NICAgVGhlIDxmaW5kU2VydmljZT4gcmVxdWVzdCBpbmNsdWRlcyBhdHRyaWJ1dGVzIHRo YXQgZ292ZXJuIHdoZXRoZXIgdGhlDSAgIHJlcXVlc3QgaXMgaGFuZGxlZCBpdGVyYXRpdmVs eSBvciByZWN1cnNpdmVseSwgd2hldGhlciBsb2NhdGlvbg0gICB2YWxpZGF0aW9uIGlzIHBl cmZvcm1lZCBhbmQgd2hpY2ggZWxlbWVudHMgbWF5IGJlIGNvbnRhaW5lZCBpbiB0aGUNICAg cmVzcG9uc2UuDQ04LjMuMS4gIFRoZSA8bG9jYXRpb24+IEVsZW1lbnQNDSAgIFRoZSA8Zmlu ZFNlcnZpY2U+IHF1ZXJ5IGNvbW11bmljYXRlcyBsb2NhdGlvbiBpbmZvcm1hdGlvbiB1c2lu ZyBvbmUNICAgb3IgbW9yZSA8bG9jYXRpb24+IGVsZW1lbnRzLCB3aGljaCBNVVNUIGNvbmZv cm0gdG8gYSBsb2NhdGlvbiBwcm9maWxlDSAgIChzZWUgU2VjdGlvbiAxMikuICBUaGVyZSBN VVNUIE5PVCBiZSBtb3JlIHRoYW4gb25lIGxvY2F0aW9uIGVsZW1lbnQNICAgZm9yIGVhY2gg ZGlzdGluY3QgbG9jYXRpb24gcHJvZmlsZS4gIFRoZSBvcmRlciBvZiBsb2NhdGlvbiBvYmpl Y3RzIGlzDSAgIHNpZ25pZmljYW50OyB0aGUgc2VydmVyIHVzZXMgdGhlIGZpcnN0IGxvY2F0 aW9uIG9iamVjdCB3aGVyZSBpdA0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAxOV0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBK dW5lIDIwMDcNDQ0gICB1bmRlcnN0YW5kcyB0aGUgbG9jYXRpb24gcHJvZmlsZS4NDTguMy4y LiAgSWRlbnRpZnlpbmcgdGhlIFNlcnZpY2U6ICBUaGUgPHNlcnZpY2U+IEVsZW1lbnQNDSAg IFRoZSB0eXBlIG9mIHNlcnZpY2UgZGVzaXJlZCBpcyBzcGVjaWZpZWQgYnkgdGhlIDxzZXJ2 aWNlPiBlbGVtZW50Lg0gICBJdCBjb250YWlucyBzZXJ2aWNlIFVSTnMgZnJvbSB0aGUgcmVn aXN0cnkgZXN0YWJsaXNoZWQgaW4gWzhdLg0NOC4zLjMuICBSZWN1cnNpb24gYW5kIEl0ZXJh dGlvbg0NICAgTG9TVCBjYW4gb3BlcmF0ZSBpbiBlaXRoZXIgcmVjdXJzaXZlIG9yIGl0ZXJh dGl2ZSBtb2RlLCBvbiBhIHJlcXVlc3QtDSAgIGJ5LXJlcXVlc3QgYmFzaXMuICBJbiByZWN1 cnNpdmUgbW9kZSwgdGhlIExvU1Qgc2VydmVyIGluaXRpYXRlcw0gICBxdWVyaWVzIG9uIGJl aGFsZiBvZiB0aGUgcmVxdWVzdGVyIGFuZCByZXR1cm5zIHRoZSByZXN1bHQgdG8gdGhlDSAg IHJlcXVlc3Rlci4NDSAgIEluIGl0ZXJhdGl2ZSBtb2RlLCB0aGUgc2VydmVyIGNvbnRhY3Rl ZCByZXR1cm5zIGEgcmVkaXJlY3Rpb24NICAgcmVzcG9uc2UgaW5kaWNhdGluZyB0aGUgbmV4 dCBzZXJ2ZXIgdG8gYmUgcXVlcmllZCBpZiB0aGUgc2VydmVyDSAgIGNvbnRhY3RlZCBjb25u b3QFIHByb3ZpZGUgYW4gYW5zd2VyIGl0c2VsZi4NDSAgIEZvciB0aGUgcXVlcmllcyBkZWZp bmVkIGluIHRoaXMgZG9jdW1lbnQsIG9ubHkgTG9TVCA8ZmluZFNlcnZpY2U+IGFuZA0gICA8 bGlzdFNlcnZpY2VzQnlMb2NhdGlvbj4gcXVlcmllcyBjYW4gYmUgcmVjdXJzaXZlLCBhcyBp bmRpY2F0ZWQgYnkNICAgdGhlICdyZWN1cnNpdmUnIGF0dHJpYnV0ZS4gIEEgdmFsdWUgb2Yg InRydWUiIGluZGljYXRlcyBhIHJlY3Vyc2l2ZQ0gICBxdWVyeSwgd2l0aCB0aGUgZGVmYXVs dCBiZWluZyAiZmFsc2UiIHdoZW4gdGhlIGF0dHJpYnV0ZSBpcyBvbWl0dGVkLg0gICBSZWdh cmRsZXNzIG9mIHRoZSBhdHRyaWJ1dGUsIGEgc2VydmVyIE1BWSBhbHdheXMgYW5zd2VyIGEg cXVlcnkgYnkNICAgcHJvdmlkaW5nIGEgTG9TVCBhcHBsaWNhdGlvbiB1bmlxdWUgc3RyaW5n IChzZWUgU2VjdGlvbiA0KSwgaS5lLiwNICAgaW5kaXJlY3Rpb24sIGhvd2V2ZXIsIGl0IE1V U1QgTk9UIHJlY3Vyc2UgaWYgdGhlIGF0dHJpYnV0ZSBpcw0gICAiZmFsc2UiLg0NOC4zLjQu ICBTZXJ2aWNlIEJvdW5kYXJ5DQ0gICBMb1NUIDxtYXBwaW5nPiBlbGVtZW50cyBjYW4gZGVz Y3JpYmUgdGhlIHNlcnZpY2UgYm91bmRhcnkgZWl0aGVyIGJ5DSAgIHZhbHVlIG9yIGJ5IHJl ZmVyZW5jZS4gIFJldHVybmluZyBhIHNlcnZpY2UgYm91bmRhcnkgcmVmZXJlbmNlIGlzDSAg IGdlbmVyYWxseSBtb3JlIHNwYWNlLWVmZmljaWVudCBmb3IgZ2Vvc3BhdGlhbCAocG9seWdv bikgYm91bmRhcmllcw0gICBhbmQgaWYgdGhlIGJvdW5kYXJpZXMgY2hhbmdlIHJhcmVseSwg YnV0IGRvZXMgaW5jdXIgYW4gYWRkaXRpb25hbA0gICA8Z2V0U2VydmljZUJvdW5kYXJ5PiBy ZXF1ZXN0LiAgVGhlIHF1ZXJpZXIgY2FuIGV4cHJlc3MgYSBwcmVmZXJlbmNlDSAgIGZvciBv bmUgb3IgdGhlIG90aGVyIG1vZGFsaXR5IHdpdGggdGhlICdzZXJ2aWNlQm91bmRhcnknIGF0 dHJpYnV0ZSBpbg0gICB0aGUgPGZpbmRTZXJ2aWNlPiByZXF1ZXN0LCBidXQgdGhlIHNlcnZl ciBtYWtlcyB0aGUgZmluYWwgZGVjaXNpb24gYXMNICAgdG8gd2hldGhlciB0byByZXR1cm4g YSByZWZlcmVuY2Ugb3IgYSB2YWx1ZS4NDTguMy41LiAgUmVxdWVzdGluZyBDaXZpYyBMb2Nh dGlvbiBWYWxpZGF0aW9uDQ0gICBDaXZpYyBhZGRyZXNzIHZhbGlkYXRpb24gaXMgcmVxdWVz dGVkIGJ5IHNldHRpbmcgdGhlIG9wdGlvbmFsDSAgIGF0dHJpYnV0ZSAndmFsaWRhdGVMb2Nh dGlvbicgdG8gdHJ1ZS4gIElmIHRoZSBhdHRyaWJ1dGUgaXMgb21pdHRlZCwNICAgaXQgaXMg YXNzdW1lZCB0byBiZSBmYWxzZS4gIFRoZSByZXNwb25zZSBpcyBkZXNjcmliZWQgaW4NICAg U2VjdGlvbiA4LjQuMi4gIFRoZSBleGFtcGxlIGluIEZpZ3VyZSA2IGRlbW9uc3RyYXRlcyBh ZGRyZXNzDSAgIHZhbGlkYXRpb24sIG9taXR0aW5nIHRoZSBzdGFuZGFyZCByZXNwb25zZSBl bGVtZW50cy4gIElmIHRoZSBzZXJ2ZXINICAgY2hvb3NlcyBhIGdlb2RldGljIGxvY2F0aW9u IGFtb25nIHRoZSBsb2NhdGlvbnMgcHJvdmlkZWQgaW4gYQ0gICByZXF1ZXN0LCB0aGUgYXR0 cmlidXRlIGlzIGlnbm9yZWQuDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVz IERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAyMF0NDA1JbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBK dW5lIDIwMDcNDQ0gICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0g ICA8ZmluZFNlcnZpY2UNICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpsb3N0 MSINICAgICByZWN1cnNpdmU9InRydWUiDSAgICAgdmFsaWRhdGVMb2NhdGlvbj0idHJ1ZSIN ICAgICBzZXJ2aWNlQm91bmRhcnk9InZhbHVlIj4NICAgICA8bG9jYXRpb24gaWQ9IjYyN2I4 YmY4MTlkMGJhZDRkIiBwcm9maWxlPSJjaXZpYyI+DSAgICAgICA8Y2l2aWNBZGRyZXNzDSAg ICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnBpZGY6Z2VvcHJpdjEwOmNp dmljQWRkciI+DSAgICAgICAgIDxjb3VudHJ5PkRFPC9jb3VudHJ5Pg0gICAgICAgICA8QTE+ QmF2YXJpYTwvQTE+DSAgICAgICAgIDxBMz5NdW5pY2g8L0EzPg0gICAgICAgICA8QTY+T3R0 by1IYWhuLVJpbmc8L0E2Pg0gICAgICAgICA8SE5PPjY8L0hOTz4NICAgICAgICAgPFBDPjgx Njc1PC9QQz4NICAgICAgIDwvY2l2aWNBZGRyZXNzPg0gICAgIDwvbG9jYXRpb24+DSAgICAg PHNlcnZpY2U+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc2VydmljZT4NICAgPC9maW5kU2Vy dmljZT4NDSAgICAgIEZpZ3VyZSA2OiBBIDxmaW5kU2VydmljZT4gcXVlcnkgd2l0aCBhZGRy ZXNzIHZhbGlkYXRpb24gcmVxdWVzdA0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1I YXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAg ICAgICAgICBbUGFnZSAyMV0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg TG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICA8P3htbCB2ZXJz aW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0gICA8ZmluZFNlcnZpY2VSZXNwb25zZSB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpsb3N0MSI+DSAgICAgPG1hcHBpbmcNICAg ICAgIGV4cGlyZXM9IjIwMDctMDEtMDFUMDE6NDQ6MzNaIg0gICAgICAgbGFzdFVwZGF0ZWQ9 IjIwMDYtMTEtMDFUMDE6MDA6MDBaIg0gICAgICAgc291cmNlPSJhdXRob3JpdGF0aXZlLmV4 YW1wbGUiDSAgICAgICBzb3VyY2VJZD0iNGRiODk4ZGY1MmI4NGVkZmE5YjY0NDVlYThhMDMy OGUiPg0gICAgICAgPGRpc3BsYXlOYW1lIHhtbDpsYW5nPSJkZSI+DSAgICAgICAgIE11ZW5j aGVuIFBvbGl6ZWktQWJ0ZWlsdW5nDSAgICAgICA8L2Rpc3BsYXlOYW1lPg0gICAgICAgPHNl cnZpY2U+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc2VydmljZT4NICAgICAgIDxzZXJ2aWNl Qm91bmRhcnkgcHJvZmlsZT0iY2l2aWMiPg0gICAgICAgICA8Y2l2aWNBZGRyZXNzDSAgICAg ICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6cGlkZjpnZW9wcml2MTA6Y2l2 aWNBZGRyIj4NICAgICAgICAgICA8Y291bnRyeT5HZXJtYW55PC9jb3VudHJ5Pg0gICAgICAg ICAgIDxBMT5CYXZhcmlhPC9BMT4NICAgICAgICAgICA8QTM+TXVuaWNoPC9BMz4NICAgICAg ICAgICA8UEM+ODE2NzU8L1BDPg0gICAgICAgICA8L2NpdmljQWRkcmVzcz4NICAgICAgIDwv c2VydmljZUJvdW5kYXJ5Pg0gICAgICAgPHVyaT5zaXA6bXVuaWNoLXBvbGljZUBleGFtcGxl LmNvbTwvdXJpPg0gICAgICAgPHVyaT54bXBwOm11bmljaC1wb2xpY2VAZXhhbXBsZS5jb208 L3VyaT4NICAgICAgIDxzZXJ2aWNlTnVtYmVyPjExMDwvc2VydmljZU51bWJlcj4NICAgICA8 L21hcHBpbmc+DSAgICAgPGxvY2F0aW9uVmFsaWRhdGlvbj4NICAgICAgIDx2YWxpZD5jb3Vu dHJ5IEExIEEzIEE2PC92YWxpZD4NICAgICAgIDxpbnZhbGlkPlBDPC9pbnZhbGlkPg0gICAg IDwvbG9jYXRpb25WYWxpZGF0aW9uPg0gICAgIDxwYXRoPg0gICAgICAgPHZpYSBzb3VyY2U9 ImF1dGhvcml0YXRpdmUuZXhhbXBsZSIvPg0gICAgICAgPHZpYSBzb3VyY2U9InJlc29sdmVy LmV4YW1wbGUiLz4NICAgICA8L3BhdGg+DSAgICAgPGxvY2F0aW9uVXNlZCBpZD0iNjI3Yjhi ZjgxOWQwYmFkNGQiLz4NICAgPC9maW5kU2VydmljZVJlc3BvbnNlPg0NICAgICBGaWd1cmUg NzogQSA8ZmluZFNlcnZpY2VSZXNwb25zZT4gbWVzc2FnZSB3aXRoIGFkZHJlc3MgdmFsaWRh dGlvbg0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZm9ybWF0aW9uDQ04LjQu ICBDb21wb25lbnRzIG9mIHRoZSBNYXBwaW5nIFJlc3BvbnNlIDxmaW5kU2VydmljZVJlc3Bv bnNlPg0NOC40LjEuICBPdmVydmlldw0NICAgTWFwcGluZyByZXNwb25zZXMgY29uc2lzdCBv ZiB0aGUgPG1hcHBpbmc+IGVsZW1lbnQgKFNlY3Rpb24gNSkNICAgZGVzY3JpYmluZyB0aGUg bWFwcGluZyBpdHNlbGYsIHBvc3NpYmx5IGZvbGxvd2VkIGJ5IHdhcm5pbmdzDSAgIChTZWN0 aW9uIDEzLjIpLCBsb2NhdGlvbiB2YWxpZGF0aW9uIGluZm9ybWF0aW9uIChTZWN0aW9uIDgu NC4yKSwgYW5kDSAgIGFuIGluZGljYXRpb24gb2YgdGhlIHBhdGggKFNlY3Rpb24gNikgdGhl IHJlc3BvbnNlIGhhcyB0YWtlbi4NDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAyMl0NDA1JbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAg ICBKdW5lIDIwMDcNDQ04LjQuMi4gIENpdmljIEFkZHJlc3MgVmFsaWRhdGlvbjogIHRoZSA8 bG9jYXRpb25WYWxpZGF0aW9uPiBFbGVtZW50BQ0NICAgQSBzZXJ2ZXIgY2FuIGluZGljYXRl IGluIGl0cyByZXNwb25zZSB3aGljaCBjaXZpYyBhZGRyZXNzIGVsZW1lbnRzIGl0DSAgIGhh cyByZWNvZ25pemVkIGFzIHZhbGlkLCB3aGljaCBvbmVzIGl0IGhhcyBpZ25vcmVkIGFuZCB3 aGljaCBvbmVzIGl0DSAgIGhhcyBjaGVja2VkIGFuZCBmb3VuZCB0byBiZSBpbnZhbGlkLiAg VGhlIHNlcnZlciBTSE9VTEQgaW5jbHVkZSB0aGlzDSAgIGluZm9ybWF0aW9uIGlmIHRoZSAn dmFsaWRhdGVMb2NhdGlvbicgYXR0cmlidXRlIGluIHRoZSByZXF1ZXN0IHdhcw0gICB0cnVl OyBidXQgbG9jYWwgcG9saWN5IGF0IHRoZSBzZXJ2ZXIgbWF5IGFsbG93IHRoaXMgaW5mb3Jt YXRpb24gdG8gYmUNICAgb21pdHRlZC4gIEVhY2ggZWxlbWVudCBjb250YWlucyBhIGxpc3Qg b2YgdG9rZW5zIHNlcGFyYXRlZCBieSB3aGl0ZQ0gICBzcGFjZSwgZW51bWVyYXRpbmcgdGhl IGNpdmljIGxvY2F0aW9uIGxhYmVscyB1c2VkIGluIGNoaWxkIGVsZW1lbnRzDSAgIG9mIHRo ZSA8Y2l2aWNBZGRyZXNzPiBlbGVtZW50LiAgVGhlIDx2YWxpZD4gZWxlbWVudCBlbnVtZXJh dGVzIHRob3NlDSAgIGNpdmljIGFkZHJlc3MgZWxlbWVudHMgdGhhdCBoYXZlIGJlZW4gcmVj b2duaXplZCBhcyB2YWxpZCBieSB0aGUgTG9TVA0gICBzZXJ2ZXIgYW5kIHRoYXQgaGF2ZSBi ZWVuIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBtYXBwaW5nLiAgVGhlDSAgIDx1bmNoZWNrZWQF PiBlbGVtZW50cyBlbnVtZXJhdGVzIHRoZSBjaXZpYyBhZGRyZXNzIGVsZW1lbnRzIHRoYXQg dGhlDSAgIHNlcnZlciBkaWQgbm90IGNoZWNrIGFuZCB0aGF0IHdlcmUgbm90IHVzZWQgaW4g ZGV0ZXJtaW5pbmcgdGhlDSAgIHJlc3BvbnNlLiAgVGhlIDxpbnZhbGlkPiBlbGVtZW50IGVu dW1lcmF0ZSBjaXZpYyBhZGRyZXNzIGVsZW1lbnRzDSAgIHRoYXQgdGhlIHNlcnZlciBhdHRl bXB0ZWQgdG8gY2hlY2ssIGJ1dCB0aGF0IGRpZCBub3QgbWF0Y2ggdGhlIG90aGVyDSAgIGNp dmljIGFkZHJlc3MgZWxlbWVudHMgZm91bmQgaW4gdGhlIDx2YWxpZD4gbGlzdC4NDSAgIE5v dGUgdGhhdCB0aGUgc2FtZSBhZGRyZXNzIGNhbiB5aWVsZCBkaWZmZXJlbnQgcmVzcG9uc2Vz IGlmIHBhcnRzIG9mBQ0gICB0aGUgY2l2aWMgYWRkcmVzcyBjb250cmFkaWN0IGVhY2ggb3Ro ZXIuICBGb3IgZXhhbXBsZSwgaWYgdGhlIHBvc3RhbA0gICBjb2RlIGRvZXMgbm90IG1hdGNo IHRoZSBjaXR5LCBsb2NhbCBzZXJ2ZXIgcG9saWN5IGRldGVybWluZXMgd2hldGhlcg0gICB0 aGUgcG9zdGFsIGNvZGUgb3IgdGhlIGNpdHkgaXMgY29uc2lkZXJlZCB2YWxpZC4gIFRoZSBt YXBwaW5nDSAgIG5hdHVyYWxseSBjb3JyZXNwb25kcyB0byB0aGUgdmFsaWQgZWxlbWVudHMu DQ0gICBUaGUgZXhhbXBsZSAoRmlndXJlIDYpIAVpbmRpY2F0ZXMgdGhhdCB0aGUgdG9rZW5z ICdjb3VudHJ5JywgJ0ExJywNICAgJ0EzJywgYW5kICdBNicFIGhhdmUgYmVlbiB2YWxpZGF0 ZWQgYnkgdGhlIExvU1Qgc2VydmVyLiAgVGhlIHNlcnZlcg0gICBjb25zaWRlcmVkIHRoZSBw b3N0YWwgY29kZSA4MTY3NSBpbiB0aGUgPFBDPiBlbGVtZW50IGFzIG5vdCB2YWxpZCBmb3IN ICAgdGhpcyBsb2NhdGlvbi4NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFn ZSAyM10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAg ICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ05LiAgUmV0cmlldmluZyB0aGUgU2Vydmlj ZSBCb3VuZGFyeSB2aWEgPGdldFNlcnZpY2VCb3VuZGFyeT4NDSAgIEFzIGRpc2N1c3NlZCBp biBTZWN0aW9uIDUuNSwgdGhlIDxmaW5kU2VydmljZVJlc3BvbnNlPiBjYW4gcmV0dXJuIGEN ICAgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZpZXIgaW4gdGhlICdzZXJ2aWNlQm91bmRhcnkn IGF0dHJpYnV0ZSB0aGF0DSAgIGNhbiBiZSB1c2VkIHRvIHJldHJpZXZlIHRoZSBzZXJ2aWNl IGJvdW5kYXJ5LCByYXRoZXIgdGhhbiByZXR1cm5pbmcNICAgdGhlIGJvdW5kYXJ5IGJ5IHZh bHVlLiAgVGhpcyBpcyBzaG93biBpbiB0aGUgZXhhbXBsZSBpbiBGaWd1cmUgOC4FDSAgIFRo ZSBjbGllbnQgY2FuIHRoZW4gcmV0cmlldmUgdGhlIGJvdW5kYXJ5IHVzaW5nIHRoZQ0gICA8 Z2V0U2VydmljZUJvdW5kYXJ5PiByZXF1ZXN0IGFuZCBvYnRhaW5zIHRoZSBib3VuZGFyeSBp biB0aGUNICAgPGdldFNlcnZpY2VCb3VuZGFyeVJlc3BvbnNlPiwgaWxsdXN0cmF0ZWQgaW4g dGhlIGV4YW1wbGUgaW4NICAgRmlndXJlIDEwLiAgVGhlIGNsaWVudCBpc3N1ZXMgdGhlIHJl cXVlc3QgdG8gdGhlIHNlcnZlciBpZGVudGlmaWVkIGluDSAgIHRoZSAnc2VydmVyJwUgYXR0 cmlidXRlIG9mIHRoZSA8c2VydmljZUJvdW5kYXJ5UmVmZXJlbmNlPiBlbGVtZW50Lg0gICBU aGVzZSByZXF1ZXN0cyBhcmUgYWx3YXlzIGRpcmVjdGVkIHRvIHRoZSBhdXRob3JpdGF0aXZl IHNlcnZlciBhbmQgZG8NICAgbm90IHJlY3Vyc2UuDQ0NDSAgIDw/eG1sIHZlcnNpb249IjEu MCIgZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxmaW5kU2VydmljZQ0gICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIg0gICAgIHhtbG5zOnAyPSJodHRwOi8vd3d3Lm9w ZW5naXMubmV0L2dtbCINICAgICByZWN1cnNpdmU9InRydWUiDSAgICAgc2VydmljZUJvdW5k YXJ5PSJyZWZlcmVuY2UiPg0gICAgIDxsb2NhdGlvbiBpZD0iNjAyMDY4OGYxY2UxODk2ZCIg cHJvZmlsZT0iZ2VvZGV0aWMtMmQiPg0gICAgICAgPHAyOlBvaW50IGlkPSJwb2ludDEiIHNy c05hbWU9InVybjpvZ2M6ZGVmOmNyczpFUFNHOjo0MzI2Ij4NICAgICAgICAgIDxwMjpwb3M+ MzcuNzc1IC0xMjIuNDIyPC9wMjpwb3M+DSAgICAgICA8L3AyOlBvaW50Pg0gICAgIDwvbG9j YXRpb24+DSAgICAgPHNlcnZpY2U+dXJuOnNlcnZpY2U6c29zLnBvbGljZTwvc2VydmljZT4N ICAgPC9maW5kU2VydmljZT4NDSAgICBGaWd1cmUgODogPGZpbmRTZXJ2aWNlPiByZXF1ZXN0 IGFuZCByZXNwb25zZSB3aXRoIHNlcnZpY2UgYm91bmRhcnkNICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcmVmZXJlbmNlDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBb UGFnZSAyNF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAg ICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICA8P3htbCB2ZXJzaW9uPSIxLjAi IGVuY29kaW5nPSJVVEYtOCI/Pg0gICA8ZmluZFNlcnZpY2VSZXNwb25zZSB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczpsb3N0MSINICAgICB4bWxuczpwMj0iaHR0cDovL3d3dy5v cGVuZ2lzLm5ldC9nbWwiPg0gICAgIDxtYXBwaW5nDSAgICAgICBleHBpcmVzPSIyMDA3LTAx LTAxVDAxOjQ0OjMzWiINICAgICAgIGxhc3RVcGRhdGVkPSIyMDA2LTExLTAxVDAxOjAwOjAw WiINICAgICAgIHNvdXJjZT0iYXV0aG9yaXRhdGl2ZS5leGFtcGxlIg0gICAgICAgc291cmNl SWQ9IjdlM2Y0MGIwOThjNzExZGJiNjA2MDgwMDIwMGM5YTY2Ij4NICAgICAgIDxkaXNwbGF5 TmFtZSB4bWw6bGFuZz0iZW4iPg0gICAgICAgICBOZXcgWW9yayBDaXR5IFBvbGljZSBEZXBh cnRtZW50DSAgICAgICA8L2Rpc3BsYXlOYW1lPg0gICAgICAgPHNlcnZpY2U+dXJuOnNlcnZp Y2U6c29zLnBvbGljZTwvc2VydmljZT4NICAgICAgIDxzZXJ2aWNlQm91bmRhcnlSZWZlcmVu Y2UNICAgICAgICAgc291cmNlPSJhdXRob3JpdGF0aXZlLmV4YW1wbGUiDSAgICAgICAgIGtl eT0iNzIxNDE0OEUwNDMzQUZFMkZBMkQ0ODAwM0QzMTE3MkUiIC8+DSAgICAgICA8dXJpPnNp cDpueXBkQGV4YW1wbGUuY29tPC91cmk+DSAgICAgICA8dXJpPnhtcHA6bnlwZEBleGFtcGxl LmNvbTwvdXJpPg0gICAgICAgPHNlcnZpY2VOdW1iZXI+OTExPC9zZXJ2aWNlTnVtYmVyPg0g ICAgIDwvbWFwcGluZz4NICAgICA8cGF0aD4NICAgICAgIDx2aWEgc291cmNlPSJhdXRob3Jp dGF0aXZlLmV4YW1wbGUiLz4NICAgICAgIDx2aWEgc291cmNlPSJyZXNvbHZlci5leGFtcGxl Ii8+DSAgICAgPC9wYXRoPg0gICAgIDxsb2NhdGlvblVzZWQgaWQ9IjYwMjA2ODhmMWNlMTg5 NmQiLz4NICAgPC9maW5kU2VydmljZVJlc3BvbnNlPg0NICAgICAgIEZpZ3VyZSA5OiA8Zmlu ZFNlcnZpY2VSZXNwb25zZT4gbWVzc2FnZSB3aXRoIHNlcnZpY2UgYm91bmRhcnkNICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgcmVmZXJlbmNlDQ0NDSAgIDw/eG1sIHZlcnNp b249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxnZXRTZXJ2aWNlQm91bmRhcnkgeG1s bnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiDSAgICAgICBrZXk9IjcyMTQxNDhF MDQzM0FGRTJGQTJENDgwMDNEMzExNzJFIi8+DQ0gICAgRmlndXJlIDEwOiBSZXF1ZXN0aW5n IGEgc2VydmljZSBib3VuZGFyeSB3aXRoIDxnZXRTZXJ2aWNlQm91bmRhcnk+DQ0gICBUaGUg PGdldFNlcnZpY2VCb3VuZGFyeT4gcmVxdWVzdCBtYXkgYWxzbyBiZSB1c2VkIHRvIHJldHJp ZXZlIHNlcnZpY2UNICAgYm91bmRhcmllcyB0aGF0IGFyZSBleHByZXNzZWQgYXMgY2l2aWMg YWRkcmVzc2VzLCBhcyBpbGx1c3RyYXRlZCBpbg0gICBGaWd1cmUgMTEuDQ0NDQ0NDQ0NDQ0N SGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAg ICAgICAgICAgW1BhZ2UgMjVdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAg IExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NICAgPD94bWwgdmVy c2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NICAgPGdldFNlcnZpY2VCb3VuZGFyeVJl c3BvbnNlDSAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiPg0gICAg IDxzZXJ2aWNlQm91bmRhcnkgcHJvZmlsZT0iY2l2aWMiPg0gICAgIDxjaXZpY0FkZHJlc3MN ICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOnBpZGY6Z2VvcHJpdjEwOmNp dmljQWRkciI+DSAgICAgICAgIDxjb3VudHJ5PlVTPC9jb3VudHJ5Pg0gICAgICAgICA8QTE+ TmV3IFlvcms8L0ExPg0gICAgICAgICA8QTM+TmV3IFlvcms8L0EzPgUNICAgICAgIDwvY2l2 aWNBZGRyZXNzPg0gICAgIDwvc2VydmljZUJvdW5kYXJ5Pg0gICAgIDxwYXRoPg0gICAgICAg PHZpYSBzb3VyY2U9ImF1dGhvcml0YXRpdmUuZXhhbXBsZSIvPg0gICAgICAgPHZpYSBzb3Vy Y2U9InJlc29sdmVyLmV4YW1wbGUiLz4NICAgICA8L3BhdGg+DSAgIDwvZ2V0U2VydmljZUJv dW5kYXJ5UmVzcG9uc2U+DQ0gICAgICAgICAgICBGaWd1cmUgMTE6IENpdmljIEFkZHJlc3Mg U2VydmljZSBCb3VuZGFyeSBSZXNwb25zZQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3 ICAgICAgICAgICAgICBbUGFnZSAyNl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAg ICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0xMC4gIExp c3QgU2VydmljZXM6IDxsaXN0U2VydmljZXM+DQ0gICBBIExvU1QgY2xpZW50IGNhbiBhc2sg YSBMb1NUIHNlcnZlciBmb3IgdGhlIGxpc3Qgb2Ygc2VydmljZXMgdGhhdCBpdA0gICB1bmRl cnN0YW5kcywgcHJpbWFyaWx5IGZvciBkaWFnbm9zdGljIHB1cnBvc2VzLiAgVGhlIHF1ZXJ5 IGRvZXMgbm90DSAgIGNvbnRhaW4gbG9jYXRpb24gaW5mb3JtYXRpb24sIGFzIGl0IHNpbXBs eSBwcm92aWRlcyBhbiBpbmRpY2F0aW9uIG9mDSAgIHdoaWNoIHNlcnZpY2VzIHRoZSBzZXJ2 ZXIgY2FuIGxvb2sgdXAsIG5vdCB3aGV0aGVyIGEgcGFydGljdWxhcg0gICBzZXJ2aWNlIGlz IG9mZmVyZWQgZm9yIGEgcGFydGljdWxhciBhcmVhLiAgVHlwaWNhbGx5LCBvbmx5IHRvcC1s ZXZlbA0gICBzZXJ2aWNlcyBhcmUgaW5jbHVkZWQgaW4gdGhlIGFuc3dlciwgaW1wbHlpbmcg c3VwcG9ydCBmb3IgYWxsIHN1Yi0NICAgc2VydmljZXMuICBTaW5jZSB0aGUgcXVlcnkgaXMg YW5zd2VyZWQgYnkgdGhlIHF1ZXJpZWQgc2VydmVyLCB0aGVyZQ0gICBpcyBubyBub3Rpb24g b2YgcmVjdXJzaW9uIG9yIGluZGlyZWN0aW9uIGFuZCBubyBwYXRoIGluZGljYXRpb24uICBU aGUNICAgPGxpc3RTZXJ2aWNlc0J5TG9jYXRpb24+IChTZWN0aW9uIDExKSBxdWVyeSBiZWxv dyBjYW4gYmUgdXNlZCB0byBmaW5kDSAgIG91dCB3aGV0aGVyIGEgcGFydGljdWxhciBzZXJ2 aWNlIGlzIG9mZmVyZWQgZm9yIGEgc3BlY2lmaWMgbG9jYXRpb24uDSAgIEFuIGV4YW1wbGUg cmVxdWVzdCBhbmQgcmVzcG9uc2UgYXJlIHNob3duIGluIEZpZ3VyZSAxMi4NDVFVRVNUSU9O Pw1JIHVuZGVyc3RhbmQgdGhlIGZvZHVjIG9mIHRoaXMgZG9jdW1lbnQgb24gZW1lcmdlbmN5 IHNlcnZpY2VzLiBJcyB0aGVyZSBhbnkgcGxhbm5lZCBub3Rpb24gb2Ygb3JnYW5pemluZyB2 YWx1ZSBhZGRlZCBzZXJ2aWNlcz8gU29tZSBzZXJ2aWNlIGhhdmUgYWxyZWFkeSBiZWVuIGRl ZmluZWQgaW4gdGhlIDNHUFAgc3BlY2lmaWNhdGlvbiBUUy0yMi0wNzEuIFRoaXMgaXMgbm90 IGFuIGV4aGF1c3RpdmUgbGlzdCBob3dldmVyLCBoYXZpbmcgdG9wLWxldmVsIFVSTnMgZGVm aW5lZCBmb3IgdGhlIHNlcnZpY2UgY2F0ZWdvcnkgd291bGQgcmVkdWNlIGxpa2VsaWhvb2Qg b2YgcHJvcHJpZXRhcnkgY2x1dHRlciBkZXZlbG9waW5nIGxhdGVyLg0NDQ0gICA8P3htbCB2 ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0gICA8bGlzdFNlcnZpY2VzDSAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiPg0gICAgIDxzZXJ2aWNlPnVy bjpzZXJ2aWNlOnNvczwvc2VydmljZT4NICAgPC9saXN0U2VydmljZXM+DQ0gICAgICAgICAg ICAgICAgRmlndXJlIDEyOiBFeGFtcGxlIG9mIDxMaXN0U2VydmljZXM+IHF1ZXJ5DQ0NDSAg IDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxsaXN0U2Vydmlj ZXNSZXNwb25zZQ0gICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiPg0g ICAgPHNlcnZpY2VMaXN0Pg0gICAgIHVybjpzZXJ2aWNlOnNvcy5hbWJ1bGFuY2UNICAgICB1 cm46c2VydmljZTpzb3MuYW5pbWFsLWNvbnRyb2wNICAgICB1cm46c2VydmljZTpzb3MuZmly ZQ0gICAgIHVybjpzZXJ2aWNlOnNvcy5nYXMNICAgICB1cm46c2VydmljZTpzb3MubW91bnRh aW4NICAgICB1cm46c2VydmljZTpzb3MubWFyaW5lDSAgICAgdXJuOnNlcnZpY2U6c29zLnBo eXNpY2lhbg0gICAgIHVybjpzZXJ2aWNlOnNvcy5wb2lzb24NICAgICB1cm46c2VydmljZTpz b3MucG9saWNlDSAgICAgdXJuOnNlcnZpY2U6c29zLnN1aWNpZGUNICAgIDwvc2VydmljZUxp c3Q+DSAgIDwvbGlzdFNlcnZpY2VzUmVzcG9uc2U+DQ0gICAgICAgICAgICAgICAgRmlndXJl IDEzOiBFeGFtcGxlIG9mIDxMaXN0U2VydmljZVJlc3BvbnNlPg0NDQ0NDQ0NSGFyZGllLCBl dCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAg W1BhZ2UgMjddDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAg ICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NMTEuICBMaXN0IFNlcnZpY2VzIEJ5 IExvY2F0aW9uOiA8bGlzdFNlcnZpY2VzQnlMb2NhdGlvbj4NDSAgIEEgTG9TVCBjbGllbnQg Y2FuIGFzayBhIExvU1Qgc2VydmVyIGZvciB0aGUgbGlzdCBvZiBzZXJ2aWNlcyBpdCBrbm93 cw0gICBhYm91dCBmb3IgYSBwYXJ0aWN1bGFyIGFyZWEuICBUaGUgPGxpc3RTZXJ2aWNlc0J5 TG9jYXRpb24+IHF1ZXJ5DSAgIGNvbnRhaW5zIG9uZSBvciBtb3JlIDxsb2NhdGlvbj4gZWxl bWVudHMsIGVhY2ggZnJvbSBhIGRpZmZlcmVudA0gICBsb2NhdGlvbiBwcm9maWxlIChTZWN0 aW9uIDEyKSwgYW5kIG1heSBjb250YWluIHRoZSA8c2VydmljZT4gZWxlbWVudC4NICAgQXMg Zm9yIDxmaW5kU2VydmljZT4sIHRoZSBzZXJ2ZXIgc2VsZWN0cyB0aGUgZmlyc3QgbG9jYXRp b24gZWxlbWVudA0gICB0aGF0IGhhcyBhIHByb2ZpbGUgdGhlIHNlcnZlciB1bmRlcnN0YW5k cyBhbmQgaXQgY2FuIG9wZXJhdGUgZWl0aGVyDSAgIHJlY3Vyc2l2ZWx5IG9yIGl0ZXJhdGl2 ZWx5OyA8dmlhPiBlbGVtZW50cyB0cmFjayB0aGUgcHJvZ3Jlc3Mgb2YgdGhlDSAgIHJlcXVl c3QuICBCeSBpdHMgbmF0dXJlLCB0aGUgcXVlcnkgY2FuIG9ubHkgaW5kaWNhdGUgdGhlIHNl cnZpY2VzDSAgIHRoYXQgYSBwYXJ0aWN1bGFyIHNlcnZlciBjYW4gZGV0ZXJtaW5lLCBub3Qg YWxsIHBvc3NpYmxlIHNlcnZpY2VzDSAgIHRoYXQgbWlnaHQgYmUgb2ZmZXJlZC4gIFVubGlr ZSA8TGlzdFNlcnZpY2VzPiwgdGhlIGFuc3dlciBkZXNjcmliZXMNICAgdGhlIHNlcnZpY2Vz IGF2YWlsYWJsZSBhdCBhIHNwZWNpZmljIGxvY2F0aW9uLCB3aGljaCBhcmUgdHlwaWNhbGx5 IGENICAgc3Vic2V0IG9mIHRob3NlIHVuZGVyc3Rvb2QgYnkgdGhlIHNlcnZlci4NDSAgIElm IHRoZSBxdWVyeSBjb250YWlucyB0aGUgPHNlcnZpY2U+IGVsZW1lbnQsIHRoZSBMb1NUIHNl cnZlciByZXR1cm5zDSAgIG9ubHkgaW1tZWRpYXRlIGNoaWxkIHNlcnZpY2VzIG9mIHRoZSBx dWVyaWVkIHNlcnZpY2UgdGhhdCBhcmUNICAgYXZhaWxhYmxlIGZvciB0aGUgcHJvdmlkZWQg bG9jYXRpb24uICBJZiB0aGUgPHNlcnZpY2U+IGVsZW1lbnQgaXMNICAgYWJzZW50LCB0aGUg TG9TVCBzZXJ2aWNlIHJldHVybnMgYWxsIHRvcC1sZXZlbCBzZXJ2aWNlcyBhdmFpbGFibGUg Zm9yDSAgIHRoZSBwcm92aWRlZCBsb2NhdGlvbiB0aGF0IGl0IGtub3dzIGFib3V0Lg0NICAg QSBzZXJ2ZXIgcmVzcG9uZHMgdG8gdGhpcyBxdWVyeSB3aXRoIGENICAgPGxpc3RTZXJ2aWNl c0J5TG9jYXRpb25SZXNwb25zZT4gcmVzcG9uc2UuICBUaGlzIHJlc3BvbnNlIE1BWSBjb250 YWluDSAgIDx2aWE+IGVsZW1lbnRzIChzZWUgU2VjdGlvbiA2KSBhbmQgTVVTVCBjb250YWlu IGEgPHNlcnZpY2VMaXN0Pg0gICBlbGVtZW50LCBjb25zaXN0aW5nIG9mIGEgd2hpdGVzcGFj ZS1zZXBhcmF0ZWQgbGlzdCBvZiBzZXJ2aWNlIFVSTnMuDSAgIFRoZSBxdWVyeSBhbmQgcmVz cG9uc2UgYXJlIGlsbHVzdHJhdGVkIGluIEZpZ3VyZSAxNCBhbmQgaW4gRmlndXJlIDE1LA0g ICByZXNwZWN0aXZlbHkuDQ0NDSAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVU Ri04Ij8+DSAgIDxsaXN0U2VydmljZXNCeUxvY2F0aW9uDSAgICAgeG1sbnM9InVybjppZXRm OnBhcmFtczp4bWw6bnM6bG9zdDEiDSAgICAgeG1sbnM6cDI9Imh0dHA6Ly93d3cub3Blbmdp cy5uZXQvZ21sIg0gICAgIHJlY3Vyc2l2ZT0idHJ1ZSI+DSAgICAgPGxvY2F0aW9uIGlkPSIz ZTE5ZGZiM2I5ODI4YzMiIHByb2ZpbGU9Imdlb2RldGljLTJkIj4NICAgICAgIDxwMjpQb2lu dCBzcnNOYW1lPSJ1cm46b2djOmRlZjpjcnM6RVBTRzo6NDMyNiI+DSAgICAgICAgIDxwMjpw b3M+LTM0LjQwNyAxNTAuODgzPC9wMjpwb3M+DSAgICAgICA8L3AyOlBvaW50Pg0gICAgIDwv bG9jYXRpb24+DSAgICAgPHNlcnZpY2U+dXJuOnNlcnZpY2U6c29zPC9zZXJ2aWNlPg0gICA8 L2xpc3RTZXJ2aWNlc0J5TG9jYXRpb24+DQ0gICAgICAgICAgIEZpZ3VyZSAxNDogRXhhbXBs ZSBvZiA8TGlzdFNlcnZpY2VzYnlMb2NhdGlvbj4gcXVlcnkNDQ0NDQ0NDUhhcmRpZSwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQ YWdlIDI4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgIDw/eG1sIHZlcnNpb249IjEuMCIg ZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxsaXN0U2VydmljZXNCeUxvY2F0aW9uUmVzcG9uc2UN ICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIj4NICAgIDxzZXJ2aWNl TGlzdD4NICAgICB1cm46c2VydmljZTpzb3MuYW1idWxhbmNlDSAgICAgdXJuOnNlcnZpY2U6 c29zLmFuaW1hbC1jb250cm9sDSAgICAgdXJuOnNlcnZpY2U6c29zLmZpcmUNICAgICB1cm46 c2VydmljZTpzb3MuZ2FzDSAgICAgdXJuOnNlcnZpY2U6c29zLm1vdW50YWluDSAgICAgdXJu OnNlcnZpY2U6c29zLm1hcmluZQ0gICAgIHVybjpzZXJ2aWNlOnNvcy5waHlzaWNpYW4NICAg ICB1cm46c2VydmljZTpzb3MucG9pc29uDSAgICAgdXJuOnNlcnZpY2U6c29zLnBvbGljZQ0g ICAgIHVybjpzZXJ2aWNlOnNvcy5zdWljaWRlDSAgICA8L3NlcnZpY2VMaXN0Pg0gICAgPHBh dGg+DSAgICAgPHZpYSBzb3VyY2U9ImF1dGhvcml0YXRpdmUuZXhhbXBsZSIvPg0gICAgIDx2 aWEgc291cmNlPSJyZXNvbHZlci5leGFtcGxlIi8+DSAgICA8L3BhdGg+DSAgICA8bG9jYXRp b25Vc2VkIGlkPSIzZTE5ZGZiM2I5ODI4YzMiLz4NICAgPC9saXN0U2VydmljZXNCeUxvY2F0 aW9uUmVzcG9uc2U+DQ0gICAgICAgICAgICAgICBGaWd1cmUgMTU6IEV4YW1wbGUgb2YgPExp c3RTZXJ2aWNlcz4gcmVzcG9uc2UNDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUhhcmRp ZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAg ICAgIFtQYWdlIDI5XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NU ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDTEyLiAgTG9jYXRpb24gUHJv ZmlsZXMNDSAgIExvU1QgdXNlcyBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpbiA8bG9jYXRpb24+ IGVsZW1lbnRzIGluIHJlcXVlc3RzIGFuZA0gICA8c2VydmljZUJvdW5kYXJ5PiBlbGVtZW50 cyBpbiByZXNwb25zZXMuICBTdWNoIGxvY2F0aW9uIGluZm9ybWF0aW9uDSAgIG1heSBiZSBl eHByZXNzZWQgaW4gYSB2YXJpZXR5IG9mIHdheXMuICBUaGlzIHZhcmlldHkgY2FuIGNhdXNl DSAgIGludGVyb3BlcmFiaWxpdHkgcHJvYmxlbXMgd2hlcmUgYSByZXF1ZXN0IG9yIHJlc3Bv bnNlIGNvbnRhaW5zDSAgIGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIGEgZm9ybWF0IG5vdCB1 bmRlcnN0b29kIGJ5IHRoZSBzZXJ2ZXIgb3IgdGhlDSAgIGNsaWVudCwgcmVzcGVjdGl2ZWx5 LiAgVG8gYWNoaWV2ZSBpbnRlcm9wZXJhYmlsaXR5LCB0aGlzIGRvY3VtZW50DSAgIGRlZmlu ZXMgdGhyZWUgbWFuZGF0b3J5LXRvLWltcGxlbWVudCBiYXNlbGluZSBsb2NhdGlvbiBwcm9m aWxlcyB0bw0gICBkZWZpbmUgdGhlIG1hbm5lciBpbiB3aGljaCBsb2NhdGlvbiBpbmZvcm1h dGlvbiBpcyB0cmFuc21pdHRlZC4gIEl0IGlzDSAgIHBvc3NpYmxlIHRvIHN0YW5kYXJkaXpl IG90aGVyIHByb2ZpbGVzIGluIHRoZSBmdXR1cmUuICBUaGUgdGhyZWUNICAgYmFzZWxpbmUg cHJvZmlsZXMgYXJlOg0NICAgZ2VvZGV0aWMtMmQ6DQ0gICAgICBhIHNpbXBsZSBwcm9maWxl IGZvciB0d28tZGltZW5zaW9uYWwgZ2VvZGV0aWMgbG9jYXRpb24NICAgICAgaW5mb3JtYXRp b24sIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEyLjI7DQ0NICAgZ2VvZGV0aWMtMmQtcG9s eWdvbjoNDSAgICAgIGEgcHJvZmlsZSBmb3IgdHdvLWRpbWVuc2lvbmFsIGdlb2RldGljIGxv Y2F0aW9uIGluZm9ybWF0aW9uDSAgICAgIGRlc2NyaWJlZCBieSBhIHBvbHlnb24sIGFzIGRl c2NyaWJlZCBpbiBTZWN0aW9uIDEyLjM7DQ0NICAgY2l2aWM6DQ0gICAgICBhIHByb2ZpbGUg Y29uc2lzdGluZyBvZiBjaXZpYyBhZGRyZXNzIGxvY2F0aW9uIGluZm9ybWF0aW9uLCBhcw0g ICAgICBkZXNjcmliZWQgaW4gU2VjdGlvbiAxMi40Lg0NICAgUmVxdWVzdHMgYW5kIHJlc3Bv bnNlcyBjb250YWluaW5nIDxsb2NhdGlvbj4gb3IgPHNlcnZpY2VCb3VuZGFyeT4NICAgZWxl bWVudHMgTVVTVCBjb250YWluIGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIGV4YWN0bHkgb25l IG9mIHRoZQ0gICB0aHJlZSBiYXNlbGluZSBwcm9maWxlcywgaW4gYWRkaXRpb24gdG8gemVy byBvciBtb3JlIGFkZGl0aW9uYWwNICAgcHJvZmlsZXMuICBUaGUgb3JkZXJpbmcgb2YgbG9j YXRpb24gaW5mb3JtYXRpb24gaW5kaWNhdGVzIGENICAgcHJlZmVyZW5jZSBvbiB0aGUgcGFy dCBvZiB0aGUgc2VuZGVyLg0NICAgU3RhbmRhcmRzIGFjdGlvbiBpcyByZXF1aXJlZCBmb3Ig ZGVmaW5pbmcgbmV3IHByb2ZpbGVzLiAgQSBsb2NhdGlvbg0gICBwcm9maWxlIE1VU1QgZGVm aW5lOg0NICAgMS4gIFRoZSB0b2tlbiBpZGVudGlmeWluZyBpdCBpbiB0aGUgTG9TVCBsb2Nh dGlvbiBwcm9maWxlIHJlZ2lzdHJ5Ow0NICAgMi4gIFRoZSBmb3JtYWwgZGVmaW5pdGlvbiBv ZiB0aGUgWE1MIHRvIGJlIHVzZWQgaW4gcmVxdWVzdHMsIGkuZS4sIGFuDSAgICAgICBlbnVt ZXJhdGlvbiBhbmQgZGVmaW5pdGlvbiBvZiB0aGUgWE1MIGNoaWxkIGVsZW1lbnRzIG9mIHRo ZQ0gICAgICAgPGxvY2F0aW9uPiBlbGVtZW50Ow0NICAgMy4gIFRoZSBmb3JtYWwgZGVmaW5p dGlvbiBvZiB0aGUgWE1MIHRvIGJlIHVzZWQgaW4gcmVzcG9uc2VzLCBpLmUuLA0gICAgICAg YW4gZW51bWVyYXRpb24gYW5kIGRlZmluaXRpb24gb2YgdGhlIFhNTCBjaGlsZCBlbGVtZW50 cyBvZiB0aGUNICAgICAgIDxzZXJ2aWNlQm91bmRhcnk+IGVsZW1lbnQ7DQ0NDUhhcmRpZSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAg IFtQYWdlIDMwXQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAg ICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgIDQuICBUaGUgZGVjbGFyYXRp b24gb2Ygd2hldGhlciBnZW9kZXRpYy0yZCBvciBjaXZpYyBpcyB0byBiZSB1c2VkIGFzDSAg ICAgICB0aGUgYmFzZWxpbmUgcHJvZmlsZS4gIEl0IGlzIG5lY2Vzc2FyeSB0byBleHBsaWNp dGx5IGRlY2xhcmUgdGhlDSAgICAgICBiYXNlbGluZSBwcm9maWxlIGFzIGZ1dHVyZSBwcm9m aWxlcyBtYXkgYmUgY29tYmluYXRpb25zIG9mDSAgICAgICBnZW9kZXRpYyBhbmQgY2l2aWMg bG9jYXRpb24gaW5mb3JtYXRpb24uDQ0xMi4xLiAgTG9jYXRpb24gUHJvZmlsZSBVc2FnZQ0N ICAgQSBsb2NhdGlvbiBwcm9maWxlIGlzIGlkZW50aWZpZWQgYnkgYSB0b2tlbiBpbiBhbiBJ QU5BLW1haW50YWluZWQNICAgcmVnaXN0cnkgKFNlY3Rpb24gMTcuNSkuICBDbGllbnRzIHNl bmQgbG9jYXRpb24gaW5mb3JtYXRpb24gY29tcGxpYW50DSAgIHdpdGggYSBsb2NhdGlvbiBw cm9maWxlLCBhbmQgc2VydmVycyByZXNwb25kIHdpdGggbG9jYXRpb24NICAgaW5mb3JtYXRp b24gY29tcGxpYW50IHdpdGggdGhhdCBzYW1lIGxvY2F0aW9uIHByb2ZpbGUuDQ0gICBXaGVu IGEgTG9TVCBjbGllbnQgc2VuZHMgYSA8ZmluZFNlcnZpY2U+IHJlcXVlc3QgdGhhdCBwcm92 aWRlcw0gICBsb2NhdGlvbiBpbmZvcm1hdGlvbiwgaXQgaW5jbHVkZXMgb25lIG9yIG1vcmUg PGxvY2F0aW9uPiBlbGVtZW50cy4gIEENICAgPGxvY2F0aW9uPiBlbGVtZW50IGNhcnJpZXMg YW4gb3B0aW9uYWwgJ3Byb2ZpbGUnIGF0dHJpYnV0ZSB0aGF0DSAgIGluZGljYXRlcyB0aGUg bG9jYXRpb24gZm9ybWF0IG9mIHRoZSBjaGlsZCBlbGVtZW50cy4gIEEgY2xpZW50IG1heQ0g ICBvYnRhaW4gbG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCBkb2VzIG5vdCBjb25mb3JtIHRv IGEgcHJvZmlsZSBpdA0gICByZWNvZ25pemVzIG9yIGl0IG1heSBub3QgaGF2ZSB0aGUgY2Fw YWJpbGl0eSB0byBtYXAgWE1MIHRvIHByb2ZpbGVzLg0gICBJbiB0aGF0IGNhc2UsIGEgY2xp ZW50IE1BWSBvbWl0IHRoZSBwcm9maWxlIGF0dHJpYnV0ZSBhbmQgdGhlIHNlcnZlcg0gICBz aG91bGQgaW50ZXJwcmV0IHRoZSBYTUwgbG9jYXRpb24gZGF0YSB0byB0aGUgYmVzdCBvZiBp dHMgYWJpbGl0eSwNICAgcmV0dXJuaW5nIGEgImxvY2F0aW9uUHJvZmlsZVVucmVjb2duaXpl ZCIgZXJyb3IgaWYgaXQgaXMgdW5hYmxlIHRvIGRvDSAgIHNvLg0NICAgVGhlIGNvbmNlcHQg b2YgbG9jYXRpb24gcHJvZmlsZXMgYXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDEyLiAgV2l0 aA0gICB0aGUgYWJpbGl0eSB0byBzcGVjaWZ5IG1vcmUgdGhhbiBvbmUgPGxvY2F0aW9uPiBl bGVtZW50IHRoZSBjbGllbnQgaXMNICAgYWJsZSB0byBjb252ZXkgbG9jYXRpb24gaW5mb3Jt YXRpb24gZm9yIG11bHRpcGxlIGxvY2F0aW9uIHByb2ZpbGVzIGluDSAgIHRoZSBzYW1lIHJl cXVlc3QuDQ0gICBXaGVuIGEgTG9TVCBzZXJ2ZXIgc2VuZHMgYSByZXNwb25zZSB0aGF0IGNv bnRhaW5zIGxvY2F0aW9uDSAgIGluZm9ybWF0aW9uLCBpdCB1c2VzIHRoZSA8c2VydmljZUJv dW5kYXJ5PiBlbGVtZW50cyBtdWNoIGxpa2UgdGhlDSAgIGNsaWVudCB1c2VzIHRoZSA8bG9j YXRpb24+IGVsZW1lbnRzLiAgRWFjaCA8c2VydmljZUJvdW5kYXJ5PiBlbGVtZW50DSAgIGNv bnRhaW5zIGxvY2F0aW9uIGluZm9ybWF0aW9uIGNvbmZvcm1hbnQgdG8gdGhlIGxvY2F0aW9u IHByb2ZpbGUNICAgc3BlY2lmaWVkIGluIHRoZSAncHJvZmlsZScgYXR0cmlidXRlLiAgV2hl biBtdWx0aXBsZSA8bG9jYXRpb24+DSAgIGVsZW1lbnRzIGFyZSBpbmNsdWRlZCB0aGVuIGl0 IGVuYWJsZXMgdGhlIHNlcnZlciB0byBzZW5kIGxvY2F0aW9uDSAgIGluZm9ybWF0aW9uIGNv bXBsaWFudCB3aXRoIG11bHRpcGxlIGxvY2F0aW9uIHByb2ZpbGVzLg0NICAgVXNpbmcgdGhl IGxvY2F0aW9uIHByb2ZpbGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCwgdGhlIGZvbGxv d2luZw0gICBydWxlcyBlbnN1cmUgaW50ZXJvcGVyYXRpYmxpdHkgYmV0d2VlbiBjbGllbnRz IGFuZCBzZXJ2ZXJzOg0NICAgMS4gIEEgY2xpZW50IE1VU1QgYmUgY2FwYWJsZSBvZiB1bmRl cnN0YW5kaW5nIHRoZSByZXNwb25zZSBmb3IgdGhlDSAgICAgICBiYXNlbGluZSBwcm9maWxl cyBpdCB1c2VkIGluIHRoZSByZXF1ZXN0Lg0NICAgMi4gIElmIGEgY2xpZW50IHNlbmRzIGxv Y2F0aW9uIGluZm9ybWF0aW9uIGNvbmZvcm1hbnQgdG8gYW55IGxvY2F0aW9uDSAgICAgICBw cm9maWxlIG90aGVyIHRoYW4gdGhlIG9uZXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQs IGl0IE1VU1QNICAgICAgIGFsc28gc2VuZCwgaW4gdGhlIHNhbWUgcmVxdWVzdCwgbG9jYXRp b24gaW5mb3JtYXRpb24gY29uZm9ybWFudA0gICAgICAgdG8gb25lIG9mIHRoZSBiYXNlbGlu ZSBwcm9maWxlcy4gIE90aGVyd2lzZSwgdGhlIHNlcnZlciBtaWdodCBub3QNICAgICAgIGJl IGFibGUgdG8gdW5kZXJzdGFuZCB0aGUgcmVxdWVzdAUuDQ0NDQ1IYXJkaWUsIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAz MV0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAg ICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICAzLiAgQSBjbGllbnQgU0hPVUxEIE5PVCBz ZW5kIG11bHRpcGxlIDxsb2NhdGlvbj4gb2JqZWN0cyB0aGF0IGFyZQ0gICAgICAgZGVyaXZl ZCBmcm9tIGRpZmZlcmVudCBiYXNlbGluZSBwcm9maWxlcy4gIEluIG90aGVyIHdvcmRzLCBh DSAgICAgICBjbGllbnQgU0hPVUxEIG9ubHkgc2VuZCBsb2NhdGlvbiBvYmplY3RzIGFjY29y ZGluZyB0byB0aGUgc2FtZQ0gICAgICAgYmFzZWxpbmUgcHJvZmlsZSBpbiBhIHF1ZXJ5LiAg SWYgYSBjbGllbnQgaGFzIGJvdGggbG9jYXRpb24NICAgICAgIGluZm9ybWF0aW9uIHByaW1h cmlseSBvZiBnZW9kZXRpYyBuYXR1cmUgYW5kIGxvY2F0aW9uIGluZm9ybWF0aW9uDSAgICAg ICBwcmltYXJpbHkgb2YgYSBjaXZpYyBuYXR1cmUsIGl0IHNob3VsZCBzZW5kIHNlcGFyYXRl IHJlcXVlc3RzDSAgICAgICBjb250YWluaW5nIGVhY2ggdHlwZSBvZiBsb2NhdGlvbiBpbmZv cm1hdGlvbi4NDSAgIDQuICBUaGVyZSBjYW4gb25seSBiZSBvbmUgaW5zdGFuY2Ugb2YgZWFj aCBsb2NhdGlvbiBwcm9maWxlIGluIGENICAgICAgIHF1ZXJ5Lg0NICAgNS4gIFNlcnZlcnMg TVVTVCBpbXBsZW1lbnQgYWxsIHByb2ZpbGVzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50 Lg0NICAgNi4gIEEgc2VydmVyIHVzZXMgdGhlIGZpcnN0LWxpc3RlZCBsb2NhdGlvbiBwcm9m aWxlIHRoYXQgaXQNICAgICAgIHVuZGVyc3RhbmRzIGFuZCBpZ25vcmVzIHRoZSBvdGhlcnMu DQ0gICA3LiAgSWYgYSBzZXJ2ZXIgcmVjZWl2ZXMgYSByZXF1ZXN0IHRoYXQgb25seSBjb250 YWlucyBsb2NhdGlvbg0gICAgICAgaW5mb3JtYXRpb24gdXNpbmcgcHJvZmlsZXMgaXQgZG9l cyBub3QgdW5kZXJzdGFuZCwgdGhlIHNlcnZlcg0gICAgICAgcmVzcG9uZHMgd2l0aCBhIDxs b2NhdGlvblByb2ZpbGVFcnJvcj4gKFNlY3Rpb24gMTMuMSkuDQ0gICA4LiAgVGhlIDxzZXJ2 aWNlQm91bmRhcnk+IGVsZW1lbnQgTVVTVCB1c2UgdGhlIHNhbWUgbG9jYXRpb24gcHJvZmls ZQ0gICAgICAgdGhhdCB3YXMgdXNlZCB0byByZXRyaWV2ZSB0aGUgYW5zd2VyIGFuZCBpbmRp Y2F0ZXMgd2hpY2ggcHJvZmlsZQ0gICAgICAgaGFzIGJlZW4gdXNlZCB3aXRoIHRoZSAncHJv ZmlsZScgYXR0cmlidXRlLg0NICAgVGhlc2UgcnVsZXMgZW5hYmxlIHRoZSB1c2Ugb2YgbG9j YXRpb24gcHJvZmlsZXMgbm90IHlldCBzcGVjaWZpZWQsDSAgIHdoaWxlIGVuc3VyaW5nIGJh c2VsaW5lIGludGVyb3BlcmFiaWxpdHkuICBUYWtlLCBmb3IgZXhhbXBsZSwgdGhpcw0gICBz Y2VuYXJpby4gIENsaWVudCBYIGhhcyBoYWQgaXRzIGZpcm13YXJlIHVwZ3JhZGVkIHRvIHN1 cHBvcnQgdGhlDSAgIHViZXItY29tcGxleC0zRCBsb2NhdGlvbiBwcm9maWxlLiAgQ2xpZW50 IFggc2VuZHMgbG9jYXRpb24NICAgaW5mb3JtYXRpb24gdG8gU2VydmVyIFksIHdoaWNoIGRv ZXMgbm90IHVuZGVyc3RhbmQgdGhlDSAgIHViZXItY29tcGxleC0zRCBsb2NhdGlvbiBwcm9m aWxlLiAgSWYgQ2xpZW50IFggYWxzbyBzZW5kcyBsb2NhdGlvbg0gICBpbmZvcm1hdGlvbiB1 c2luZyB0aGUgZ2VvZGV0aWMtMkQgYmFzZWxpbmUgcHJvZmlsZSwgdGhlbiBTZXJ2ZXIgWQ0g ICB3aWxsIHN0aWxsIGJlIGFibGUgdG8gdW5kZXJzdGFuZCB0aGUgcmVxdWVzdCBhbmQgcHJv dmlkZSBhbg0gICB1bmRlcnN0YW5kYWJsZSByZXNwb25zZSwgdGhvdWdoIHdpdGggbG9jYXRp b24gaW5mb3JtYXRpb24gdGhhdCBtaWdodA0gICBub3QgYmUgYXMgcHJlY2lzZSBvciBleHBy ZXNzaXZlIGFzIGRlc2lyZWQuICBUaGlzIGlzIHBvc3NpYmxlIGJlY2F1c2UNICAgYm90aCBD bGllbnQgWCBhbmQgU2VydmVyIFkgdW5kZXJzdGFuZCB0aGUgYmFzZWxpbmUgcHJvZmlsZS4N DU5PVEU6DVRoaXMgaXMgYW5vdGhlciB2ZXJ5IGdvb2QgY2FzZSBmb3IgbG9jYWwgTG9TVCBz ZXJ2ZXIgZGlzY292ZXJ5LiBGb3IgZXhhbXBsZSBpZiBteSBsb2NhbCBMSVMgZ2l2ZSBtZSBh IGxvY2F0aW9uIGZvcm0gdGhhdCBJIGNhbiBjb252ZXJ0IHRvIGFuIHViZXItY29tcGxleC0z RCBmb3JtLCB0aGVuIGl0IGlzIGxpa2VseSB0aGF0IHRoZSBsb2NhbCBMb1NUIHNlcnZlciBj YW4gYWxzbyBkZWFsIHdpdGggdGhpcy4gVGhlcmUgYXJlIGhvd2V2ZXIgbm8gZ3VhcmFudGVl cyB0aGF0IGEgTG9TVCBzZXJ2ZXIgaW4gU2llcnJhIExlb25lIHdpbGwgdW5kZXJzdGFuZCB0 aGlzLCBzbyBpdCB3aWxsIGRyb3AgYmFjayB0byB0aGUgYmFzZS1wcm9maWxlIGJlZm9yZSBj b250YWN0aW5nIHRoZSBMb1NUIHNlcnZlciBhc3NvY2lhdGVkIHdpdGggbXkgY3VycmVudCBs b2NhdGlvbi4gVGhpcyByZXN1bHRzIGluIGEgZGVncmFkYXRpb24gb2YgZnVuY3Rpb25hbGl0 eS4NDQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2Vt YmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAzMl0NDA1JbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIw MDcNDQ0gICA8P3htbCB2ZXJzaW9uPSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0gICA8Zmlu ZFNlcnZpY2UNICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpsb3N0MSINICAg ICB4bWxuczpwMj0iaHR0cDovL3d3dy5vcGVuZ2lzLm5ldC9nbWwiDSAgICAgcmVjdXJzaXZl PSJ0cnVlIg0gICAgIHNlcnZpY2VCb3VuZGFyeT0idmFsdWUiPg0gICAgIDxsb2NhdGlvbiBp ZD0iNzg0Yzc1NDFlMDI0MzQxMSIgcHJvZmlsZT0idWJlci1jb21wbGV4LTNkIj4NICAgICAg IDxwMjpQb2ludCBpZD0icG9pbnQxIiBzcnNOYW1lPSJ1cm46b2djOmRlZjpjcnM6RVBTRzo6 NDMyNiI+DSAgICAgICAgICA8cDI6cG9zPjM3Ljc3NSAtMTIyLjQyMjwvcDI6cG9zPg0gICAg ICAgPC9wMjpQb2ludD4NICAgICAgICAgPHAyOlBvbHlnb24gc3JzTmFtZT0idXJuOm9nYzpk ZWY6OmNyczpFUFNHOjo0MzI2Ij4NICAgICAgICAgICA8cDI6ZXh0ZXJpb3I+DSAgICAgICAg ICAgICA8cDI6TGluZWFyUmluZz4NICAgICAgICAgICAgICAgPHAyOnBvcz4zNy43NzUgLTEy Mi40MTk0PC9wMjpwb3M+DSAgICAgICAgICAgICAgIDxwMjpwb3M+MzcuNTU1IC0xMjIuNDE5 NDwvcDI6cG9zPg0gICAgICAgICAgICAgICA8cDI6cG9zPjM3LjU1NSAtMTIyLjQyNjQ8L3Ay OnBvcz4NICAgICAgICAgICAgICAgPHAyOnBvcz4zNy43NzUgLTEyMi40MjY0PC9wMjpwb3M+ DSAgICAgICAgICAgICAgIDxwMjpwb3M+MzcuNzc1IC0xMjIuNDE5NDwvcDI6cG9zPg0gICAg ICAgICAgICAgIDwvcDI6TGluZWFyUmluZz4NICAgICAgICAgICAgPC9wMjpleHRlcmlvcj4N ICAgICAgICAgPC9wMjpQb2x5Z29uPg0gICAgICAgPHAyOlBvaW50IGlkPSJwb2ludDEiIHNy c05hbWU9InVybjpvZ2M6ZGVmOmNyczpFUFNHOjo0MzI2Ij4NICAgICAgICAgIDxwMjpwb3M+ LTEyMi40MjIgMzcuNzc1PC9wMjpwb3M+DSAgICAgICA8L3AyOlBvaW50Pg0gICAgIDwvbG9j YXRpb24+DSAgICAgPGxvY2F0aW9uIGlkPSI2MDIwNjg4ZjFjZTE4OTZkIiBwcm9maWxlPSJn ZW9kZXRpYy0yZCI+DSAgICAgICA8cDI6UG9pbnQgaWQ9InBvaW50MSIgc3JzTmFtZT0idXJu Om9nYzpkZWY6Y3JzOkVQU0c6OjQzMjYiPg0gICAgICAgICAgPHAyOnBvcz4zNy43NzUgLTEy Mi40MjI8L3AyOnBvcz4NICAgICAgIDwvcDI6UG9pbnQ+DSAgICAgPC9sb2NhdGlvbj4NICAg ICA8c2VydmljZT51cm46c2VydmljZTpzb3MucG9saWNlPC9zZXJ2aWNlPg0gICA8L2ZpbmRT ZXJ2aWNlPg0NICAgIEZpZ3VyZSAxNjogRXhhbXBsZSBvZiBhIDxmaW5kU2VydmljZXM+IHF1 ZXJ5IHdpdGggYmFzZWxpbmUgcHJvZmlsZQ0gICAgICAgICAgICAgICAgICAgICAgICAgICAg IGludGVyb3BlcmFiaWxpdHkNDQ0NDQ0NDQ0NDQ0NDQ0NDUhhcmRpZSwgZXQgYWwuICAgICAg ICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDMzXQ0M DUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAg ICAgICAgICAgIEp1bmUgMjAwNw0NDSAgIDw/eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9 IlVURi04Ij8+DSAgIDxmaW5kU2VydmljZVJlc3BvbnNlDSAgICAgeG1sbnM9InVybjppZXRm OnBhcmFtczp4bWw6bnM6bG9zdDEiDSAgICAgeG1sbnM6cDI9Imh0dHA6Ly93d3cub3Blbmdp cy5uZXQvIj4NICAgICA8bWFwcGluZw0gICAgICAgZXhwaXJlcz0iMjAwNy0wMS0wMVQwMTo0 NDozM1oiDSAgICAgICBsYXN0VXBkYXRlZD0iMjAwNi0xMS0wMVQwMTowMDowMFoiDSAgICAg ICBzb3VyY2U9ImF1dGhvcml0YXRpdmUuZXhhbXBsZSINICAgICAgIHNvdXJjZUlkPSJjZjE5 YmJiMDM4ZmI0YWRlOTU4NTI3OTVmMDQ1Mzg3ZCI+DSAgICAgICA8ZGlzcGxheU5hbWUgeG1s Omxhbmc9ImVuIj4NICAgICAgICAgTmV3IFlvcmsgQ2l0eSBQb2xpY2UgRGVwYXJ0bWVudA0g ICAgICAgPC9kaXNwbGF5TmFtZT4NICAgICAgIDxzZXJ2aWNlPnVybjpzZXJ2aWNlOnNvcy5w b2xpY2U8L3NlcnZpY2U+DSAgICAgICA8c2VydmljZUJvdW5kYXJ5IHByb2ZpbGU9Imdlb2Rl dGljLTJkIj4NICAgICAgICAgPHAyOlBvbHlnb24gc3JzTmFtZT0idXJuOm9nYzpkZWY6OmNy czpFUFNHOjo0MzI2Ij4NICAgICAgICAgICA8cDI6ZXh0ZXJpb3I+DSAgICAgICAgICAgICA8 cDI6TGluZWFyUmluZz4NICAgICAgICAgICAgICAgPHAyOnBvcz4zNy43NzUgLTEyMi40MTk0 PC9wMjpwb3M+DSAgICAgICAgICAgICAgIDxwMjpwb3M+MzcuNTU1IC0xMjIuNDE5NDwvcDI6 cG9zPg0gICAgICAgICAgICAgICA8cDI6cG9zPjM3LjU1NSAtMTIyLjQyNjQ8L3AyOnBvcz4N ICAgICAgICAgICAgICAgPHAyOnBvcz4zNy43NzUgLTEyMi40MjY0PC9wMjpwb3M+DSAgICAg ICAgICAgICAgIDxwMjpwb3M+MzcuNzc1IC0xMjIuNDE5NDwvcDI6cG9zPg0gICAgICAgICAg ICAgPC9wMjpMaW5lYXJSaW5nPg0gICAgICAgICAgIDwvcDI6ZXh0ZXJpb3I+DSAgICAgICAg IDwvcDI6UG9seWdvbj4NICAgICAgIDwvc2VydmljZUJvdW5kYXJ5Pg0gICAgICAgPHVyaT5z aXA6bnlwZEBleGFtcGxlLmNvbTwvdXJpPg0gICAgIDwvbWFwcGluZz4NICAgICA8cGF0aD4N ICAgICAgIDx2aWEgc291cmNlPSJhdXRob3JpdGF0aXZlLmV4YW1wbGUiLz4NICAgICAgIDx2 aWEgc291cmNlPSJyZXNvbHZlci5leGFtcGxlIi8+DSAgICAgPC9wYXRoPg0gICAgIDxsb2Nh dGlvblVzZWQgaWQ9IjYwMjA2ODhmMWNlMTg5NmQiLz4NICAgPC9maW5kU2VydmljZVJlc3Bv bnNlPg0NICAgIEZpZ3VyZSAxNzogRXhhbXBsZSBvZiBhIDxmaW5kU2VydmljZVJlc3BvbnNl PiBtZXNzYWdlIHdpdGggYmFzZWxpbmUNICAgICAgICAgICAgICAgICAgICAgICAgIHByb2Zp bGUgaW50ZXJvcGVyYWJpbGl0eQ0NMTIuMi4gIFR3byBEaW1lbnNpb25hbCBHZW9kZXRpYyBQ cm9maWxlDQ0gICBUaGUgImdlb2RldGljLTJkIiBsb2NhdGlvbiBwcm9maWxlIGlzIGlkZW50 aWZpZWQgYnkgImdlb2RldGljLTJkIi4NICAgQ2xpZW50cyB1c2UgdGhpcyBwcm9maWxlIGJ5 IHBsYWNpbmcgYSA8UG9pbnQ+IGVsZW1lbnQsIGFzIGRlc2NyaWJlZA0gICBpbiBTZWN0aW9u IDcuMi4xIG9mIFsxMl0sIHdpdGhpbiB0aGUgPGxvY2F0aW9uPiBlbGVtZW50LiAgU2VjdGlv bg0gICA3LjIuMSBvZiBbMTJdIGRlc2NyaWJlcyB0aGUgc3BlY2lmaWNhdGlvbiBvZiBhIDxQ b2ludD4gd2l0aCBlaXRoZXIgYQ0gICB0d28gZGltZW5zaW9uYWwgcG9zaXRpb24gKGxhdGl0 dWRlIGFuZCBsb25naXR1ZGUpIG9yIHRocmVlDSAgIGRpbWVuc2lvbmFsIHBvc2l0aW9uIChs YXRpdHVkZSwgbG9uZ2l0dWRlLCBhbmQgYWx0aXR1ZGUpLiAgQSBjbGllbnQNICAgTUFZIHVz ZSB0aGUgdGhyZWUgZGltZW5zaW9uYWwgcG9zaXRpb24sIGFuZCBzZXJ2ZXJzIE1BWSBpbnRl cnByZXQgYQ0gICB0aHJlZSBkaW1lbnNpb25hbCBwb3NpdGlvbiBhcyBhIHR3byBkaW1lbnNp b25hbCBwb3NpdGlvbiBieSBpZ25vcmluZw0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSAzNF0NDA1JbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMDcNDQ0gICB0aGUgYWx0aXR1ZGUgdmFsdWUuDQ0gICBTZXJ2ZXJzIHVz ZSB0aGlzIHByb2ZpbGUgYnkgcGxhY2luZyBhIDxQb2x5Z29uPiBlbGVtZW50LCBhcyBkZXNj cmliZWQNICAgaW4gU2VjdGlvbiA3LjIuMiBvZiBbMTJdLCB3aXRoaW4gdGhlIDxzZXJ2aWNl Qm91bmRhcnk+IGVsZW1lbnQuICBUaGlzDSAgIGlzIGRlZmluZWQgYnkgdGhlICdwb2x5Z29u JyBwYXR0ZXJuIGluIHRoZSBMb1NUIHNjaGVtYSAoc2VlDSAgIFNlY3Rpb24gMTUpLg0NICAg VGhlIHJlc3RyaWN0aW9uIHRvIDE2IHBvaW50cyBmb3IgYSBwb2x5Z29uIGNvbnRhaW5lZCBp biBTZWN0aW9uIDcuMi4yDSAgIG9mIFsxMl0gaXMgbm90IGFwcGxpY2FibGUgdG8gdGhpcyBk b2N1bWVudC4NDSAgIFdpdGggdGhpcyBhbmQgdGhlICJnZW9kZXRpYy0yZC1wb2x5Z29uIiBw cm9maWxlIGRlc2NyaWJlZCBiZWxvdywNICAgbG9jYXRpb24gZWxlbWVudHMgTVVTVCB1c2Ug V0dTIDg0IGNvb3JkaW5hdGUgcmVmZXJlbmNlIHN5c3RlbSBmb3INICAgbG9uZ2l0dWRlLCBs YXRpdHVkZSBhbmQgYWx0aXR1ZGUsIGkuZS4sIHRoZSBzcnNOYW1lIHNldCB0bw0gICAndXJu Om9nYzpkZWY6Y3JzOkVQU0c6OjQzMjYnLiAgVGhlIG9yaWVudGF0aW9uIG9mIHRoZSBwb2lu dHMgaW4gdGhlDSAgIHBvbHlnb24gaXMgdXB3YXJkIG5vcm1hbCBhcyBkZXNjcmliZWQgaW4g U2VjdGlvbiA3LjIuMiBvZiBbMTJdLg0NMTIuMy4gIFR3byBEaW1lbnNpb25hbCBQb2x5Z29u IEdlb2RldGljIFByb2ZpbGUNDSAgIFRoZSAiZ2VvZGV0aWMtMmQtcG9seWdvbiIgbG9jYXRp b24gcHJvZmlsZSBpcyBpZGVudGlmaWVkIGJ5DSAgICJnZW9kZXRpYy0yZC1wb2x5Z29uIi4g IENsaWVudHMgdXNlIHRoaXMgcHJvZmlsZSBieSBwbGFjaW5nIGENICAgPFBvbHlnb24+IGVs ZW1lbnQsIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDcuMi4yIG9mIFsxMl0sIHdpdGhpbiB0 aGUNICAgPGxvY2F0aW9uPiBlbGVtZW50LiAgVGhlIGVsZW1lbnQgaW5kaWNhdGVzIHRoYXQg dGhlIHF1ZXJ5IGlzIGFib3V0DSAgIGFueSBwb2ludCBjb250YWluZWQgaW4gdGhlIHBvbHln b247IGl0IGlzIGxlZnQgdG8gdGhlIHNlcnZlciB0bw0gICBzZWxlY3QgYW4gYXBwcm9wcmlh dGUgbWF0Y2hpbmcgYWxnb3JpdGhtLCBzdWNoIGFzIHVzaW5nIHRoZSBwb2x5Z29uJ3MNICAg Y2VudHJvaWQuICBTZWN0aW9uIDcuMi4yIG9mIFsxMl0gZGVzY3JpYmVzIHRoZSBzcGVjaWZp Y2F0aW9uIG9mIGENICAgPFBvbHlnb24+IHdpdGggZWl0aGVyIGEgdHdvIGRpbWVuc2lvbmFs IHBvaW50cyAobGF0aXR1ZGUgYW5kDSAgIGxvbmdpdHVkZSkgb3IgdGhyZWUgZGltZW5zaW9u YWwgcG9pbnRzIChsYXRpdHVkZSwgbG9uZ2l0dWRlLCBhbmQNICAgYWx0aXR1ZGUpLiAgQSBj bGllbnQgTUFZIHVzZSB0aHJlZSBkaW1lbnNpb25hbCBwb2ludHMsIGFuZCBzZXJ2ZXJzDSAg IE1BWSBpbnRlcnByZXQgYSB0aHJlZSBkaW1lbnNpb25hbCBwb3NpdGlvbiBhcyB0d28gZGlt ZW5zaW9uYWwgcG9pbnRzDSAgIGJ5IGlnbm9yaW5nIHRoZSBhbHRpdHVkZSB2YWx1ZXMuICBU aGUgMTYtcG9pbnQgcmVzdHJpY3Rpb24gZm9yIGENICAgcG9seWdvbiBkb2VzIG5vdCBhcHBs eS4NDSAgIFRoZSBzZXJ2ZXIgYmVoYXZpb3IgaXMgdGhlIHNhbWUgYXMgZm9yIHRoZSAiZ2Vv ZGV0aWMtMmQiIHByb2ZpbGUNICAgYWJvdmUFLg0NMTIuNC4gIEJhc2ljIENpdmljIFByb2Zp bGUNDSAgIFRoZSBiYXNpYy1jaXZpYyBsb2NhdGlvbiBwcm9maWxlIGlzIGlkZW50aWZpZWQg YnkgdGhlIHRva2VuICdjaXZpYycuDSAgIENsaWVudHMgdXNlIHRoaXMgcHJvZmlsZSBieSBw bGFjaW5nIGEgPGNpdmljQWRkcmVzcz4gZWxlbWVudCwgZGVmaW5lZA0gICBpbiBbOV0sIHdp dGhpbiB0aGUgPGxvY2F0aW9uPiBlbGVtZW50Lg0NICAgU2VydmVycyB1c2UgdGhpcyBwcm9m aWxlIGJ5IHBsYWNpbmcgYSA8Y2l2aWNBZGRyZXNzPiBlbGVtZW50LCBkZWZpbmVkDSAgIGlu IFs5XSwgd2l0aGluIHRoZSA8c2VydmljZUJvdW5kYXJ5PiBlbGVtZW50Lg0NDQ0NDQ0NDUhh cmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAg ICAgICAgIFtQYWdlIDM1XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBM b1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDTEzLiAgRXJyb3JzLCBX YXJuaW5ncywgYW5kIFJlZGlyZWN0cw0NICAgV2hlbiBhIExvU1Qgc2VydmVyIGNhbm5vdCBm dWxmaWxsIGEgcmVxdWVzdCBjb21wbGV0ZWx5LCBpdCBjYW4gcmV0dXJuDSAgIGVpdGhlciBh biBlcnJvciBvciBhIHdhcm5pbmcsIGRlcGVuZGluZyBvbiB0aGUgc2V2ZXJpdHkgb2YgdGhl DSAgIHByb2JsZW0uICBJdCByZXR1cm5zIGFuIGVycm9yIGVsZW1lbnQgaWYgbm8gdXNlZnVs IHJlc3BvbnNlIGNhbiBiZQ0gICByZXR1cm5lZCBmb3IgdGhlIHF1ZXJ5LiAgSXQgcmV0dXJu cyBhIDx3YXJuaW5ncz4gZWxlbWVudCBhcyBwYXJ0IG9mDSAgIGFub3RoZXIgcmVzcG9uc2Ug ZWxlbWVudCBpZiBpdCB3YXMgYWJsZSB0byByZXNwb25kIGluIHBhcnQsIGJ1dCB0aGUNICAg cmVzcG9uc2UgbWF5IG5vdCBiZSBxdWl0ZSB3aGF0IHRoZSBjbGllbnQgaGFkIGRlc2lyZWQu ICBUaGlzIGRvY3VtZW50DSAgIGRvZXMgbm90IGRlZmluZSB3YXJuaW5ncy4gIEZvciBib3Ro IGVsZW1lbnRzLCB0aGUgJ3NvdXJjZScgYXR0cmlidXRlDSAgIG5hbWVzIHRoZSBzZXJ2ZXIg dGhhdCBvcmlnaW5hbGx5IGdlbmVyYXRlZCB0aGUgZXJyb3Igb3Igd2FybmluZywgc3VjaA0g ICBhcyB0aGUgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIuICBVbmxlc3Mgb3RoZXJ3aXNlIG5vdGVk LCBhbGwgZWxlbWVudHMNICAgYmVsb3cgY2FuIGJlIGVpdGhlciBhbiBlcnJvciBvciBhIHdh cm5pbmcsIGRlcGVuZGluZyBvbiB3aGV0aGVyIGENICAgZGVmYXVsdCByZXNwb25zZSwgc3Vj aCBhcyBhIG1hcHBpbmcsIGlzIGluY2x1ZGVkLg0NMTMuMS4gIEVycm9ycw0NICAgTG9TVCBk ZWZpbmVzIGEgcGF0dGVybiBmb3IgZXJyb3JzLCBkZWZpbmVkIGFzIDxlcnJvcnM+IGVsZW1l bnRzIGluDSAgIHRoZSBSZWxheCBORyBzY2hlbWEuICBUaGlzIHBhdHRlcm4gZGVmaW5lcyBh ICdtZXNzYWdlJyBhdHRyaWJ1dGUNICAgY29udGFpbmluZyBodW1hbiByZWFkYWJsZSB0ZXh0 IGFuZCBhbiAneG1sOmxhbmcnIGF0dHJpYnV0ZSBkZW5vdGluZw0gICB0aGUgbGFuZ3VhZ2Ug b2YgdGhlIGh1bWFuIHJlYWRhYmxlIHRleHQuICBPbmUgb3IgbW9yZSBzdWNoIGVycm9yDSAg IGVsZW1lbnRzIGFyZSBjb250YWluZWQgaW4gdGhlIDxlcnJvcnM+IGVsZW1lbnQuDQ1FcnJv cnMgaW5kaWNhdGUgYXBwbGljYXRpb24tbGF5ZXIgcHJvYmxlbXMgYW5kIG5vdCB0cmFuc3Bv cnQgcmVsYXRlZCBjb25jZXJucy4gQ29uc2VxdWVudGx5IExvU1QgZXJyb3JzIFNIQUxMIG9u bHkgZXZlciBiZSByZXR1cm5lZCB3aXRoIGFuIEhUVFAgMjAwIE9LIG1lc3NhZ2UuDQ0gICBU aGUgZm9sbG93aW5nIGVycm9ycyBmb2xsb3cgdGhpcyBiYXNpYyBwYXR0ZXJuOg0NICAgYmFk UmVxdWVzdA0NICAgICAgVGhlIHNlcnZlciBjb3VsZCBub3QgcGFyc2Ugb3Igb3RoZXJ3aXNl IHVuZGVyc3RhbmQgYSByZXF1ZXN0LA0gICAgICBlLmcuLCBiZWNhdXNlIHRoZSBYTUwgd2Fz IG1hbGZvcm1lZC4NDQ0gICBmb3JiaWRkZW4NDSAgICAgIFRoZSBzZXJ2ZXIgcmVmdXNlZCB0 byBzZW5kIGFuIGFuc3dlci4gIFRoaXMgZ2VuZXJhbGx5IG9ubHkgb2NjdXJzDSAgICAgIGZv ciByZWN1cnNpdmUgcXVlcmllcywgbmFtZWx5IGlmIHRoZSBjbGllbnQgdHJpZWQgdG8gY29u dGFjdCB0aGUNICAgICAgYXV0aG9yaXRhdGl2ZSBzZXJ2ZXIgYW5kIHdhcyByZWZ1c2VkLiAg KEZvciBIVFRQIGFzIHRoZSB1bmRlcmx5aW5nDSAgICAgIHByb3RvY29sLCBhbiBIVFRQIDQw MSBlcnJvciB3b3VsZCBiZSByZXR1cm5lZC4pDQ0NICAgaW50ZXJuYWxFcnJvcg0NICAgICAg VGhlIHNlcnZlciBjb3VsZCBub3Qgc2F0aXNmeSBhIHJlcXVlc3QgZHVlIHRvIG1pc2NvbmZp Z3VyYXRpb24gb3INICAgICAgb3RoZXIgb3BlcmF0aW9uYWwgYW5kIG5vbi1wcm90b2NvbCBy ZWxhdGVkIHJlYXNvbnMuDQ0NICAgbG9jYXRpb25Qcm9maWxlVW5yZWNvZ25pemVkDQ0gICAg ICBOb25lIG9mIHRoZSBwcm9maWxlcyBpbiB0aGUgcmVxdWVzdCB3ZXJlIHJlY29nbml6ZWQg YnkgdGhlIHNlcnZlcg0gICAgICAoc2VlIFNlY3Rpb24gMTIpLg0NDQ1IYXJkaWUsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFn ZSAzNl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAg ICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICBsb2NhdGlvbkludmFsaWQNDSAgICAg IFRoZSBnZW9kZXRpYyBsb2NhdGlvbiBpbiB0aGUgcmVxdWVzdCB3YXMgaW52YWxpZCwgZS5n LiwgYmVjYXVzZQ0gICAgICB0aGUgbG9uZ2l0dWRlIG9yIGxhdGl0dWRlIHZhbHVlcyBmYWxs IG91dHNpZGUgdGhlIGFjY2VwdGFibGUNICAgICAgcmFuZ2VzLg0NDSAgIFNSU0ludmFsaWQN DSAgICAgIFRoZSBzcGF0aWFsIHJlZmVyZW5jZSBzeXN0ZW0gKFNSUykgY29udGFpbmVkIGlu IHRoZSBsb2NhdGlvbg0gICAgICBlbGVtZW50IHdhcyBub3QgcmVjb2duaXplZCBvciBkb2Vz IG5vdCBtYXRjaCB0aGUgbG9jYXRpb24gcHJvZmlsZS4NDQ0gICBsb29wDQ0gICAgICBEdXJp bmcgYSByZWN1cnNpdmUgcXVlcnksIHRoZSBzZXJ2ZXIgd2FzIGFib3V0IHRvIHZpc2l0IGEg c2VydmVyDSAgICAgIHRoYXQgd2FzIGFscmVhZHkgaW4gdGhlIHNlcnZlciBsaXN0IGluIHRo ZSA8cGF0aD4gZWxlbWVudCwNICAgICAgaW5kaWNhdGluZyBhIHJlcXVlc3QgbG9vcC4NDQ0g ICBub3RGb3VuZA0NICAgICAgVGhlIHNlcnZlciBjb3VsZCBub3QgZmluZCBhbiBhbnN3ZXIg dG8gdGhlIHF1ZXJ5Lg0NDSAgIHNlcnZlckVycm9yDQ0gICAgICBBbiBhbnN3ZXIgd2FzIHJl Y2VpdmVkIGZyb20gYW5vdGhlciBMb1NUIHNlcnZlciwgYnV0IGl0IGNvdWxkIG5vdA0gICAg ICBiZSBwYXJzZWQgb3Igb3RoZXJ3aXNlIHVuZGVyc3Rvb2QuICBUaGlzIGVycm9yIG9jY3Vy cyBvbmx5IGZvcg0gICAgICByZWN1cnNpdmUgcXVlcmllcy4NDQ0gICBzZXJ2ZXJUaW1lb3V0 DQ0gICAgICBBIHRpbWUgb3V0IG9jY3VycmVkIGJlZm9yZSBhbiBhbnN3ZXIgd2FzIHJlY2Vp dmVkLg0NDSAgIHNlcnZpY2VOb3RJbXBsZW1lbnRlZA0NICAgICAgVGhlIHJlcXVlc3RlZCBz ZXJ2aWNlIFVSTiBpcyBub3QgaW1wbGVtZW50ZWQgYW5kIG5vIHN1YnN0aXR1dGlvbg0gICAg ICB3YXMgYXZhaWxhYmxlLg0NDSAgIEFuIGV4YW1wbGUgaXMgYmVsb3c6DQ0NDQ0NDQ1IYXJk aWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAg ICAgICBbUGFnZSAzN10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9T VCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICA8P3htbCB2ZXJzaW9u PSIxLjAiIGVuY29kaW5nPSJVVEYtOCI/Pg0gICA8ZXJyb3JzIHhtbG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOmxvc3QxIg0gICAgIHNvdXJjZT0icmVzb2x2ZXIuZXhhbXBsZSI+DSAg ICAgIDxpbnRlcm5hbEVycm9yIG1lc3NhZ2U9IlNvZnR3YXJlIGJ1Zy4iIHhtbDpsYW5nPSJl biIvPg0gICA8L2Vycm9ycz4NDSAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxODogRXhhbXBs ZSBvZiBhbiBlcnJvciByZXNvbnNlDQ0xMy4yLiAgV2FybmluZ3MNDSAgIEEgcmVzcG9uc2Ug TUFZIGNvbnRhaW4gemVybyBvciBtb3JlIHdhcm5pbmdzLiAgVGhpcyBwYXR0ZXJuIGRlZmlu ZXMgYQ0gICAnbWVzc2FnZScgYXR0cmlidXRlIGNvbnRhaW5pbmcgaHVtYW4gcmVhZGFibGUg dGV4dCBhbmQgYW4gJ3htbDpsYW5nJw0gICBhdHRyaWJ1dGUgZGVub3RpbmcgdGhlIGxhbmd1 YWdlIG9mIHRoZSBodW1hbiByZWFkYWJsZSB0ZXh0LiAgT25lIG9yDSAgIG1vcmUgc3VjaCB3 YXJuaW5nIGVsZW1lbnRzIGFyZSBjb250YWluZWQgaW4gdGhlIDx3YXJuaW5ncz4gZWxlbWVu dC4NDSAgIFRoaXMgdmVyc2lvbiBvZiB0aGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBkZWZp bmUgYW55IHdhcm5pbmcNICAgZWxlbWVudHMuDQ0xMy4zLiAgUmVkaXJlY3RzDQ0gICBBIExv U1Qgc2VydmVyIGNhbiByZXNwb25kIGluZGljYXRpbmcgdGhhdCB0aGUgcXVlcmllciBzaG91 bGQgcmVkaXJlY3QNICAgdGhlIHF1ZXJ5IHRvIGFub3RoZXIgc2VydmVyLCB1c2luZyB0aGUg PHJlZGlyZWN0PiBlbGVtZW50LiAgVGhlDSAgIGVsZW1lbnQgaW5jbHVkZXMgYSAndGFyZ2V0 JyBhdHRyaWJ1dGUgaW5kaWNhdGluZyB0aGUgTG9TVCBhcHBsaWNhdGlvbg0gICB1bmlxdWUg c3RyaW5nIChzZWUgU2VjdGlvbiA0KSB0aGF0IHRoZSBjbGllbnQgU0hPVUxEIGJlIGNvbnRh Y3RpbmcNICAgbmV4dCwgYXMgd2VsbCBhcyB0aGUgJ3NvdXJjZScgYXR0cmlidXRlIGluZGlj YXRpbmcgdGhlIHNlcnZlciB0aGF0DSAgIGdlbmVyYXRlZCB0aGUgcmVkaXJlY3QgcmVzcG9u c2UgYW5kIGEgJ21lc3NhZ2UnIGF0dHJpYnV0ZSBleHBsYWluaW5nDSAgIHRoZSByZWFzb24g Zm9yIHRoZSByZWRpcmVjdCByZXNwb25zZS4gIER1cmluZyBhIHJlY3Vyc2l2ZSBxdWVyeSwg YQ0gICBzZXJ2ZXIgcmVjZWl2aW5nIGEgPHJlZGlyZWN0PiByZXNwb25zZSBjYW4gZGVjaWRl IHdoZXRoZXIgaXQgd2FudHMgdG8NICAgZm9sbG93IHRoZSByZWRpcmVjdGlvbiBvciBzaW1w bHkgcmV0dXJuIHRoZSByZXNwb25zZSB0byBpdHMgdXBzdHJlYW0NICAgcXVlcmllci4NDSAg IEFuIGV4YW1wbGUgaXMgYmVsb3c6DQ0NICAgPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu Zz0iVVRGLTgiPz4NICAgPHJlZGlyZWN0IHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5z Omxvc3QxIg0gICAgIHRhcmdldD0iZWFzdHBzYXAuZXhhbXBsZSINICAgICBzb3VyY2U9Indl c3Rwc2FwLmV4YW1wbGUiDSAgICAgbWVzc2FnZT0iV2UgaGF2ZSB0ZW1wb3JhcmlseSBmYWls ZWQgb3Zlci4iIHhtbDpsYW5nPSJlbiIvPg0NICAgICAgICAgICAgICAgICBGaWd1cmUgMTk6 IEV4YW1wbGUgb2YgYSByZWRpcmVjdCByZXNvbnNlBQ0NDQ0NDQ0NDQ0NSGFyZGllLCBldCBh bC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1Bh Z2UgMzhdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAg ICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NMTQuICBMb1NUIFRyYW5zcG9ydA0NICAg TG9TVCBuZWVkcyBhbiB1bmRlcmx5aW5nIHByb3RvY29sIHRyYW5zcG9ydCBtZWNoYW5pc21z IHRvIGNhcnJ5DSAgIHJlcXVlc3RzIGFuZCByZXNwb25zZXMuICBUaGlzIGRvY3VtZW50IGRl ZmluZXMgdGhlIHVzZSBvZiBMb1NUIG92ZXINICAgSFRUUCBhbmQgTG9TVCBvdmVyIEhUVFAt b3Zlci1UTFM7IG90aGVyIG1lY2hhbmlzbXMgYXJlIGxlZnQgdG8gZnV0dXJlDSAgIGRvY3Vt ZW50cy4gIFRoZSBhdmFpbGFibGUgdHJhbnNwb3J0IG1lY2hhbmlzbXMgYXJlIGRldGVybWlu ZWQgdGhyb3VnaA0gICB0aGUgdXNlIG9mIHRoZSBMb1NUIFUtTkFQVFIgYXBwbGljYXRpb24u ICBJbiBwcm90b2NvbHMgdGhhdCBzdXBwb3J0DSAgIGNvbnRlbnQgdHlwZSBpbmRpY2F0aW9u LCBMb1NUIHVzZXMgdGhlIG1lZGlhIHR5cGUgYXBwbGljYXRpb24vDSAgIGxvc3QreG1sLg0N ICAgV2hlbiB1c2luZyBIVFRQIFszXSBhbmQgSFRUUC1vdmVyLVRMUyBbNF0sIExvU1QgcmVx dWVzdHMgdXNlIHRoZSBIVFRQDSAgIFBPU1QgbWV0aG9kLiAgQWxsIEhUVFAgcmVzcG9uc2Vz IGFyZSBhcHBsaWNhYmxlLiAgVGhlIEhUVFAgVVJMIGlzDSAgIGRlcml2ZWQgZnJvbSB0aGUg TG9TVCBzZXJ2ZXIgbmFtZSB2aWEgVS1OQVBUUiBhcHBsaWNhdGlvbiwgYXMNICAgZGlzY3Vz c2VkIGFib3ZlLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NSGFyZGll LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAg ICAgW1BhZ2UgMzldDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1Qg ICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NMTUuICBSZWxheCBORyBTY2hl bWENDSAgIFRoaXMgc2VjdGlvbiBwcm92aWRlcyB0aGUgUmVsYXggTkcgc2NoZW1hIHVzZWQg YnkgTG9TVCBwcm90b2NvbCBpbg0gICB0aGUgY29tcGFjdCBmb3JtLiAgVGhlIHZlcmJvc2Ug Zm9ybSBpcyBpbmNsdWRlZCBpbiBBcHBlbmRpeCBBLg0NDQ1uYW1lc3BhY2UgYSA9ICJodHRw Oi8vcmVsYXhuZy5vcmcvbnMvY29tcGF0aWJpbGl0eS9hbm5vdGF0aW9ucy8xLjAiDWRlZmF1 bHQgbmFtZXNwYWNlIG5zMSA9ICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIg0NDSMj DSMjICAgICAgIExvY2F0aW9uLXRvLVNlcnZpY2UgVHJhbnNsYXRpb24gUHJvdG9jb2wgKExv U1QpDSMjDSMjICAgICAgIEEgTG9TVCBYTUwgaW5zdGFuY2UgaGFzIHRocmVlIHJlcXVlc3Qg dHlwZXMsIGVhY2ggd2l0aA0jIyAgICAgICBhIGNvb3Jlc3BvbmRpbmcgcmVzcG9uc2UgdHlw ZTogZmluZCBzZXJ2aWNlLCBsaXN0IHNlcnZpY2VzLA0jIyAgICAgICBhbmQgZ2V0IHNlcnZp Y2UgYm91bmRhcnkuDSMjDXN0YXJ0ID0NICBmaW5kU2VydmljZQ0gIHwgbGlzdFNlcnZpY2Vz DSAgfCBsaXN0U2VydmljZXNCeUxvY2F0aW9uDSAgfCBnZXRTZXJ2aWNlQm91bmRhcnkNICB8 IGZpbmRTZXJ2aWNlUmVzcG9uc2UNICB8IGxpc3RTZXJ2aWNlc1Jlc3BvbnNlDSAgfCBsaXN0 U2VydmljZXNCeUxvY2F0aW9uUmVzcG9uc2UNICB8IGdldFNlcnZpY2VCb3VuZGFyeVJlc3Bv bnNlDSAgfCBlcnJvcnMNICB8IHJlZGlyZWN0DQ0jIw0jIyAgICAgICBUaGUgcXVlcmllcy4N IyMNZGl2IHsNICBmaW5kU2VydmljZSA9DSAgICBlbGVtZW50IGZpbmRTZXJ2aWNlIHsNICAg ICAgZWxlbWVudCBsb2NhdGlvbiB7IGxvY2F0aW9uSW5mb3JtYXRpb24gfSssDSAgICAgIGNv bW1vblJlcXVlc3RQYXR0ZXJuLA0gICAgICBhdHRyaWJ1dGUgdmFsaWRhdGVMb2NhdGlvbiB7 DSAgICAgICAgeHNkOmJvb2xlYW4gPj4gYTpkZWZhdWx0VmFsdWUgWyAiZmFsc2UiIF0NICAg ICAgfT8sDSAgICAgIGF0dHJpYnV0ZSBzZXJ2aWNlQm91bmRhcnkgew0gICAgICAgICgicmVm ZXJlbmNlIiB8ICJ2YWx1ZSIpID4+IGE6ZGVmYXVsdFZhbHVlIFsgInJlZmVyZW5jZSIgXQ0g ICAgICB9PywNICAgICAgYXR0cmlidXRlIHJlY3Vyc2l2ZSB7IHhzZDpib29sZWFuID4+IGE6 ZGVmYXVsdFZhbHVlIFsgImZhbHNlIiBdIH0/DSAgICB9DSAgbGlzdFNlcnZpY2VzID0gZWxl bWVudCBsaXN0U2VydmljZXMgeyBjb21tb25SZXF1ZXN0UGF0dGVybiB9DSAgbGlzdFNlcnZp Y2VzQnlMb2NhdGlvbiA9DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDQwXQ0MDUludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUg MjAwNw0NDSAgICBlbGVtZW50IGxpc3RTZXJ2aWNlc0J5TG9jYXRpb24gew0gICAgICBlbGVt ZW50IGxvY2F0aW9uIHsgbG9jYXRpb25JbmZvcm1hdGlvbiB9KiwNICAgICAgY29tbW9uUmVx dWVzdFBhdHRlcm4sDSAgICAgIGF0dHJpYnV0ZSByZWN1cnNpdmUgeyB4c2Q6Ym9vbGVhbiA+ PiBhOmRlZmF1bHRWYWx1ZSBbICJ0cnVlIiBdIH0/DSAgICB9DSAgZ2V0U2VydmljZUJvdW5k YXJ5ID0NICAgIGVsZW1lbnQgZ2V0U2VydmljZUJvdW5kYXJ5IHsgc2VydmljZUJvdW5kYXJ5 S2V5LCBleHRlbnNpb25Qb2ludCB9DX0NDSMjDSMjICAgICAgIFRoZSByZXNwb25zZXMuDSMj DWRpdiB7DSAgZmluZFNlcnZpY2VSZXNwb25zZSA9DSAgICBlbGVtZW50IGZpbmRTZXJ2aWNl UmVzcG9uc2Ugew0gICAgICBtYXBwaW5nKywgbG9jYXRpb25WYWxpZGF0aW9uPywgY29tbW9u UmVzcG9uc2VQYXR0ZXJuDSAgICB9DSAgbGlzdFNlcnZpY2VzUmVzcG9uc2UgPQ0gICAgZWxl bWVudCBsaXN0U2VydmljZXNSZXNwb25zZSB7IHNlcnZpY2VMaXN0LCBjb21tb25SZXNwb25z ZVBhdHRlcm4gfQ0gIGxpc3RTZXJ2aWNlc0J5TG9jYXRpb25SZXNwb25zZSA9DSAgICBlbGVt ZW50IGxpc3RTZXJ2aWNlc0J5TG9jYXRpb25SZXNwb25zZSB7DSAgICAgIHNlcnZpY2VMaXN0 LCBjb21tb25SZXNwb25zZVBhdHRlcm4NICAgIH0NICBnZXRTZXJ2aWNlQm91bmRhcnlSZXNw b25zZSA9DSAgICBlbGVtZW50IGdldFNlcnZpY2VCb3VuZGFyeVJlc3BvbnNlIHsNICAgICAg c2VydmljZUJvdW5kYXJ5LCBjb21tb25SZXNwb25zZVBhdHRlcm4NICAgIH0NfQ0NIyMNIyMg ICAgICAgQSBwYXR0ZXJuIGNvbW1vbiB0byBzb21lIG9mIHRoZSBxdWVyaWVzLg0jIw1kaXYg ew0gIGNvbW1vblJlcXVlc3RQYXR0ZXJuID0gc2VydmljZSwgcGF0aD8sIGV4dGVuc2lvblBv aW50DX0NDSMjDSMjICAgICAgIEEgcGF0dGVybiBjb21tb24gdG8gcmVzcG9uc2VzLg0jIw1k aXYgew0gIGNvbW1vblJlc3BvbnNlUGF0dGVybiA9IHdhcm5pbmdzKiwgcGF0aCwgZXh0ZW5z aW9uUG9pbnQNfQ0NIyMNIyMgICAgICAgTG9jYXRpb24gSW5mb3JtYXRpb24NIyMNZGl2IHsN ICBsb2NhdGlvbkluZm9ybWF0aW9uID0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNDFdDQwNSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAg ICAgSnVuZSAyMDA3DQ0NICAgIGV4dGVuc2lvblBvaW50KywNICAgIGF0dHJpYnV0ZSBpZCB7 IHhzZDp0b2tlbiB9LA0gICAgYXR0cmlidXRlIHByb2ZpbGUgeyB4c2Q6Tk1UT0tFTiB9Pw19 DQ0jIw0jIyAgICAgICBTZXJ2aWNlIEJvdW5kYXJ5DSMjDWRpdiB7DSAgc2VydmljZUJvdW5k YXJ5ID0gZWxlbWVudCBzZXJ2aWNlQm91bmRhcnkgeyBsb2NhdGlvbkluZm9ybWF0aW9uIH0r DX0NDSMjDSMjICAgICAgIFNlcnZpY2UgQm91bmRhcnkgUmVmZXJlbmNlDSMjDWRpdiB7DSAg c2VydmljZUJvdW5kYXJ5UmVmZXJlbmNlID0NICAgIGVsZW1lbnQgc2VydmljZUJvdW5kYXJ5 UmVmZXJlbmNlIHsNICAgICAgc291cmNlLCBzZXJ2aWNlQm91bmRhcnlLZXksIGV4dGVuc2lv blBvaW50DSAgICB9DSAgc2VydmljZUJvdW5kYXJ5S2V5ID0gYXR0cmlidXRlIGtleSB7IHhz ZDp0b2tlbiB9DX0NDSMjDSMjICAgICAgIFBhdGggLQ0jIyAgICAgICBDb250YWlucyBhIGxp c3Qgb2YgdmlhIGVsZW1lbnRzIC0NIyMgICAgICAgcGxhY2VzIHRocm91Z2ggd2hpY2ggaW5m b3JtYXRpb24gZmxvd2VkDSMjDWRpdiB7DSAgcGF0aCA9DSAgICBlbGVtZW50IHBhdGggew0g ICAgICBlbGVtZW50IHZpYSB7IHNvdXJjZSwgZXh0ZW5zaW9uUG9pbnQgfSsNICAgIH0NfQ0N IyMNIyMgICAgICAgRXhwaXJlcyBwYXR0ZXJuDSMjDWRpdiB7DSAgZXhwaXJlcyA9DSAgICBh dHRyaWJ1dGUgZXhwaXJlcyB7IHhzZDpkYXRlVGltZSB8ICJOTy1DQUNIRSIgfCAiTk8tRVhQ SVJBVElPTiIgfQ19DQ0jIw0jIyAgICAgICBBIFFOYW1lIGxpc3QNIyMNZGl2IHsNICBxbmFt ZUxpc3QgPSBsaXN0IHsgeHNkOlFOYW1lKiB9DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAg IEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDQyXQ0MDUlu dGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAg ICAgICAgIEp1bmUgMjAwNw0NDX0NDSMjDSMjICAgICAgIEEgbG9jYXRpb24tdG8tc2Vydmlj ZSBtYXBwaW5nLg0jIw1kaXYgew0gIG1hcHBpbmcgPQ0gICAgZWxlbWVudCBtYXBwaW5nIHsN ICAgICAgZWxlbWVudCBkaXNwbGF5TmFtZSB7DSAgICAgICAgeHNkOnN0cmluZywNICAgICAg ICBhdHRyaWJ1dGUgeG1sOmxhbmcgeyB4c2Q6bGFuZ3VhZ2UgfQ0gICAgICB9KiwNICAgICAg c2VydmljZSwNICAgICAgKHNlcnZpY2VCb3VuZGFyeSB8IHNlcnZpY2VCb3VuZGFyeVJlZmVy ZW5jZSk/LA0gICAgICBlbGVtZW50IHVyaSB7IHhzZDphbnlVUkkgfSosDSAgICAgIGVsZW1l bnQgc2VydmljZU51bWJlciB7DSAgICAgICAgeHNkOnN0cmluZyB7IHBhdHRlcm4gPSAiWzAt OSojXSsiIH0NICAgICAgfT8sDSAgICAgIGV4dGVuc2lvblBvaW50LA0gICAgICBleHBpcmVz LA0gICAgICBhdHRyaWJ1dGUgbGFzdFVwZGF0ZWQgeyB4c2Q6ZGF0ZVRpbWUgfSwNICAgICAg c291cmNlLA0gICAgICBhdHRyaWJ1dGUgc291cmNlSWQgeyB4c2Q6dG9rZW4gfSwNICAgICAg bWVzc2FnZQ0gICAgfQ19DQ0jIw0jIyAgICAgICBMb2NhdGlvbiB2YWxpZGF0aW9uDSMjDWRp diB7DSAgbG9jYXRpb25WYWxpZGF0aW9uID0NICAgIGVsZW1lbnQgbG9jYXRpb25WYWxpZGF0 aW9uIHsNICAgICAgZWxlbWVudCB2YWxpZCB7IHFuYW1lTGlzdCB9PywNICAgICAgZWxlbWVu dCBpbnZhbGlkIHsgcW5hbWVMaXN0IH0/LA0gICAgICBlbGVtZW50IHVuY2hlY2tlZCB7IHFu YW1lTGlzdCB9PywNICAgICAgZXh0ZW5zaW9uUG9pbnQNICAgIH0NfQ0NIyMNIyMgICAgICAg RXJyb3JzIGFuZCBXYXJuaW5ncyBDb250YWluZXIuDSMjDWRpdiB7DSAgZXJyb3JDb250YWlu ZXIgPQ0gICAgKGJhZFJlcXVlc3Q/DSAgICAgJiBpbnRlcm5hbEVycm9yPw0gICAgICYgc2Vy dmljZVN1YnN0aXR1dGlvbj8NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBE ZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNDNdDQwNSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVu ZSAyMDA3DQ0NICAgICAmIGZvcmJpZGRlbj8NICAgICAmIG5vdEZvdW5kPw0gICAgICYgbG9v cD8NICAgICAmIHNlcnZpY2VOb3RJbXBsZW1lbnRlZD8NICAgICAmIHNlcnZlclRpbWVvdXQ/ DSAgICAgJiBzZXJ2ZXJFcnJvcj8NICAgICAmIGxvY2F0aW9uSW52YWxpZD8NICAgICAmIGxv Y2F0aW9uUHJvZmlsZVVucmVjb2duaXplZD8pLA0gICAgZXh0ZW5zaW9uUG9pbnQsDSAgICBz b3VyY2UNICBlcnJvcnMgPSBlbGVtZW50IGVycm9ycyB7IGVycm9yQ29udGFpbmVyIH0NICB3 YXJuaW5ncyA9IGVsZW1lbnQgd2FybmluZ3MgeyBlcnJvckNvbnRhaW5lciB9DX0NDSMjDSMj ICAgICAgIEJhc2ljIEVycm9ycw0jIw1kaXYgew0NICAjIw0gICMjICAgICAgICAgRXJyb3Ig cGF0dGVybi4NICAjIw0gIGJhc2ljRXJyb3IgPSBtZXNzYWdlLCBleHRlbnNpb25Qb2ludA0g IGJhZFJlcXVlc3QgPSBlbGVtZW50IGJhZFJlcXVlc3QgeyBiYXNpY0Vycm9yIH0NICBpbnRl cm5hbEVycm9yID0gZWxlbWVudCBpbnRlcm5hbEVycm9yIHsgYmFzaWNFcnJvciB9DSAgc2Vy dmljZVN1YnN0aXR1dGlvbiA9IGVsZW1lbnQgc2VydmljZVN1YnN0aXR1dGlvbiB7IGJhc2lj RXJyb3IgfQ0gIGZvcmJpZGRlbiA9IGVsZW1lbnQgZm9yYmlkZGVuIHsgYmFzaWNFcnJvciB9 DSAgbm90Rm91bmQgPSBlbGVtZW50IG5vdEZvdW5kIHsgYmFzaWNFcnJvciB9DSAgbG9vcCA9 IGVsZW1lbnQgbG9vcCB7IGJhc2ljRXJyb3IgfQ0gIHNlcnZpY2VOb3RJbXBsZW1lbnRlZCA9 IGVsZW1lbnQgc2VydmljZU5vdEltcGxlbWVudGVkIHsgYmFzaWNFcnJvciB9DSAgc2VydmVy VGltZW91dCA9IGVsZW1lbnQgc2VydmVyVGltZW91dCB7IGJhc2ljRXJyb3IgfQ0gIHNlcnZl ckVycm9yID0gZWxlbWVudCBzZXJ2ZXJFcnJvciB7IGJhc2ljRXJyb3IgfQ0gIGxvY2F0aW9u SW52YWxpZCA9IGVsZW1lbnQgbG9jYXRpb25JbnZhbGlkIHsgYmFzaWNFcnJvciB9DSAgbG9j YXRpb25Qcm9maWxlVW5yZWNvZ25pemVkID0NICAgIGVsZW1lbnQgbG9jYXRpb25Qcm9maWxl VW5yZWNvZ25pemVkIHsNICAgICAgYXR0cmlidXRlIHVuc3VwcG9ydGVkUHJvZmlsZXMgeyB4 c2Q6Tk1UT0tFTlMgfSwNICAgICAgYmFzaWNFcnJvcg0gICAgfQ19DQ0jIw0jIyAgICAgICBS ZWRpcmVjdC4NIyMNZGl2IHsNDSAgIyMNICAjIyAgICAgICAgIFJlZGlyZWN0IHBhdHRlcm4N ICAjIw0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAy MDA3ICAgICAgICAgICAgICBbUGFnZSA0NF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAg ICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gIHJl ZGlyZWN0ID0NICAgIGVsZW1lbnQgcmVkaXJlY3Qgew0gICAgICBhdHRyaWJ1dGUgdGFyZ2V0 IHsgYXBwVW5pcXVlU3RyaW5nIH0sDSAgICAgIHNvdXJjZSwNICAgICAgbWVzc2FnZSwNICAg ICAgZXh0ZW5zaW9uUG9pbnQNICAgIH0NfQ0NIyMNIyMgICAgICAgU29tZSBjb21tb24gcGF0 dGVybnMuDSMjDWRpdiB7DSAgbWVzc2FnZSA9DSAgICAoYXR0cmlidXRlIG1lc3NhZ2UgeyB4 c2Q6c3RyaW5nIH0sDSAgICAgYXR0cmlidXRlIHhtbDpsYW5nIHsgeHNkOmxhbmd1YWdlIH0p Pw0gIHNlcnZpY2UgPSBlbGVtZW50IHNlcnZpY2UgeyB4c2Q6YW55VVJJIH0/DSAgYXBwVW5p cXVlU3RyaW5nID0NICAgIHhzZDpzdHJpbmcgeyBwYXR0ZXJuID0gIihbYS16QS1aMC05XC1d K1wuKStbYS16QS1aMC05XSsiIH0NICBzb3VyY2UgPSBhdHRyaWJ1dGUgc291cmNlIHsgYXBw VW5pcXVlU3RyaW5nIH0NICBzZXJ2aWNlTGlzdCA9DSAgICBlbGVtZW50IHNlcnZpY2VMaXN0 IHsNICAgICAgbGlzdCB7IHhzZDphbnlVUkkqIH0NICAgIH0NfQ0NIyMNIyMgICAgICAgUGF0 dGVybnMgZm9yIGluY2x1c2lvbiBvZiBlbGVtZW50cyBmcm9tIHNjaGVtYXMgaW4NIyMgICAg ICAgb3RoZXIgbmFtZXNwYWNlcy4NIyMNZGl2IHsNDSAgIyMNICAjIyAgICAgICAgIEFueSBl bGVtZW50IG5vdCBpbiB0aGUgTG9TVCBuYW1lc3BhY2UuDSAgIyMNICBub3RMb3N0ID0gZWxl bWVudCAqIC0gKG5zMToqIHwgbnMxOiopIHsgYW55RWxlbWVudCB9DQ0gICMjDSAgIyMgICAg ICAgICBBIHdpbGRjYXJkIHBhdHRlcm4gZm9yIGluY2x1ZGluZyBhbnkgZWxlbWVudA0gICMj ICAgICAgICAgZnJvbSBhbnkgb3RoZXIgbmFtZXNwYWNlLg0gICMjDSAgYW55RWxlbWVudCA9 DSAgICAoZWxlbWVudCAqIHsgYW55RWxlbWVudCB9DSAgICAgfCBhdHRyaWJ1dGUgKiB7IHRl eHQgfQ0gICAgIHwgdGV4dCkqDQ0gICMjDSAgIyMgICAgICAgICBBIHBvaW50IHdoZXJlIGZ1 dHVyZSBleHRlbnNpb25zDQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDQ1XQ0MDUludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUg MjAwNw0NDSAgIyMgICAgICAgICAoZWxlbWVudHMgZnJvbSBvdGhlciBuYW1lc3BhY2VzKQ0g ICMjICAgICAgICAgY2FuIGJlIGFkZGVkLg0gICMjDSAgZXh0ZW5zaW9uUG9pbnQgPSBub3RM b3N0Kg19DQ0gICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIwOiBSZWxheE5HIHNj aGVtYQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUhhcmRp ZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAg ICAgIFtQYWdlIDQ2XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NU ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDTE2LiAgSW50ZXJuYXRpb25h bGl6YXRpb24gQ29uc2lkZXJhdGlvbnMNDSAgIFRoZSBMb1NUIHByb3RvY29sIGlzIG1vc3Rs eSBtZWFudCBmb3IgbWFjaGluZS10by1tYWNoaW5lDSAgIGNvbW11bmljYXRpb25zOyBhcyBz dWNoLCBtb3N0IG9mIGl0cyBlbGVtZW50cyBhcmUgdG9rZW5zIG5vdCBtZWFudA0gICBmb3Ig ZGlyZWN0IGh1bWFuIGNvbnN1bXB0aW9uLiAgSWYgdGhlc2UgdG9rZW5zIGFyZSBwcmVzZW50 ZWQgdG8gdGhlDSAgIGVuZCB1c2VyLCBzb21lIGxvY2FsaXphdGlvbiBtYXkgbmVlZCB0byBv Y2N1ci4gIFRoZSBjb250ZW50IG9mIHRoZQ0gICA8ZGlzcGxheU5hbWU+IGVsZW1lbnQgYW5k IHRoZSAnbWVzc2FnZScgYXR0cmlidXRlcyBtYXkgYmUgZGlzcGxheWVkDSAgIHRvIHRoZSBl bmQgdXNlciwgYW5kIHRoZXkgYXJlIHRodXMgY29tcGxleCB0eXBlcyBkZXNpZ25lZCBmb3Ig dGhpcw0gICBwdXJwb3NlLg0NICAgTG9TVCBleGNoYW5nZXMgaW5mb3JtYXRpb24gdXNpbmcg WE1MLiAgQWxsIFhNTCBwcm9jZXNzb3JzIGFyZQ0gICByZXF1aXJlZCB0byB1bmRlcnN0YW5k IFVURi04IGFuZCBVVEYtMTYgZW5jb2RpbmdzLCBhbmQgdGhlcmVmb3JlIGFsbA0gICBMb1NU IGNsaWVudHMgYW5kIHNlcnZlcnMgTVVTVCB1bmRlcnN0YW5kIFVURi04IGFuZCBVVEYtMTYg ZW5jb2RlZA0gICBYTUwuICBBZGRpdGlvbmFsbHksIExvU1Qgc2VydmVycyBhbmQgY2xpZW50 cyBNVVNUIE5PVCBlbmNvZGUgWE1MIHdpdGgNICAgZW5jb2RpbmdzIG90aGVyIHRoYW4gVVRG LTggb3IgVVRGLTE2Lg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJk aWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAg ICAgICBbUGFnZSA0N10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9T VCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0xNy4gIElBTkEgQ29uc2lk ZXJhdGlvbnMNDTE3LjEuICBVLU5BUFRSIFJlZ2lzdHJhdGlvbnMNDSAgIFRoaXMgZG9jdW1l bnQgcmVnaXN0ZXJzIHRoZSBmb2xsb3dpbmcgVS1OQVBUUiBhcHBsaWNhdGlvbiBzZXJ2aWNl DSAgIHRhZzoNDSAgIEFwcGxpY2F0aW9uIFNlcnZpY2UgVGFnOiAgTG9TVA0NICAgRGVmaW5p bmcgUHVibGljYXRpb246ICBUaGUgc3BlY2lmaWNhdGlvbiBjb250YWluZWQgd2l0aGluIHRo aXMNICAgICAgZG9jdW1lbnQuDQ0gICBUaGlzIGRvY3VtZW50IHJlZ2lzdGVycyB0aGUgZm9s bG93aW5nIFUtTkFQVFIgYXBwbGljYXRpb24gcHJvdG9jb2wNICAgdGFnczoNDSAgIG8NDSAg ICAgIEFwcGxpY2F0aW9uIFByb3RvY29sIFRhZzogIGh0dHANDSAgICAgIERlZmluaW5nIFB1 YmxpY2F0aW9uOiAgUkZDIDI2MTYgWzNdDQ0gICBvDQ0gICAgICBBcHBsaWNhdGlvbiBQcm90 b2NvbCBUYWc6ICBodHRwcw0NICAgICAgRGVmaW5pbmcgUHVibGljYXRpb246ICBSRkMgMjgx OCBbNF0NDTE3LjIuICBDb250ZW50LXR5cGUgcmVnaXN0cmF0aW9uIGZvciAnYXBwbGljYXRp b24vbG9zdCt4bWwnDQ0gICBUaGlzIHNwZWNpZmljYXRpb24gcmVxdWVzdHMgdGhlIHJlZ2lz dHJhdGlvbiBvZiBhIG5ldyBNSU1FIHR5cGUNICAgYWNjb3JkaW5nIHRvIHRoZSBwcm9jZWR1 cmVzIG9mIFJGQyA0Mjg4IFs3XSBhbmQgZ3VpZGVsaW5lcyBpbiBSRkMNICAgMzAyMyBbNV0u DQ0gICBNSU1FIG1lZGlhIHR5cGUgbmFtZTogIGFwcGxpY2F0aW9uDQ0NICAgTUlNRSBzdWJ0 eXBlIG5hbWU6ICBsb3N0K3htbA0NDSAgIE1hbmRhdG9yeSBwYXJhbWV0ZXJzOiAgbm9uZQ0N DSAgIE9wdGlvbmFsIHBhcmFtZXRlcnM6ICBjaGFyc2V0DQ0gICAgICBJbmRpY2F0ZXMgdGhl IGNoYXJhY3RlciBlbmNvZGluZyBvZiBlbmNsb3NlZCBYTUwuDQ0NDQ0NDUhhcmRpZSwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQ YWdlIDQ4XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAg ICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgIEVuY29kaW5nIGNvbnNpZGVyYXRp b25zOiAgVXNlcyBYTUwsIHdoaWNoIGNhbiBlbXBsb3kgOC1iaXQNICAgICAgY2hhcmFjdGVy cywgZGVwZW5kaW5nIG9uIHRoZSBjaGFyYWN0ZXIgZW5jb2RpbmcgdXNlZC4gIFNlZSBSRkMN ICAgICAgMzAyMyBbNV0sIFNlY3Rpb24gMy4yLg0NDSAgIFNlY3VyaXR5IGNvbnNpZGVyYXRp b25zOiAgVGhpcyBjb250ZW50IHR5cGUgaXMgZGVzaWduZWQgdG8gY2FycnkgTG9TVA0gICAg ICBwcm90b2NvbCBwYXlsb2Fkcy4NDQ0gICBJbnRlcm9wZXJhYmlsaXR5IGNvbnNpZGVyYXRp b25zOiAgTm9uZQ0NDQ0gICBQdWJsaXNoZWQgc3BlY2lmaWNhdGlvbjogIFJGQ1hYWFggW05P VEUgVE8gSUFOQS9SRkMtRURJVE9SOiBQbGVhc2UNICAgICAgcmVwbGFjZSBYWFhYIHdpdGgg dGhlIFJGQyBudW1iZXIgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLl0NDQ0gICBBcHBsaWNhdGlv bnMgd2hpY2ggdXNlIHRoaXMgbWVkaWEgdHlwZTogIEVtZXJnZW5jeSBhbmQgTG9jYXRpb24t YmFzZWQNICAgICAgU3lzdGVtcw0NDSAgIEFkZGl0aW9uYWwgaW5mb3JtYXRpb246DQ0gICAg ICBNYWdpYyBOdW1iZXI6ICBOb25lDQ0NICAgICAgRmlsZSBFeHRlbnNpb246ICAubG9zdHht bA0NDSAgICAgIE1hY2ludG9zaCBmaWxlIHR5cGUgY29kZTogICdURVhUJw0NDSAgIFBlcnNv bmFsIGFuZCBlbWFpbCBhZGRyZXNzIGZvciBmdXJ0aGVyIGluZm9ybWF0aW9uOiAgSGFubmVz DSAgICAgIFRzY2hvZmVuaWcsIEhhbm5lcy5Uc2Nob2ZlbmlnQHNpZW1lbnMuY29tDQ0NICAg SW50ZW5kZWQgdXNhZ2U6ICBMSU1JVEVEIFVTRQ0NDSAgIEF1dGhvcjoNDSAgICAgIFRoaXMg c3BlY2lmaWNhdGlvbiBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgSUVURiBFQ1JJVCB3b3JraW5n IGdyb3VwLA0gICAgICB3aXRoIG1haWxpbmcgbGlzdCBhZGRyZXNzIDxlY3JpdEBpZXRmLm9y Zz4uDQ0NDQ0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAy NSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNDldDQwNSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0N ICAgQ2hhbmdlIGNvbnRyb2xsZXI6DQ0gICAgICBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4N DTE3LjMuICBMb1NUIFJlbGF4IE5HIFNjaGVtYSBSZWdpc3RyYXRpb24NDSAgIFVSSTogIHVy bjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDENDSAgIFJlZ2lzdHJhbnQgQ29udGFjdDogIElF VEYgRUNSSVQgV29ya2luZyBHcm91cCwgSGFubmVzIFRzY2hvZmVuaWcNICAgICAgKEhhbm5l cy5Uc2Nob2ZlbmlnQHNpZW1lbnMuY29tKS4NDSAgIFJlbGF4IE5HIFNjaGVtYTogIFRoZSBS ZWxheCBORyBzY2hlbWEgdG8gYmUgcmVnaXN0ZXJlZCBpcyBjb250YWluZWQNICAgICAgaW4g U2VjdGlvbiAxNS4gIEl0cyBmaXJzdCBsaW5lIGlzDQ0gICBkZWZhdWx0IG5hbWVzcGFjZSA9 ICJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOmxvc3QxIg0NICAgICAgYW5kIGl0cyBsYXN0IGxp bmUgaXMNDSAgIH0NDTE3LjQuICBMb1NUIE5hbWVzcGFjZSBSZWdpc3RyYXRpb24NDSAgIFVS STogIHVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDENDSAgIFJlZ2lzdHJhbnQgQ29udGFj dDogIElFVEYgRUNSSVQgV29ya2luZyBHcm91cCwgSGFubmVzIFRzY2hvZmVuaWcNICAgICAg KEhhbm5lcy5Uc2Nob2ZlbmlnQHNpZW1lbnMuY29tKS4NDSAgIFhNTDoNDSAgIEJFR0lODSAg IDw/eG1sIHZlcnNpb249IjEuMCI/Pg0gICA8IURPQ1RZUEUgaHRtbCBQVUJMSUMgIi0vL1cz Qy8vRFREIFhIVE1MIEJhc2ljIDEuMC8vRU4iDSAgICAgImh0dHA6Ly93d3cudzMub3JnL1RS L3hodG1sLWJhc2ljL3hodG1sLWJhc2ljMTAuZHRkIj4NICAgPGh0bWwgeG1sbnM9Imh0dHA6 Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPg0gICA8aGVhZD4NICAgICA8bWV0YSBodHRwLWVx dWl2PSJjb250ZW50LXR5cGUiDSAgICAgICAgICAgY29udGVudD0idGV4dC9odG1sO2NoYXJz ZXQ9aXNvLTg4NTktMSIvPg0gICAgIDx0aXRsZT5Mb1NUIE5hbWVzcGFjZTwvdGl0bGU+DSAg IDwvaGVhZD4NICAgPGJvZHk+DSAgICAgPGgxPk5hbWVzcGFjZSBmb3IgTG9TVDwvaDE+DSAg ICAgPGgyPnVybjppZXRmOnBhcmFtczp4bWw6bnM6bG9zdDE8L2gyPg0gICA8cD5TZWUgPGEg aHJlZj0iW1VSTCBvZiBwdWJsaXNoZWQgUkZDXSI+UkZDWFhYWA0gICAgICAgW05PVEUgVE8g SUFOQS9SRkMtRURJVE9SOg0gICAgICAgIFBsZWFzZSByZXBsYWNlIFhYWFggd2l0aCB0aGUg UkZDIG51bWJlciBvZiB0aGlzDSAgICAgICBzcGVjaWZpY2F0aW9uLl08L2E+LjwvcD4NICAg PC9ib2R5Pg0gICA8L2h0bWw+DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg RGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDUwXQ0MDUludGVybmV0LURy YWZ0ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1 bmUgMjAwNw0NDSAgIEVORA0NMTcuNS4gIExvU1QgTG9jYXRpb24gUHJvZmlsZSBSZWdpc3Ry eQ0NICAgVGhpcyBkb2N1bWVudCBzZWVrcyB0byBjcmVhdGUgYSByZWdpc3RyeSBvZiBsb2Nh dGlvbiBwcm9maWxlIG5hbWVzDSAgIGZvciB0aGUgTG9TVCBwcm90b2NvbC4gIFByb2ZpbGUg bmFtZXMgYXJlIFhNTCB0b2tlbnMuICBUaGlzIHJlZ2lzdHJ5DSAgIHdpbGwgb3BlcmF0ZSBp biBhY2NvcmRhbmNlIHdpdGggUkZDIDI0MzQgWzJdLCBTdGFuZGFyZHMgQWN0aW9uLg0NICAg Z2VvZGV0aWMtMmQ6DQ0gICAgICBEZWZpbmVkIGluIFNlY3Rpb24gMTIuMi4NDQ0gICBjaXZp YzoNDSAgICAgIERlZmluZWQgaW4gU2VjdGlvbiAxMi40Lg0NICAgZ2VvZGV0aWMtMmQtcG9s eWdvbjoNDSAgICAgIERlZmluZWQgaW4gU2VjdGlvbiAxMi4zLg0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDQ0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJl ciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNTFdDQwNSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3 DQ0NMTguICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0NICAgVGhlcmUgYXJlIG11bHRpcGxl IHRocmVhdHMgdG8gdGhlIG92ZXJhbGwgc3lzdGVtIG9mIHdoaWNoIHNlcnZpY2UNICAgbWFw cGluZyBmb3JtcyBhIHBhcnQuICBBbiBhdHRhY2tlciB0aGF0IGNhbiBvYnRhaW4gc2Vydmlj ZSBjb250YWN0DSAgIFVSSXMgY2FuIHVzZSB0aG9zZSBVUklzIHRvIGF0dGVtcHQgdG8gZGlz cnVwdCB0aG9zZSBzZXJ2aWNlcy4gIEFuDSAgIGF0dGFja2VyIHRoYXQgY2FuIHByZXZlbnQg dGhlIGxvb2t1cCBvZiBjb250YWN0IFVSSXMgY2FuIGltcGFpciB0aGUNICAgcmVhY2hhYmls aXR5IG9mIHN1Y2ggc2VydmljZXMuICBBbiBhdHRhY2tlciB0aGF0IGNhbiBlYXZlc2Ryb3Ag b24gdGhlDSAgIGNvbW11bmljYXRpb24gcmVxdWVzdGluZyB0aGlzIGxvb2t1cCBjYW4gc3Vy bWlzZSB0aGUgZXhpc3RlbmNlIG9mIGFuDSAgIGVtZXJnZW5jeSBhbmQgcG9zc2libHkgaXRz IG5hdHVyZSwgYW5kIG1heSBiZSBhYmxlIHRvIHVzZSB0aGlzIHRvDSAgIGxhdW5jaCBhIHBo eXNpY2FsIGF0dGFjayBvbiB0aGUgY2FsbGVyLg0NICAgVG8gYXZvaWQgdGhhdCBhbiBhdHRh Y2tlciBjYW4gbW9kaWZ5IHRoZSBxdWVyeSBvciBpdHMgcmVzdWx0LCB0aGUgdXNlDSAgIG9m IGNoYW5uZWwgc2VjdXJpdHksIHN1Y2ggYXMgVExTLCBpcyBSRUNPTU1FTkRFRC4NDSAgIEdl bmVyYWxseSwgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gaXMgbm90IHJlcXVp cmVkIGZvcg0gICBtYXBwaW5nIHF1ZXJpZXMuICBJZiBpdCBpcywgYXV0aGVudGljYXRpb24g bWVjaGFuaXNtIG9mIHRoZQ0gICB1bmRlcmx5aW5nIHRyYW5zcG9ydCBtZWNoYW5pc20sIHN1 Y2ggYXMgSFRUUCBiYXNpYyBhbmQgZGlnZXN0DSAgIGF1dGhlbnRpY2F0aW9uLCBNQVkgYmUg dXNlZC4gIChCYXNpYyBhdXRoZW50aWNhdGlvbiBTSE9VTEQgb25seSBiZQ0gICB1c2VkIGlu IGNvbWJpbmF0aW9uIHdpdGggVExTLikNDSAgIEEgbW9yZSBkZXRhaWxlZCBkZXNjcmlwdGlv biBvZiB0aHJlYXRzIGFuZCBzZWN1cml0eSByZXF1aXJlbWVudHMgYXJlDSAgIHByb3ZpZGVk IGluIFsxNl0uDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NSGFyZGllLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2Ug NTJdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAg ICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NMTkuICBBY2tub3dsZWRnbWVudHMNDSAgIFdl IHdvdWxkIGxpa2UgdG8gdGhlIHRoYW5rIHRoZSBmb2xsb3dpbmcgd29ya2luZyBncm91cCBt ZW1iZXJzIGZvcg0gICB0aGUgZGV0YWlsZWQgcmV2aWV3IG9mIHByZXZpb3VzIExvU1QgZG9j dW1lbnQgdmVyc2lvbnM6DQ0gICBvICBNYXJ0aW4gVGhvbXNvbiAoUmV2aWV3IEp1bHkgMjAw NikNDSAgIG8gIEpvbmF0aGFuIFJvc2VuYmVyZyAoUmV2aWV3IEp1bHkgMjAwNikNDSAgIG8g IExlc2xpZSBEYWlnbGUgKFJldmlldyBTZXB0ZW1iZXIgMjAwNikNDSAgIG8gIFNoaWRhIFNj aHViZXJ0IChSZXZpZXcgTm92ZW1iZXIgMjAwNikNDSAgIG8gIE1hcnRpbiBUaG9tc29uIChS ZXZpZXcgRGVjZW1iZXIgMjAwNikNDSAgIG8gIEJhcmJhcmEgU3RhcmsgKFJldmlldyBKYW51 YXJ5IDIwMDcpDQ0gICBvICBQYXRyaWsgRmFlbHRzdHJvZW0gKFJldmlldyBKYW51YXJ5IDIw MDcNDSAgIG8gIFNoaWRhIFNjaHViZXJ0IChSZXZpZXcgSmFudWFyeSAyMDA3IGFzIGEgZGVz aWduYXRlZCBleHBlcnQNICAgICAgcmV2aWV3ZXIpDQ0gICBvICBKb25hdGhhbiBSb3NlbmJl cmcgKFJldmlldyBGZWJydWFyeSAyMDA3KQ0NICAgbyAgVG9tIFRheWxvciAoUmV2aWV3IEZl YnJ1YXJ5IDIwMDcpDQ0gICBvICBUaGVyZXNhIFJlZXNlIChSZXZpZXcgRmVicnVhcnkgMjAw NykNDSAgIG8gIFNoaWRhIFNjaHViZXJ0IChSZXZpZXcgRmVicnVhcnkgMjAwNykNDSAgIFdl IHdvdWxkIGFsc28gbGlrZSB0byB0aGFuayB0aGUgZm9sbG93aW5nIHdvcmtpbmcgZ3JvdXAg bWVtYmVycyBmb3INICAgdGhlaXIgaW5wdXQgdG8gc2VsZWN0ZWQgZGVzaWduIGFzcGVjdHMg b2YgdGhlIExvU1QgcHJvdG9jb2w6DQ0gICBvICBMZXNsaWUgRGFpZ2xlIGFuZCBNYXJ0aW4g VGhvbXNvbiAoRE5TLWJhc2VkIExvU1QgZGlzY292ZXJ5DSAgICAgIHByb2NlZHVyZSkNDSAg IG8gIEpvaG4gU2Nobml6bGVpbiAoYXV0aG9yaXRpdmUgTG9TVCBhbnN3ZXJzKQ0NICAgbyAg Um9oYW4gTWFoeSAoZGlzcGxheSBuYW1lcykNDSAgIG8gIEphbWVzIFBvbGsgKGVycm9yIGhh bmRsaW5nKQ0NICAgbyAgUm9uIFdhdHJvIGFuZCBSaWNoYXJkIEJhcm5lcyAoZXhwaXJ5IG9m IGNhY2hlZCBkYXRhKQ0NICAgbyAgU3RlcGhlbiBFZGdlLCBLZWl0aCBEcmFnZSwgVG9tIFRh eWxvciwgTWFydGluIFRob21zb24gYW5kIEphbWVzDSAgICAgIFdpbnRlcmJvdHRvbSAoSW5k aWNhdGlvbiBvZiBQU0FQIENvbmZpZGVuY2UgTGV2ZWwpDQ0NDQ0NSGFyZGllLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2Ug NTNdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAg ICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NICAgbyAgTWFydGluIFRob21zb24gKHNlcnZp Y2UgYm91bmRhcnkgcmVmZXJlbmNlcykNDSAgIG8gIE1hcnRpbiBUaG9tc29uIChzZXJ2aWNl IFVSTiBpbiBMb1NUIHJlc3BvbnNlIG1lc3NhZ2UpDQ0gICBvICBDdWxsZW4gSmVubmluZ3Mg KHNlcnZpY2UgYm91bmRhcmllcykNDSAgIG8gIENsaXZlIEQuVy4gRmVhdGhlciwgTWFydGlu IFRob21zb24gKFZhbGlkYXRpb24gRnVuY3Rpb25hbGl0eSkNDSAgIG8gIFJvZ2VyIE1hcnNo YWxsIChQU0FQIFByZWZlcmVuY2UgaW4gTG9TVCByZXNwb25zZSkNDSAgIG8gIEphbWVzIFdp bnRlcmJvdHRvbSwgTWFyYyBMaW5zbmVyLCBLZWl0aCBEcmFnZSwgVG9tLVBUIFRheWxvciwN ICAgICAgTWFydGluIFRob21zb24sIEpvaG4gU2Nobml6bGVpbiwgU2hpZGEgU2NodWJlcnQs IENsaXZlIEQuVy4NICAgICAgRmVhdGhlciwgUmljaGFyZCBTdGFzdG55LCBKb2huIEhlYXJ0 eSwgUm9nZXIgTWFyc2hhbGwsIEplYW4tDSAgICAgIEZyYW5jb2lzIE11bGUsIFBpZXJyZSBE ZXNqYXJkaW5zIChMb2NhdGlvbiBQcm9maWxlcykNDSAgIG8gIE1pY2hhZWwgSGFtbWVyLCBQ YXRyaWsgRmFlbHRzdHJvZW0sIFN0YXN0bnkgUmljaGFyZCwgVGhvbXNvbiwNICAgICAgTWFy dGluLCBSb2dlciBNYXJzaGFsbCwgVG9tLVBUIFRheWxvciwgU3BlbmNlciBEYXdraW5zLCBE cmFnZSwNICAgICAgS2VpdGggKExpc3QgU2VydmljZXMgZnVuY3Rpb25hbGl0eSkNDSAgIG8g IFRob21zb24sIE1hcnRpbiwgTWljaGFlbCBIYW1tZXIgKE1hcHBpbmcgb2YgU2VydmljZXMp DQ0gICBvICBTaGlkYSBTY2h1YmVydCwgSmFtZXMgV2ludGVyYm90dG9tLCBLZWl0aCBEcmFn ZSAoZGVmYXVsdCBzZXJ2aWNlDSAgICAgIFVSTikNDSAgIG8gIE90bWFyIExlbmRsIChMb1NU IGFnZ3JlZ2F0aW9uKQ0NICAgbyAgVG9tIFRheWxvciAoVGVybWlub2xvZ3kpDQ0gICBLbGF1 cyBEYXJpbGlvbiBhbmQgTWFyYyBMaW5zbmVyIHByb3ZpZGVkIG1pc2NlbGxhbmVvdXMgaW5w dXQgdG8gdGhlDSAgIGRlc2lnbiBvZiB0aGUgcHJvdG9jb2wuICBGaW5hbGx5LCB3ZSB3b3Vs ZCBsaWtlIHRvIHRoYW5rIEJyaWFuIFJvc2VuDSAgIHdobyBwYXJ0aWNpcGF0ZWQgaW4gYWxt b3N0IGV2ZXJ5IGRpc2N1c3Npb24gdGhyZWFkLg0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUhhcmRp ZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAg ICAgIFtQYWdlIDU0XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NU ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDTIwLiAgT3BlbiBJc3N1ZXMN DSAgIFBsZWFzZSBmaW5kIG9wZW4gaXNzdWVzIGF0OiBodHRwOi8vd3d3LmlldGYtZWNyaXQu b3JnOjgwODAvbG9zdC8NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwg MjAwNyAgICAgICAgICAgICAgW1BhZ2UgNTVdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAg ICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NMjEu ICBSZWZlcmVuY2VzDQ0yMS4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMNDSAgIFsxXSAgIEJy YWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZSBSZXF1 aXJlbWVudA0gICAgICAgICBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LCBNYXJjaCAxOTk3 Lg0NICAgWzJdICAgTmFydGVuLCBULiBhbmQgSC4gQWx2ZXN0cmFuZCwgIkd1aWRlbGluZXMg Zm9yIFdyaXRpbmcgYW4gSUFOQQ0gICAgICAgICBDb25zaWRlcmF0aW9ucyBTZWN0aW9uIGlu IFJGQ3MiLCBCQ1AgMjYsIFJGQyAyNDM0LA0gICAgICAgICBPY3RvYmVyIDE5OTguDQ0gICBb M10gICBGaWVsZGluZywgUi4sIEdldHR5cywgSi4sIE1vZ3VsLCBKLiwgRnJ5c3R5aywgSC4s IE1hc2ludGVyLCBMLiwNICAgICAgICAgTGVhY2gsIFAuLCBhbmQgVC4gQmVybmVycy1MZWUs ICJIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgLS0NICAgICAgICAgSFRUUC8xLjEiLCBS RkMgMjYxNiwgSnVuZSAxOTk5Lg0NICAgWzRdICAgUmVzY29ybGEsIEUuLCAiSFRUUCBPdmVy IFRMUyIsIFJGQyAyODE4LCBNYXkgMjAwMC4NDSAgIFs1XSAgIE11cmF0YSwgTS4sIFN0LiBM YXVyZW50LCBTLiwgYW5kIEQuIEtvaG4sICJYTUwgTWVkaWEgVHlwZXMiLA0gICAgICAgICBS RkMgMzAyMywgSmFudWFyeSAyMDAxLg0NICAgWzZdICAgUGV0ZXJzb24sIEouLCAiQSBQcmVz ZW5jZS1iYXNlZCBHRU9QUklWIExvY2F0aW9uIE9iamVjdA0gICAgICAgICBGb3JtYXQiLCBS RkMgNDExOSwgRGVjZW1iZXIgMjAwNS4NDSAgIFs3XSAgIEZyZWVkLCBOLiBhbmQgSi4gS2xl bnNpbiwgIk1lZGlhIFR5cGUgU3BlY2lmaWNhdGlvbnMgYW5kDSAgICAgICAgIFJlZ2lzdHJh dGlvbiBQcm9jZWR1cmVzIiwgQkNQIDEzLCBSRkMgNDI4OCwgRGVjZW1iZXIgMjAwNS4NDSAg IFs4XSAgIFNjaHVsenJpbm5lLCBILiwgIkEgVW5pZm9ybSBSZXNvdXJjZSBOYW1lIChVUk4p IGZvciBTZXJ2aWNlcyIsDSAgICAgICAgIGRyYWZ0LWlldGYtZWNyaXQtc2VydmljZS11cm4t MDYgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDA3Lg0NICAgWzldICAgVGhvbXNvbiwg TS4gYW5kIEouIFdpbnRlcmJvdHRvbSwgIlJldmlzZWQgQ2l2aWMgTG9jYXRpb24gRm9ybWF0 DSAgICAgICAgIGZvciBQSURGLUxPIiwgZHJhZnQtaWV0Zi1nZW9wcml2LXJldmlzZWQtY2l2 aWMtbG8tMDUgKHdvcmsgaW4NICAgICAgICAgcHJvZ3Jlc3MpLCBGZWJydWFyeSAyMDA3Lg0N ICAgWzEwXSAgRGFpZ2xlLCBMLiwgIkRvbWFpbi1iYXNlZCBBcHBsaWNhdGlvbiBTZXJ2aWNl IExvY2F0aW9uIFVzaW5nDSAgICAgICAgIFVSSXMgYW5kIHRoZSBEeW5hbWljICBEZWxlZ2F0 aW9uIERpc2NvdmVyeSBTZXJ2aWNlIChERERTKSIsDSAgICAgICAgIGRyYWZ0LWRhaWdsZS11 bmFwdHItMDIgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBGZWJydWFyeSAyMDA3Lg0NICAgWzExXSAg Q294LCBTLiwgRGFpc2V5LCBQLiwgTGFrZSwgUi4sIFBvcnRlbGUsIEMuLCBhbmQgQS4gV2hp dGVzaWRlLA0gICAgICAgICAiR2VvZ3JhcGhpYyBpbmZvcm1hdGlvbiAtIEdlb2dyYXBoeSBN YXJrdXAgTGFuZ3VhZ2UgKEdNTCkiLCBPR0MNICAgICAgICAgU3RhbmRhcmQgT3BlbkdJUyAw My0xMDVyMSwgQXByaWwgMjAwNC4NDSAgIFsxMl0gIFJlZWQsIEMuIGFuZCBNLiBUaG9tc29u LCAiR01MIDMuMS4xIFBJREYtTE8gU2hhcGUgQXBwbGljYXRpb24NICAgICAgICAgU2NoZW1h IGZvciB1c2UgYnkgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYp IiwNICAgICAgICAgQ2FuZGlkYXRlIE9wZW5HSVMgSW1wbGVtZW50YXRpb24gU3BlY2lmaWNh dGlvbiAsIERlY2VtYmVyIDIwMDYuDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSA1Nl0NDA1JbnRl cm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMDcNDQ0yMS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcw0NICAgWzEz XSAgUm9zZW5iZXJnLCBKLiwgU2NodWx6cmlubmUsIEguLCBDYW1hcmlsbG8sIEcuLCBKb2hu c3RvbiwgQS4sDSAgICAgICAgIFBldGVyc29uLCBKLiwgU3BhcmtzLCBSLiwgSGFuZGxleSwg TS4sIGFuZCBFLiBTY2hvb2xlciwgIlNJUDoNICAgICAgICAgU2Vzc2lvbiBJbml0aWF0aW9u IFByb3RvY29sIiwgUkZDIDMyNjEsIEp1bmUgMjAwMi4NDSAgIFsxNF0gIFNhaW50LUFuZHJl LCBQLiwgRWQuLCAiRXh0ZW5zaWJsZSBNZXNzYWdpbmcgYW5kIFByZXNlbmNlDSAgICAgICAg IFByb3RvY29sIChYTVBQKTogSW5zdGFudCBNZXNzYWdpbmcgYW5kIFByZXNlbmNlIiwgUkZD IDM5MjEsDSAgICAgICAgIE9jdG9iZXIgMjAwNC4NDSAgIFsxNV0gIFNjaHVsenJpbm5lLCBI LiwgIlRoZSB0ZWwgVVJJIGZvciBUZWxlcGhvbmUgTnVtYmVycyIsIFJGQyAzOTY2LA0gICAg ICAgICBEZWNlbWJlciAyMDA0Lg0NICAgWzE2XSAgVGF5bG9yLCBULiwgIlNlY3VyaXR5IFRo cmVhdHMgYW5kIFJlcXVpcmVtZW50cyBmb3IgRW1lcmdlbmN5DSAgICAgICAgIENhbGwgTWFy a2luZyBhbmQgTWFwcGluZyIsIGRyYWZ0LWlldGYtZWNyaXQtc2VjdXJpdHktdGhyZWF0cy0w NA0gICAgICAgICAod29yayBpbiBwcm9ncmVzcyksIEFwcmlsIDIwMDcuDQ0gICBbMTddICBT Y2h1bHpyaW5uZSwgSC4gYW5kIFIuIE1hcnNoYWxsLCAiUmVxdWlyZW1lbnRzIGZvciBFbWVy Z2VuY3kNICAgICAgICAgQ29udGV4dCBSZXNvbHV0aW9uIHdpdGggSW50ZXJuZXQgVGVjaG5v bG9naWVzIiwNICAgICAgICAgZHJhZnQtaWV0Zi1lY3JpdC1yZXF1aXJlbWVudHMtMTMgKHdv cmsgaW4gcHJvZ3Jlc3MpLA0gICAgICAgICBNYXJjaCAyMDA3Lg0NICAgWzE4XSAgU2NodWx6 cmlubmUsIEguLCAiTG9jYXRpb24tdG8tVVJMIE1hcHBpbmcgQXJjaGl0ZWN0dXJlIGFuZA0g ICAgICAgICBGcmFtZXdvcmsiLCBkcmFmdC1pZXRmLWVjcml0LW1hcHBpbmctYXJjaC0wMSAo d29yayBpbg0gICAgICAgICBwcm9ncmVzcyksIERlY2VtYmVyIDIwMDYuDQ0gICBbMTldICBS b3NlbiwgQi4gYW5kIEouIFBvbGssICJCZXN0IEN1cnJlbnQgUHJhY3RpY2UgZm9yDSAgICAg ICAgIENvbW11bmljYXRpb25zIFNlcnZpY2VzIGluIHN1cHBvcnQgb2YgRW1lcmdlbmN5ICBD YWxsaW5nIiwNICAgICAgICAgZHJhZnQtaWV0Zi1lY3JpdC1waG9uZWJjcC0wMSAod29yayBp biBwcm9ncmVzcyksIE1hcmNoIDIwMDcuDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAg ICBbUGFnZSA1N10NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAg ICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ1BcHBlbmRpeCBBLiAgTm9uLU5v cm1hdGl2ZSBSRUxBWCBORyBTY2hlbWEgaW4gWE1MIFN5bnRheA0NDSAgIDw/eG1sIHZlcnNp b249IjEuMCIgZW5jb2Rpbmc9IlVURi04Ij8+DSAgIDxncmFtbWFyIG5zPSJ1cm46aWV0Zjpw YXJhbXM6eG1sOm5zOmxvc3QxIg0gICB4bWxucz0iaHR0cDovL3JlbGF4bmcub3JnL25zL3N0 cnVjdHVyZS8xLjAiDSAgIHhtbG5zOmE9Imh0dHA6Ly9yZWxheG5nLm9yZy9ucy9jb21wYXRp YmlsaXR5L2Fubm90YXRpb25zLzEuMCINICAgZGF0YXR5cGVMaWJyYXJ5PSJodHRwOi8vd3d3 LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1kYXRhdHlwZXMiPg0gICA8c3RhcnQ+DSAgIDxhOmRv Y3VtZW50YXRpb24+DSAgICAgICAgIExvY2F0aW9uLXRvLVNlcnZpY2UgVHJhbnNsYXRpb24g UHJvdG9jb2wgKExvU1QpDSAgICAgICAgIEEgTG9TVCBYTUwgaW5zdGFuY2UgaGFzIHRocmVl IHJlcXVlc3QgdHlwZXMsIGVhY2ggd2l0aA0gICAgICAgICBhIGNvb3Jlc3BvbmRpbmcgcmVz cG9uc2UgdHlwZTogZmluZCBzZXJ2aWNlLCBsaXN0IHNlcnZpY2VzLA0gICAgICAgICBhbmQg Z2V0IHNlcnZpY2UgYm91bmRhcnkuDSAgIDwvYTpkb2N1bWVudGF0aW9uPg0gICA8Y2hvaWNl Pg0gICA8cmVmIG5hbWU9ImZpbmRTZXJ2aWNlIiAvPg0gICA8cmVmIG5hbWU9Imxpc3RTZXJ2 aWNlcyIgLz4NICAgPHJlZiBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0aW9uIiAvPg0gICA8 cmVmIG5hbWU9ImdldFNlcnZpY2VCb3VuZGFyeSIgLz4NICAgPHJlZiBuYW1lPSJmaW5kU2Vy dmljZVJlc3BvbnNlIiAvPg0gICA8cmVmIG5hbWU9Imxpc3RTZXJ2aWNlc1Jlc3BvbnNlIiAv Pg0gICA8cmVmIG5hbWU9Imxpc3RTZXJ2aWNlc0J5TG9jYXRpb25SZXNwb25zZSIgLz4NICAg PHJlZiBuYW1lPSJnZXRTZXJ2aWNlQm91bmRhcnlSZXNwb25zZSIgLz4NICAgPHJlZiBuYW1l PSJlcnJvcnMiIC8+DSAgIDxyZWYgbmFtZT0icmVkaXJlY3QiIC8+DSAgIDwvY2hvaWNlPg0g ICA8L3N0YXJ0Pg0gICA8ZGl2Pg0gICA8YTpkb2N1bWVudGF0aW9uPg0gICAgICAgICBUaGUg cXVlcmllcy4NICAgICAgIDwvYTpkb2N1bWVudGF0aW9uPg0NICAgICAgIDxkZWZpbmUgbmFt ZT0iZmluZFNlcnZpY2UiPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJmaW5kU2VydmljZSI+ DSAgICAgICAgICAgPG9uZU9yTW9yZT4NICAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9Imxv Y2F0aW9uIj4NICAgICAgICAgICAgICAgPHJlZiBuYW1lPSJsb2NhdGlvbkluZm9ybWF0aW9u IiAvPg0gICAgICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgICAgIDwvb25lT3JNb3JlPg0g ICAgICAgICAgIDxyZWYgbmFtZT0iY29tbW9uUmVxdWVzdFBhdHRlcm4iIC8+DSAgICAgICAg ICAgPG9wdGlvbmFsPg0gICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJ2YWxpZGF0ZUxv Y2F0aW9uIj4NICAgICAgICAgICAgICAgPGRhdGEgdHlwZT0iYm9vbGVhbiIgLz4NICAgICAg ICAgICAgICAgPGE6ZGVmYXVsdFZhbHVlPmZhbHNlPC9hOmRlZmF1bHRWYWx1ZT4NICAgICAg ICAgICAgIDwvYXR0cmlidXRlPg0gICAgICAgICAgIDwvb3B0aW9uYWw+DSAgICAgICAgICAg PG9wdGlvbmFsPg0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVy IDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSA1OF0NDA1JbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcN DQ0gICAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJzZXJ2aWNlQm91bmRhcnkiPg0gICAg ICAgICAgICAgICA8Y2hvaWNlPg0gICAgICAgICAgICAgICAgIDx2YWx1ZT5yZWZlcmVuY2U8 L3ZhbHVlPg0gICAgICAgICAgICAgICAgIDx2YWx1ZT52YWx1ZTwvdmFsdWU+DSAgICAgICAg ICAgICAgIDwvY2hvaWNlPg0gICAgICAgICAgICAgICA8YTpkZWZhdWx0VmFsdWU+cmVmZXJl bmNlPC9hOmRlZmF1bHRWYWx1ZT4NICAgICAgICAgICAgIDwvYXR0cmlidXRlPg0gICAgICAg ICAgIDwvb3B0aW9uYWw+DSAgICAgICAgICAgPG9wdGlvbmFsPg0gICAgICAgICAgICAgPGF0 dHJpYnV0ZSBuYW1lPSJyZWN1cnNpdmUiPg0gICAgICAgICAgICAgICA8ZGF0YSB0eXBlPSJi b29sZWFuIiAvPg0gICAgICAgICAgICAgICAgIDxhOmRlZmF1bHRWYWx1ZT5mYWxzZTwvYTpk ZWZhdWx0VmFsdWU+DSAgICAgICAgICAgICA8L2F0dHJpYnV0ZT4NICAgICAgICAgICA8L29w dGlvbmFsPg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8 ZGVmaW5lIG5hbWU9Imxpc3RTZXJ2aWNlcyI+DSAgICAgICAgIDxlbGVtZW50IG5hbWU9Imxp c3RTZXJ2aWNlcyI+DSAgICAgICAgICAgPHJlZiBuYW1lPSJjb21tb25SZXF1ZXN0UGF0dGVy biIgLz4NICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgPC9kZWZpbmU+DQ0gICAgICAgPGRl ZmluZSBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0aW9uIj4NICAgICAgICAgPGVsZW1lbnQg bmFtZT0ibGlzdFNlcnZpY2VzQnlMb2NhdGlvbiI+DSAgICAgICAgICAgPHplcm9Pck1vcmU+ DSAgICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJsb2NhdGlvbiI+DSAgICAgICAgICAgICAg IDxyZWYgbmFtZT0ibG9jYXRpb25JbmZvcm1hdGlvbiIgLz4NICAgICAgICAgICAgIDwvZWxl bWVudD4NICAgICAgICAgICA8L3plcm9Pck1vcmU+DSAgICAgICAgICAgPHJlZiBuYW1lPSJj b21tb25SZXF1ZXN0UGF0dGVybiIgLz4NICAgICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAg ICAgICA8YXR0cmlidXRlIG5hbWU9InJlY3Vyc2l2ZSI+DSAgICAgICAgICAgICAgIDxkYXRh IHR5cGU9ImJvb2xlYW4iIC8+DSAgICAgICAgICAgICAgIDxhOmRlZmF1bHRWYWx1ZT50cnVl PC9hOmRlZmF1bHRWYWx1ZT4NICAgICAgICAgICAgIDwvYXR0cmlidXRlPg0gICAgICAgICAg IDwvb3B0aW9uYWw+DSAgICAgICAgIDwvZWxlbWVudD4NICAgICAgIDwvZGVmaW5lPg0NICAg ICAgIDxkZWZpbmUgbmFtZT0iZ2V0U2VydmljZUJvdW5kYXJ5Ij4NICAgICAgICAgPGVsZW1l bnQgbmFtZT0iZ2V0U2VydmljZUJvdW5kYXJ5Ij4NICAgICAgICAgICA8cmVmIG5hbWU9InNl cnZpY2VCb3VuZGFyeUtleSIgLz4NICAgICAgICAgICA8cmVmIG5hbWU9ImV4dGVuc2lvblBv aW50IiAvPg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDSAgICAgPC9k aXY+DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIw MDcgICAgICAgICAgICAgIFtQYWdlIDU5XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgICAg PGRpdj4NICAgICAgIDxhOmRvY3VtZW50YXRpb24+DSAgICAgICAgIFRoZSByZXNwb25zZXMu DSAgICAgICA8L2E6ZG9jdW1lbnRhdGlvbj4NDQ0gICAgICAgPGRlZmluZSBuYW1lPSJmaW5k U2VydmljZVJlc3BvbnNlIj4NICAgICAgICAgPGVsZW1lbnQgbmFtZT0iZmluZFNlcnZpY2VS ZXNwb25zZSI+DSAgICAgICAgICAgPG9uZU9yTW9yZT4NICAgICAgICAgICAgIDxyZWYgbmFt ZT0ibWFwcGluZyIgLz4NICAgICAgICAgICA8L29uZU9yTW9yZT4NICAgICAgICAgICA8b3B0 aW9uYWw+DSAgICAgICAgICAgICA8cmVmIG5hbWU9ImxvY2F0aW9uVmFsaWRhdGlvbiIgLz4N ICAgICAgICAgICA8L29wdGlvbmFsPg0gICAgICAgICAgIDxyZWYgbmFtZT0iY29tbW9uUmVz cG9uc2VQYXR0ZXJuIiAvPg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4N DQ0gICAgICAgPGRlZmluZSBuYW1lPSJsaXN0U2VydmljZXNSZXNwb25zZSI+DSAgICAgICAg IDxlbGVtZW50IG5hbWU9Imxpc3RTZXJ2aWNlc1Jlc3BvbnNlIj4NICAgICAgICAgICA8cmVm IG5hbWU9InNlcnZpY2VMaXN0IiAvPg0gICAgICAgICAgIDxyZWYgbmFtZT0iY29tbW9uUmVz cG9uc2VQYXR0ZXJuIiAvPg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4N DQ0gICAgICAgPGRlZmluZSBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0aW9uUmVzcG9uc2Ui Pg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJsaXN0U2VydmljZXNCeUxvY2F0aW9uUmVzcG9u c2UiPg0gICAgICAgICAgIDxyZWYgbmFtZT0ic2VydmljZUxpc3QiIC8+DSAgICAgICAgICAg PHJlZiBuYW1lPSJjb21tb25SZXNwb25zZVBhdHRlcm4iIC8+DSAgICAgICAgIDwvZWxlbWVu dD4NICAgICAgIDwvZGVmaW5lPg0NICAgICAgIDxkZWZpbmUgbmFtZT0iZ2V0U2VydmljZUJv dW5kYXJ5UmVzcG9uc2UiPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJnZXRTZXJ2aWNlQm91 bmRhcnlSZXNwb25zZSI+DSAgICAgICAgICAgPHJlZiBuYW1lPSJzZXJ2aWNlQm91bmRhcnki Lz4NICAgICAgICAgICA8cmVmIG5hbWU9ImNvbW1vblJlc3BvbnNlUGF0dGVybiIgLz4NICAg ICAgICAgPC9lbGVtZW50Pg0gICAgICAgPC9kZWZpbmU+DQ0gICAgIDwvZGl2Pg0NICAgICA8 ZGl2Pg0gICAgICAgPGE6ZG9jdW1lbnRhdGlvbj4NICAgICAgICAgQSBwYXR0ZXJuIGNvbW1v biB0byBzb21lIG9mIHRoZSBxdWVyaWVzLg0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0N DQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAg ICAgICAgICAgICBbUGFnZSA2MF0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICAgICAgPGRl ZmluZSBuYW1lPSJjb21tb25SZXF1ZXN0UGF0dGVybiI+DSAgICAgICAgIDxyZWYgbmFtZT0i c2VydmljZSIgLz4NICAgICAgICAgPG9wdGlvbmFsPg0gICAgICAgICAgIDxyZWYgbmFtZT0i cGF0aCIgLz4NICAgICAgICAgPC9vcHRpb25hbD4NICAgICAgICAgPHJlZiBuYW1lPSJleHRl bnNpb25Qb2ludCIgLz4NICAgICAgIDwvZGVmaW5lPg0gICAgIDwvZGl2Pg0NICAgICA8ZGl2 Pg0gICAgICAgPGE6ZG9jdW1lbnRhdGlvbj4NICAgICAgICAgQSBwYXR0ZXJuIGNvbW1vbiB0 byByZXNwb25zZXMuDSAgICAgICA8L2E6ZG9jdW1lbnRhdGlvbj4NDSAgICAgICA8ZGVmaW5l IG5hbWU9ImNvbW1vblJlc3BvbnNlUGF0dGVybiI+DSAgICAgICAgIDx6ZXJvT3JNb3JlPg0g ICAgICAgICAgIDxyZWYgbmFtZT0id2FybmluZ3MiIC8+DSAgICAgICAgIDwvemVyb09yTW9y ZT4NICAgICAgICAgPHJlZiBuYW1lPSJwYXRoIiAvPg0gICAgICAgICA8cmVmIG5hbWU9Imxv Y2F0aW9uVXNlZCIgLz4NICAgICAgICAgPHJlZiBuYW1lPSJleHRlbnNpb25Qb2ludCIgLz4N ICAgICAgIDwvZGVmaW5lPg0gICAgIDwvZGl2Pg0NICAgICA8ZGl2Pg0gICAgICAgPGE6ZG9j dW1lbnRhdGlvbj4NICAgICAgICAgTG9jYXRpb24gSW5mb3JtYXRpb24NICAgICAgIDwvYTpk b2N1bWVudGF0aW9uPg0NICAgICAgIDxkZWZpbmUgbmFtZT0ibG9jYXRpb25JbmZvcm1hdGlv biI+DSAgICAgICAgIDxvbmVPck1vcmU+DSAgICAgICAgICAgPHJlZiBuYW1lPSJleHRlbnNp b25Qb2ludCIvPg0gICAgICAgICA8L29uZU9yTW9yZT4NICAgICAgICAgPGF0dHJpYnV0ZSBu YW1lPSJpZCI+DSAgICAgICAgICAgPGRhdGEgdHlwZT0idG9rZW4iIC8+DSAgICAgICAgIDwv YXR0cmlidXRlPg0gICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAgPGF0dHJpYnV0ZSBu YW1lPSJwcm9maWxlIj4NICAgICAgICAgICAgIDxkYXRhIHR5cGU9Ik5NVE9LRU4iIC8+DSAg ICAgICAgICAgPC9hdHRyaWJ1dGU+DSAgICAgICAgIDxvcHRpb25hbD4NICAgICAgIDwvZGVm aW5lPg0gICAgIDwvZGl2Pg0NICAgICA8ZGl2Pg0gICAgICAgPGE6ZG9jdW1lbnRhdGlvbj4N ICAgICAgICAgU2VydmljZSBCb3VuZGFyeQ0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0N DUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAg ICAgICAgICAgIFtQYWdlIDYxXQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgICAgICA8ZGVm aW5lIG5hbWU9InNlcnZpY2VCb3VuZGFyeSI+DSAgICAgICAgIDxvbmVPck1vcmU+DSAgICAg ICAgICAgPGVsZW1lbnQgbmFtZT0ic2VydmljZUJvdW5kYXJ5Ij4NICAgICAgICAgICAgIDxy ZWYgbmFtZT0ibG9jYXRpb25JbmZvcm1hdGlvbiIgLz4NICAgICAgICAgICA8L2VsZW1lbnQ+ DSAgICAgICAgIDwvb25lT3JNb3JlPg0gICAgICAgPC9kZWZpbmU+DSAgICAgPC9kaXY+DQ0g ICAgIDxkaXY+DSAgICAgICA8YTpkb2N1bWVudGF0aW9uPg0gICAgICAgICBTZXJ2aWNlIEJv dW5kYXJ5IFJlZmVyZW5jZQ0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0gICAgICAgPGRl ZmluZSBuYW1lPSJzZXJ2aWNlQm91bmRhcnlSZWZlcmVuY2UiPg0NICAgICAgICAgPGVsZW1l bnQgbmFtZT0ic2VydmljZUJvdW5kYXJ5UmVmZXJlbmNlIj4NICAgICAgICAgICA8cmVmIG5h bWU9InNvdXJjZSIgLz4NICAgICAgICAgICA8cmVmIG5hbWU9InNlcnZpY2VCb3VuZGFyeUtl eSIgLz4NICAgICAgICAgICA8cmVmIG5hbWU9ImV4dGVuc2lvblBvaW50IiAvPg0gICAgICAg ICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9InNl cnZpY2VCb3VuZGFyeUtleSI+DSAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ia2V5Ij4NICAg ICAgICAgICA8ZGF0YSB0eXBlPSJ0b2tlbiIgLz4NICAgICAgICAgPC9hdHRyaWJ1dGU+DSAg ICAgICA8L2RlZmluZT4NDSAgICAgPC9kaXY+DQ0gICAgIDxkaXY+DSAgICAgICA8YTpkb2N1 bWVudGF0aW9uPg0gICAgICAgICBQYXRoIC0NICAgICAgICAgQ29udGFpbnMgYSBsaXN0IG9m IHZpYSBlbGVtZW50cyAtDSAgICAgICAgIHBsYWNlcyB0aHJvdWdoIHdoaWNoIGluZm9ybWF0 aW9uIGZsb3dlZA0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0gICAgICAgPGRlZmluZSBu YW1lPSJwYXRoIj4NICAgICAgICAgPGVsZW1lbnQgbmFtZT0icGF0aCI+DSAgICAgICAgICAg PG9uZU9yTW9yZT4NICAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9InZpYSI+DSAgICAgICAg ICAgICAgIDxyZWYgbmFtZT0ic291cmNlIiAvPg0gICAgICAgICAgICAgICA8cmVmIG5hbWU9 ImV4dGVuc2lvblBvaW50IiAvPg0gICAgICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgICAg IDwvb25lT3JNb3JlPg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDQ0N SGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAg ICAgICAgICAgW1BhZ2UgNjJdDQwNSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAg IExvU1QgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDA3DQ0NICAgICA8L2Rpdj4N DSAgICAgPGRpdj4NICAgICAgIDxhOmRvY3VtZW50YXRpb24+DSAgICAgICAgIGxvY2F0aW9u VXNlZCAtDSAgICAgICAgIENvbnRhaW5zIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBsY29hdGlv biB1c2VkLg0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0gICAgICAgPGRlZmluZSBuYW1l PSJsb2NhdGlvblVzZWQiPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJsb2NhdGlvblVzZWQi Pg0gICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0iaWQiPg0gICAgICAgICAgICAgPGRhdGEg dHlwZT0idG9rZW4iIC8+DSAgICAgICAgICAgPC9hdHRyaWJ1dGU+DSAgICAgICAgIDwvZWxl bWVudD4NICAgICAgIDwvZGVmaW5lPg0gICAgIDwvZGl2Pg0NICAgICA8ZGl2Pg0gICAgICAg PGE6ZG9jdW1lbnRhdGlvbj4NICAgICAgICAgRXhwaXJlcyBwYXR0ZXJuDSAgICAgICA8L2E6 ZG9jdW1lbnRhdGlvbj4NDSAgICAgICA8ZGVmaW5lIG5hbWU9ImV4cGlyZXMiPg0gICAgICAg ICA8YXR0cmlidXRlIG5hbWU9ImV4cGlyZXMiPg0gICAgICAgICAgIDxjaG9pY2U+DSAgICAg ICAgICAgICA8ZGF0YSB0eXBlPSJkYXRlVGltZSIvPg0gICAgICAgICAgICAgPHZhbHVlPk5P LUNBQ0hFPC92YWx1ZT4NICAgICAgICAgICAgIDx2YWx1ZT5OTy1FWFBJUkFUSU9OPC92YWx1 ZT4NICAgICAgICAgICA8L2Nob2ljZT4NICAgICAgICAgPC9hdHRyaWJ1dGU+DSAgICAgICA8 L2RlZmluZT4NICAgICA8L2Rpdj4NDSAgICAgPGRpdj4NICAgICAgIDxhOmRvY3VtZW50YXRp b24+DSAgICAgICAgIEEgUU5hbWUgbGlzdA0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0g ICAgICAgPGRlZmluZSBuYW1lPSJxbmFtZUxpc3QiPg0gICAgICAgICA8bGlzdD4NICAgICAg ICAgICA8emVyb09yTW9yZT4NICAgICAgICAgICAgIDxkYXRhIHR5cGU9IlFOYW1lIi8+DSAg ICAgICAgICAgPC96ZXJvT3JNb3JlPg0gICAgICAgICA8L2xpc3Q+DSAgICAgICA8L2RlZmlu ZT4NICAgICA8L2Rpdj4NDSAgICAgPGRpdj4NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAg RXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNjNdDQwNSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAg ICAgICAgSnVuZSAyMDA3DQ0NICAgICAgIDxhOmRvY3VtZW50YXRpb24+DSAgICAgICAgIEEg bG9jYXRpb24tdG8tc2VydmljZSBtYXBwaW5nLg0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+ DQ0gICAgICAgPGRlZmluZSBuYW1lPSJtYXBwaW5nIj4NICAgICAgICAgPGVsZW1lbnQgbmFt ZT0ibWFwcGluZyI+DSAgICAgICAgICAgPHplcm9Pck1vcmU+DSAgICAgICAgICAgICA8ZWxl bWVudCBuYW1lPSJkaXNwbGF5TmFtZSI+DSAgICAgICAgICAgICAgIDxkYXRhIHR5cGU9InN0 cmluZyIvPg0gICAgICAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9InhtbDpsYW5nIj4NICAg ICAgICAgICAgICAgICA8ZGF0YSB0eXBlPSJsYW5ndWFnZSIvPg0gICAgICAgICAgICAgICA8 L2F0dHJpYnV0ZT4NICAgICAgICAgICAgIDwvZWxlbWVudD4NICAgICAgICAgICA8L3plcm9P ck1vcmU+DSAgICAgICAgICAgPHJlZiBuYW1lPSJzZXJ2aWNlIiAvPg0gICAgICAgICAgIDxv cHRpb25hbD4NICAgICAgICAgICAgIDxjaG9pY2U+DSAgICAgICAgICAgICAgIDxyZWYgbmFt ZT0ic2VydmljZUJvdW5kYXJ5Ii8+DSAgICAgICAgICAgICAgIDxyZWYgbmFtZT0ic2Vydmlj ZUJvdW5kYXJ5UmVmZXJlbmNlIi8+DSAgICAgICAgICAgICA8L2Nob2ljZT4NICAgICAgICAg ICA8L29wdGlvbmFsPg0gICAgICAgICAgIDx6ZXJvT3JNb3JlPg0gICAgICAgICAgICAgPGVs ZW1lbnQgbmFtZT0idXJpIj4NICAgICAgICAgICAgICAgPGRhdGEgdHlwZT0iYW55VVJJIi8+ DSAgICAgICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICAgICAgPC96ZXJvT3JNb3JlPg0gICAg ICAgICAgIDxvcHRpb25hbD4NICAgICAgICAgICAgIDxlbGVtZW50IG5hbWU9InNlcnZpY2VO dW1iZXIiPg0gICAgICAgICAgICAgICA8ZGF0YSB0eXBlPSJzdHJpbmciPg0gICAgICAgICAg ICAgICAgIDxwYXJhbSBuYW1lPSJwYXR0ZXJuIj5bMC05KiNdKzwvcGFyYW0+DSAgICAgICAg ICAgICAgIDwvZGF0YT4NICAgICAgICAgICAgIDwvZWxlbWVudD4NICAgICAgICAgICA8L29w dGlvbmFsPg0gICAgICAgICAgIDxyZWYgbmFtZT0iZXh0ZW5zaW9uUG9pbnQiLz4NICAgICAg ICAgICA8cmVmIG5hbWU9ImV4cGlyZXMiLz4NICAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9 Imxhc3RVcGRhdGVkIj4NICAgICAgICAgICAgIDxkYXRhIHR5cGU9ImRhdGVUaW1lIi8+DSAg ICAgICAgICAgPC9hdHRyaWJ1dGU+DSAgICAgICAgICAgPHJlZiBuYW1lPSJzb3VyY2UiIC8+ DSAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJzb3VyY2VJZCI+DSAgICAgICAgICAgICA8 ZGF0YSB0eXBlPSJ0b2tlbiIgLz4NICAgICAgICAgICA8L2F0dHJpYnV0ZT4NICAgICAgICAg ICA8cmVmIG5hbWU9Im1lc3NhZ2UiLz4NICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgPC9k ZWZpbmU+DQ0gICAgIDwvZGl2Pg0NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJl cyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNjRdDQwNSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAgICAg SnVuZSAyMDA3DQ0NICAgICA8ZGl2Pg0gICAgICAgPGE6ZG9jdW1lbnRhdGlvbj4NICAgICAg ICAgTG9jYXRpb24gdmFsaWRhdGlvbg0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0gICAg ICAgPGRlZmluZSBuYW1lPSJsb2NhdGlvblZhbGlkYXRpb24iPg0gICAgICAgICA8ZWxlbWVu dCBuYW1lPSJsb2NhdGlvblZhbGlkYXRpb24iPg0gICAgICAgICAgIDxvcHRpb25hbD4NICAg ICAgICAgICAgIDxlbGVtZW50IG5hbWU9InZhbGlkIj4NICAgICAgICAgICAgICAgPHJlZiBu YW1lPSJxbmFtZUxpc3QiIC8+DSAgICAgICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICAgICAg PC9vcHRpb25hbD4NICAgICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAgICA8ZWxlbWVu dCBuYW1lPSJpbnZhbGlkIj4NICAgICAgICAgICAgICAgPHJlZiBuYW1lPSJxbmFtZUxpc3Qi IC8+DSAgICAgICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICAgICAgPC9vcHRpb25hbD4NICAg ICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAgICA8ZWxlbWVudCBuYW1lPSJ1bmNoZWNr ZWQiPg0gICAgICAgICAgICAgICA8cmVmIG5hbWU9InFuYW1lTGlzdCIgLz4NICAgICAgICAg ICAgIDwvZWxlbWVudD4NICAgICAgICAgICA8L29wdGlvbmFsPg0gICAgICAgICAgIDxyZWYg bmFtZT0iZXh0ZW5zaW9uUG9pbnQiLz4NICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgPC9k ZWZpbmU+DSAgICAgPC9kaXY+DQ0gICAgIDxkaXY+DSAgICAgICA8YTpkb2N1bWVudGF0aW9u Pg0gICAgICAgICBFcnJvcnMgYW5kIFdhcm5pbmdzIENvbnRhaW5lci4NICAgICAgIDwvYTpk b2N1bWVudGF0aW9uPg0NICAgICAgIDxkZWZpbmUgbmFtZT0iZXJyb3JDb250YWluZXIiPg0g ICAgICAgICA8aW50ZXJsZWF2ZT4NICAgICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAg ICA8cmVmIG5hbWU9ImJhZFJlcXVlc3QiIC8+DSAgICAgICAgICAgPC9vcHRpb25hbD4NICAg ICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAgICA8cmVmIG5hbWU9ImludGVybmFsRXJy b3IiIC8+DSAgICAgICAgICAgPC9vcHRpb25hbD4NICAgICAgICAgICA8b3B0aW9uYWw+DSAg ICAgICAgICAgICA8cmVmIG5hbWU9InNlcnZpY2VTdWJzdGl0dXRpb24iIC8+DSAgICAgICAg ICAgPC9vcHRpb25hbD4NICAgICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAgICA8cmVm IG5hbWU9ImZvcmJpZGRlbiIgLz4NICAgICAgICAgICA8L29wdGlvbmFsPg0gICAgICAgICAg IDxvcHRpb25hbD4NICAgICAgICAgICAgIDxyZWYgbmFtZT0ibm90Rm91bmQiIC8+DQ0NDUhh cmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAg ICAgICAgIFtQYWdlIDY1XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBM b1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAgICAgICAgICAgPC9v cHRpb25hbD4NICAgICAgICAgICA8b3B0aW9uYWw+DSAgICAgICAgICAgICA8cmVmIG5hbWU9 Imxvb3AiIC8+DSAgICAgICAgICAgPC9vcHRpb25hbD4NICAgICAgICAgICA8b3B0aW9uYWw+ DSAgICAgICAgICAgICA8cmVmIG5hbWU9InNlcnZpY2VOb3RJbXBsZW1lbnRlZCIgLz4NICAg ICAgICAgICA8L29wdGlvbmFsPg0gICAgICAgICAgIDxvcHRpb25hbD4NICAgICAgICAgICAg IDxyZWYgbmFtZT0ic2VydmVyVGltZW91dCIgLz4NICAgICAgICAgICA8L29wdGlvbmFsPg0g ICAgICAgICAgIDxvcHRpb25hbD4NICAgICAgICAgICAgIDxyZWYgbmFtZT0ic2VydmVyRXJy b3IiIC8+DSAgICAgICAgICAgPC9vcHRpb25hbD4NICAgICAgICAgICA8b3B0aW9uYWw+DSAg ICAgICAgICAgICA8cmVmIG5hbWU9ImxvY2F0aW9uSW52YWxpZCIgLz4NICAgICAgICAgICA8 L29wdGlvbmFsPg0gICAgICAgICAgIDxvcHRpb25hbD4NICAgICAgICAgICAgIDxyZWYgbmFt ZT0ibG9jYXRpb25Qcm9maWxlVW5yZWNvZ25pemVkIiAvPg0gICAgICAgICAgIDwvb3B0aW9u YWw+DSAgICAgICAgIDwvaW50ZXJsZWF2ZT4NICAgICAgICAgPHJlZiBuYW1lPSJleHRlbnNp b25Qb2ludCIgLz4NICAgICAgICAgPHJlZiBuYW1lPSJzb3VyY2UiIC8+DSAgICAgICA8L2Rl ZmluZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9ImVycm9ycyI+DSAgICAgICAgIDxlbGVtZW50 IG5hbWU9ImVycm9ycyI+DSAgICAgICAgICAgPHJlZiBuYW1lPSJlcnJvckNvbnRhaW5lciIg Lz4NICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgPC9kZWZpbmU+DQ0gICAgICAgPGRlZmlu ZSBuYW1lPSJ3YXJuaW5ncyI+DSAgICAgICAgIDxlbGVtZW50IG5hbWU9Indhcm5pbmdzIj4N ICAgICAgICAgICA8cmVmIG5hbWU9ImVycm9yQ29udGFpbmVyIiAvPg0gICAgICAgICA8L2Vs ZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDSAgICAgPC9kaXY+DQ0gICAgIDxkaXY+DSAgICAg ICA8YTpkb2N1bWVudGF0aW9uPg0gICAgICAgICBCYXNpYyBFcnJvcnMNICAgICAgIDwvYTpk b2N1bWVudGF0aW9uPg0NICAgICAgIDxkZWZpbmUgbmFtZT0iYmFzaWNFcnJvciI+DSAgICAg ICAgIDxhOmRvY3VtZW50YXRpb24+DSAgICAgICAgICAgRXJyb3IgcGF0dGVybi4NICAgICAg ICAgPC9hOmRvY3VtZW50YXRpb24+DSAgICAgICAgIDxyZWYgbmFtZT0ibWVzc2FnZSIvPg0N DQ1IYXJkaWUsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAg ICAgICAgICAgICBbUGFnZSA2Nl0NDA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgTG9TVCAgICAgICAgICAgICAgICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICAgICAgICA8 cmVmIG5hbWU9ImV4dGVuc2lvblBvaW50IiAvPg0gICAgICAgPC9kZWZpbmU+DQ0gICAgICAg PGRlZmluZSBuYW1lPSJiYWRSZXF1ZXN0Ij4NICAgICAgICAgPGVsZW1lbnQgbmFtZT0iYmFk UmVxdWVzdCI+DSAgICAgICAgICAgPHJlZiBuYW1lPSJiYXNpY0Vycm9yIi8+DSAgICAgICAg IDwvZWxlbWVudD4NICAgICAgIDwvZGVmaW5lPg0NICAgICAgIDxkZWZpbmUgbmFtZT0iaW50 ZXJuYWxFcnJvciI+DSAgICAgICAgIDxlbGVtZW50IG5hbWU9ImludGVybmFsRXJyb3IiPg0g ICAgICAgICAgIDxyZWYgbmFtZT0iYmFzaWNFcnJvciIvPg0gICAgICAgICA8L2VsZW1lbnQ+ DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9InNlcnZpY2VTdWJzdGl0 dXRpb24iPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJzZXJ2aWNlU3Vic3RpdHV0aW9uIj4N ICAgICAgICAgICA8cmVmIG5hbWU9ImJhc2ljRXJyb3IiLz4NICAgICAgICAgPC9lbGVtZW50 Pg0gICAgICAgPC9kZWZpbmU+DQ0gICAgICAgPGRlZmluZSBuYW1lPSJmb3JiaWRkZW4iPg0g ICAgICAgICA8ZWxlbWVudCBuYW1lPSJmb3JiaWRkZW4iPg0gICAgICAgICAgIDxyZWYgbmFt ZT0iYmFzaWNFcnJvciIvPg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4N DSAgICAgICA8ZGVmaW5lIG5hbWU9Im5vdEZvdW5kIj4NICAgICAgICAgPGVsZW1lbnQgbmFt ZT0ibm90Rm91bmQiPg0gICAgICAgICAgIDxyZWYgbmFtZT0iYmFzaWNFcnJvciIvPg0gICAg ICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9 Imxvb3AiPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJsb29wIj4NICAgICAgICAgICA8cmVm IG5hbWU9ImJhc2ljRXJyb3IiIC8+DSAgICAgICAgIDwvZWxlbWVudD4NICAgICAgIDwvZGVm aW5lPg0NICAgICAgIDxkZWZpbmUgbmFtZT0ic2VydmljZU5vdEltcGxlbWVudGVkIj4NICAg ICAgICAgPGVsZW1lbnQgbmFtZT0ic2VydmljZU5vdEltcGxlbWVudGVkIj4NICAgICAgICAg ICA8cmVmIG5hbWU9ImJhc2ljRXJyb3IiLz4NICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAg PC9kZWZpbmU+DQ0gICAgICAgPGRlZmluZSBuYW1lPSJzZXJ2ZXJUaW1lb3V0Ij4NICAgICAg ICAgPGVsZW1lbnQgbmFtZT0ic2VydmVyVGltZW91dCI+DSAgICAgICAgICAgPHJlZiBuYW1l PSJiYXNpY0Vycm9yIi8+DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVj ZW1iZXIgMjUsIDIwMDcgICAgICAgICAgICAgIFtQYWdlIDY3XQ0MDUludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUg MjAwNw0NDSAgICAgICAgIDwvZWxlbWVudD4NICAgICAgIDwvZGVmaW5lPg0NICAgICAgIDxk ZWZpbmUgbmFtZT0ic2VydmVyRXJyb3IiPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJzZXJ2 ZXJFcnJvciI+DSAgICAgICAgICAgPHJlZiBuYW1lPSJiYXNpY0Vycm9yIi8+DSAgICAgICAg IDwvZWxlbWVudD4NICAgICAgIDwvZGVmaW5lPg0NICAgICAgIDxkZWZpbmUgbmFtZT0ibG9j YXRpb25JbnZhbGlkIj4NICAgICAgICAgPGVsZW1lbnQgbmFtZT0ibG9jYXRpb25JbnZhbGlk Ij4NICAgICAgICAgICA8cmVmIG5hbWU9ImJhc2ljRXJyb3IiLz4NICAgICAgICAgPC9lbGVt ZW50Pg0gICAgICAgPC9kZWZpbmU+DQ0gICAgICAgPGRlZmluZSBuYW1lPSJsb2NhdGlvblBy b2ZpbGVVbnJlY29nbml6ZWQiPg0gICAgICAgICA8ZWxlbWVudCBuYW1lPSJsb2NhdGlvblBy b2ZpbGVVbnJlY29nbml6ZWQiPg0gICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0idW5zdXBw b3J0ZWRQcm9maWxlcyI+DSAgICAgICAgICAgICA8ZGF0YSB0eXBlPSJOTVRPS0VOUyIgLz4N ICAgICAgICAgICA8L2F0dHJpYnV0ZT4NICAgICAgICAgICA8cmVmIG5hbWU9ImJhc2ljRXJy b3IiLz4NICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgPC9kZWZpbmU+DQ0gICAgIDwvZGl2 Pg0NICAgICA8ZGl2Pg0gICAgICAgPGE6ZG9jdW1lbnRhdGlvbj4NICAgICAgICAgUmVkaXJl Y3QuDSAgICAgICA8L2E6ZG9jdW1lbnRhdGlvbj4NDSAgICAgICA8ZGVmaW5lIG5hbWU9InJl ZGlyZWN0Ij4NICAgICAgICAgPGE6ZG9jdW1lbnRhdGlvbj4NICAgICAgICAgICBSZWRpcmVj dCBwYXR0ZXJuDSAgICAgICAgIDwvYTpkb2N1bWVudGF0aW9uPg0gICAgICAgICA8ZWxlbWVu dCBuYW1lPSJyZWRpcmVjdCI+DSAgICAgICAgICAgPGF0dHJpYnV0ZSBuYW1lPSJ0YXJnZXQi Pg0gICAgICAgICAgICAgPHJlZiBuYW1lPSJhcHBVbmlxdWVTdHJpbmciIC8+DSAgICAgICAg ICAgPC9hdHRyaWJ1dGU+DSAgICAgICAgICAgPHJlZiBuYW1lPSJzb3VyY2UiIC8+DSAgICAg ICAgICAgPHJlZiBuYW1lPSJtZXNzYWdlIiAvPg0gICAgICAgICAgIDxyZWYgbmFtZT0iZXh0 ZW5zaW9uUG9pbnQiIC8+DSAgICAgICAgIDwvZWxlbWVudD4NICAgICAgIDwvZGVmaW5lPg0N ICAgICA8L2Rpdj4NDSAgICAgPGRpdj4NDQ0NSGFyZGllLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAgICAgICAgW1BhZ2UgNjhdDQwNSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIExvU1QgICAgICAgICAgICAgICAgICAgICAg ICAgSnVuZSAyMDA3DQ0NICAgICAgIDxhOmRvY3VtZW50YXRpb24+DSAgICAgICAgIFNvbWUg Y29tbW9uIHBhdHRlcm5zLg0gICAgICAgPC9hOmRvY3VtZW50YXRpb24+DQ0gICAgICAgPGRl ZmluZSBuYW1lPSJtZXNzYWdlIj4NICAgICAgICAgPG9wdGlvbmFsPg0gICAgICAgICAgIDxn cm91cD4NICAgICAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ibWVzc2FnZSI+DSAgICAgICAg ICAgICAgIDxkYXRhIHR5cGU9InN0cmluZyIvPg0gICAgICAgICAgICAgPC9hdHRyaWJ1dGU+ DSAgICAgICAgICAgICA8YXR0cmlidXRlIG5hbWU9InhtbDpsYW5nIj4NICAgICAgICAgICAg ICAgPGRhdGEgdHlwZT0ibGFuZ3VhZ2UiLz4NICAgICAgICAgICAgIDwvYXR0cmlidXRlPg0g ICAgICAgICAgIDwvZ3JvdXA+DSAgICAgICAgIDwvb3B0aW9uYWw+DSAgICAgICA8L2RlZmlu ZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9InNlcnZpY2UiPg0gICAgICAgICA8b3B0aW9uYWw+ DSAgICAgICAgICAgPGVsZW1lbnQgbmFtZT0ic2VydmljZSI+DSAgICAgICAgICAgICA8ZGF0 YSB0eXBlPSJhbnlVUkkiLz4NICAgICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICAgIDwvb3B0 aW9uYWw+DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9ImFwcFVuaXF1 ZVN0cmluZyI+DSAgICAgICAgIDxkYXRhIHR5cGU9InN0cmluZyI+DSAgICAgICAgICAgPHBh cmFtIG5hbWU9InBhdHRlcm4iPihbYS16QS1aMC05XC1dK1wuKStbYS16QS1aMC05XSs8L3Bh cmFtPg0gICAgICAgICA8L2RhdGE+DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8ZGVmaW5l IG5hbWU9InNvdXJjZSI+DSAgICAgICAgIDxhdHRyaWJ1dGUgbmFtZT0ic291cmNlIj4NICAg ICAgICAgICA8cmVmIG5hbWU9ImFwcFVuaXF1ZVN0cmluZyIgLz4NICAgICAgICAgPC9hdHRy aWJ1dGU+DSAgICAgICA8L2RlZmluZT4NDSAgICAgICA8ZGVmaW5lIG5hbWU9InNlcnZpY2VM aXN0IiA+DSAgICAgICAgIDxlbGVtZW50IG5hbWU9InNlcnZpY2VMaXN0Ij4NICAgICAgICAg ICA8bGlzdD4NICAgICAgICAgICAgIDx6ZXJvT3JNb3JlPg0gICAgICAgICAgICAgICA8ZGF0 YSB0eXBlPSJhbnlVUkkiIC8+DSAgICAgICAgICAgICA8L3plcm9Pck1vcmU+DSAgICAgICAg ICAgPC9saXN0Pg0gICAgICAgICA8L2VsZW1lbnQ+DSAgICAgICA8L2RlZmluZT4NDSAgICAg PC9kaXY+DQ0NDUhhcmRpZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUs IDIwMDcgICAgICAgICAgICAgIFtQYWdlIDY5XQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAg ICAgICAgICAgICBMb1NUICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDSAg ICAgPGRpdj4NICAgICAgIDxhOmRvY3VtZW50YXRpb24+DSAgICAgICAgIFBhdHRlcm5zIGZv ciBpbmNsdXNpb24gb2YgZWxlbWVudHMgZnJvbSBzY2hlbWFzIGluDSAgICAgICAgIG90aGVy IG5hbWVzcGFjZXMuDSAgICAgICA8L2E6ZG9jdW1lbnRhdGlvbj4NDSAgICAgICA8ZGVmaW5l IG5hbWU9Im5vdExvc3QiPg0gICAgICAgICA8YTpkb2N1bWVudGF0aW9uPg0gICAgICAgICAg IEFueSBlbGVtZW50IG5vdCBpbiB0aGUgTG9TVCBuYW1lc3BhY2UuDSAgICAgICAgIDwvYTpk b2N1bWVudGF0aW9uPg0gICAgICAgICA8ZWxlbWVudD4NICAgICAgICAgICA8YW55TmFtZT4N ICAgICAgICAgICAgIDxleGNlcHQ+DSAgICAgICAgICAgICAgIDxuc05hbWUgbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bG9zdDEiLz4NICAgICAgICAgICAgICAgPG5zTmFtZS8+DSAg ICAgICAgICAgICA8L2V4Y2VwdD4NICAgICAgICAgICA8L2FueU5hbWU+DSAgICAgICAgICAg PHJlZiBuYW1lPSJhbnlFbGVtZW50Ii8+DSAgICAgICAgIDwvZWxlbWVudD4NICAgICAgIDwv ZGVmaW5lPg0NDSAgICAgICA8ZGVmaW5lIG5hbWU9ImFueUVsZW1lbnQiPg0gICAgICAgICA8 YTpkb2N1bWVudGF0aW9uPg0gICAgICAgICAgIEEgd2lsZGNhcmQgcGF0dGVybiBmb3IgaW5j bHVkaW5nIGFueSBlbGVtZW50DSAgICAgICAgICAgZnJvbSBhbnkgb3RoZXIgbmFtZXNwYWNl Lg0gICAgICAgICA8L2E6ZG9jdW1lbnRhdGlvbj4NICAgICAgICAgPHplcm9Pck1vcmU+DSAg ICAgICAgICAgPGNob2ljZT4NICAgICAgICAgICAgIDxlbGVtZW50Pg0gICAgICAgICAgICAg ICA8YW55TmFtZS8+DSAgICAgICAgICAgICAgIDxyZWYgbmFtZT0iYW55RWxlbWVudCIvPg0g ICAgICAgICAgICAgPC9lbGVtZW50Pg0gICAgICAgICAgICAgPGF0dHJpYnV0ZT4NICAgICAg ICAgICAgICAgPGFueU5hbWUvPg0gICAgICAgICAgICAgPC9hdHRyaWJ1dGU+DSAgICAgICAg ICAgICA8dGV4dC8+DSAgICAgICAgICAgPC9jaG9pY2U+DSAgICAgICAgIDwvemVyb09yTW9y ZT4NICAgICAgIDwvZGVmaW5lPg0NICAgICAgIDxkZWZpbmUgbmFtZT0iZXh0ZW5zaW9uUG9p bnQiPg0gICAgICAgICA8YTpkb2N1bWVudGF0aW9uPg0gICAgICAgICAgIEEgcG9pbnQgd2hl cmUgZnV0dXJlIGV4dGVuc2lvbnMNICAgICAgICAgICAoZWxlbWVudHMgZnJvbSBvdGhlciBu YW1lc3BhY2VzKQ0gICAgICAgICAgIGNhbiBiZSBhZGRlZC4NICAgICAgICAgPC9hOmRvY3Vt ZW50YXRpb24+DSAgICAgICAgIDx6ZXJvT3JNb3JlPg0NDQ1IYXJkaWUsIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSA3MF0N DA1JbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAg ICAgICAgICAgICBKdW5lIDIwMDcNDQ0gICAgICAgICAgIDxyZWYgbmFtZT0ibm90TG9zdCIg Lz4NICAgICAgICAgPC96ZXJvT3JNb3JlPg0gICAgICAgPC9kZWZpbmU+DQ0gICAgIDwvZGl2 Pg0NICAgPC9ncmFtbWFyPg0NICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDI0DQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDQ0NDUhhcmRp ZSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMjUsIDIwMDcgICAgICAgICAg ICAgIFtQYWdlIDcxXQ0MDUludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBMb1NU ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMjAwNw0NDUF1dGhvcnMnIEFkZHJlc3Nl cw0NICAgVGVkIEhhcmRpZQ0gICBRdWFsY29tbSwgSW5jLg0NICAgRW1haWw6IGhhcmRpZUBx dWFsY29tbS5jb20NDQ0gICBBbmRyZXcgTmV3dG9uDSAgIFN1blJvY2tldA0gICA4MDQ1IExl ZXNidXJnIFBpa2UsIFN1aXRlIDMwMA0gICBWaWVubmEsIFZBICAyMjE4Mg0gICBVUw0NICAg UGhvbmU6ICsxIDcwMyA2MzYgMDg1Mg0gICBFbWFpbDogYW5keUBoeHIudXMNDQ0gICBIZW5u aW5nIFNjaHVsenJpbm5lDSAgIENvbHVtYmlhIFVuaXZlcnNpdHkNICAgRGVwYXJ0bWVudCBv ZiBDb21wdXRlciBTY2llbmNlDSAgIDQ1MCBDb21wdXRlciBTY2llbmNlIEJ1aWxkaW5nDSAg IE5ldyBZb3JrLCBOWSAgMTAwMjcNICAgVVMNDSAgIFBob25lOiArMSAyMTIgOTM5IDcwMDQN ICAgRW1haWw6IGhncytlY3JpdEBjcy5jb2x1bWJpYS5lZHUNICAgVVJJOiAgIGh0dHA6Ly93 d3cuY3MuY29sdW1iaWEuZWR1DQ0NICAgSGFubmVzIFRzY2hvZmVuaWcNICAgU2llbWVucyBO ZXR3b3JrcyBHbWJIICYgQ28gS0cNICAgT3R0by1IYWhuLVJpbmcgNg0gICBNdW5pY2gsIEJh dmFyaWEgIDgxNzM5DSAgIEdlcm1hbnkNDSAgIFBob25lOiArNDkgODkgNjM2IDQwMzkwDSAg IEVtYWlsOiBIYW5uZXMuVHNjaG9mZW5pZ0BzaWVtZW5zLmNvbQ0gICBVUkk6ICAgaHR0cDov L3d3dy50c2Nob2ZlbmlnLmNvbQ0NDQ0NDQ0NDQ0NDQ1IYXJkaWUsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIERlY2VtYmVyIDI1LCAyMDA3ICAgICAgICAgICAgICBbUGFnZSA3Ml0NDA1J bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgTG9TVCAgICAgICAgICAgICAgICAg ICAgICAgICBKdW5lIDIwMDcNDQ1GdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNDSAgIENvcHly aWdodCAoQykgVGhlIElFVEYgVHJ1c3QgKDIwMDcpLg0NICAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCByZXN0cmljdGlvbnMNICAgY29u dGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQgZm9ydGggdGhlcmVpbiwgdGhl IGF1dGhvcnMNICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQ0gICBUaGlzIGRvY3VtZW50 IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24g YW4NICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFU SU9OIEhFL1NIRSBSRVBSRVNFTlRTDSAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwg VEhFIElOVEVSTkVUIFNPQ0lFVFksIFRIRSBJRVRGIFRSVVNUIEFORA0gICBUSEUgSU5URVJO RVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FSUkFOVElFUywgRVhQ UkVTUw0gICBPUiBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBX QVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YNICAgVEhFIElORk9STUFUSU9OIEhFUkVJTiBXSUxM IE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEDSAgIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NF Lg0NDUludGVsbGVjdHVhbCBQcm9wZXJ0eQ0NICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRp b24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNICAgSW50ZWxsZWN0 dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBvdGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFp bWVkIHRvDSAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUg dGVjaG5vbG9neSBkZXNjcmliZWQgaW4NICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50 IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRzDSAgIG1pZ2h0IG9yIG1p Z2h0IG5vdCBiZSBhdmFpbGFibGU7IG5vciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhh cw0gICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2gg cmlnaHRzLiAgSW5mb3JtYXRpb24NICAgb24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0 IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0gICBmb3VuZCBpbiBCQ1AgNzgg YW5kIEJDUCA3OS4NDSAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUg SUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DSAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8g YmUgbWFkZSBhdmFpbGFibGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NICAgYXR0ZW1wdCBtYWRl IHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNl IG9mDSAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2Vy cyBvZiB0aGlzDSAgIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElF VEYgb24tbGluZSBJUFIgcmVwb3NpdG9yeSBhdA0gICBodHRwOi8vd3d3LmlldGYub3JnL2lw ci4NDSAgIFRoZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcg dG8gaXRzIGF0dGVudGlvbiBhbnkNICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQg YXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0gICByaWdodHMgdGhhdCBtYXkg Y292ZXIgdGVjaG5vbG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNICAg dGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUg SUVURiBhdA0gICBpZXRmLWlwckBpZXRmLm9yZy4NDQ1BY2tub3dsZWRnbWVudA0NICAgRnVu ZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElF VEYNICAgQWRtaW5pc3RyYXRpdmUgU3VwcG9ydCBBY3Rpdml0eSAoSUFTQSkuDQ0NDQ0NSGFy ZGllLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBEZWNlbWJlciAyNSwgMjAwNyAgICAgICAg ICAgICAgW1BhZ2UgNzNdDQwNDQ0FVGhpcyByZWZlcmVuY2UgaXMgdG8gYmFzZWQgR01MIDMu MSwgc2hvdWxkIHRoaXMgYmUgYSByZWZlcmVuY2UgdG8gdGhlIGdlb3NoYXBlcyBwcm9maWxl IGRvY3VtZW50Pw0FVGhlIHByZXZpb3VzIHBhcmFncmFwaHMgZGVzY3JpYmUgaG93IGEgY2xp ZW50IGxlYXJuIHRoZSBMb1NUIHNlcnZlciBpZGVudGl0eSwgc28gSSBhbSBub3QgdG9vIHN1 cmUgd2hhdCB0aGlzIGFkZGl0aW9uYWwgcGFyYWdyYXBoIGlzIHRyeWluZyB0byBzYXkuDQ1J cyBpdCB0cnlpbmcgdG8gc2F5IHRoYXQgdGhlcmUgYXJlIG90aGVyIHdheXMgdGhhdCBhIGNs aWVudCBjYW4gbGVhcm4gdGhlIGlkZW50aXR5IG9mIGEgTG9TVCBzZXJ2ZXIsIG9yIGlzIGl0 IGhpbnRpbmcgdGhhdCBvdGhlciBzdGVwcyBhcmUgcmVxdWlyZWQgZm9yIGEgY2xpZW50IHRv IGxlYXJuIHRoZSBsb2NhbCBMb1NUIHNlcnZlcj8NBUlzIHRoZXJlIGEgdGltZSBhZnRlciB3 aGljaCB0aGUgc2VydmVyIE1VU1QgZXhwaXJlIHRoZSB2YWx1ZSBmcm9tIGNhY2hlLCBhbmQg bm8gbG9uZ2VyIGNvbnRpbnVlIHRyeWluZyB0byBnZXQgYSBuZXcgbWFwcGluZz8NQXMgYSBk ZXZlbG9wZXIgb2YgYSBMb1NUIHNlcnZlciBzdWNoIGd1aWRhbmNlIGlzIHF1aXRlIGltcG9y dGFudC4NBUkgdGhpbmsgYW4gZXhhbXBsZSBmb3IgdGhpcyBzZWN0aW9uIHdvdWxkIHNwZWFr IHdvbmRlcnMuDQ1UaGUgb25lIHRoYXQgc3ByaW5ncyB0byBtaW5kIHdvdWxkIGJlIHNvbWVv bmUgYXNraW5nIGZvciBhIHNwZWNpZmljIHR5cGUgb2YgZW1lcmdlbmN5IHNlcnZpY2UsIGJ1 dCB0aGUgbG9jYWwgc2VydmljZSBpcyBzaW1wbHkgYSBnZW5lcmFsIGVtZXJnZW5jeSBzZXJ2 aWNlIFVSSS4gSXQgd291bGQgYmUgb2theSB0byByZXR1cm4gdGhlIGxhdHRlciwgc2luY2Ug dGhlIGZvcm1lciBkb2VzIG5vdCBleGlzdC4NBUl0IG1heSBiZSB1c2VmdWwsIG9yIGRlc2ly YWJsZSBmb3IgYSBzb21lIHNlcnZpY2UgYm91bmRhcmllcyB0byBub3QgYmUgInJlbGVhc2Vk IiBmcm9tIGEgZ2l2ZW4gTG9TVCBzZXJ2aWNlLiBJcyB0aGVyZSBhIHdheSB0byBzcGVjaWZ5 IHRoaXM/DQVJdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyB0aGlzIGNvbnNlcnZlcyBiYW5kd2lk dGggZm9yIHRoZSBjbGllbnQgaWYgdGhlIGNsaWVudCBpcyBhbiBlbmQtcG9pbnQuDVRoZSBy ZWFzb24gYmVpbmcgdGhhdCBpZiBJIHJlcXVpcmUgdGhlIGluZm9ybWF0aW9uLCB0aGVuIEkg bmVlZCB0byBvYnRhaW4sIHNvIHdoZXRoZXIgaXQgc2VudCBvdmVyIExvU1Qgb3Igc29tZSBv dGhlciBtZWFucyB3aWxsIG5vdCBsaWtlbHkgY29uc2VydmUgYmFuZHdpZHRoLi4gSWYgSSBk b24ndCByZXF1aXJlIHRoZSBpbmZvcm1hdGlvbiB0aGVuIEkgcHJvYmFibHkgd29uJ3QgYXNr IGZvciBpdC4NDUkgc3VnZ2VzdCB0aGF0IHN0cm9uZ2VyIG1vdGl2YXRpb24gZm9yIHRoaXMg ZnVuY3Rpb24gaXMgcmVxdWlyZWQuDQVJIHRoaW5rIHRoZXJlIG5lZWRzIHRvIGJlIGEgY29t bWVudCBpbiBoZXJlIHRvIGluZGljYXRlIHRoYXQgbm90IG9ubHkgZG9lcyB0aGUgaWRlbnRp ZmllciBjaGFuZ2UsIGJ1dCB0aGUgb2xkIGlkZW50aWZpZXIgTVVTVCBiZSB2b2lkZWQgYW5k IHJlcXVlc3RzIHRvIHRoYXQgcmVmZXJlbmNlIE1VU1QgcmVzdWx0IGluIGFuIGVycm9yLg0F SWYgdGhpcyB3ZXJlIGl0ZXJhdGl2ZSwgdGhlbiBob3cgZG9lcyB0aGUgdmlhIGluZGljYXRl IHRoaXM/DQ1NeSByZWFkaW5nIG9uIHRoaXMgbWFrZXMgdGhpcyBpbmRpc3Rpbmd1aXNoYWJs ZSBmcm9tIGEgY2hhaW4sIHdoaWNoIHNlZW1zIHRvIGJlIHRoZSBub3JtLg0NIElmIHRoZXJl IGlzIGEgd2F5IHRvIGRpc3Rpbmd1aXNoIHRoZW0gdGhlbiBpdCBzaG91bGQgYmUgc3RhdGVk LCBhbmQgYW4gZXhhbXBsZSBwcm92aWRlZC4gT3RoZXJ3aXNlIEkgdGhpbmsgdGhpcyB3aWxs IGxlYWQgdG8gY29uZnVzaW9uLg0FaW4gdGhlIHNjb3BlIG9mIHRoZSByZXF1ZXN0Lg0FTW9y ZSBleGFtcGxlcyBhcmUgZ29vZC4NDUkgdGhpbmsgYXQgbGVhc3Qgb25lIGV4YW1wbGUgc2hv d2luZyBob3cgdGhlIHF1ZXJ5IHdhcyBmb3IgdGhlIHBvbGljZSwgYnV0IHRoZSByZXNwb25z ZSBjYW1lIGJhY2sgZm9yIGEgZ2VuZXJhbCBQU0FQIHdvdWxkIGJlIGdvb2QuDQ1UaGlzIGV4 YW1wbGUgbWF5IGFsc28gaW5jbHVkZSB0aGUgcmVxdWVzdCBjb21pbmcgaW4gd2l0aCBhIGNp cmNsZSBpbnN0ZWFkIG9mIGp1c3QgYSBwb2ludCwgc2luY2UgZm9yIGdlb2RldGljIHJlcXVl c3RzIHRoaXMgaXMgZmFyIG1vcmUgbGlrZWx5Lg0FY2Fubm90DQVJIGZvdW5kIHRoaXMgc2Vj dGlvbiB2ZXJ5IGhhcmQgdG8gZm9sbG93IGJlY2F1c2UgdGhlcmUgaXMgbm8gc2NoZW1hIGZy YWdtZW50Lg0NSSB0aGluayBmb3IgY2xhcml0eSwgeW91IGVpdGhlciBuZWVkIHRvIHJlcGxp Y2F0ZSBtdWNoIG9mIGZpZ3VyZSA3IGhlcmUgKGJlc3Qgb3B0aW9uKSwgb3IgYXQgbGVhc3Qg c3VnZ2VzdCByZWZlcnJpbmcgdG8gaXQgYXQgdGhlIHN0YXJ0IG9mIHRoZSBzZWN0aW9uLCBy YXRoZXIgdGhhbiBhdCB0aGUgYm90dG9tLg0FdW5jaGVja2VkIGlzIG5vdCBpbmNsdWRlZCBp biB0aGUgZXhhbXBsZXMsIGl0IG1heSBiZSBnb29kIHRvIGluY2x1ZGUgdGhpcyBhbHNvLg0F V2hpbGUgaW1wbGVtZW50aW5nIHRoZSBvcGVuIHNvdXJjZSBMSVMgbG9jYXRpb24gYXNzZXJ0 aW9uIGZ1bmN0aW9uIEkgcmFuIGludG8gYSBzZXQgb2YgcHJvYmxlbXMgdGhhdCB5b3UgaGF2 ZSBub3QgZGVzY3JpYmVkIGhlcmUuIEFuZCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBo b3cgSSB3b3VsZCBhZGRyZXNzIHRoZXNlIGluIExvU1QuDQ1Gb3IgYW55IGdpdmVuIGFyZWEs IEkgaGF2ZSBhIHNwZWNpZmljIHNldCBvZiBmaWVsZHMgaW4gdGhlIGNpdmljIHN0cnVjdHVy ZSB0aGF0IGFyZSB1c2VmdWwuIFNvbWUgb2YgdGhlIHJlbWFpbmluZyBmaWVsZHMgZG9uJ3Qg bWF0dGVyLCBhbmQgc3RpbGwgc29tZSBvdGhlcnMgZnVuZGFtZW50YWxseSBjaGFuZ2UgdGhl IGxvY2F0aW9uIGludGVycHJldGF0aW9uLCBhbmQgc28gbXVzdCBub3QgYmUgdXNlZC4NDVdo ZW4gSSBpbXBsZW1lbnRlZCB0aGUgTElTLCBJIGhhZCB0d28gbGlzdHMgb2YgY2l2aWMgZWxl bWVudHMsIGEgd2hpdGUtbGlzdCBhbmQgYSBibGFjay1saXN0LiBJIGNoZWNrZWQgdGhlIHdo aXRlLWxpc3QgZm9yIGVxdWFsaXR5LCBJIGNoZWNrZWQgdGhlIGJsYWNrLWxpc3QgZm9yIG5v bi1lbXB0eS4NDUxldCBtZSBrbm93IGlmIHRoaXMgbWFrZXMgc2Vuc2UsIGJlY2F1c2UgZnJv bSBhIHJlcG9ydGVkIGxvY2F0aW9uIHBlcnNwZWN0aXZlIEkgdGhpbmsgdGhlcmUgaXMgYSBk aWZmZXJlbmNlLg0NRXhhbXBsZTogU3VwcG9zZSBJIGZpbGwgaW4gQTYgZm9yIHJvYWQsIGJ1 dCBub3QgUkQsIHdoYXQgd291bGQgSSBleHBlY3QgdG8gc2VlIGNvbWUgYmFjaz8NDQ0FSSB0 aGluayB5b3UgbWVhbiBmaWd1cmUgNy4gVGhpcyByZWFsbHkgdGhyb3VnaCBtZSBmb3IgYSB3 aGlsZS4NBUE2IGlzIG1vcmUgb3IgbGVzcyBkZXByZWNhdGVkIGJ5IHRoZSB2YXJpb3VzIHRo b3JvdWdoZmFyZSBlbGVtZW50cyBpbiByZXZpc2VkIGNpdmljLiBXZSBzaG91bGQgbm90IGVu Y291cmFnZSBpdHMgdXNlLg0FVGhpcyBpcyBjb25mdXNpbmcuIEZpZ3VyZSA4IHNob3dzIHRo ZSByZXF1ZXN0LCBhbmQgbm90IHRoZSByZXNwb25zZSBhcyBpbmRpY2F0ZWQuDQU8c2Vydmlj ZUJvdW5kYXJ5UmVmZXJlbmNlDSAgICAgICAgIHNvdXJjZT0iYXV0aG9yaXRhdGl2ZS5leGFt cGxlIg0gICAgICAgICBrZXk9IjcyMTQxNDhFMDQzM0FGRTJGQTJENDgwMDNEMzExNzJFIiAv Pg0NDVRoZXJlIGlzIG5vIHNlcnZlciBwcm92aWRlZCBoZXJlLg1BbHNvIHNob3VsZCB0aGVy ZSBiZSBhIC5jb20gb3Igc29tZXRoaW5nIGFkZGVkIHRvIHRoZSBleGFtcGxlPw0NQWxzbywg aWYgeW91IG1ha2UgdGhpcyBhIExvU1QgVVJJIHJhdGhlciB0aGFuIGEgc2ltcGxlIGhvc3Qg bmFtZSwgdGhlbiBJIHRoaW5rIGl0IHdpbGwgYmUgY2xlYXJlciBhcyB0byB3aGF0IGlzIHJl cXVpcmVkLg0NSSBhbHNvIHdvbmRlciB3aGV0aGVyIHVzaW5nIExvU1QgZm9yIHRoaXMgcmV0 cmlldmFsIGlzIHRoZSByaWdodCB0aGluZyB0byBkby4gRm9yIGV4YW1wbGUsIHdoeSBjb3Vs ZG4ndCB0aGlzIGp1c3QgYmUgYW4gSFRUUCBnZXQgb3Igc29tZXRoaW5nIGxpa2UgdGhhdD8N BUlzIHRoaXMgcmVwZWF0IGludGVudGlvbmFsPw0FV2hlbiB0aGlzIHJ1bGUgaXMgY291cGxl ZCB3aXRoIHJ1bGUgNSBtZWFucyB0aGF0IG9yZGVyIG9mIHByb2ZpbGVzIGluIHRoZSByZXF1 ZXN0IE1VU1QgYmUgYWRoZXJlZCB0by4NDVRoYXQgaXMsIGlmIEkgcHJvdmlkZSBhIG5ldyBm YW5jeSBwcm9maWxlLCBteSBwcmVmZXJlbmNlIGlzIHRoYXQgdGhlIHNlcnZlciB1c2VzIGl0 LCBpZiB0aGUgc2VydmVyIGlzIHVuYWJsZSB0byB1c2UgaXQsIHRoZW4gaXQgTUFZIHVzZSB0 aGUgb2xkZXIgcHJvZmlsZSBpZiBpdCBoYXMgdG8uDQ1UaGlzIGNvbnN0cmFpbnQgbmVlZHMg dG8gYmUgc3BlbHQgb3V0LiBJcyB0aGlzIHdoYXQgcnVsZSA2IGlzIHRyeWluZyB0byBzYXk/ DQVJIGhhdmUgVkVSWSBTVFJPTkcgY29uY2VybnMgYWJvdXQgdGhpcyBwcm9maWxlIGJlaW5n IHNvIHJlc3RyaWN0aXZlLg0NSWYgSSB3ZXJlIHRvIHVzZSBhIEdQUyBmb3IgZXhhbXBsZSBJ IG1heSBnZXQgYW55IG9uZSBvZiB0aGUgZm9sbG93aW5nIHNoYXBlIHR5cGVzOg0NQ2lyY2xl LA1TcGhlcmUsDUVsbGlwc2UNRWxsaXBzb2lkDQ1UaGUgcHJvZmlsZXMgYmVpbmcgc3VnZ2Vz dGVkIEZPUkNFIHRoZSBjbGllbnQgdG8gaW50ZXJwcmV0IHRoaXMgbG9jYXRpb24gZWl0aGVy IGFzIGEgcG9pbnQsIG9yIGNvbnZlcnQgaXQgdG8gYSBwb2x5Z29uLiBCb3RoIGFyZSB1bmFj Y2VwdGFibGUuDQ1BbmQgZW5kLXBvaW50IE1VU1QgYmUgYWJsZSB0byBwcm92aWRlIGxvY2F0 aW9uIHRvIHRoZSBMb1NUIHNlcnZlciBpbiB0aGUgZm9ybSBpdCBoYXMgYWNxdWlyZWQgaXQu IEhvdyB0aGUgTG9TVCBzZXJ2ZXIgZG9lcyB0aGlzIGNvbnZlcnNpb24gaXMgYSBMb1NUIHBy b2JsZW0uDQ1DaGFuZ2luZyB0aGUgMkQgcG9seWdvbiBwcm9maWxlIHRvIHN1cHBvcnQgdGhp cyBpcyBub3QgYSBiaWcgY2hhbmdlLCBidXQgbWFrZXMgdGhlIGZ1bmN0aW9uYWxpdHkgYWN0 dWFsbHkgdXNlZnVsLCB3aXRob3V0IGV4cGVjdGluZyB0aGUgZW5kLXBvaW50IHRvIHVuZGVy c3RhbmQgaG93IHRvIGludGVycHJldCBsb2NhdGlvbi4NBXJlc3BvbnNlDQ0NAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAYAAGUoAABmKAAA1DgAANU4AADjOAAA5zgAAI1JAACOSQAAk0kAAJ5JAACfSQAA HksAAF5LAABjSwAAgksAAKxLAACtSwAAPk4AAEJOAAAoWAAAKVgAAK9cAACwXAAABV4AAAZe AAAZZgAAGmYAAKFpAAD56fnT+cn5ufmvpZuRh5GHgPl2+bn5ZvlW+Vb5AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAB8DagAAAAAWaOluXgAwShAAT0oAAFFKAABVCAFeSgAAHwNqAAAA ABZoY0APADBKEABPSgAAUUoAAFUIAV5KAAATAQiBBEgBAAVoNQy3BhZo9ge3AAwVaEIPsgAW aB0gHQAAEwEIgQRIAQAFaGAStyYWaB0gHQATAQiBBEgBAAVoXxK3JhZoHSAdABMBCIEESAEA BWhdErcmFmgdIB0AEwEIgQRIAQAFaFwStyYWaEIPsgATAQiBBEgBAAVoXBK3JhZoHSAdAB8D agAAAAAWaPYHtwAwShAAT0oAAFFKAABVCAFeSgAAEwEIgQRIAQAFaBsMtwYWaC8TvAArAAiB FWhCD7IAFmhCD7IAF2gvE7wAY0gBAGRoAAAAAGRoAAAAAGRoGwy3Bh8DagAAAAAWaC8TvAAw ShAAT0oAAFFKAABVCAFeSgAADBVoQg+yABZoQg+yABwABgAAAQgAAAIIAAADCAAATAgAAJUI AADeCAAAJwkAAHAJAAC5CQAAAgoAAEsKAACUCgAAlQoAAJYKAADTCgAABgsAAAcLAAAbCwAA HAsAAGILAACnCwAA7QsAADEMAAAyDAAAdwwAALsMAAD+DAAACQ0AAAoNAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8T vAAAHQAGAAD2wgEAhNcBAP7+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAQECCg0AAFMNAACbDQAA3Q0AABsOAAAcDgAA Vg4AAIUOAACGDgAAyg4AAO4OAADvDgAAKA8AACkPAAA6DwAAOw8AAGMPAABkDwAAZQ8AAGYP AABnDwAAaA8AAGkPAABqDwAAaw8AAGwPAAC1DwAAtw8AAAAQAAABEAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AB0BEAAAAhAAAAsQAAAMEAAAURAAAJYQAADXEAAADBEAAA0RAAAOEQAAIBEAACERAABqEQAA sxEAAPwRAABFEgAAjhIAAMwSAAAVEwAAXhMAAKcTAADwEwAAMhQAAHsUAACrFAAA9BQAAD0V AACGFQAAzxUAAAkWAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHQkWAABSFgAAmxYAAOQWAAAtFwAAdhcAAL8X AAAIGAAAURgAAJoYAADjGAAALBkAAHUZAACjGQAA7BkAADUaAABjGgAArBoAAPUaAAA+GwAA hxsAAIgbAACJGwAAihsAANMbAADVGwAAHhwAAB8cAAAgHAAAaRwAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd aRwAALIcAAD7HAAARB0AAI0dAADWHQAAHx4AAGgeAACxHgAA+h4AAEMfAACMHwAA1R8AAB4g AABnIAAAsCAAAPkgAABCIQAAiyEAANQhAAAdIgAAZiIAAK8iAAD4IgAAQSMAAIojAADTIwAA 1CMAANUjAADWIwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB3WIwAA1yMAANgjAADZIwAA2iMAANsjAADcIwAA 3SMAAN4jAADfIwAA4CMAAOEjAADiIwAA4yMAAOQjAADlIwAA5iMAAOcjAADoIwAA6SMAAOoj AADrIwAANCQAADYkAAB/JAAAgCQAAIEkAACSJAAAkyQAANgkAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHdgk AAAgJQAAaCUAALAlAAD4JQAAOyYAAIImAADGJgAADicAAFEnAACUJwAAlScAANwnAAAjKAAA aygAALEoAADyKAAAOykAAIEpAADIKQAAByoAAAgqAABNKgAAjyoAANQqAAAZKwAAWysAAJwr AADiKwAAKSwAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdKSwAAGgsAACsLAAAxCwAAMUsAAAOLQAAVi0AAJ4t AADdLQAA3i0AACQuAABsLgAAqC4AAKkuAADxLgAANS8AAHcvAAB4LwAAeS8AAHovAADDLwAA xS8AAA4wAAAPMAAAEDAAAFQwAABdMAAAXjAAAJ4wAADkMAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB3kMAAA JTEAAGkxAACpMQAA8TEAADgyAACAMgAAxzIAAAwzAABTMwAAmzMAANEzAADSMwAA0zMAANQz AADVMwAA1jMAANczAADYMwAA2TMAANozAADbMwAA3DMAAN0zAADeMwAA3zMAAOAzAADhMwAA 4jMAAOMzAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAAHeMzAADkMwAA5TMAAOYzAADnMwAA6DMAAOkzAADqMwAA 6zMAAOwzAADtMwAA7jMAAO8zAADwMwAA8TMAAPIzAADzMwAA9DMAAD00AAA/NAAAiDQAAIk0 AACKNAAAtDQAALU0AAD8NAAARDUAAHs1AAB8NQAApzUAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdpzUAAKg1 AADuNQAANzYAAIA2AADJNgAAEjcAAEU3AABGNwAARzcAAIw3AADANwAAwTcAAMI3AAAKOAAA STgAAI04AACOOAAAjzgAANY4AAAcOQAARjkAAEc5AABIOQAAkTkAANo5AAAhOgAARDoAAEU6 AABGOgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2QvE7wAAB1GOgAAVToAAFY6AACeOgAAyDoAAMk6AAALOwAADDsAAA07 AAAOOwAADzsAABA7AAAROwAAEjsAABM7AAAUOwAAXTsAAF87AACoOwAAqTsAAKo7AADJOwAA yjsAAAo8AAAYPAAAGTwAAEQ8AABFPAAAjjwAANc8AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHdc8AAAdPQAA Yj0AAJ89AACgPQAAoT0AANo9AADbPQAAID4AAE4+AABPPgAAUD4AAH0+AAB+PgAAxT4AAAg/ AAAJPwAACj8AAEs/AABMPwAAkz8AANw/AAD5PwAA+j8AAD1AAABfQAAAYEAAAKVAAACmQAAA 40AAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkLxO8AAAd40AAACxBAAAtQQAAc0EAAI5BAACPQQAAw0EAAMRBAAALQgAA SkIAAF5CAABfQgAAYEIAAGFCAACqQgAArEIAAPVCAAD2QgAA90IAADtDAAB/QwAAx0MAAAdE AABMRAAAfEQAAH1EAAB+RAAAf0QAAIBEAACBRAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2BRAAAgkQAAINE AACERAAAhUQAAIZEAACHRAAAiEQAAIlEAACKRAAAi0QAAIxEAACNRAAAjkQAAI9EAACQRAAA kUQAAJJEAACTRAAAlEQAAJVEAACWRAAAl0QAAJhEAACZRAAAmkQAAJtEAACcRAAAnUQAAJ5E AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZC8TvAAAHZ5EAACfRAAAoEQAAKFEAACiRAAAo0QAAKREAAClRAAApkQAAKdE AACoRAAAqUQAAPJEAAD0RAAAPUUAAD5FAAA/RQAAZUUAAGZFAACtRQAA40UAAABGAAABRgAA SkYAAJFGAADYRgAAIUcAAERHAABFRwAAhkcAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdhkcAAM9HAAAUSAAA IkgAACNIAAAkSAAAOEgAADlIAABnSAAApEgAAKVIAADSSAAAB0kAAAhJAABPSQAAjUkAAI9J AACQSQAAkUkAAJJJAACTSQAAn0kAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAABA8AZ2QvE7wAABWfSQAAH0sAACBLAACtSwAArksAAK9LAACwSwAAsUsAALJLAACzSwAA tEsAALVLAAC2SwAAtwAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAagAA AAAAAAAAAAAAAGoAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAGoAAAAA AAAAAAAAAABqAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAABqAAAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAARw8AQyQBRcaAAAABAF8StyYAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZC8T vAAARw8AQyQBRcaAAAABAF0StyYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZC8TvAAADLZLAAC3SwAAuEsAALlL AAC6SwAAu0sAALxLAAC9SwAAvksAAAdMAAAJTAAAUkwAAFNMAABUTAAAbkwAAG9MAAC3TAAA /kwAAC5NAAAvTQAAdk0AAIdNAACITQAAyU0AABBOAABYTgAAnk4AAOROAAAtTwAAR08AAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkLxO8AAAdR08AAEhPAACMTwAA008AANRPAAAdUAAAYVAAAKhQAADtUAAA+FAAAPlQ AAA+UQAAhFEAAMpRAAAGUgAAR1IAAEhSAAB5UgAAelIAAL1SAAD+UgAAQFMAAIZTAADNUwAA 2VMAANpTAAAhVAAAalQAALBUAAD2VAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB32VAAA91QAAD5VAACBVQAA glUAAINVAACEVQAAzVUAAM9VAAAYVgAAGVYAABpWAABjVgAAq1YAAPBWAAA4VwAAgFcAAMFX AAAJWAAAK1gAACxYAABoWAAAaVgAAKxYAADyWAAAOlkAAFRZAABVWQAAhlkAAIdZAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZC8TvAAAHYdZAADQWQAAFloAAFRaAABVWgAAm1oAAOBaAAAnWwAAUlsAAFNbAACcWwAA 41sAACJcAABoXAAAsVwAAPFcAAA4XQAAgV0AAMBdAADBXQAAB14AAAheAABRXgAAlV4AANVe AAAcXwAAZF8AAKxfAADzXwAAPGAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdPGAAAINgAACEYAAAhWAAAIZg AADPYAAA0WAAABphAAAbYQAAHGEAAGVhAACtYQAA82EAADxiAACBYgAAgmIAAL5iAAACYwAA DmMAAA9jAABWYwAAnWMAAOJjAAApZAAAcWQAALNkAADSZAAA02QAABllAAAnZQAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2QvE7wAAB0nZQAAKGUAAHFlAAC3ZQAA/mUAAEdmAACOZgAAzWYAABNnAABPZwAAemcAAHtn AADCZwAACmgAAFBoAACIaAAAv2gAAMBoAAAGaQAATWkAAJVpAADfaQAAJWoAAGtqAACzagAA +GoAADtrAACEawAAuGsAALlrAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHaFpAACiaQAARHMAAEVzAADdcwAA 3nMAABJ3AAATdwAA8nkAAPN5AACgmAAAoZgAAAWqAAAGqgAALqsAAC+rAAAzqwAA3awAAN6s AADyrAAA86wAAGSuAABlrgAAgq8AAIOvAAC/rwAAwK8AAFOyAABUsgAAY7MAAO/o0ujC6LLo suii6JLoiHLokuhc6JLokuiS6EzoAAAAHwNqAAAAABZo9AcQADBKEABPSgAAUUoAAFUIAV5K AAArAAiBFWhCD7IAFmhCD7IAF2j+MSwAY0gBAGRoAAAAAGRoAAAAAGRoThK3JisACIEVaEIP sgAWaEIPsgAXaP4xLABjSAEAZGgAAAAAZGgAAAAAZGhNErcmEwEIgQRIAQAFaE0StyYWaP4x LAAfA2oAAAAAFmgNCV8AMEoQAE9KAABRSgAAVQgBXkoAAB8DagAAAAAWaP4xLAAwShAAT0oA AFFKAABVCAFeSgAAHwNqAAAAABZo0FvoADBKEABPSgAAUUoAAFUIAV5KAAAfA2oAAAAAFmjH FGwAMEoQAE9KAABRSgAAVQgBXkoAACsACIEVaEIPsgAWaEIPsgAXaMcUbABjSAEAZGgAAAAA ZGgAAAAAZGhZDLcGDBVoQg+yABZoQg+yAAAfA2oAAAAAFmhHd6MAMEoQAE9KAABRSgAAVQgB XkoAAAAduWsAALprAAC7awAABGwAAAZsAABPbAAAUGwAAFFsAACIbAAAiWwAAMtsAAARbQAA VW0AAGFtAABibQAAiG0AAIltAADRbQAAFW4AAFtuAACebgAA5m4AAPFuAADybgAA824AAPRu AAD1bgAA9m4AAPduAAD4bgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB34bgAA+W4AAPpuAAD7bgAA/G4AAP1u AAD+bgAA/24AAABvAAABbwAAAm8AAANvAAAEbwAABW8AAAZvAAAHbwAACG8AAAlvAAAKbwAA C28AAAxvAAANbwAADm8AAA9vAAAQbwAAEW8AABJvAAATbwAAFG8AABVvAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8T vAAAHRVvAABebwAAYG8AAKlvAACqbwAAq28AANVvAADWbwAAHnAAAGFwAACmcAAA63AAADBx AAB2cQAAvnEAAAJyAABLcgAAV3IAAFhyAAChcgAA6nIAAC9zAAB0cwAAdXMAAL1zAADgcwAA 4XMAACd0AABwdAAAonQAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdonQAAMJ0AADDdAAAxHQAAMV0AADGdAAA x3QAAMh0AADJdAAAynQAAMt0AADMdAAAzXQAAM50AADPdAAA0HQAANF0AADSdAAA03QAANR0 AADVdAAA1nQAANd0AADYdAAA2XQAANp0AADbdAAA3HQAACV1AAAndQAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AB0ndQAAcHUAAHF1AABydQAAuHUAALl1AAABdgAASHYAAJB2AADWdgAAGncAAFt3AACjdwAA 33cAAPZ3AAD3dwAA+HcAAPl3AAD6dwAA+3cAAPx3AAD9dwAA/ncAAP93AAAAeAAAAXgAAAJ4 AAADeAAABHgAAAV4AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHQV4AAAGeAAAB3gAAAh4AAAJeAAACngAAAt4 AAAMeAAADXgAAA54AAAPeAAAEHgAABF4AAASeAAAE3gAABR4AAAVeAAAFngAABd4AAAYeAAA GXgAABp4AAAbeAAAHHgAAB14AAAeeAAAZ3gAAGl4AACyeAAAs3gAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd s3gAALR4AADueAAA73gAAP54AAD/eAAAO3kAAH15AADFeQAA43kAAOR5AAD0eQAA9XkAACB6 AAAhegAAaXoAAK16AADKegAAy3oAAMx6AAD2egAABnsAADB7AABbewAAeHsAAI97AACQewAA zHsAAA98AAA6fAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB06fAAATXwAAF58AACNfAAAjnwAAKB8AAChfAAA 23wAANx8AAAhfQAAZH0AAKd9AADqfQAAMX4AAHl+AADCfgAACn8AAFB/AACZfwAA1X8AANZ/ AADXfwAA2H8AANl/AAAigAAAJIAAAG2AAABugAAAb4AAAJmAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHZmA AADWgAAAAoEAABCBAAA2gQAAYIEAAIaBAAC6gQAA3YEAAAaCAAAcggAATYIAAHyCAAC4ggAA 0YIAAO6CAAAfgwAAUIMAAIGDAACygwAA44MAAAGEAAAbhAAAMoQAAEyEAABzhAAAm4QAAMWE AADVhAAA4YQAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd4YQAAA6FAAA2hQAAQ4UAAG6FAACIhQAAiYUAAMiF AADJhQAA74UAAPCFAAA4hgAAeoYAALyGAAAFhwAASocAAF+HAABghwAAYYcAAGKHAABjhwAA ZIcAAK2HAACvhwAA+IcAAPmHAAD6hwAAJIgAAFmIAACIiAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2IiAAA v4gAANSIAAAWiQAAOokAAFSJAABtiQAAjokAAKSJAAC8iQAA04kAAOSJAAATigAAJYoAACaK AABjigAAZIoAAKmKAADsigAAL4sAAHSLAAC7iwAAAYwAAEKMAACHjAAAzIwAAA6NAABXjQAA lo0AAJeNAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAAHZeNAACYjQAAmY0AAJqNAACbjQAAnI0AAJ2NAACejQAA n40AAKCNAAChjQAAoo0AAKONAACkjQAApY0AAKaNAACnjQAAqI0AAKmNAACqjQAA840AAPWN AAA+jgAAP44AAECOAABqjgAAqI4AALaOAADcjgAABo8AAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdBo8AADCP AABkjwAAh48AAKuPAADBjwAA8o8AAAqQAABQkAAAZ5AAAKuQAADRkAAA7ZAAAAiRAAAikQAA O5EAAFWRAACFkQAAtpEAAOCRAADwkQAA/JEAAC2SAABgkgAAbZIAAJmSAACzkgAAtJIAAPWS AAD2kgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2QvE7wAAB32kgAAJJMAACWTAABukwAAsZMAAPeTAAAElAAABZQAACSU AAAllAAAbJQAALWUAAD8lAAARZUAAIiVAACJlQAAipUAAIuVAADUlQAA1pUAAB+WAAAglgAA IZYAAEaWAABHlgAAf5YAAICWAADGlgAACJcAAAmXAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHQmXAAAplwAA KpcAAHOXAAC2lwAA+pcAAAiYAAAJmAAASpgAAI2YAAC8mAAAvZgAAAaZAABMmQAAk5kAANuZ AAAhmgAAZpoAAKeaAACzmgAAtJoAAM2aAADOmgAAFZsAAFqbAACgmwAA5ZsAACycAAB1nAAA vpwAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkLxO8AAAdvpwAAO6cAADvnAAAHJ0AAB2dAABenQAApZ0AAOGdAAAhngAA aJ4AAKmeAADPngAA0J4AANGeAADSngAA054AAByfAAAenwAAZ58AAGifAABpnwAAk58AAKOf AADNnwAA458AAACgAAAeoAAAVaAAAGqgAACsoAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2soAAAy6AAAOWg AAD+oAAAH6EAADWhAABNoQAAZKEAAHWhAACkoQAAtqEAALehAAD9oQAA/qEAAP+hAAAAogAA AaIAAAKiAAADogAABKIAAAWiAAAGogAAB6IAAAiiAAAJogAACqIAAAuiAAAMogAADaIAAA6i AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZC8TvAAAHQ6iAAAPogAAEKIAABGiAAASogAAE6IAABSiAAAVogAAFqIAABei AAAYogAAGaIAABqiAAAbogAAZKIAAGaiAACvogAAsKIAALGiAADbogAAGaMAACejAABNowAA d6MAAJ2jAADRowAA9KMAABikAAAupAAAX6QAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdX6QAAIikAACfpAAA 46QAAAmlAAAlpQAAQKUAAFqlAABzpQAAjaUAAL2lAADupQAAGKYAACimAABCpgAAaaYAAIam AAChpgAAraYAANqmAAACpwAAD6cAADunAABVpwAAVqcAAJ2nAADJpwAAyqcAAAmoAAAKqAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2QvE7wAAB0KqAAAG6gAAByoAABeqAAAnqgAAOaoAAAnqQAAKKkAACmpAAAqqQAA K6kAACypAAB1qQAAd6kAAMCpAADBqQAAwqkAAAeqAAAIqgAAUaoAAJmqAADhqgAAJ6sAAHCr AAC3qwAA/qsAAEasAACPrAAA0KwAABitAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHRitAABarQAAn60AAOet AAAcrgAAHa4AAGauAACurgAA9q4AADevAABnrwAAaK8AAK6vAAD1rwAAPrAAAFCwAABRsAAA UrAAAFOwAABUsAAAVbAAAFawAABXsAAAWLAAAFmwAABasAAAW7AAAFywAABdsAAAXrAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkLxO8AAAdXrAAAF+wAABgsAAAYbAAAGKwAABjsAAAZLAAAGWwAABmsAAAZ7AAALCw AACysAAA+7AAAPywAAD9sAAAOrEAADuxAACCsQAAyLEAAA+yAABVsgAAjLIAAMyyAAALswAA VLMAAJqzAADjswAA87MAAPSzAAD1swAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB1jswAAZLMAAFK+AABTvgAA McMAADLDAAC6wwAApsQAAKfEAACoxAAAhNYAAIfWAADx5QAA8uUAANftAADc7QAA3e0AADTv AAA67wAAO+8AAL7vAAC/7wAAJAUBACUFAQCOCwEAjwsBABQMAQAYDAEAMAwBADEMAQB2GgEA 7+jv6N7UytTD6LnoqeiflZ+Ln4uE6HToamBWYE/oAAAAAAwVaEIPsgAWaClRngAAEwEIgQRI AQAFaAkTtyYWaClRngATAQiBBEgBAAVoCBO3JhZoKVGeABMBCIEESAEABWgIE7cmFmhCD7IA HwNqAAAAABZoKVGeADBKEABPSgAAUUoAAFUIAV5KAAAMFWhCD7IAFmieCewAABMBCIEESAEA BWj4ErcmFmieCewAEwEIgQRIAQAFaPYStyYWaEIPsgATAQiBBEgBAAVo9hK3JhZongnsAB8D agAAAAAWaJ4J7AAwShAAT0oAAFFKAABVCAFeSgAAEwEIgQRIAQAFaO4StyYWaJ4J7AAMFWhC D7IAFmiXKM0AABMBCIEESAEABWjEErcmFmjAAvQAEwEIgQRIAQAFaHAStyYWaJcozQATAQiB BEgBAAVocBK3JhZoQg+yAAwVaEIPsgAWaEIPsgAAHwNqAAAAABZo9AcQADBKEABPSgAAUUoA AFUIAV5KAAAAHvWzAAD2swAAILQAADC0AABatAAAhbQAAJu0AAC9tAAA+bQAADy1AABntQAA erUAAIu1AAC6tQAAzLUAAM21AAAUtgAAP7YAAEC2AABBtgAAQrYAAEO2AABEtgAARbYAAEa2 AABHtgAASLYAAEm2AABKtgAAS7YAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdS7YAAEy2AABNtgAATrYAAE+2 AABQtgAAUbYAAFK2AACbtgAAnbYAAOa2AADntgAA6LYAABK3AABPtwAAe7cAAIm3AACvtwAA 2bcAAP+3AAAzuAAAVrgAAH+4AACVuAAAxrgAAOe4AAAPuQAAQrkAAGm5AACRuQAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2QvE7wAAB2RuQAAu7kAAMu5AADXuQAABLoAACy6AAA5ugAAZLoAAH66AAB/ugAAxLoAAO+6 AADwugAA8boAAPK6AAAcuwAAWLsAAIi7AACJuwAA0LsAANG7AAAavAAAYbwAAG+8AABwvAAA cbwAAHK8AABzvAAAdLwAAHW8AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHXW8AAB2vAAAd7wAAHi8AAB5vAAA erwAAMO8AADFvAAADr0AAA+9AAAQvQAAOr0AAFm9AACEvQAAq70AAL69AAD+vQAAHb4AADi+ AABUvgAAa74AAIO+AACPvgAAvL4AAOS+AADxvgAAEr8AABO/AABSvwAAU78AAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk LxO8AAAdU78AAFS/AABVvwAAVr8AAFe/AABYvwAAWb8AAFq/AABbvwAAXL8AAF2/AABevwAA X78AAGC/AABhvwAAYr8AAGO/AABkvwAAZb8AAGa/AABnvwAAaL8AAGm/AABqvwAAa78AAGy/ AABtvwAAbr8AAG+/AABwvwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB1wvwAAcb8AAHK/AABzvwAAvL8AAL6/ AAAHwAAACMAAAAnAAAAswAAALcAAAHXAAAC8wAAABMEAAEfBAACPwQAA1cEAABzCAABlwgAA rsIAAPbCAAAxwwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZC8T vAAAFTHDAAAywwAAPMMAAKfEAACoxAAAqcQAAKrEAADUxAAA5cQAABDFAAA4xQAAS8UAAEzF AAC3AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAA sgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIA AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAAAAAAAA AEcPAEMkAUXGgAAAAQBxErcmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QvE7wAAAQPAGdkLxO8AABHDwBDJAFF xoAAAAEAcBK3JgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkLxO8AAAMTMUAAIfFAACIxQAAicUAAIrFAAC0xQAA zcUAAPfFAAAJxgAAKMYAAEzGAABmxgAAf8YAAJ3GAAC5xgAA2MYAAPTGAAAQxwAALccAAEDH AABbxwAAXMcAAJjHAACZxwAAmscAAJvHAACcxwAAnccAAJ7HAACfxwAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AB2fxwAA6McAAOrHAAAzyAAANMgAADXIAABuyAAAb8gAALjIAAD8yAAAP8kAAIjJAADPyQAA FsoAAF7KAACjygAA6MoAAC/LAAB3ywAApMsAAKXLAADtywAALswAAHPMAAC8zAAA6swAAOvM AAAVzQAAXs0AAKHNAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHaHNAADozQAAMc4AAELOAABDzgAARM4AAEXO AABvzgAAis4AALTOAADfzgAA9s4AADHPAABozwAAks8AAKXPAAC2zwAA3s8AAPvPAAD8zwAA PNAAAD3QAAA+0AAAP9AAAEDQAABB0AAAQtAAAEPQAACM0AAAjtAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd jtAAANfQAADY0AAA2dAAAAPRAAAm0QAAUNEAAGLRAACB0QAApdEAAL/RAADY0QAA9tEAABLS AAAx0gAATdIAAGnSAACG0gAAmdIAAKTSAADP0gAA9dIAAAHTAAAq0wAAT9MAAFDTAACN0wAA jtMAAI/TAACQ0wAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2Q0wAAkdMAAJLTAACT0wAAlNMAAJXTAACW0wAA l9MAAJjTAACZ0wAAmtMAAJvTAACc0wAAndMAAJ7TAACf0wAAoNMAAKHTAACi0wAAo9MAAKTT AACl0wAAptMAAKfTAACo0wAAqdMAAPLTAAD00wAAPdQAAD7UAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHT7U AAA/1AAAVtQAAFfUAACg1AAA59QAACnVAABr1QAAs9UAAPjVAAA+1gAAiNYAAMzWAADm1gAA 59YAAPfWAAD41gAANdcAAGbXAABn1wAAaNcAAIDXAACB1wAAw9cAAP/XAAAA2AAAAdgAAAvY AAAM2AAAUdgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdUdgAAHLYAABz2AAAuNgAAPzYAAA/2QAAftkAAKfZ AACo2QAA79kAAAfaAAAI2gAAT9oAAFDaAACZ2gAA3NoAAPfaAAD42gAAP9sAAIXbAACn2wAA qNsAAKnbAACq2wAA89sAAPXbAAA+3AAAP9wAAEDcAACI3AAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2I3AAA 0NwAABLdAABC3QAAQ90AAGHdAABi3QAAp90AAPDdAAAu3gAAaN4AAGneAACr3gAA9N4AADff AAB93wAAwt8AAArgAABS4AAAmOAAAOHgAADo4AAA6eAAADDhAAB54QAAwuEAANfhAADY4QAA FuIAAFviAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAAHVviAACj4gAA5+IAACrjAABv4wAAqeMAAKrjAADx4wAA MOQAADHkAAB35AAAqOQAAKnkAADy5AAAOeUAAIDlAADJ5QAA9OUAAPXlAAD25QAA9+UAAPjl AABB5gAAQ+YAAIzmAACN5gAAjuYAANPmAAAX5wAAXecAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdXecAAKDn AADp5wAALugAAGPoAABk6AAAqOgAALboAAC36AAA/ugAAP/oAAA+6QAAaekAAGrpAACs6QAA 8ekAAC/qAAAw6gAAeOoAAMDqAADz6gAA9OoAADrrAACA6wAAxOsAAALsAAA87AAAguwAAMfs AAAG7QAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2QvE7wAAB0G7QAATu0AAJftAADW7QAA1+0AAN3tAAC/7wAAwO8AAMHv AADC7wAAw+8AAMTvAADF7wAAxu8AAMfvAADI7wAAye8AAMrvAADL7wAAzO8AAM3vAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAALIAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABH DwBDJAFFxoAAAAEA9hK3JgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGdkLxO8AAAEDwBnZC8TvAAAFM3vAAAW8AAA GPAAAGHwAABi8AAAY/AAAI3wAACd8AAAx/AAAPLwAAAI8QAAJvEAAGbxAACp8QAA1PEAAOfx AAAj8gAAPPIAAFnyAACK8gAAu/IAAOzyAAAd8wAATvMAAG3zAACI8wAAn/MAAOLzAAAN9AAA IPQAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkLxO8AAAdIPQAADH0AABt9AAAsPQAANv0AADu9AAA//QAAC71AABA9QAA QfUAAIj1AAC29QAAt/UAALj1AAC59QAAuvUAALv1AAC89QAAvfUAAL71AAC/9QAAwPUAAMH1 AADC9QAAw/UAAMT1AADF9QAAxvUAAA/2AAAR9gAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB0R9gAAWvYAAFv2 AABc9gAAhvYAAJ72AADI9gAA8fYAAP/2AAAl9wAAT/cAAHX3AACp9wAAzPcAAPX3AAAL+AAA PPgAAGv4AACn+AAAwPgAAN34AAAO+QAAP/kAAHD5AACh+QAA0vkAAPD5AAAK+gAAIfoAADv6 AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZC8TvAAAHTv6AABi+gAAcvoAAH76AACr+gAA0/oAAOD6AAAL+wAAJfsAACb7 AABu+wAAoPsAAKH7AADJ+wAAyvsAABD8AABX/AAAnPwAAOT8AAAi/QAAaf0AALD9AAD4/QAA +f0AAPr9AAD7/QAARP4AAEb+AACP/gAAkP4AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdkP4AAJH+AACo/gAA qf4AAPL+AAA7/wAAev8AAIr/AACL/wAA1P8AAAMAAQAEAAEASAABAI0AAQDLAAEAEgEBAFUB AQBWAQEAhgEBAIcBAQDGAQEABwIBAE8CAQCVAgEA2AIBACEDAQBmAwEApgMBAOoDAQAwBAEA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2QvE7wAAB0wBAEAeAQBALwEAQDXBAEA2AQBABwFAQAnBQEAKAUBAEMFAQBEBQEA jAUBANUFAQD/BQEAAAYBAEkGAQB6BgEAewYBAHwGAQB9BgEAfgYBAH8GAQCABgEAgQYBAIIG AQDLBgEAzQYBABYHAQAXBwEAGAcBAD0HAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHT0HAQA+BwEAhwcBAMkH AQAPCAEAVggBAJ0IAQDmCAEALgkBAHcJAQC9CQEAAgoBADcKAQA4CgEARgoBAEcKAQCNCgEA 0QoBABgLAQBcCwEAjwsBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQPAGdkLxO8AAAUjwsBAJALAQAxDAEAMgwBAGUMAQBmDAEAdAwBAHUMAQC5DAEA5AwBAOUM AQDmDAEA8wwBAPQMAQA8DQEAgw0BAMwNAQACDgEAAw4BAAQOAQAVDgEAtwAAAAAAAAAAAAAA ALcAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACy AAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAA AAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAA AAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACyAAAAAAAA AAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AEcPAEMkAUXGgAAAAQAIE7cmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2QvE7wAABQVDgEAFg4BAF4OAQCYDgEA mQ4BAJoOAQC5DgEAug4BAAIPAQAaDwEAGw8BABwPAQAdDwEAZg8BAGgPAQCxDwEAsg8BALMP AQDGDwEAxw8BAA0QAQBQEAEAXhABAF8QAQBgEAEAbhABAG8QAQCyEAEA+xABAPwQAQD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZC8TvAAAHfwQAQD9EAEABREBAAYRAQBNEQEAjhEBAK8RAQCwEQEAsREBAL0RAQC+EQEA 9hEBAPcRAQD4EQEABxIBAAgSAQBQEgEAlRIBAK4SAQCvEgEAsBIBAMESAQDCEgEA+xIBAPwS AQD9EgEAFhMBABcTAQBeEwEAcxMBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdcxMBAHQTAQB1EwEAjRMBAI4T AQCPEwEAkBMBAJETAQCSEwEAkxMBAJQTAQDdEwEA3xMBACgUAQApFAEAKhQBAFQUAQCEFAEA pBQBAOEUAQDuFAEA7xQBACgVAQApFQEAORUBADoVAQCDFQEAyxUBABIWAQBZFgEA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2QvE7wAAB1ZFgEAWhYBAJsWAQCoFgEAqRYBALoWAQC7FgEABBcBAEcXAQCQFwEA1hcBABwY AQBkGAEAqhgBAPMYAQA7GQEARxkBAEgZAQBgGQEAYRkBAGIZAQCMGQEAvhkBAN0ZAQD8GQEA PBoBAD0aAQB4GgEAeRoBAHoaAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHXYaAQB3GgEA9sIBAPfCAQBZwwEA WsMBALDEAQCxxAEAcMUBAHHFAQCTxgEAlMYBACHHAQAixwEAqsgBAKvIAQBryQEAbMkBAI7K AQCPygEArMoBAK3KAQDbywEA3MsBAOPLAQDkywEA5swBAOfMAQA3zQEAOM0BAF7QAQBf0AEA ntABAJ/QAQAV0QEAFtEBAGjRAQBp0QEA3tEBAFbTAQBX0wEAc9MBAHTTAQDR1AEA0tQBAHnX AQB61wEAhNcBAIXXAQDv6N7a3tre2t7a3tre2t7a3tre2t7a3tre2t7a3tre2t7a3tre09re 2t7a3tre2ugAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBVoQg+yABZoygQrAAAGFmjKBCsAABMDagAAAAAW aMoEKwAwShAAVQgBDBVoQg+yABZoQg+yAAAfA2oAAAAAFmjKBCsAMEoQAE9KAABRSgAAVQgB XkoAAAAwehoBAHsaAQB8GgEAfRoBAH4aAQB/GgEAgBoBAIEaAQCCGgEAyxoBAM0aAQAWGwEA FxsBABgbAQAsGwEALRsBAHAbAQC3GwEAABwBAEkcAQCQHAEA0hwBAN8cAQDgHAEAKR0BAG4d AQCvHQEAwx0BAMQdAQDFHQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB3FHQEAxh0BAMcdAQDIHQEAyR0BAMod AQDLHQEAzB0BAM0dAQDOHQEAzx0BANAdAQDRHQEA0h0BANMdAQDUHQEA1R0BANYdAQDXHQEA 2B0BANkdAQDaHQEA2x0BANwdAQDdHQEA3h0BAN8dAQDgHQEA4R0BAOIdAQD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8T vAAAHeIdAQDjHQEA5B0BAOUdAQDmHQEA5x0BAOgdAQAxHgEAMx4BAHweAQB9HgEAfh4BAJMe AQCUHgEA2h4BABwfAQAdHwEAHh8BAB8fAQBjHwEAmh8BAJsfAQCcHwEAnx8BANgfAQDbHwEA GyABAGAgAQCDIAEAhiABAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdhiABAI4gAQCcIAEArSABAMggAQDfIAEA 9yABABAhAQAzIQEAUiEBAF0hAQBqIQEAayEBAG4hAQCEIQEAhyEBAI0hAQCdIQEAtyEBAOgh AQAEIgEAJyIBAFkiAQBjIgEAhSIBAMciAQDRIgEAGiMBACAjAQBfIwEA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AB1fIwEAeiMBAHsjAQB8IwEAfSMBAMYjAQDIIwEAESQBABIkAQATJAEAOCQBAGkkAQCFJAEA zSQBANMkAQDqJAEAMCUBADIlAQAzJQEANiUBAE4lAQBRJQEAVyUBAG8lAQCRJQEAzCUBANIl AQDrJQEAMyYBAFYmAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHVYmAQCDJgEArCYBALImAQDRJgEA+iYBACcn AQAtJwEALycBADAnAQAzJwEAZScBAGgnAQBuJwEApicBAKgnAQCpJwEArCcBANQnAQDXJwEA 3ScBABcoAQAZKAEAGigBAB0oAQA7KAEAPigBAEQoAQBcKAEAXSgBAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd XSgBAF4oAQBfKAEAqCgBAKooAQDzKAEA9CgBAPUoAQAKKQEAKikBAFEpAQBTKQEAVCkBAFcp AQBxKQEAdCkBAHopAQC/KQEAwSkBAMIpAQDFKQEA6SkBAOwpAQDyKQEADyoBADYqAQBnKgEA bSoBAKAqAQCiKgEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2iKgEAoyoBAKYqAQC2KgEA4SoBABIrAQAVKwEA GysBACQrAQA3KwEAZSsBAGsrAQBtKwEAbisBAHErAQCKKwEAjSsBAJMrAQCfKwEA5SsBAOcr AQDoKwEA6ysBAAEsAQAELAEACiwBACwsAQAtLAEALiwBAC8sAQD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHS8s AQB4LAEAeiwBAMMsAQDELAEAxSwBAMcsAQDILAEAyywBAPMsAQD2LAEA/CwBAAgtAQAeLQEA Oi0BAE4tAQB6LQEAhC0BAJMtAQDILQEA6y0BAAkuAQA1LgEAPy4BAFUuAQBkLgEAki4BAKAu AQDILgEA1i4BAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd1i4BANwuAQDeLgEA3y4BAOIuAQD/LgEAAi8BAAgv AQAfLwEAQC8BAGQvAQCKLwEAsi8BAMcvAQDNLwEAzy8BANAvAQDTLwEA+y8BAP4vAQAEMAEA FzABACgwAQA+MAEAWjABAFswAQBcMAEAXTABAKYwAQCoMAEA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2oMAEA 8TABAPIwAQDzMAEABTEBABYxAQAjMQEAQTEBAFcxAQBrMQEAgzEBAKkxAQC9MQEAyDEBAPUx AQAmMgEAKDIBACkyAQAsMgEAQjIBAEUyAQBLMgEATDIBAFEyAQBtMgEAcjIBAJkyAQDKMgEA ATMBAEQzAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAAHUQzAQBzMwEAoDMBAMUzAQAMNAEAQzQBAHY0AQCxNAEA 0TQBAPs0AQAxNQEAQjUBAEg1AQBKNQEASzUBAE41AQBhNQEAZDUBAGo1AQBrNQEAcDUBAI41 AQCTNQEAlDUBAJU1AQCWNQEA3zUBAOE1AQAqNgEAKzYBAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdKzYBACw2 AQA5NgEAUDYBAHw2AQCKNgEAmTYBAK42AQC0NgEAtjYBALc2AQC6NgEA2TYBANw2AQDiNgEA 7jYBABU3AQBANwEAbDcBAIA3AQC/NwEA7zcBAP83AQAZOAEANDgBADo4AQA8OAEAPTgBAEA4 AQB8OAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2QvE7wAAB18OAEAlzgBAJo4AQCgOAEAoTgBAKY4AQDaOAEA3zgBABY5 AQAXOQEAHDkBAFY5AQB9OQEAgjkBAJE5AQCvOQEAyzkBANk5AQDaOQEA3zkBAAw6AQANOgEA DjoBAA86AQBYOgEAWjoBAKM6AQCkOgEApToBANM6AQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHdM6AQDuOgEA 8zoBAA87AQAROwEAEjsBAEU7AQBGOwEARzsBAEg7AQBJOwEASjsBAEs7AQBMOwEATTsBAE47 AQBPOwEAUDsBAFE7AQBSOwEAUzsBAFQ7AQBVOwEAVjsBAFc7AQBYOwEAWTsBAFo7AQBbOwEA XDsBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkLxO8AAAdXDsBAF07AQBeOwEAXzsBAGA7AQBhOwEAYjsBAGM7AQBkOwEA ZTsBAGY7AQBnOwEAaDsBAGk7AQBqOwEAazsBAGw7AQBtOwEAbjsBAG87AQBwOwEAcTsBALo7 AQC8OwEABTwBAAY8AQAHPAEAMDwBADE8AQBtPAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB1tPAEAszwBAPo8 AQBAPQEAhz0BAM09AQDZPQEA2j0BABs+AQBjPgEAqD4BAPE+AQAaPwEAGz8BABw/AQAdPwEA Hj8BAB8/AQAgPwEAIT8BACI/AQAjPwEAJD8BACU/AQAmPwEAJz8BACg/AQApPwEAKj8BACs/ AQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZC8TvAAAHSs/AQAsPwEALT8BAC4/AQAvPwEAMD8BADE/AQAyPwEAMz8BADQ/ AQA1PwEANj8BADc/AQA4PwEAOT8BADo/AQA7PwEAPD8BAD0/AQA+PwEAhz8BAIk/AQDSPwEA 0z8BANQ/AQDtPwEA7j8BAAtAAQAMQAEAUUABAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdUUABAFlAAQBaQAEA fEABAH1AAQC/QAEAz0ABANBAAQAWQQEAH0EBACBBAQAlQQEAJkEBAExBAQBNQQEAd0EBAHhB AQB9QQEAfkEBAKVBAQCmQQEA0EEBANFBAQANQgEADkIBAFFCAQCWQgEAo0IBAKRCAQDKQgEA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2QvE7wAAB3KQgEAy0IBAMxCAQDsQgEA7UIBAO5CAQANQwEADkMBAA9DAQAwQwEA MUMBAGlDAQBqQwEAa0MBAGxDAQBtQwEAbkMBAG9DAQC4QwEAukMBAANEAQAERAEABUQBAENE AQCIRAEApUQBAKZEAQCnRAEA8EQBAAlFAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHQlFAQAKRQEAC0UBADVF AQA2RQEAN0UBADhFAQB+RQEAvUUBAL5FAQC/RQEACEYBABZGAQAXRgEAGEYBADNGAQA0RgEA TkYBAE9GAQBQRgEAcEYBAHFGAQByRgEAmkYBAJtGAQCcRgEA20YBAAtHAQAMRwEADUcBAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkLxO8AAAdDUcBAC1HAQAuRwEAL0cBADpHAQA7RwEAhEcBALZHAQC3RwEAuEcBALlH AQC6RwEAu0cBALxHAQC9RwEAvkcBAAdIAQAJSAEAUkgBAFNIAQBUSAEAakgBAGtIAQCKSAEA i0gBALRIAQC1SAEA20gBANxIAQAgSQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB0gSQEAR0kBAEhJAQCPSQEA t0kBALhJAQDuSQEA70kBAApKAQALSgEAEEoBABFKAQA0SgEANUoBAFtKAQBcSgEAoEoBAMdK AQDISgEA0EoBANFKAQDaSgEA80oBAC5LAQBpSwEAmEsBAKJLAQDHSwEA+0sBAB5MAQD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZC8TvAAAHR5MAQApTAEAM0wBAFRMAQB/TAEAskwBANNMAQALTQEAK00BADZNAQBBTQEA Qk0BAENNAQBETQEAjU0BAI9NAQDYTQEA2U0BANpNAQDhTQEA4k0BAAhOAQAJTgEAT04BAJdO AQDaTgEA204BAOtOAQDsTgEAC08BAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdC08BAAxPAQANTwEAF08BABhP AQA3TwEAOE8BAFBPAQBRTwEAcE8BAHFPAQByTwEAc08BAHRPAQB1TwEAdk8BAHdPAQB4TwEA eU8BAHpPAQB7TwEAfE8BAH1PAQB+TwEAf08BAIBPAQCBTwEAgk8BAINPAQCETwEA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2QvE7wAAB2ETwEAhU8BAIZPAQCHTwEAiE8BAIlPAQCKTwEAi08BAIxPAQCNTwEAjk8BAI9P AQDYTwEA2k8BACNQAQAkUAEAJVABAEJQAQBDUAEAiFABAM5QAQATUQEAWlEBAKNRAQDrUQEA MFIBAFtSAQBcUgEApVIBANpSAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHdpSAQDbUgEAHlMBAF1TAQCeUwEA 5FMBAAZUAQAHVAEAT1QBAGRUAQBlVAEAZlQBAGdUAQBoVAEAaVQBAGpUAQBrVAEAbFQBAG1U AQBuVAEAb1QBAHBUAQBxVAEAclQBAHNUAQB0VAEAdVQBAHZUAQB3VAEAeFQBAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk LxO8AAAdeFQBAHlUAQB6VAEAe1QBAHxUAQB9VAEAflQBAH9UAQCAVAEAgVQBAMpUAQDMVAEA FVUBABZVAQAXVQEALFUBAC1VAQBzVQEArlUBAK9VAQDXVQEA2FUBAARWAQAFVgEAMVYBADJW AQBeVgEAX1YBAItWAQCMVgEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2MVgEAtlYBALdWAQDlVgEA5lYBACdX AQA3VwEAOFcBAGhXAQBpVwEAkVcBAJJXAQC9VwEAvlcBAOpXAQDrVwEAMlgBAHJYAQBzWAEA tFgBAMVYAQDGWAEA91gBAPhYAQAZWQEAGlkBADxZAQA9WQEAeFkBAHlZAQD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8T vAAAHXlZAQC/WQEA+FkBAPlZAQD6WQEA+1kBAPxZAQD9WQEARloBAEhaAQCRWgEAkloBAJNa AQDGWgEAx1oBAANbAQAEWwEAL1sBADBbAQB0WwEAdVsBAK1bAQCuWwEA8lsBADRcAQB3XAEA slwBALNcAQD3XAEAPF0BAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdPF0BAGZdAQBnXQEAo10BAKRdAQDrXQEA 9l0BAPddAQAcXgEAHV4BADxeAQA9XgEAhF4BAMxeAQADXwEABF8BAAVfAQAGXwEAB18BAAhf AQAJXwEACl8BAAtfAQAMXwEADV8BAA5fAQAPXwEAEF8BABFfAQASXwEA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AB0SXwEAE18BABRfAQAVXwEAFl8BABdfAQBgXwEAYl8BAKtfAQCsXwEArV8BAL5fAQC/XwEA A2ABAARgAQAFYAEABmABAAdgAQAIYAEACWABAApgAQALYAEADGABAA1gAQAOYAEAD2ABABBg AQARYAEAEmABABNgAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHRNgAQAUYAEAFWABABZgAQAXYAEAGGABABlg AQAaYAEAG2ABABxgAQAdYAEAHmABAB9gAQAgYAEAIWABACJgAQAjYAEAJGABACVgAQAmYAEA J2ABAChgAQApYAEAKmABACtgAQAsYAEALWABAC5gAQAvYAEAMGABAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd MGABADFgAQAyYAEAM2ABAHxgAQB+YAEAx2ABAMhgAQDJYAEA2WABANpgAQD2YAEA92ABAEBh AQBwYQEAcWEBALhhAQD0YQEAC2IBAAxiAQBVYgEAnWIBAMZiAQDHYgEAA2MBAARjAQBKYwEA a2MBAGxjAQCtYwEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2tYwEA2GMBANljAQAbZAEAX2QBAGBkAQCoZAEA 8WQBAPJkAQA7ZQEAgmUBAKVlAQCmZQEA7GUBADFmAQB0ZgEAdWYBALxmAQAFZwEANWcBADZn AQB9ZwEAxWcBAA5oAQAPaAEAEGgBABFoAQASaAEAE2gBABRoAQD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHRRo AQAVaAEAXmgBAGBoAQCpaAEAqmgBAKtoAQDJaAEAymgBABBpAQBXaQEAk2kBAJRpAQDWaQEA G2oBADJqAQAzagEAfGoBAJRqAQCVagEA22oBACRrAQBNawEATmsBAJRrAQDNawEAC2wBACBs AQAhbAEAZWwBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdZWwBAKRsAQDHbAEAyGwBAANtAQBHbQEAjW0BAI5t AQCPbQEAkG0BAJFtAQCSbQEAk20BAJRtAQCVbQEAlm0BAJdtAQCYbQEAmW0BAJptAQCbbQEA nG0BAJ1tAQCebQEAn20BAKBtAQChbQEAom0BAKNtAQDsbQEA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB3sbQEA 7m0BADduAQA4bgEAOW4BAHJuAQBzbgEAdG4BAJ5uAQDMbgEA+24BADxvAQB9bwEAiG8BAJ1v AQDWbwEAFnABAFtwAQB+cAEAlHABAKBwAQC+cAEA3XABAAZxAQArcQEAUXEBAHhxAQCpcQEA 1nEBAO9xAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAAHe9xAQAKcgEAF3IBACNyAQAscgEAQXIBAFdyAQBxcgEA cnIBAJVyAQC7cgEA0nIBAPlyAQArcwEAQ3MBAFtzAQCKcwEAoHMBANFzAQD4cwEALnQBAEh0 AQBfdAEAdXQBAHZ0AQB3dAEAeHQBAMF0AQDDdAEADHUBAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdDHUBAA11 AQAOdQEAPnUBAFZ1AQCAdQEApnUBAL91AQD5dQEAE3YBACp2AQBAdgEAanYBAJF2AQDJdgEA 43YBAPp2AQAOdwEAH3cBACB3AQBEdwEAa3cBAJp3AQCudwEAv3cBAMB3AQDudwEAH3gBADd4 AQBeeAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2QvE7wAAB1eeAEAkHgBAKh4AQDBeAEA8HgBAAZ5AQAweQEAV3kBAIx5 AQCmeQEAvXkBANF5AQDieQEA43kBAA16AQA6egEAZ3oBAJB6AQCkegEAtXoBALZ6AQDCegEA w3oBAMR6AQDFegEADnsBABB7AQBZewEAWnsBAFt7AQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHVt7AQBmewEA f3sBAJd7AQCxewEAsnsBALN7AQDeewEADHwBACN8AQBHfAEAX3wBAHV8AQCkfAEAu3wBAOt8 AQD/fAEAEH0BABF9AQASfQEAPn0BAG19AQCTfQEAw30BANd9AQDofQEA6X0BAOp9AQAgfgEA WX4BAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAAAAAAAAQPAGdkLxO8AAAdWX4BAH9+AQCvfgEAw34BANR+AQDVfgEAB38BADx/AQBlfwEA lX8BAKl/AQC6fwEAu38BAMd/AQDIfwEA038BAOx/AQAegAEAOIABADmAAQA6gAEAO4ABADyA AQCFgAEAh4ABANCAAQDRgAEA0oABAP6AAQAegQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB0egQEAMoEBAFGB AQBmgQEAjYEBAJ6BAQCqgQEAq4EBALaBAQDPgQEA94EBABGCAQASggEAP4IBAFWCAQB4ggEA j4IBAKyCAQDRggEA+IIBAAmDAQAVgwEAFoMBACGDAQA6gwEAWIMBAHKDAQBzgwEAnoMBALOD AQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA AAAAAAAEDwBnZC8TvAAAHbODAQDbgwEA8YMBABCEAQAxhAEAR4QBAFuEAQCBhAEApoQBAL6E AQDShAEA44QBAO+EAQDwhAEA+4QBABSFAQAuhQEASIUBAEmFAQBKhQEAS4UBAJSFAQCWhQEA 34UBAOCFAQDhhQEACIYBAB2GAQBJhgEAeYYBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdeYYBAI+GAQClhgEA toYBAMKGAQDDhgEAzoYBAOeGAQALhwEAJYcBACaHAQBWhwEAV4cBAIqHAQCrhwEA2IcBAAGI AQAViAEAJogBACeIAQBRiAEAcYgBAJKIAQCoiAEAuYgBALqIAQDGiAEAx4gBANKIAQDriAEA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA AAAABA8AZ2QvE7wAAB3riAEA+4gBACaJAQBXiQEAcYkBAHKJAQCOiQEArYkBAMSJAQDmiQEA C4oBADiKAQBQigEAaIoBAHyKAQCNigEAjooBAI+KAQCQigEA2YoBANuKAQAkiwEAJYsBACaL AQAyiwEAM4sBAD6LAQBXiwEAb4sBAKaLAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHaaLAQDAiwEAwYsBAOWL AQAMjAEALYwBAFCMAQBojAEAfIwBAI2MAQCZjAEAmowBAKWMAQC+jAEA14wBAPGMAQDyjAEA EY0BADWNAQBJjQEAbo0BAJONAQC9jQEA0o0BAOiNAQD5jQEABY4BAAaOAQARjgEAKo4BAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA AAQPAGdkLxO8AAAdKo4BAECOAQBajgEAW44BAHyOAQCMjgEApI4BAMaOAQDfjgEA8I4BAAGP AQANjwEADo8BABmPAQAajwEAG48BAByPAQBljwEAZ48BALCPAQCxjwEAso8BAMuPAQDzjwEA DZABAA6QAQAtkAEAT5ABAGeQAQCRkAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2RkAEAtpABAOGQAQAKkQEA JpEBAD6RAQBXkQEAeZEBAI+RAQClkQEA0pEBAAiSAQAfkgEANpIBAE6SAQBwkgEAlZIBAK2S AQDGkgEA3JIBAAiTAQAskwEAZJMBAHuTAQCTkwEAqpMBANKTAQDzkwEAHZQBAEKUAQD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAE DwBnZC8TvAAAHUKUAQBalAEAe5QBAKKUAQDFlAEA3ZQBAP6UAQASlQEAI5UBACSVAQAwlQEA MZUBADKVAQAzlQEANJUBAH2VAQB/lQEAyJUBAMmVAQDKlQEA1ZUBAO6VAQALlgEAJZYBACaW AQBQlgEAfZYBAJOWAQC3lgEA35YBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd35YBAPeWAQAOlwEAJJcBAEqX AQBylwEAipcBAKGXAQC3lwEA35cBAAeYAQAfmAEANpgBAF6YAQBymAEAg5gBAI+YAQCQmAEA m5gBALSYAQDcmAEA9pgBAPeYAQAdmQEAM5kBAEmZAQBwmQEAh5kBAJ2ZAQDHmQEA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8A Z2QvE7wAAB3HmQEA3pkBAPSZAQAkmgEAO5oBAFGaAQB3mgEAjpoBAKSaAQDJmgEAypoBAMua AQDMmgEAFZsBABebAQBgmwEAYZsBAGKbAQB5mwEAj5sBALCbAQDHmwEA3ZsBAA+cAQAmnAEA PJwBAGacAQB9nAEAk5wBALucAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHbucAQDSnAEA6JwBABSdAQArnQEA QZ0BAHmdAQCQnQEAp50BAM6dAQDtnQEA/p0BAP+dAQAdngEAPp4BAGeeAQB7ngEAjJ4BAI2e AQCtngEA0J4BAPmeAQANnwEAHp8BAB+fAQArnwEALJ8BADefAQBQnwEAZp8BAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdk LxO8AAAdZp8BAICfAQCBnwEAo58BAL6fAQDYnwEA9J8BABOgAQAUoAEAFaABABagAQBfoAEA YaABAKqgAQCroAEArKABANOgAQDkoAEA5aABAAehAQAsoQEAUKEBAGShAQB1oQEAdqEBAJuh AQDDoQEA56EBAPuhAQAMogEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB0MogEADaIBADiiAQBmogEAiqIBAJ6i AQCvogEAsKIBANGiAQD1ogEAGaMBAC2jAQA+owEAP6MBAF+jAQCCowEApqMBALqjAQDLowEA zKMBAOijAQAHpAEALKQBAECkAQBRpAEAUqQBAH+kAQCvpAEA06QBAOekAQD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8T vAAAHeekAQD4pAEA+aQBAB6lAQBGpQEAaqUBAGulAQBspQEAbaUBALalAQC4pQEAAaYBAAKm AQADpgEAF6YBACimAQAppgEATKYBAHKmAQCWpgEAqqYBALumAQC8pgEA46YBAA2nAQAxpwEA RacBAFanAQBXpwEAiqcBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdiqcBAMCnAQDypwEAGKgBADCoAQBUqAEA aKgBAHmoAQB6qAEAhqgBAIeoAQCSqAEAq6gBAL6oAQDYqAEA2agBAPmoAQAUqQEAMKkBAEyp AQBvqQEAlKkBAMCpAQDYqQEA+akBABuqAQBEqgEAWKoBAGmqAQBqqgEA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wA AB1qqgEAdqoBAHeqAQCCqgEAg6oBAISqAQCFqgEAzqoBANCqAQAZqwEAGqsBABurAQA0qwEA U6sBAG2rAQBuqwEAjasBAKGrAQC0qwEA3KsBAAGsAQAbrAEARKwBAGusAQCFrAEAmawBAK6s AQC/rAEAwKwBAN+sAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHd+sAQDzrAEAF60BADqtAQBQrQEAZa0BAHat AQB3rQEAnq0BALytAQAFrgEAFq4BACeuAQAorgEARq4BAGmuAQCTrgEAqa4BALquAQC7rgEA 364BAAWvAQAXrwEAMa8BAFevAQByrwEAha8BAJmvAQCqrwEAq68BAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAd q68BALevAQC4rwEAua8BALqvAQADsAEABbABAE6wAQBPsAEAULABAFuwAQB0sAEAsLABAMuw AQDlsAEA5rABAAWxAQAgsQEAUrEBAG6xAQCBsQEAlrEBAKyxAQDnsQEAALIBABeyAQAtsgEA UbIBAGWyAQB2sgEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB12sgEAd7IBAHiyAQCasgEAtbIBAO2yAQASswEA LrMBAESzAQBYswEAb7MBAImzAQCxswEAybMBAOKzAQD8swEAFrQBACu0AQBAtAEAV7QBAGi0 AQBptAEAj7QBAKq0AQDVtAEAAbUBABq1AQA2tQEATLUBAE21AQD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHU21 AQBOtQEAT7UBAJi1AQCatQEA47UBAOS1AQDltQEAB7YBAB62AQAvtgEAMLYBADy2AQA9tgEA S7YBAEy2AQB3tgEAeLYBAHm2AQB6tgEAe7YBAHy2AQB9tgEAfrYBAH+2AQCAtgEAgbYBAIK2 AQCDtgEAhLYBAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdhLYBAIW2AQCGtgEAh7YBAIi2AQCJtgEAirYBAIu2 AQCMtgEAjbYBAI62AQCPtgEAkLYBAJG2AQCStgEAk7YBAJS2AQCVtgEAlrYBAJe2AQCYtgEA mbYBAJq2AQCbtgEAnLYBAJ22AQCetgEAn7YBAKC2AQChtgEA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAABA8AZ2QvE7wAAB2htgEA 6rYBAOy2AQA1twEANrcBADe3AQBKtwEAS7cBAFm3AQBrtwEAbLcBAIq3AQCLtwEAjLcBAJ23 AQCqtwEAy7cBAOC3AQDmtwEA57cBAAG4AQAXuAEAGLgBABm4AQAwuAEAR7gBAGm4AQCKuAEA obgBAKe4AQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAAAAAAAEDwBnZC8TvAAAHae4AQCouAEAwrgBAOa4AQALuQEADLkBAA25AQAiuQEA Q7kBAFe5AQBxuQEAfLkBAH25AQCYuQEAwLkBAOS5AQDluQEA5rkBAOe5AQDouQEA6bkBAOq5 AQDruQEA7LkBAO25AQDuuQEA77kBAPC5AQA5ugEAO7oBAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkLxO8AAAdO7oBAIS6 AQCFugEAhroBAJ+6AQCgugEAyLoBAMm6AQAOuwEAU7sBAG+7AQBwuwEAubsBAAK8AQBLvAEA k7wBANy8AQAivQEAaL0BAGm9AQBqvQEAgL0BAIG9AQDGvQEAD74BAFa+AQCcvgEA4r4BACu/ AQBvvwEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAAAAAAABA8AZ2QvE7wAAB1vvwEAjr8BAI+/AQDRvwEAFcABAF7AAQCawAEA48ABAP/A AQAAwQEAR8EBAIvBAQDRwQEAEsIBACjCAQApwgEAKsIBADnCAQA6wgEAecIBAKTCAQClwgEA psIBAKfCAQCowgEAqcIBAPLCAQD0wgEA9cIBAPbCAQD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZC8TvAAAHfbCAQBZwwEA 7sMBAO/DAQCwxAEALsUBAHDFAQCqxQEAq8UBAJPGAQAhxwEAgccBAGfIAQBoyAEAqsgBAGvJ AQCpyQEAqskBAATKAQAFygEAjsoBAKzKAQDFygEAxsoBAErLAQBLywEA28sBAOPLAQAyzAEA M8wBAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAERAAAdM8wBAObMAQA3zQEA/M0BAP3NAQDlzgEA5s4BAJPPAQCUzwEA AdABAALQAQBc0AEAXdABAF7QAQCe0AEAFdEBAGjRAQCD0QEAq9EBAN7RAQDf0QEA4NEBAALS AQBB0gEAQtIBALzSAQC90gEAVtMBAHPTAQD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEDwBnZPQHEAAAAREAABxz0wEA2tMBANvT AQCD1AEAhNQBANHUAQAX1QEAGNUBAGvVAQBs1QEAdNUBAHzVAQCE1QEAjtUBAI/VAQAe1gEA H9YBAL3WAQC+1gEAedcBAIPXAQCE1wEAhdcBAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABA8A Z2QvE7wAAAEAAAABEQAAFjIAMZBoATpwLxO8AB+wgi4gsMZBIbCABCKwgAQjkKAFJJCgBSWw AAAXsMQCGLDEAgyQxAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIYCFAASAAEAnAAPAAQAAAAAAAAA AAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAEDx/wIAQAAMBAAAAAAAAAAA BgBOAG8AcgBtAGEAbAAAAAIAAAAYAENKGABfSAEEYUoYAG1ICQxzSAkMdEgJDAAAAAAAAAAA AAAAAAAAAAAAAEQAQUDy/6EARAAMBQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIA YQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABSAGlA8/+zAFIADAUAAAAAAAAAAAwAVABhAGIA bABlACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsA AAAoAGtA9P/BACgAAAUAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIAAAAAAAAARABaQAEA 8gBEAAwEAACTdysAAAAKAFAAbABhAGkAbgAgAFQAZQB4AHQAAAACAA8AFABDShQAT0oDAFFK AwBeSgMAYUoUAEIAJ0CiAAEBQgAMBQAALxO8AAAAEQBDAG8AbQBtAGUAbgB0ACAAUgBlAGYA ZQByAGUAbgBjAGUAAAAIAENKEABhShAAPAAeQAEAEgE8AAwFAAAvE7wAAAAMAEMAbwBtAG0A ZQBuAHQAIABUAGUAeAB0AAAAAgARAAgAQ0oUAGFKFABAAGpAEQESAUAADAUAAC8TvAAAAA8A QwBvAG0AbQBlAG4AdAAgAFMAdQBiAGoAZQBjAHQAAAACABIABgA1CIFcCIFIAJlAAQAyAUgA DAUAAC8TvAAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABMAFABDShAAT0oEAFFK BABeSgQAYUoQAAkAagBhAHcAaQBuAHQAZQByAGIAZSAAAI1BAAAoUAAAr1QAAAVWAAAZXgAA oWEAAN1rAAASbwAA8nEAAKCQAAAFogAA3aQAAGSmAACCpwAAv6cAAFOqAABjqwAAUrYAAPHd AAAk/QAAdhIBAIXPAQADAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAOZSMgoDAEEASgBXAAAA AAAAAAAAAAAAAAAAAAAAANRZMgoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAO5bMgoDAEEA SgBXAAAAAAAAAAAAAAAAAAAAAAAAAONcMgoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAAFf MgoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAACNgMgoDAEEASgBXAAAAAAAAAAAAAAAAAAAA AAAAAAdhMgoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAHxiMgoDAEEASgBXAAAAAAAAAAAA AAAAAAAAAAAAACw8MwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAACs9MwoDAEEASgBXAAAA AAAAAAAAAAAAAAAAAAAAACc+MwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAJ9AMwoDAEEA SgBXAAAAAAAAAAAAAAAAAAAAAAAAAONBMwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAACRC MwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAHBBMwoDAEEASgBXAAAAAAAAAAAAAAAAAAAA AAAAAP5AMwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAHtFMwoDAEEASgBXAAAAAAAAAAAA AAAAAAAAAAAAAJpGMwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAAG9HMwoDAEEASgBXAAAA AAAAAAAAAAAAAAAAAAAAAA1lMwoDAEEASgBXAAAAAAAAAAAAAAAAAAAAAAAAANtnMwoDAEEA SgBXAAAAAAAAAAAAAAAAAAAAAAAAAM5pMwoVDLcGAAAAAAAAAAAAAAAAAAA0DLcGAAAAAAAA AAAAAAAAAABBDLcGAAAAAAAAAAAAAAAAAABEDLcGAAAAAAAAAAAAAAAAAABODLcGAAAAAAAA AAAAAAAAAABTDLcGAAAAAAAAAAAAAAAAAABWDLcGAAAAAAAAAAAAAAAAAABgDLcGAAAAAAAA AAAAAAAAAAA4ErcmAAAAAAAAAAAAAAAAAABBErcmAAAAAAAAAAAAAAAAAABFErcmAAAAAAAA AAAAAAAAAABUErcmAAAAAAAAAAAAAAAAAABUErcmAAAAAAAAAAAAAAAAAABbErcmAAAAAAAA AAAAAAAAAABTErcmAAAAAAAAAAAAAAAAAABRErcmAAAAAAAAAAAAAAAAAABkErcmAAAAAAAA AAAAAAAAAABrErcmAAAAAAAAAAAAAAAAAABsErcmAAAAAAAAAAAAAAAAAAD2ErcmAAAAAAAA AAAAAAAAAAAGE7cmAAAAAAAAAAAAAAAAAAAKE7cmAAAAAAAAAAAAAAAAAAAAAAAAYwAAALoB AAB6AgAAnQMAACsEAAC0BQAAdQYAAJgHAAC2BwAA5QgAAO0IAADwCQAAQQoAAGgNAACoDQAA Hw4AAHIOAABgEAAAfRAAANsRAACDFAAAjRQAAJAUAAAAAAAAhc8BAAgAAAgDAAYA/////wAA AAABAAAAAgAAAAMAAABMAAAAlQAAAN4AAAAnAQAAcAEAALkBAAACAgAASwIAAJQCAACVAgAA lgIAANMCAAAGAwAABwMAABsDAAAcAwAAYgMAAKcDAADtAwAAMQQAADIEAAB3BAAAuwQAAP4E AAAJBQAACgUAAFMFAACbBQAA3QUAABsGAAAcBgAAVgYAAIUGAACGBgAAygYAAO4GAADvBgAA KAcAACkHAAA6BwAAOwcAAGMHAABkBwAAZQcAAGYHAABnBwAAaAcAAGkHAABqBwAAawcAAGwH AAC1BwAAtwcAAAAIAAABCAAAAggAAAsIAAAMCAAAUQgAAJYIAADXCAAADAkAAA0JAAAOCQAA IAkAACEJAABqCQAAswkAAPwJAABFCgAAjgoAAMwKAAAVCwAAXgsAAKcLAADwCwAAMgwAAHsM AACrDAAA9AwAAD0NAACGDQAAzw0AAAkOAABSDgAAmw4AAOQOAAAtDwAAdg8AAL8PAAAIEAAA URAAAJoQAADjEAAALBEAAHURAACjEQAA7BEAADUSAABjEgAArBIAAPUSAAA+EwAAhxMAAIgT AACJEwAAihMAANMTAADVEwAAHhQAAB8UAAAgFAAAaRQAALIUAAD7FAAARBUAAI0VAADWFQAA HxYAAGgWAACxFgAA+hYAAEMXAACMFwAA1RcAAB4YAABnGAAAsBgAAPkYAABCGQAAixkAANQZ AAAdGgAAZhoAAK8aAAD4GgAAQRsAAIobAADTGwAA1BsAANUbAADWGwAA1xsAANgbAADZGwAA 2hsAANsbAADcGwAA3RsAAN4bAADfGwAA4BsAAOEbAADiGwAA4xsAAOQbAADlGwAA5hsAAOcb AADoGwAA6RsAAOobAADrGwAANBwAADYcAAB/HAAAgBwAAIEcAACSHAAAkxwAANgcAAAgHQAA aB0AALAdAAD4HQAAOx4AAIIeAADGHgAADh8AAFEfAACUHwAAlR8AANwfAAAjIAAAayAAALEg AADyIAAAOyEAAIEhAADIIQAAByIAAAgiAABNIgAAjyIAANQiAAAZIwAAWyMAAJwjAADiIwAA KSQAAGgkAACsJAAAxCQAAMUkAAAOJQAAViUAAJ4lAADdJQAA3iUAACQmAABsJgAAqCYAAKkm AADxJgAANScAAHcnAAB4JwAAeScAAHonAADDJwAAxScAAA4oAAAPKAAAECgAAFQoAABdKAAA XigAAJ4oAADkKAAAJSkAAGkpAACpKQAA8SkAADgqAACAKgAAxyoAAAwrAABTKwAAmysAANEr AADSKwAA0ysAANQrAADVKwAA1isAANcrAADYKwAA2SsAANorAADbKwAA3CsAAN0rAADeKwAA 3ysAAOArAADhKwAA4isAAOMrAADkKwAA5SsAAOYrAADnKwAA6CsAAOkrAADqKwAA6ysAAOwr AADtKwAA7isAAO8rAADwKwAA8SsAAPIrAADzKwAA9CsAAD0sAAA/LAAAiCwAAIksAACKLAAA tCwAALUsAAD8LAAARC0AAHstAAB8LQAApy0AAKgtAADuLQAANy4AAIAuAADJLgAAEi8AAEUv AABGLwAARy8AAIwvAADALwAAwS8AAMIvAAAKMAAASTAAAI0wAACOMAAAjzAAANYwAAAcMQAA RjEAAEcxAABIMQAAkTEAANoxAAAhMgAARDIAAEUyAABGMgAAVTIAAFYyAACeMgAAyDIAAMky AAALMwAADDMAAA0zAAAOMwAADzMAABAzAAARMwAAEjMAABMzAAAUMwAAXTMAAF8zAACoMwAA qTMAAKozAADJMwAAyjMAAAo0AAAYNAAAGTQAAEQ0AABFNAAAjjQAANc0AAAdNQAAYjUAAJ81 AACgNQAAoTUAANo1AADbNQAAIDYAAE42AABPNgAAUDYAAH02AAB+NgAAxTYAAAg3AAAJNwAA CjcAAEs3AABMNwAAkzcAANw3AAD5NwAA+jcAAD04AABfOAAAYDgAAKU4AACmOAAA4zgAACw5 AAAtOQAAczkAAI45AACPOQAAwzkAAMQ5AAALOgAASjoAAF46AABfOgAAYDoAAGE6AACqOgAA rDoAAPU6AAD2OgAA9zoAADs7AAB/OwAAxzsAAAc8AABMPAAAfDwAAH08AAB+PAAAfzwAAIA8 AACBPAAAgjwAAIM8AACEPAAAhTwAAIY8AACHPAAAiDwAAIk8AACKPAAAizwAAIw8AACNPAAA jjwAAI88AACQPAAAkTwAAJI8AACTPAAAlDwAAJU8AACWPAAAlzwAAJg8AACZPAAAmjwAAJs8 AACcPAAAnTwAAJ48AACfPAAAoDwAAKE8AACiPAAAozwAAKQ8AAClPAAApjwAAKc8AACoPAAA qTwAAPI8AAD0PAAAPT0AAD49AAA/PQAAZT0AAGY9AACtPQAA4z0AAAA+AAABPgAASj4AAJE+ AADYPgAAIT8AAEQ/AABFPwAAhj8AAM8/AAAUQAAAIkAAACNAAAAkQAAAOEAAADlAAABnQAAA pEAAAKVAAADSQAAAB0EAAAhBAABPQQAAjUEAAI9BAACQQQAAkUEAAJJBAACTQQAAn0EAAB9D AAAgQwAArUMAAK5DAACvQwAAsEMAALFDAACyQwAAs0MAALRDAAC1QwAAtkMAALdDAAC4QwAA uUMAALpDAAC7QwAAvEMAAL1DAAC+QwAAB0QAAAlEAABSRAAAU0QAAFREAABuRAAAb0QAALdE AAD+RAAALkUAAC9FAAB2RQAAh0UAAIhFAADJRQAAEEYAAFhGAACeRgAA5EYAAC1HAABHRwAA SEcAAIxHAADTRwAA1EcAAB1IAABhSAAAqEgAAO1IAAD4SAAA+UgAAD5JAACESQAAykkAAAZK AABHSgAASEoAAHlKAAB6SgAAvUoAAP5KAABASwAAhksAAM1LAADZSwAA2ksAACFMAABqTAAA sEwAAPZMAAD3TAAAPk0AAIFNAACCTQAAg00AAIRNAADNTQAAz00AABhOAAAZTgAAGk4AAGNO AACrTgAA8E4AADhPAACATwAAwU8AAAlQAAArUAAALFAAAGhQAABpUAAArFAAAPJQAAA6UQAA VFEAAFVRAACGUQAAh1EAANBRAAAWUgAAVFIAAFVSAACbUgAA4FIAACdTAABSUwAAU1MAAJxT AADjUwAAIlQAAGhUAACxVAAA8VQAADhVAACBVQAAwFUAAMFVAAAHVgAACFYAAFFWAACVVgAA 1VYAABxXAABkVwAArFcAAPNXAAA8WAAAg1gAAIRYAACFWAAAhlgAAM9YAADRWAAAGlkAABtZ AAAcWQAAZVkAAK1ZAADzWQAAPFoAAIFaAACCWgAAvloAAAJbAAAOWwAAD1sAAFZbAACdWwAA 4lsAAClcAABxXAAAs1wAANJcAADTXAAAGV0AACddAAAoXQAAcV0AALddAAD+XQAAR14AAI5e AADNXgAAE18AAE9fAAB6XwAAe18AAMJfAAAKYAAAUGAAAIhgAAC/YAAAwGAAAAZhAABNYQAA lWEAAN9hAAAlYgAAa2IAALNiAAD4YgAAO2MAAIRjAAC4YwAAuWMAALpjAAC7YwAABGQAAAZk AABPZAAAUGQAAFFkAACIZAAAiWQAAMtkAAARZQAAVWUAAGFlAABiZQAAiGUAAIllAADRZQAA FWYAAFtmAACeZgAA5mYAAPFmAADyZgAA82YAAPRmAAD1ZgAA9mYAAPdmAAD4ZgAA+WYAAPpm AAD7ZgAA/GYAAP1mAAD+ZgAA/2YAAABnAAABZwAAAmcAAANnAAAEZwAABWcAAAZnAAAHZwAA CGcAAAlnAAAKZwAAC2cAAAxnAAANZwAADmcAAA9nAAAQZwAAEWcAABJnAAATZwAAFGcAABVn AABeZwAAYGcAAKlnAACqZwAAq2cAANVnAADWZwAAHmgAAGFoAACmaAAA62gAADBpAAB2aQAA vmkAAAJqAABLagAAV2oAAFhqAAChagAA6moAAC9rAAB0awAAdWsAAL1rAADgawAA4WsAACds AABwbAAAomwAAMJsAADDbAAAxGwAAMVsAADGbAAAx2wAAMhsAADJbAAAymwAAMtsAADMbAAA zWwAAM5sAADPbAAA0GwAANFsAADSbAAA02wAANRsAADVbAAA1mwAANdsAADYbAAA2WwAANps AADbbAAA3GwAACVtAAAnbQAAcG0AAHFtAABybQAAuG0AALltAAABbgAASG4AAJBuAADWbgAA Gm8AAFtvAACjbwAA328AAPZvAAD3bwAA+G8AAPlvAAD6bwAA+28AAPxvAAD9bwAA/m8AAP9v AAAAcAAAAXAAAAJwAAADcAAABHAAAAVwAAAGcAAAB3AAAAhwAAAJcAAACnAAAAtwAAAMcAAA DXAAAA5wAAAPcAAAEHAAABFwAAAScAAAE3AAABRwAAAVcAAAFnAAABdwAAAYcAAAGXAAABpw AAAbcAAAHHAAAB1wAAAecAAAZ3AAAGlwAACycAAAs3AAALRwAADucAAA73AAAP5wAAD/cAAA O3EAAH1xAADFcQAA43EAAORxAAD0cQAA9XEAACByAAAhcgAAaXIAAK1yAADKcgAAy3IAAMxy AAD2cgAABnMAADBzAABbcwAAeHMAAI9zAACQcwAAzHMAAA90AAA6dAAATXQAAF50AACNdAAA jnQAAKB0AAChdAAA23QAANx0AAAhdQAAZHUAAKd1AADqdQAAMXYAAHl2AADCdgAACncAAFB3 AACZdwAA1XcAANZ3AADXdwAA2HcAANl3AAAieAAAJHgAAG14AABueAAAb3gAAJl4AADWeAAA AnkAABB5AAA2eQAAYHkAAIZ5AAC6eQAA3XkAAAZ6AAAcegAATXoAAHx6AAC4egAA0XoAAO56 AAAfewAAUHsAAIF7AACyewAA43sAAAF8AAAbfAAAMnwAAEx8AABzfAAAm3wAAMV8AADVfAAA 4XwAAA59AAA2fQAAQ30AAG59AACIfQAAiX0AAMh9AADJfQAA730AAPB9AAA4fgAAen4AALx+ AAAFfwAASn8AAF9/AABgfwAAYX8AAGJ/AABjfwAAZH8AAK1/AACvfwAA+H8AAPl/AAD6fwAA JIAAAFmAAACIgAAAv4AAANSAAAAWgQAAOoEAAFSBAABtgQAAjoEAAKSBAAC8gQAA04EAAOSB AAATggAAJYIAACaCAABjggAAZIIAAKmCAADsggAAL4MAAHSDAAC7gwAAAYQAAEKEAACHhAAA zIQAAA6FAABXhQAAloUAAJeFAACYhQAAmYUAAJqFAACbhQAAnIUAAJ2FAACehQAAn4UAAKCF AAChhQAAooUAAKOFAACkhQAApYUAAKaFAACnhQAAqIUAAKmFAACqhQAA84UAAPWFAAA+hgAA P4YAAECGAABqhgAAqIYAALaGAADchgAABocAADCHAABkhwAAh4cAAKuHAADBhwAA8ocAAAqI AABQiAAAZ4gAAKuIAADRiAAA7YgAAAiJAAAiiQAAO4kAAFWJAACFiQAAtokAAOCJAADwiQAA /IkAAC2KAABgigAAbYoAAJmKAACzigAAtIoAAPWKAAD2igAAJIsAACWLAABuiwAAsYsAAPeL AAAEjAAABYwAACSMAAAljAAAbIwAALWMAAD8jAAARY0AAIiNAACJjQAAio0AAIuNAADUjQAA 1o0AAB+OAAAgjgAAIY4AAEaOAABHjgAAf44AAICOAADGjgAACI8AAAmPAAApjwAAKo8AAHOP AAC2jwAA+o8AAAiQAAAJkAAASpAAAI2QAAC8kAAAvZAAAAaRAABMkQAAk5EAANuRAAAhkgAA ZpIAAKeSAACzkgAAtJIAAM2SAADOkgAAFZMAAFqTAACgkwAA5ZMAACyUAAB1lAAAvpQAAO6U AADvlAAAHJUAAB2VAABelQAApZUAAOGVAAAhlgAAaJYAAKmWAADPlgAA0JYAANGWAADSlgAA 05YAAByXAAAelwAAZ5cAAGiXAABplwAAk5cAAKOXAADNlwAA45cAAACYAAAemAAAVZgAAGqY AACsmAAAy5gAAOWYAAD+mAAAH5kAADWZAABNmQAAZJkAAHWZAACkmQAAtpkAALeZAAD9mQAA /pkAAP+ZAAAAmgAAAZoAAAKaAAADmgAABJoAAAWaAAAGmgAAB5oAAAiaAAAJmgAACpoAAAua AAAMmgAADZoAAA6aAAAPmgAAEJoAABGaAAASmgAAE5oAABSaAAAVmgAAFpoAABeaAAAYmgAA GZoAABqaAAAbmgAAZJoAAGaaAACvmgAAsJoAALGaAADbmgAAGZsAACebAABNmwAAd5sAAJ2b AADRmwAA9JsAABicAAAunAAAX5wAAIicAACfnAAA45wAAAmdAAAlnQAAQJ0AAFqdAABznQAA jZ0AAL2dAADunQAAGJ4AACieAABCngAAaZ4AAIaeAAChngAArZ4AANqeAAACnwAAD58AADuf AABVnwAAVp8AAJ2fAADJnwAAyp8AAAmgAAAKoAAAG6AAABygAABeoAAAnqAAAOagAAAnoQAA KKEAACmhAAAqoQAAK6EAACyhAAB1oQAAd6EAAMChAADBoQAAwqEAAAeiAAAIogAAUaIAAJmi AADhogAAJ6MAAHCjAAC3owAA/qMAAEakAACPpAAA0KQAABilAABapQAAn6UAAOelAAAcpgAA HaYAAGamAACupgAA9qYAADenAABnpwAAaKcAAK6nAAD1pwAAPqgAAFCoAABRqAAAUqgAAFOo AABUqAAAVagAAFaoAABXqAAAWKgAAFmoAABaqAAAW6gAAFyoAABdqAAAXqgAAF+oAABgqAAA YagAAGKoAABjqAAAZKgAAGWoAABmqAAAZ6gAALCoAACyqAAA+6gAAPyoAAD9qAAAOqkAADup AACCqQAAyKkAAA+qAABVqgAAjKoAAMyqAAALqwAAVKsAAJqrAADjqwAA86sAAPSrAAD1qwAA 9qsAACCsAAAwrAAAWqwAAIWsAACbrAAAvawAAPmsAAA8rQAAZ60AAHqtAACLrQAAuq0AAMyt AADNrQAAFK4AAD+uAABArgAAQa4AAEKuAABDrgAARK4AAEWuAABGrgAAR64AAEiuAABJrgAA Sq4AAEuuAABMrgAATa4AAE6uAABPrgAAUK4AAFGuAABSrgAAm64AAJ2uAADmrgAA564AAOiu AAASrwAAT68AAHuvAACJrwAAr68AANmvAAD/rwAAM7AAAFawAAB/sAAAlbAAAMawAADnsAAA D7EAAEKxAABpsQAAkbEAALuxAADLsQAA17EAAASyAAAssgAAObIAAGSyAAB+sgAAf7IAAMSy AADvsgAA8LIAAPGyAADysgAAHLMAAFizAACIswAAibMAANCzAADRswAAGrQAAGG0AABvtAAA cLQAAHG0AABytAAAc7QAAHS0AAB1tAAAdrQAAHe0AAB4tAAAebQAAHq0AADDtAAAxbQAAA61 AAAPtQAAELUAADq1AABZtQAAhLUAAKu1AAC+tQAA/rUAAB22AAA4tgAAVLYAAGu2AACDtgAA j7YAALy2AADktgAA8bYAABK3AAATtwAAUrcAAFO3AABUtwAAVbcAAFa3AABXtwAAWLcAAFm3 AABatwAAW7cAAFy3AABdtwAAXrcAAF+3AABgtwAAYbcAAGK3AABjtwAAZLcAAGW3AABmtwAA Z7cAAGi3AABptwAAarcAAGu3AABstwAAbbcAAG63AABvtwAAcLcAAHG3AABytwAAc7cAALy3 AAC+twAAB7gAAAi4AAAJuAAALLgAAC24AAB1uAAAvLgAAAS5AABHuQAAj7kAANW5AAAcugAA ZboAAK66AAD2ugAAMbsAADK7AAA8uwAAp7wAAKi8AACpvAAAqrwAANS8AADlvAAAEL0AADi9 AABLvQAATL0AAIe9AACIvQAAib0AAIq9AAC0vQAAzb0AAPe9AAAJvgAAKL4AAEy+AABmvgAA f74AAJ2+AAC5vgAA2L4AAPS+AAAQvwAALb8AAEC/AABbvwAAXL8AAJi/AACZvwAAmr8AAJu/ AACcvwAAnb8AAJ6/AACfvwAA6L8AAOq/AAAzwAAANMAAADXAAABuwAAAb8AAALjAAAD8wAAA P8EAAIjBAADPwQAAFsIAAF7CAACjwgAA6MIAAC/DAAB3wwAApMMAAKXDAADtwwAALsQAAHPE AAC8xAAA6sQAAOvEAAAVxQAAXsUAAKHFAADoxQAAMcYAAELGAABDxgAARMYAAEXGAABvxgAA isYAALTGAADfxgAA9sYAADHHAABoxwAAkscAAKXHAAC2xwAA3scAAPvHAAD8xwAAPMgAAD3I AAA+yAAAP8gAAEDIAABByAAAQsgAAEPIAACMyAAAjsgAANfIAADYyAAA2cgAAAPJAAAmyQAA UMkAAGLJAACByQAApckAAL/JAADYyQAA9skAABLKAAAxygAATcoAAGnKAACGygAAmcoAAKTK AADPygAA9coAAAHLAAAqywAAT8sAAFDLAACNywAAjssAAI/LAACQywAAkcsAAJLLAACTywAA lMsAAJXLAACWywAAl8sAAJjLAACZywAAmssAAJvLAACcywAAncsAAJ7LAACfywAAoMsAAKHL AACiywAAo8sAAKTLAAClywAApssAAKfLAACoywAAqcsAAPLLAAD0ywAAPcwAAD7MAAA/zAAA VswAAFfMAACgzAAA58wAACnNAABrzQAAs80AAPjNAAA+zgAAiM4AAMzOAADmzgAA584AAPfO AAD4zgAANc8AAGbPAABnzwAAaM8AAIDPAACBzwAAw88AAP/PAAAA0AAAAdAAAAvQAAAM0AAA UdAAAHLQAABz0AAAuNAAAPzQAAA/0QAAftEAAKfRAACo0QAA79EAAAfSAAAI0gAAT9IAAFDS AACZ0gAA3NIAAPfSAAD40gAAP9MAAIXTAACn0wAAqNMAAKnTAACq0wAA89MAAPXTAAA+1AAA P9QAAEDUAACI1AAA0NQAABLVAABC1QAAQ9UAAGHVAABi1QAAp9UAAPDVAAAu1gAAaNYAAGnW AACr1gAA9NYAADfXAAB91wAAwtcAAArYAABS2AAAmNgAAOHYAADo2AAA6dgAADDZAAB52QAA wtkAANfZAADY2QAAFtoAAFvaAACj2gAA59oAACrbAABv2wAAqdsAAKrbAADx2wAAMNwAADHc AAB33AAAqNwAAKncAADy3AAAOd0AAIDdAADJ3QAA9N0AAPXdAAD23QAA990AAPjdAABB3gAA Q94AAIzeAACN3gAAjt4AANPeAAAX3wAAXd8AAKDfAADp3wAALuAAAGPgAABk4AAAqOAAALbg AAC34AAA/uAAAP/gAAA+4QAAaeEAAGrhAACs4QAA8eEAAC/iAAAw4gAAeOIAAMDiAADz4gAA 9OIAADrjAACA4wAAxOMAAALkAAA85AAAguQAAMfkAAAG5QAATuUAAJflAADW5QAA1+UAAN3l AAC/5wAAwOcAAMHnAADC5wAAw+cAAMTnAADF5wAAxucAAMfnAADI5wAAyecAAMrnAADL5wAA zOcAAM3nAAAW6AAAGOgAAGHoAABi6AAAY+gAAI3oAACd6AAAx+gAAPLoAAAI6QAAJukAAGbp AACp6QAA1OkAAOfpAAAj6gAAPOoAAFnqAACK6gAAu+oAAOzqAAAd6wAATusAAG3rAACI6wAA n+sAAOLrAAAN7AAAIOwAADHsAABt7AAAsOwAANvsAADu7AAA/+wAAC7tAABA7QAAQe0AAIjt AAC27QAAt+0AALjtAAC57QAAuu0AALvtAAC87QAAve0AAL7tAAC/7QAAwO0AAMHtAADC7QAA w+0AAMTtAADF7QAAxu0AAA/uAAAR7gAAWu4AAFvuAABc7gAAhu4AAJ7uAADI7gAA8e4AAP/u AAAl7wAAT+8AAHXvAACp7wAAzO8AAPXvAAAL8AAAPPAAAGvwAACn8AAAwPAAAN3wAAAO8QAA P/EAAHDxAACh8QAA0vEAAPDxAAAK8gAAIfIAADvyAABi8gAAcvIAAH7yAACr8gAA0/IAAODy AAAL8wAAJfMAACbzAABu8wAAoPMAAKHzAADJ8wAAyvMAABD0AABX9AAAnPQAAOT0AAAi9QAA afUAALD1AAD49QAA+fUAAPr1AAD79QAARPYAAEb2AACP9gAAkPYAAJH2AACo9gAAqfYAAPL2 AAA79wAAevcAAIr3AACL9wAA1PcAAAP4AAAE+AAASPgAAI34AADL+AAAEvkAAFX5AABW+QAA hvkAAIf5AADG+QAAB/oAAE/6AACV+gAA2PoAACH7AABm+wAApvsAAOr7AAAw/AAAePwAALz8 AADX/AAA2PwAABz9AAAn/QAAKP0AAEP9AABE/QAAjP0AANX9AAD//QAAAP4AAEn+AAB6/gAA e/4AAHz+AAB9/gAAfv4AAH/+AACA/gAAgf4AAIL+AADL/gAAzf4AABb/AAAX/wAAGP8AAD3/ AAA+/wAAh/8AAMn/AAAPAAEAVgABAJ0AAQDmAAEALgEBAHcBAQC9AQEAAgIBADcCAQA4AgEA RgIBAEcCAQCNAgEA0QIBABgDAQBcAwEAjwMBAJADAQAxBAEAMgQBAGUEAQBmBAEAdAQBAHUE AQC5BAEA5AQBAOUEAQDmBAEA8wQBAPQEAQA8BQEAgwUBAMwFAQACBgEAAwYBAAQGAQAVBgEA FgYBAF4GAQCYBgEAmQYBAJoGAQC5BgEAugYBAAIHAQAaBwEAGwcBABwHAQAdBwEAZgcBAGgH AQCxBwEAsgcBALMHAQDGBwEAxwcBAA0IAQBQCAEAXggBAF8IAQBgCAEAbggBAG8IAQCyCAEA +wgBAPwIAQD9CAEABQkBAAYJAQBNCQEAjgkBAK8JAQCwCQEAsQkBAL0JAQC+CQEA9gkBAPcJ AQD4CQEABwoBAAgKAQBQCgEAlQoBAK4KAQCvCgEAsAoBAMEKAQDCCgEA+woBAPwKAQD9CgEA FgsBABcLAQBeCwEAcwsBAHQLAQB1CwEAjQsBAI4LAQCPCwEAkAsBAJELAQCSCwEAkwsBAJQL AQDdCwEA3wsBACgMAQApDAEAKgwBAFQMAQCEDAEApAwBAOEMAQDuDAEA7wwBACgNAQApDQEA OQ0BADoNAQCDDQEAyw0BABIOAQBZDgEAWg4BAJsOAQCoDgEAqQ4BALoOAQC7DgEABA8BAEcP AQCQDwEA1g8BABwQAQBkEAEAqhABAPMQAQA7EQEARxEBAEgRAQBgEQEAYREBAGIRAQCMEQEA vhEBAN0RAQD8EQEAPBIBAD0SAQB4EgEAeRIBAHoSAQB7EgEAfBIBAH0SAQB+EgEAfxIBAIAS AQCBEgEAghIBAMsSAQDNEgEAFhMBABcTAQAYEwEALBMBAC0TAQBwEwEAtxMBAAAUAQBJFAEA kBQBANIUAQDfFAEA4BQBACkVAQBuFQEArxUBAMMVAQDEFQEAxRUBAMYVAQDHFQEAyBUBAMkV AQDKFQEAyxUBAMwVAQDNFQEAzhUBAM8VAQDQFQEA0RUBANIVAQDTFQEA1BUBANUVAQDWFQEA 1xUBANgVAQDZFQEA2hUBANsVAQDcFQEA3RUBAN4VAQDfFQEA4BUBAOEVAQDiFQEA4xUBAOQV AQDlFQEA5hUBAOcVAQDoFQEAMRYBADMWAQB8FgEAfRYBAH4WAQCTFgEAlBYBANoWAQAcFwEA HRcBAB4XAQAfFwEAYxcBAJoXAQCbFwEAnBcBAJ8XAQDYFwEA2xcBABsYAQBgGAEAgxgBAIYY AQCOGAEAnBgBAK0YAQDIGAEA3xgBAPcYAQAQGQEAMxkBAFIZAQBdGQEAahkBAGsZAQBuGQEA hBkBAIcZAQCNGQEAnRkBALcZAQDoGQEABBoBACcaAQBZGgEAYxoBAIUaAQDHGgEA0RoBABob AQAgGwEAXxsBAHobAQB7GwEAfBsBAH0bAQDGGwEAyBsBABEcAQASHAEAExwBADgcAQBpHAEA hRwBAM0cAQDTHAEA6hwBADAdAQAyHQEAMx0BADYdAQBOHQEAUR0BAFcdAQBvHQEAkR0BAMwd AQDSHQEA6x0BADMeAQBWHgEAgx4BAKweAQCyHgEA0R4BAPoeAQAnHwEALR8BAC8fAQAwHwEA Mx8BAGUfAQBoHwEAbh8BAKYfAQCoHwEAqR8BAKwfAQDUHwEA1x8BAN0fAQAXIAEAGSABABog AQAdIAEAOyABAD4gAQBEIAEAXCABAF0gAQBeIAEAXyABAKggAQCqIAEA8yABAPQgAQD1IAEA CiEBACohAQBRIQEAUyEBAFQhAQBXIQEAcSEBAHQhAQB6IQEAvyEBAMEhAQDCIQEAxSEBAOkh AQDsIQEA8iEBAA8iAQA2IgEAZyIBAG0iAQCgIgEAoiIBAKMiAQCmIgEAtiIBAOEiAQASIwEA FSMBABsjAQAkIwEANyMBAGUjAQBrIwEAbSMBAG4jAQBxIwEAiiMBAI0jAQCTIwEAnyMBAOUj AQDnIwEA6CMBAOsjAQABJAEABCQBAAokAQAsJAEALSQBAC4kAQAvJAEAeCQBAHokAQDDJAEA xCQBAMUkAQDHJAEAyCQBAMskAQDzJAEA9iQBAPwkAQAIJQEAHiUBADolAQBOJQEAeiUBAIQl AQCTJQEAyCUBAOslAQAJJgEANSYBAD8mAQBVJgEAZCYBAJImAQCgJgEAyCYBANYmAQDcJgEA 3iYBAN8mAQDiJgEA/yYBAAInAQAIJwEAHycBAEAnAQBkJwEAiicBALInAQDHJwEAzScBAM8n AQDQJwEA0ycBAPsnAQD+JwEABCgBABcoAQAoKAEAPigBAFooAQBbKAEAXCgBAF0oAQCmKAEA qCgBAPEoAQDyKAEA8ygBAAUpAQAWKQEAIykBAEEpAQBXKQEAaykBAIMpAQCpKQEAvSkBAMgp AQD1KQEAJioBACgqAQApKgEALCoBAEIqAQBFKgEASyoBAEwqAQBRKgEAbSoBAHIqAQCZKgEA yioBAAErAQBEKwEAcysBAKArAQDFKwEADCwBAEMsAQB2LAEAsSwBANEsAQD7LAEAMS0BAEIt AQBILQEASi0BAEstAQBOLQEAYS0BAGQtAQBqLQEAay0BAHAtAQCOLQEAky0BAJQtAQCVLQEA li0BAN8tAQDhLQEAKi4BACsuAQAsLgEAOS4BAFAuAQB8LgEAii4BAJkuAQCuLgEAtC4BALYu AQC3LgEAui4BANkuAQDcLgEA4i4BAO4uAQAVLwEAQC8BAGwvAQCALwEAvy8BAO8vAQD/LwEA GTABADQwAQA6MAEAPDABAD0wAQBAMAEAfDABAJcwAQCaMAEAoDABAKEwAQCmMAEA2jABAN8w AQAWMQEAFzEBABwxAQBWMQEAfTEBAIIxAQCRMQEArzEBAMsxAQDZMQEA2jEBAN8xAQAMMgEA DTIBAA4yAQAPMgEAWDIBAFoyAQCjMgEApDIBAKUyAQDTMgEA7jIBAPMyAQAPMwEAETMBABIz AQBFMwEARjMBAEczAQBIMwEASTMBAEozAQBLMwEATDMBAE0zAQBOMwEATzMBAFAzAQBRMwEA UjMBAFMzAQBUMwEAVTMBAFYzAQBXMwEAWDMBAFkzAQBaMwEAWzMBAFwzAQBdMwEAXjMBAF8z AQBgMwEAYTMBAGIzAQBjMwEAZDMBAGUzAQBmMwEAZzMBAGgzAQBpMwEAajMBAGszAQBsMwEA bTMBAG4zAQBvMwEAcDMBAHEzAQC6MwEAvDMBAAU0AQAGNAEABzQBADA0AQAxNAEAbTQBALM0 AQD6NAEAQDUBAIc1AQDNNQEA2TUBANo1AQAbNgEAYzYBAKg2AQDxNgEAGjcBABs3AQAcNwEA HTcBAB43AQAfNwEAIDcBACE3AQAiNwEAIzcBACQ3AQAlNwEAJjcBACc3AQAoNwEAKTcBACo3 AQArNwEALDcBAC03AQAuNwEALzcBADA3AQAxNwEAMjcBADM3AQA0NwEANTcBADY3AQA3NwEA ODcBADk3AQA6NwEAOzcBADw3AQA9NwEAPjcBAIc3AQCJNwEA0jcBANM3AQDUNwEA7TcBAO43 AQALOAEADDgBAFE4AQBZOAEAWjgBAHw4AQB9OAEAvzgBAM84AQDQOAEAFjkBAB85AQAgOQEA JTkBACY5AQBMOQEATTkBAHc5AQB4OQEAfTkBAH45AQClOQEApjkBANA5AQDROQEADToBAA46 AQBROgEAljoBAKM6AQCkOgEAyjoBAMs6AQDMOgEA7DoBAO06AQDuOgEADTsBAA47AQAPOwEA MDsBADE7AQBpOwEAajsBAGs7AQBsOwEAbTsBAG47AQBvOwEAuDsBALo7AQADPAEABDwBAAU8 AQBDPAEAiDwBAKU8AQCmPAEApzwBAPA8AQAJPQEACj0BAAs9AQA1PQEANj0BADc9AQA4PQEA fj0BAL09AQC+PQEAvz0BAAg+AQAWPgEAFz4BABg+AQAzPgEAND4BAE4+AQBPPgEAUD4BAHA+ AQBxPgEAcj4BAJo+AQCbPgEAnD4BANs+AQALPwEADD8BAA0/AQAtPwEALj8BAC8/AQA6PwEA Oz8BAIQ/AQC2PwEAtz8BALg/AQC5PwEAuj8BALs/AQC8PwEAvT8BAL4/AQAHQAEACUABAFJA AQBTQAEAVEABAGpAAQBrQAEAikABAItAAQC0QAEAtUABANtAAQDcQAEAIEEBAEdBAQBIQQEA j0EBALdBAQC4QQEA7kEBAO9BAQAKQgEAC0IBABBCAQARQgEANEIBADVCAQBbQgEAXEIBAKBC AQDHQgEAyEIBANBCAQDRQgEA2kIBAPNCAQAuQwEAaUMBAJhDAQCiQwEAx0MBAPtDAQAeRAEA KUQBADNEAQBURAEAf0QBALJEAQDTRAEAC0UBACtFAQA2RQEAQUUBAEJFAQBDRQEAREUBAI1F AQCPRQEA2EUBANlFAQDaRQEA4UUBAOJFAQAIRgEACUYBAE9GAQCXRgEA2kYBANtGAQDrRgEA 7EYBAAtHAQAMRwEADUcBABdHAQAYRwEAN0cBADhHAQBQRwEAUUcBAHBHAQBxRwEAckcBAHNH AQB0RwEAdUcBAHZHAQB3RwEAeEcBAHlHAQB6RwEAe0cBAHxHAQB9RwEAfkcBAH9HAQCARwEA gUcBAIJHAQCDRwEAhEcBAIVHAQCGRwEAh0cBAIhHAQCJRwEAikcBAItHAQCMRwEAjUcBAI5H AQCPRwEA2EcBANpHAQAjSAEAJEgBACVIAQBCSAEAQ0gBAIhIAQDOSAEAE0kBAFpJAQCjSQEA 60kBADBKAQBbSgEAXEoBAKVKAQDaSgEA20oBAB5LAQBdSwEAnksBAORLAQAGTAEAB0wBAE9M AQBkTAEAZUwBAGZMAQBnTAEAaEwBAGlMAQBqTAEAa0wBAGxMAQBtTAEAbkwBAG9MAQBwTAEA cUwBAHJMAQBzTAEAdEwBAHVMAQB2TAEAd0wBAHhMAQB5TAEAekwBAHtMAQB8TAEAfUwBAH5M AQB/TAEAgEwBAIFMAQDKTAEAzEwBABVNAQAWTQEAF00BACxNAQAtTQEAc00BAK5NAQCvTQEA 100BANhNAQAETgEABU4BADFOAQAyTgEAXk4BAF9OAQCLTgEAjE4BALZOAQC3TgEA5U4BAOZO AQAnTwEAN08BADhPAQBoTwEAaU8BAJFPAQCSTwEAvU8BAL5PAQDqTwEA608BADJQAQByUAEA c1ABALRQAQDFUAEAxlABAPdQAQD4UAEAGVEBABpRAQA8UQEAPVEBAHhRAQB5UQEAv1EBAPhR AQD5UQEA+lEBAPtRAQD8UQEA/VEBAEZSAQBIUgEAkVIBAJJSAQCTUgEAxlIBAMdSAQADUwEA BFMBAC9TAQAwUwEAdFMBAHVTAQCtUwEArlMBAPJTAQA0VAEAd1QBALJUAQCzVAEA91QBADxV AQBmVQEAZ1UBAKNVAQCkVQEA61UBAPZVAQD3VQEAHFYBAB1WAQA8VgEAPVYBAIRWAQDMVgEA A1cBAARXAQAFVwEABlcBAAdXAQAIVwEACVcBAApXAQALVwEADFcBAA1XAQAOVwEAD1cBABBX AQARVwEAElcBABNXAQAUVwEAFVcBABZXAQAXVwEAYFcBAGJXAQCrVwEArFcBAK1XAQC+VwEA v1cBAANYAQAEWAEABVgBAAZYAQAHWAEACFgBAAlYAQAKWAEAC1gBAAxYAQANWAEADlgBAA9Y AQAQWAEAEVgBABJYAQATWAEAFFgBABVYAQAWWAEAF1gBABhYAQAZWAEAGlgBABtYAQAcWAEA HVgBAB5YAQAfWAEAIFgBACFYAQAiWAEAI1gBACRYAQAlWAEAJlgBACdYAQAoWAEAKVgBACpY AQArWAEALFgBAC1YAQAuWAEAL1gBADBYAQAxWAEAMlgBADNYAQB8WAEAflgBAMdYAQDIWAEA yVgBANlYAQDaWAEA9lgBAPdYAQBAWQEAcFkBAHFZAQC4WQEA9FkBAAtaAQAMWgEAVVoBAJ1a AQDGWgEAx1oBAANbAQAEWwEASlsBAGtbAQBsWwEArVsBANhbAQDZWwEAG1wBAF9cAQBgXAEA qFwBAPFcAQDyXAEAO10BAIJdAQClXQEApl0BAOxdAQAxXgEAdF4BAHVeAQC8XgEABV8BADVf AQA2XwEAfV8BAMVfAQAOYAEAD2ABABBgAQARYAEAEmABABNgAQAUYAEAFWABAF5gAQBgYAEA qWABAKpgAQCrYAEAyWABAMpgAQAQYQEAV2EBAJNhAQCUYQEA1mEBABtiAQAyYgEAM2IBAHxi AQCUYgEAlWIBANtiAQAkYwEATWMBAE5jAQCUYwEAzWMBAAtkAQAgZAEAIWQBAGVkAQCkZAEA x2QBAMhkAQADZQEAR2UBAI1lAQCOZQEAj2UBAJBlAQCRZQEAkmUBAJNlAQCUZQEAlWUBAJZl AQCXZQEAmGUBAJllAQCaZQEAm2UBAJxlAQCdZQEAnmUBAJ9lAQCgZQEAoWUBAKJlAQCjZQEA 7GUBAO5lAQA3ZgEAOGYBADlmAQByZgEAc2YBAHRmAQCeZgEAzGYBAPtmAQA8ZwEAfWcBAIhn AQCdZwEA1mcBABZoAQBbaAEAfmgBAJRoAQCgaAEAvmgBAN1oAQAGaQEAK2kBAFFpAQB4aQEA qWkBANZpAQDvaQEACmoBABdqAQAjagEALGoBAEFqAQBXagEAcWoBAHJqAQCVagEAu2oBANJq AQD5agEAK2sBAENrAQBbawEAimsBAKBrAQDRawEA+GsBAC5sAQBIbAEAX2wBAHVsAQB2bAEA d2wBAHhsAQDBbAEAw2wBAAxtAQANbQEADm0BAD5tAQBWbQEAgG0BAKZtAQC/bQEA+W0BABNu AQAqbgEAQG4BAGpuAQCRbgEAyW4BAONuAQD6bgEADm8BAB9vAQAgbwEARG8BAGtvAQCabwEA rm8BAL9vAQDAbwEA7m8BAB9wAQA3cAEAXnABAJBwAQCocAEAwXABAPBwAQAGcQEAMHEBAFdx AQCMcQEApnEBAL1xAQDRcQEA4nEBAONxAQANcgEAOnIBAGdyAQCQcgEApHIBALVyAQC2cgEA wnIBAMNyAQDEcgEAxXIBAA5zAQAQcwEAWXMBAFpzAQBbcwEAZnMBAH9zAQCXcwEAsXMBALJz AQCzcwEA3nMBAAx0AQAjdAEAR3QBAF90AQB1dAEApHQBALt0AQDrdAEA/3QBABB1AQARdQEA EnUBAD51AQBtdQEAk3UBAMN1AQDXdQEA6HUBAOl1AQDqdQEAIHYBAFl2AQB/dgEAr3YBAMN2 AQDUdgEA1XYBAAd3AQA8dwEAZXcBAJV3AQCpdwEAuncBALt3AQDHdwEAyHcBANN3AQDsdwEA HngBADh4AQA5eAEAOngBADt4AQA8eAEAhXgBAId4AQDQeAEA0XgBANJ4AQD+eAEAHnkBADJ5 AQBReQEAZnkBAI15AQCeeQEAqnkBAKt5AQC2eQEAz3kBAPd5AQARegEAEnoBAD96AQBVegEA eHoBAI96AQCsegEA0XoBAPh6AQAJewEAFXsBABZ7AQAhewEAOnsBAFh7AQByewEAc3sBAJ57 AQCzewEA23sBAPF7AQAQfAEAMXwBAEd8AQBbfAEAgXwBAKZ8AQC+fAEA0nwBAON8AQDvfAEA 8HwBAPt8AQAUfQEALn0BAEh9AQBJfQEASn0BAEt9AQCUfQEAln0BAN99AQDgfQEA4X0BAAh+ AQAdfgEASX4BAHl+AQCPfgEApX4BALZ+AQDCfgEAw34BAM5+AQDnfgEAC38BACV/AQAmfwEA Vn8BAFd/AQCKfwEAq38BANh/AQABgAEAFYABACaAAQAngAEAUYABAHGAAQCSgAEAqIABALmA AQC6gAEAxoABAMeAAQDSgAEA64ABAPuAAQAmgQEAV4EBAHGBAQBygQEAjoEBAK2BAQDEgQEA 5oEBAAuCAQA4ggEAUIIBAGiCAQB8ggEAjYIBAI6CAQCPggEAkIIBANmCAQDbggEAJIMBACWD AQAmgwEAMoMBADODAQA+gwEAV4MBAG+DAQCmgwEAwIMBAMGDAQDlgwEADIQBAC2EAQBQhAEA aIQBAHyEAQCNhAEAmYQBAJqEAQClhAEAvoQBANeEAQDxhAEA8oQBABGFAQA1hQEASYUBAG6F AQCThQEAvYUBANKFAQDohQEA+YUBAAWGAQAGhgEAEYYBACqGAQBAhgEAWoYBAFuGAQB8hgEA jIYBAKSGAQDGhgEA34YBAPCGAQABhwEADYcBAA6HAQAZhwEAGocBABuHAQAchwEAZYcBAGeH AQCwhwEAsYcBALKHAQDLhwEA84cBAA2IAQAOiAEALYgBAE+IAQBniAEAkYgBALaIAQDhiAEA CokBACaJAQA+iQEAV4kBAHmJAQCPiQEApYkBANKJAQAIigEAH4oBADaKAQBOigEAcIoBAJWK AQCtigEAxooBANyKAQAIiwEALIsBAGSLAQB7iwEAk4sBAKqLAQDSiwEA84sBAB2MAQBCjAEA WowBAHuMAQCijAEAxYwBAN2MAQD+jAEAEo0BACONAQAkjQEAMI0BADGNAQAyjQEAM40BADSN AQB9jQEAf40BAMiNAQDJjQEAyo0BANWNAQDujQEAC44BACWOAQAmjgEAUI4BAH2OAQCTjgEA t44BAN+OAQD3jgEADo8BACSPAQBKjwEAco8BAIqPAQChjwEAt48BAN+PAQAHkAEAH5ABADaQ AQBekAEAcpABAIOQAQCPkAEAkJABAJuQAQC0kAEA3JABAPaQAQD3kAEAHZEBADORAQBJkQEA cJEBAIeRAQCdkQEAx5EBAN6RAQD0kQEAJJIBADuSAQBRkgEAd5IBAI6SAQCkkgEAyZIBAMqS AQDLkgEAzJIBABWTAQAXkwEAYJMBAGGTAQBikwEAeZMBAI+TAQCwkwEAx5MBAN2TAQAPlAEA JpQBADyUAQBmlAEAfZQBAJOUAQC7lAEA0pQBAOiUAQAUlQEAK5UBAEGVAQB5lQEAkJUBAKeV AQDOlQEA7ZUBAP6VAQD/lQEAHZYBAD6WAQBnlgEAe5YBAIyWAQCNlgEArZYBANCWAQD5lgEA DZcBAB6XAQAflwEAK5cBACyXAQA3lwEAUJcBAGaXAQCAlwEAgZcBAKOXAQC+lwEA2JcBAPSX AQATmAEAFJgBABWYAQAWmAEAX5gBAGGYAQCqmAEAq5gBAKyYAQDTmAEA5JgBAOWYAQAHmQEA LJkBAFCZAQBkmQEAdZkBAHaZAQCbmQEAw5kBAOeZAQD7mQEADJoBAA2aAQA4mgEAZpoBAIqa AQCemgEAr5oBALCaAQDRmgEA9ZoBABmbAQAtmwEAPpsBAD+bAQBfmwEAgpsBAKabAQC6mwEA y5sBAMybAQDomwEAB5wBACycAQBAnAEAUZwBAFKcAQB/nAEAr5wBANOcAQDnnAEA+JwBAPmc AQAenQEARp0BAGqdAQBrnQEAbJ0BAG2dAQC2nQEAuJ0BAAGeAQACngEAA54BABeeAQAongEA KZ4BAEyeAQByngEAlp4BAKqeAQC7ngEAvJ4BAOOeAQANnwEAMZ8BAEWfAQBWnwEAV58BAIqf AQDAnwEA8p8BABigAQAwoAEAVKABAGigAQB5oAEAeqABAIagAQCHoAEAkqABAKugAQC+oAEA 2KABANmgAQD5oAEAFKEBADChAQBMoQEAb6EBAJShAQDAoQEA2KEBAPmhAQAbogEARKIBAFii AQBpogEAaqIBAHaiAQB3ogEAgqIBAIOiAQCEogEAhaIBAM6iAQDQogEAGaMBABqjAQAbowEA NKMBAFOjAQBtowEAbqMBAI2jAQChowEAtKMBANyjAQABpAEAG6QBAESkAQBrpAEAhaQBAJmk AQCupAEAv6QBAMCkAQDfpAEA86QBABelAQA6pQEAUKUBAGWlAQB2pQEAd6UBAJ6lAQC8pQEA BaYBABamAQAnpgEAKKYBAEamAQBppgEAk6YBAKmmAQC6pgEAu6YBAN+mAQAFpwEAF6cBADGn AQBXpwEAcqcBAIWnAQCZpwEAqqcBAKunAQC3pwEAuKcBALmnAQC6pwEAA6gBAAWoAQBOqAEA T6gBAFCoAQBbqAEAdKgBALCoAQDLqAEA5agBAOaoAQAFqQEAIKkBAFKpAQBuqQEAgakBAJap AQCsqQEA56kBAACqAQAXqgEALaoBAFGqAQBlqgEAdqoBAHeqAQB4qgEAmqoBALWqAQDtqgEA EqsBAC6rAQBEqwEAWKsBAG+rAQCJqwEAsasBAMmrAQDiqwEA/KsBABasAQArrAEAQKwBAFes AQBorAEAaawBAI+sAQCqrAEA1awBAAGtAQAarQEANq0BAEytAQBNrQEATq0BAE+tAQCYrQEA mq0BAOOtAQDkrQEA5a0BAAeuAQAergEAL64BADCuAQA8rgEAPa4BAEuuAQBMrgEAd64BAHiu AQB5rgEAeq4BAHuuAQB8rgEAfa4BAH6uAQB/rgEAgK4BAIGuAQCCrgEAg64BAISuAQCFrgEA hq4BAIeuAQCIrgEAia4BAIquAQCLrgEAjK4BAI2uAQCOrgEAj64BAJCuAQCRrgEAkq4BAJOu AQCUrgEAla4BAJauAQCXrgEAmK4BAJmuAQCargEAm64BAJyuAQCdrgEAnq4BAJ+uAQCgrgEA oa4BAOquAQDsrgEANa8BADavAQA3rwEASq8BAEuvAQBZrwEAa68BAGyvAQCKrwEAi68BAIyv AQCdrwEAqq8BAMuvAQDgrwEA5q8BAOevAQABsAEAF7ABABiwAQAZsAEAMLABAEewAQBpsAEA irABAKGwAQCnsAEAqLABAMKwAQDmsAEAC7EBAAyxAQANsQEAIrEBAEOxAQBXsQEAcbEBAHyx AQB9sQEAmLEBAMCxAQDksQEA5bEBAOaxAQDnsQEA6LEBAOmxAQDqsQEA67EBAOyxAQDtsQEA 7rEBAO+xAQDwsQEAObIBADuyAQCEsgEAhbIBAIayAQCfsgEAoLIBAMiyAQDJsgEADrMBAFOz AQBvswEAcLMBALmzAQACtAEAS7QBAJO0AQDctAEAIrUBAGi1AQBptQEAarUBAIC1AQCBtQEA xrUBAA+2AQBWtgEAnLYBAOK2AQArtwEAb7cBAI63AQCPtwEA0bcBABW4AQBeuAEAmrgBAOO4 AQD/uAEAALkBAEe5AQCLuQEA0bkBABK6AQAougEAKboBACq6AQA5ugEAOroBAHm6AQCkugEA pboBAKa6AQCnugEAqLoBAKm6AQDyugEA9LoBAPW6AQD2ugEAWbsBAO67AQDvuwEAsLwBAC69 AQBwvQEAqr0BAKu9AQCTvgEAIb8BAIG/AQBnwAEAaMABAKrAAQBrwQEAqcEBAKrBAQAEwgEA BcIBAI7CAQCswgEAxcIBAMbCAQBKwwEAS8MBANvDAQDjwwEAMsQBADPEAQDmxAEAN8UBAPzF AQD9xQEA5cYBAObGAQCTxwEAlMcBAAHIAQACyAEAXMgBAF3IAQBeyAEAnsgBABXJAQBoyQEA g8kBAKvJAQDeyQEA38kBAODJAQACygEAQcoBAELKAQC8ygEAvcoBAFbLAQBzywEA2ssBANvL AQCDzAEAhMwBANHMAQAXzQEAGM0BAGvNAQBszQEAdM0BAHzNAQCEzQEAjs0BAI/NAQAezgEA H84BAL3OAQC+zgEAec8BAIPPAQCGzwEAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA gACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA gACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA gACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA gACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAACAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAIAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAQAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAGYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAZgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJpAAAARMAAA AAAAAACAAAAAgAAAAPgAAAAAAASYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAA ETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAA ETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAA AIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAZhAAAARMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAA ETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhA AAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAA AAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACA AAAAAAAAAAAAAJhAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmEAAABEwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAARMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYQAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAACgAAAAAAAAAAAAAA AAAAAAAAGTCFFAAAAAAABwAAAAABAAAAAgAAAAMAAABMAAAAlQAAAN4AAAAnAQAAcAEAAI0w AACOMAAAjzAAANYwAAAcMQAACEEAAE9BAACNQQAAj0EAAJBBAACRQQAAkkEAAJNBAACfQQAA H0MAACBDAACtQwAAh0UAAIhFAADJRQAAEEYAAFhGAACBVQAAwFUAAMFVAAAHVgAAGV0AACdd AAAoXQAAcV0AACViAABrYgAAs2IAAPhiAAChagAA6moAAC9rAAB0awAACZAAAEqQAACNkAAA vJAAAM2SAADOkgAAFZMAAFqTAABRogAAmaIAAOGiAAAnowAAcKMAAEakAACPpAAA0KQAABil AAA3pwAAZ6cAAGinAACupwAA9acAAH+wAACVsAAAxrAAAOewAAD+tQAAHbYAADi2AABUtgAA ZboAAK66AAD2ugAAMbsAADK7AAA8uwAAp7wAAKi8AABrzQAAs80AAPjNAAA+zgAAiM4AAAbl AABO5QAAl+UAANblAADX5QAA3eUAAL/nAACNAgEA0QIBABgDAQBcAwEAjwMBAJADAQAxBAEA 9roBAFm7AQDuuwEA77sBALC8AQAuvQEAcL0BAKq9AQCrvQEAk74BACG/AQCBvwEAZ8ABAGjA AQCqwAEAa8EBAKnBAQCqwQEABMIBAAXCAQCOwgEArMIBAMXCAQDGwgEASsMBAEvDAQDbwwEA 48MBADLEAQAzxAEA5sQBADfFAQD8xQEA/cUBAOXGAQDmxgEAk8cBAJTHAQAByAEAAsgBAFzI AQBdyAEAXsgBAJ7IAQAVyQEAaMkBAIPJAQCryQEA3skBAN/JAQDgyQEAAsoBAEHKAQBCygEA vMoBAL3KAQBWywEAc8sBANrLAQDbywEAg8wBAITMAQDRzAEAF80BABjNAQBrzQEAbM0BAHTN AQB8zQEAhM0BAI7NAQCPzQEAHs4BAB/OAQC9zgEAvs4BAHnPAQCDzwEAhs8BAIiQADAAEAAA AAAAAAEAAAAAAAAAAAAAAAAAgAGIkAAwABAAAAAAAAABAAAAAAAAAAAAAAAAAIABiJAAMAAQ AAAAAAAAAQAAAAAAAAAAAAAAAACAAYiQADAAEAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGIkAAw ABAAAAAAAAABAAAAAAAAAAAAAAAAAIABiJAAMAAQAAAAAAAAAQAAAAAAAAAAAAAAAACAAYiQ ADAAEAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGIkAAwABAAAAAAAAABAAAAAAAAAAAAAAAAAIAB iJAAMAgAAAAAAAAAAQAAAAQAAAAJAAAAKCbMB4iQADAIAAAAAAAAAAEAAAADAAAAAAAAAAAA gAGIkAAwCAAAAAAAAAACAAAAAQAAAAAAAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACAAYiQADAAEAAAAAAAAAEAAAAAAAAAAAAAAAAAgAeIkAAwDQAAAAAAAAABAAAAMAAAAA4A AABgF7sHiJAAMA0AAAAAAAAAAQAAAC8AAAAAAAAAAACAAYiQADANAAAAAAAAAAIAAAAtAAAA AAAAAAAAgAGIkAAwDQAAAAAAAAABAAAABAAAAAAAAAAAAIABiJAAMA0AAAAAAAAAAQAAAAUA AAAAAAAAAACAAYiQADANAAAAAAAAAAEAAAAFAAAAAAAAAAAAgAGIkAAwDQAAAAAAAAABAAAA BQAAAAAAAAAAAIABiJAAMA0AAAAAAAAAAQAAAAUAAAAAAAAAAACAAYiQADANAAAAAAAAAAEA AAAFAAAAAAAAAAAAkAGIkAAwFgAAAAAAAAABAAAALgAAAAAAAAAAAJABiJAAMA0AAAAAAAAA AQAAAAUAAAAAAAAAAACQAYiQADANAAAAAAAAAAEAAAAFAAAAAAAAAAAAgAeIkAAwDQAAAAAA AAABAAAABQAAAA4AAACYYMwHiJAAMA0AAAAAAAAAAQAAAAQAAAAAAAAAAACAAYiQADANAAAA AAAAAAIAAAACAAAAAAAAAAAAgAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAIABiJAAMAAQ AAAAAAAAAQAAAAAAAAAAAAAAAACAB4iQADASAAAAAAAAAAEAAAAFAAAAEwAAAOBTzAeIkAAw EgAAAAAAAAABAAAABAAAAAAAAAAAAIABiJAAMBIAAAAAAAAAAgAAAAIAAAAAAAAAAACAAZgA AAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAgAeIkAAwFgAAAAAAAAABAAAABQAAABcAAAB0QOcH iJAAMBYAAAAAAAAAAQAAAAQAAAAAAAAAAACAAYiQADAWAAAAAAAAAAIAAAACAAAAAAAAAAAA gAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAIABiJAAMBoAAAAAAAAAAQAAAAUAAAAbAAAA oE3nB4iQADAaAAAAAAAAAAEAAAAEAAAAAAAAAAAAgAGIkAAwGgAAAAAAAAACAAAAAgAAAAAA AAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAACAAYiQADAeAAAAAAAAAAEAAAAFAAAA HwAAABBO5weIkAAwHgAAAAAAAAABAAAABAAAAAAAAAAAAIABiJAAMB4AAAAAAAAAAgAAAAIA AAAAAAAAAACAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAeIkAAwIgAAAAAAAAABAAAA BQAAACMAAAA8paEHiJAAMCIAAAAAAAAAAQAAAAQAAAAAAAAAAACAAYiQADAiAAAAAAAAAAIA AAACAAAAAAAAAAAAgAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHiJAAMCYAAAAAAAAA AQAAAAUAAAAnAAAArKWhB4iQADAmAAAAAAAAAAEAAAAEAAAAAAAAAAAAgAGIkAAwJgAAAAAA AAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAYiQADAqAAAA AAAAAAEAAAAGAAAAKwAAABymoQeIkAAwKgAAAAAAAAABAAAABQAAAAAAAAAAAIABiJAAMCoA AAAAAAAAAQAAAAQAAAAAAAAAAACAAYiQADAqAAAAAAAAAAIAAAACAAAAAAAAAAAAgAGYAAAA AAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHiJAAMC8AAAAAAAAAAQAAAAUAAAAwAAAAqKahB4iQ ADAvAAAAAAAAAAEAAAAEAAAAAAAAAAAAgAGIkAAwLwAAAAAAAAACAAAAAgAAAAAAAAAAAIAB mAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAB4iQADAzAAAAAAAAAAEAAAAGAAAANAAAAIgb uweIkAAwMwAAAAAAAAABAAAABQAAAAAAAAAAAIABiJAAMDMAAAAAAAAAAQAAAAQAAAAAAAAA AACAAYiQADAzAAAAAAAAAAIAAAACAAAAAAAAAAAAgAeYAAAAAAAAAAAAAAAAgAAAAIAAAAAA AAAAAAAHiJAAMEQAAAAAAAAAAQAAAAUAAABFAAAAwDK7B4iQADBEAAAAAAAAAAEAAAAEAAAA AAAAAAAAgAGIkAAwRAAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACA AAAAAAAAAAAAAYiQADBIAAAAAAAAAAEAAAAFAAAASQAAADAzuweIkAAwSAAAAAAAAAABAAAA BAAAAAAAAAAAAIABiJAAMEgAAAAAAAAAAgAAAAIAAAAAAAAAAACAAZgAAAAAAAAAAAAAAACA AAAAgAAAAAAAAAAAAAeIkAAwTAAAAAAAAAABAAAABQAAAE0AAACgM7sHiJAAMEwAAAAAAAAA AQAAAAQAAAAAAAAAAACAAYiQADBMAAAAAAAAAAIAAAACAAAAAAAAAAAAgAGYAAAAAAAAAAAA AAAAgAAAAIAAAACAAAAAAAABmAAAAAAAAAAAAAAAAIAAAACAAAAAgAAAAAAQAZgAAAAAAAAA AAAAAACAAAAAgAAAAIAAAAAAEAGYAAAAAAAAAAAAAAAAgAAAAIAAAACAAAAAABAHmAAAAAAA AAAAAAAAAIAAAACAAAAAgAAAAAAAB4iQADBUAAAAAAAAAAEAAAAFAAAAVQAAADS08AeIkAAw VAAAAAAAAAABAAAABAAAAAAAAAAAAIABiJAAMFQAAAAAAAAAAgAAAAIAAAAAAAAAAACAAZgA AAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAH iJAAMFkAAAAAAAAAAQAAAAUAAABaAAAAwLTwB4iQADBZAAAAAAAAAAEAAAAEAAAAAAAAAAAA gAGIkAAwWQAAAAAAAAACAAAAAgAAAAAAAAAAAIABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAA AAAAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAgAAAAIAAAAAA AAAAABABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAYiQADBgAAAAAAAAAAEAAAAFAAAA YQAAAIS18AeIkAAwYAAAAAAAAAABAAAABAAAAAAAAAAAAIABiJAAMGAAAAAAAAAAAgAAAAIA AAAAAAAAAACAAZgAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYAAAAAAAAAAAAAAAAgAAA AIAAAAAAAAAAABABmAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAQAZgAAAAAAAAAAAAAAACA AAAAgAAAAAAAAAAAAAeYAAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHiNAAMAAAAAAAAAAA AQAAAAAAAAAA+AAAAAAAB4jQADABAAAAAAAAAAEAAAACAAAAAAAAAAAAgAGI0AAwAAAAAAAA AAABAAAAAAAAAAAAAAAAAIABiNAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAYjQADAEAAAA AAAAAAEAAAACAAAAAAAAAAAAgAGI0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIABiNAAMAAA AAAAAAAAAQAAAAAAAAAAAAAAAACAAYjQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGI0AAw AAAAAAAAAAABAAAAAAAAAAAAAAAAAIABiNAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAYjQ ADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGI0AAwCwAAAAAAAAABAAAAAgAAAAAAAAAAAIAB iNAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAYjQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA gAGI0AAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIABiNAAMAAAAAAAAAAAAQAAAAAAAAAAAAAA AACAAYjQADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAgAGI0AAwAAAAAAAAAAABAAAAAAAAAAAA AAAAAIABiNAAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAYjQADAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAgAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACA AAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGI0AAwFwAAAAAAAAABAAAA AgAAAAAAAAAAAIABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAZhAAAAAAAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAA AIAAAACAAAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAYjQADAfAAAA AAAAAAEAAAAGAAAAAAAAAAAAAAGI0AAwHwAAAAAAAAABAAAABAAAAAAAAAAAAAABiNAAMCEA AAAAAAAAAQAAAAYAAAAAAAAAAAAAAYjQADAfAAAAAAAAAAEAAAAEAAAAAAAAAAAAAAGI0AAw IwAAAAAAAAABAAAABgAAAAAAAAAAAIABiNAAMB8AAAAAAAAAAQAAAAQAAAAAAAAAAAAAAYjQ ADAfAAAAAAAAAAEAAAAEAAAAAAAAAAAAAAGI0AAwHwAAAAAAAAABAAAABAAAAAAAAAAAAAAB iNAAMB8AAAAAAAAAAQAAAAQAAAAAAAAAAAAAB5hAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAA AAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAA AAAAAAAHmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAYjQADAuAAAAAAAAAAIAAAABAAAA AAAAAAAAgAEAQAAAAIAAAACAAAAAAAAAAAAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACA AAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAAAAAAgAAA AIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAZhAAAAAAAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAA AIAAAACAAAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAA AAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAZhAAAAAAAAA AAAAAACAAAAAgAAAAAAAAAAAAAGI0AAwOwAAAAAAAAABAAAAAgAAAAAAAAAAAAABmEAAAAAA AAAAAAAAAIAAAACAAAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYQAAA AAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAZhA AAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAAB mEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAA AAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAA AAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAGI0AAwRwAAAAAAAAABAAAAAgAAAAAA AAAAAIABmEAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAAAAYjQADBJAAAAAAAAAAEAAAACAAAA AAAAAAAAgAGYQAAAAAAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmEAAAAAAAAAAAAAAAIAAAACA AAAAAAAAAAAAAZhAAAAAAAAAAAAAAACAAAAAgAAAAAAAAAAAAAcIAAAAAAAAAAAAAAAAAAAA AAAZMAUVAAAAAAAHAAYAAKFpAABjswAAdhoBAIXXAQDsAAAABgEAAB0BAAA8AQAAAAYAAAoN AAABEAAACRYAAGkcAADWIwAA2CQAACksAADkMAAA4zMAAKc1AABGOgAA1zwAAONAAACBRAAA nkQAAIZHAACfSQAAtksAAEdPAAD2VAAAh1kAADxgAAAnZQAAuWsAAPhuAAAVbwAAonQAACd1 AAAFeAAAs3gAADp8AACZgAAA4YQAAIiIAACXjQAABo8AAPaSAAAJlwAAvpwAAKygAAAOogAA X6QAAAqoAAAYrQAAXrAAAPWzAABLtgAAkbkAAHW8AABTvwAAcL8AADHDAABMxQAAn8cAAKHN AACO0AAAkNMAAD7UAABR2AAAiNwAAFviAABd5wAABu0AAM3vAAAg9AAAEfYAADv6AACQ/gAA MAQBAD0HAQCPCwEAFQ4BAPwQAQBzEwEAWRYBAHoaAQDFHQEA4h0BAIYgAQBfIwEAViYBAF0o AQCiKgEALywBANYuAQCoMAEARDMBACs2AQB8OAEA0zoBAFw7AQBtPAEAKz8BAFFAAQDKQgEA CUUBAA1HAQAgSQEAHkwBAAtPAQCETwEA2lIBAHhUAQCMVgEAeVkBADxdAQASXwEAE2ABADBg AQCtYwEAFGgBAGVsAQDsbQEA73EBAAx1AQBeeAEAW3sBAFl+AQAegQEAs4MBAHmGAQDriAEA posBACqOAQCRkAEAQpQBAN+WAQDHmQEAu5wBAGafAQAMogEA56QBAIqnAQBqqgEA36wBAKuv AQB2sgEATbUBAIS2AQChtgEAp7gBADu6AQBvvwEA9sIBADPMAQBz0wEAhdcBAO0AAADvAAAA 8AAAAPEAAADyAAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP0A AAD+AAAA/wAAAAABAAABAQAAAgEAAAMBAAAEAQAABQEAAAcBAAAIAQAACQEAAAoBAAALAQAA DAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEAABYBAAAXAQAAGAEAABkB AAAaAQAAGwEAABwBAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAA KAEAACkBAAAqAQAAKwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUB AAA2AQAANwEAADgBAAA5AQAAOgEAADsBAAA9AQAAPgEAAD8BAABAAQAAQQEAAEIBAABDAQAA RAEAAEUBAABGAQAARwEAAEgBAABJAQAASgEAAEsBAABMAQAATQEAAE4BAABPAQAAUAEAAFEB AABSAQAAUwEAAFQBAABVAQAAVgEAAFcBAABYAQAAWQEAAFoBAABbAQAAXAEAAF0BAABeAQAA XwEAAGABAABhAQAAYgEAAGMBAABkAQAAZQEAAGYBAABnAQAAaAEAAGkBAABqAQAAawEAAGwB AABtAQAAbgEAAG8BAABwAQAAcQEAAHIBAABzAQAAdAEAAHUBAAB2AQAAdwEAAHgBAAB5AQAA egEAAHsBAAB8AQAAfQEAAH4BAAB/AQAAgAEAAIEBAACCAQAAgwEAAAAGAACE1wEA7gAAAP// LQAAAAYA5NkIABAAAQCkH7kCBgDl2QgAEQABAEQbuQIGAObZCAARAAEAxBu5AgYA59kIABEA AQAEG7kCBgDo2QgAEAABAIQbuQIGAOnZCAAQAAEABBy5AgYA6tkIABEAAQDU+rgCBgDr2QgA EQABABT7uAIGAOzZCAARAAEAVPu4AgYA7dkIABAAAQCk9rgCBgDu2QgAEAABAGT2uAIGAO/Z CAARAAEARAWxAgYA8NkIABAAAQCc3K8CBgDx2QgAEQABAJzFHAAGAPLZCAARAAEAjKGsAgYA 89kIABAAAQBcxhwABgD02QgAEQABAGzTuQIGAPXZCAAQAAEA1EqxAgYA9tkIABEAAQBkfqwC BgD32QgAEAABAERougIGAPjZCAAQAAEAxIC5AgYA+dkIABEAAQDMNLoCBgD62QgAEAABAAyK sAIGAPvZCAARAAEA9KkjAAYA/NkIABAAAQA0CbkCBgD92QgAEQABALzyIwAGAP7ZCAAQAAEA BIQbAAYA/9kIABEAAQDsG44IBgAA2ggAEQABAPQuGAAGAAHaCAAQAAEAzDG5AgYAAtoIABAA AQAMQh0ABgAD2ggAEQABAGw2uQIGAATaCAAQAAEALDa5AgYABdoIABEAAQCMhroCBgAG2ggA EQABAHyJugIGAAfaCAAQAAEADE2wAgYACNoIABAAAQDUoLoCBgAJ2ggAEQABAPQGqwIGAAra CAARAAEAtC4YAAYAC9oIABAAAQBMKLECBgAM2ggACAACALTVGAAGAA3aCAAIAAIAFD0YAAYA DtoIAAgAAgAUPhgABgAP2ggACAACAOyoHAAGABDaCAAIAAIANFcYAK0BAACtAQAAtgEAAIgh AACIIQAATX8AAE1/AABVfwAAKIEAACiBAABHgQAAR4EAAGGBAABhgQAAMYQAADGEAAB0hQAA dIUAAL+IAAC/iAAA4IgAAOCIAAD8iAAA/IgAANiYAADYmAAA8pgAAPKYAAD3nAAA95wAABid AAAYnQAANJ0AADSdAAAQtgAAELYAACq2AAAqtgAARbYAAEW2AADtPgEAJ0EBAKdCAQBtVQEA orEBAIbPAQABAAAAAgAAAAAAAgACAAAAAgADAAAAAgAEAAAAAgAGAAAAAgAFAAAAAgAHAAAA AgAIAAAAAgAJAAAAAgAKAAAAAgALAAAAAgAMAAAAAgANAAAAAgAOAAAAAgAPAAAAAgAQAAAA AgARAAAAAgASAAAAAgATAAAAAgAUAAAAAgAVAAAAAgAWAAAAAgAXAAAAAgAYAAAAAgAZAAAA AgAaAAAAAgAbAAAAAgAcAAAAAgAdAAAAAgAeAAAAAgAfAAAAAgAgAAAAAgAhAAAAAgAiAAAA AgAjAAAAAgAkAAAAAgAlAAAAAgAmAAAAAgAnAAAAAgAoAAAAAQApAAAAAQAqAAAAAQArAAAA AQAsAAAAAQC1AQAAuAEAALgBAACVIQAAlSEAAFN/AABcfwAAXH8AAC+BAAAvgQAAToEAAE6B AABngQAAZ4EAADeEAAA3hAAAeoUAAHqFAADGiAAAxogAAOeIAADniAAAAokAAAKJAADfmAAA 35gAAPiYAAD4mAAA/pwAAP6cAAAfnQAAH50AADqdAAA6nQAAErYAABK2AAAytgAAMrYAAE22 AABNtgAACj8BAERBAQDEQgEAfFUBAL+xAQCGzwEAAQABAAAAAAACAAAAAwAAAAQAAAAGAAEA BQAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMA AAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAA IQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAABwAAAD0A AAArAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MJgFBs YWNlVHlwZQCAPQAAACwAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNt YXJ0dGFncwmAUGxhY2VOYW1lAIA+AAAABQAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNv bTpvZmZpY2U6c21hcnR0YWdzCoBQZXJzb25OYW1lAIA5AAAALQAAACqAdXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCAQgAAACoAAAAqgHVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncw6AY291bnRyeS1yZWdpb24A gDgAAAAnAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3ME gENpdHkAgDkAAAAiAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MFgFN0YXRlAIAMAAABdKzYAQAAAAAtAAAAAAAsAAAAAAArAAAAAAAqAAAAAAAtAAAA AAAtAAAAAAAnAAAAAAAqAAAAAAAqAAAAAAAtAAAAAAAtAAAAAAAiAAAAAAAtAAAAAAAnAAAA AAAnAAAAAAAtAAAAAAAnAAAAAAAtAAAAAAAqAAAAAAAtAAAAAAAtAAAAAAAiAAAAAAAtAAAA AAAnAAAAAAAtAAAAAAAiAAAAAAAtAAAAAAAnAAAAAAAqAAAAAAAtAAAAAAAtAAAAAAAiAAAA AAAtAAAAAAAnAAAAAAAqAAAAAAAtAAAAAAAtAAAAAAAiAAAAAAAiAAAAAAAtAAAAAAAFAAAA AAAFAAAAAAAFAAAAAAAFAAAAAAAFAAAAAAD//xYACgAAAAAB5lIyCv////8AAAAB1FkyCv// //8AAAAB7lsyCv////8AAAAB41wyCv////8AAAABAV8yCv////8AAAABI2AyCv////8AAAAB B2EyCv////8AAAABfGIyCv////8AAAABLDwzCv////8AAAABKz0zCv////8AAAABJz4zCv// //8AAAABn0AzCv////8AAAAB40EzCv////8AAAABJEIzCv////8AAAABcEEzCv////8AAAAB /kAzCv////8AAAABe0UzCv////8AAAABmkYzCv////8AAAABb0czCv////8AAAABDWUzCv// //8AAAAB22czCv////8AAAABzmkzCv////9hIAAAC0EAACNQAACrVAAA0FUAACtdAACbYQAA 1GsAAAtvAADqcQAAmpAAAP6hAADUpAAAYqYAAHenAAC7pwAAKqoAAFurAABBtgAA6t0AAB/9 AABvEgEA+LoBAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAA CwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAABlIAAAjUEAAChQ AACvVAAABVYAABleAAChYQAA3WsAABJvAADycQAAoJAAAAWiAADdpAAAZKYAAIKnAAC/pwAA U6oAAGOrAABStgAA8d0AACT9AAB2EgEA+LoBAAAAAAAdAQAAJgEAAKICAACmAgAAdwUAAIAF AADZBwAA3QcAAKEIAAClCAAAAwoAAAcKAAC+CgAAxgoAANgKAADjCgAAigsAAJULAAAhDAAA MAwAALcMAADPDAAAGQ0AACYNAABbDQAAXg0AABEOAAAdDgAAgg4AAI0OAADdDwAA6A8AAK8R AADCEQAAcxIAAIUSAADYEgAA6hIAAAwTAAAYEwAAYRMAAHcTAAD3EwAA+xMAALgWAAC8FgAA VBgAAFwYAAByGAAAdhgAALsYAAC/GAAABBkAAAgZAABYHAAAXBwAAOgfAADsHwAAuiAAAL4g AADJIAAAzCAAAGohAABuIQAA5yEAAO8hAAAuIgAAMiIAAF4iAABiIgAAniIAAKIiAADEIgAA zCIAAPUiAAD5IgAAKiMAAC4jAACTIwAAlyMAADokAAA+JAAAyCQAAMwkAABRJQAAVSUAAP4l AAACJgAA5ycAAOsnAADrKAAA7ygAAP4oAAACKQAAECkAABQpAACQKQAAlCkAAAMqAAAHKgAA iyoAAI8qAACoKgAArCoAAGEsAABlLAAAIS4AACUuAAAuLgAAMi4AABgvAAAcLwAASi8AAE4v AABpLwAAbS8AAIEvAACFLwAAqC8AAKwvAADFLwAAyS8AAOQvAADoLwAA/y8AAAMwAAAjMAAA JzAAAKAwAACkMAAAQDEAAEQxAADRMQAA1TEAAIAyAACIMgAAgTMAAIUzAADRMwAA1TMAAB00 AAAoNAAALzQAAEI0AABNNAAAUTQAAGs0AABvNAAApTUAALc1AAC+NQAA2DUAAOM1AADnNQAA QDYAAEI2AABUNgAAYDYAAGc2AAB7NgAApjYAAKo2AADWNgAA2jYAAA43AAAkNwAAKzcAAEk3 AABUNwAAWDcAAP03AAABOAAAzjoAANI6AAAWPQAAGj0AAEM9AABHPQAAaT0AAG09AACMPgAA kD4AAFtAAABlQAAAx0AAANBAAAAdQQAAIUEAAORBAADoQQAAGEIAABxCAAB4QgAAfEIAAF5D AABiQwAAmEMAAJxDAAArRAAAL0QAAKREAACoRAAAWkUAAGJFAABpRQAAdEUAAJ5FAACmRQAA sUUAALxFAAARRwAAGUcAADlHAABERwAAbUcAAHFHAADcRwAA5EcAAAFJAAAMSQAAeUkAAIFJ AADSSQAA2kkAAOJJAADrSQAAM0oAADtKAAABSwAACksAABRLAAAcSwAAQUwAAElMAADxTQAA 9U0AAO9PAADzTwAAAFAAAAhQAABTUAAAXlAAAHpQAACFUAAA/1AAAAdRAAARUgAAFVIAAPtS AAD/UgAAKlQAAD9UAADtVQAA/FUAAL9XAADOVwAAM1gAADtYAAByWAAAgVgAAPNYAAD3WAAA wloAANFaAAA4WwAAR1sAAHFbAACAWwAAt1wAAMZcAAD/XAAAF10AAGteAACDXgAAnl4AAKJe AABSXwAAZF8AAMpfAADZXwAAHmAAACJgAACMYAAApGAAAChkAAAsZAAAcWQAAH5kAAC8ZAAA yWQAAHtlAAB+ZQAAwmUAAMVlAACCZwAAhmcAALZoAAC6aAAAImkAACZpAACgawAAp2sAADhs AAA8bAAAk2wAAJdsAAClbAAAwGwAAEltAABNbQAAqm0AALZtAADjbwAA728AAItwAACPcAAA 4XAAAOxwAAAHcQAAEnEAADZxAAA6cQAAsXIAAMdyAAD6cgAABXMAAAtzAAAQcwAARnMAAFlz AABgcwAAb3MAAOlzAADwcwAAbHQAAIJ0AACTdAAAnnQAAL90AADKdAAAFXYAABl2AACIdwAA j3cAAM93AADTdwAARngAAEp4AACdeAAAsHgAALF4AAC2eAAA7HgAAP94AAA9eQAASHkAAG95 AACEeQAAjXkAAJV5AADCeQAAzXkAAM55AADWeQAAD3oAABp6AAAsegAAQnoAAFV6AABkegAA kXoAAJh6AAA7fAAASnwAAFR8AABXfAAAe3wAAH58AACjfAAAsHwAALZ8AADDfAAA9XwAAAp9 AAAifQAAMn0AAEl9AABVfQAAc30AAIZ9AACjfQAAtn0AANd+AADtfgAA0X8AANV/AAAogAAA M4AAADSAAAA5gAAAb4AAAH6AAADHgAAA04AAAN2AAADigAAAxYEAANGBAADygQAACIIAABiC AAAjggAAQoIAAE2CAABBgwAASYMAAEqDAABbgwAAmIMAAJyDAACghAAAu4QAAP6EAAAFhQAA F4YAABuGAABuhgAAgYYAAIKGAACHhgAA44YAAO6GAAA3hwAAP4cAAGyHAAB3hwAAeIcAAICH AACQhwAAmIcAAJmHAACqhwAAtIcAAL+HAADRhwAA54cAAPqHAAAJiAAAHIgAAE2IAABaiAAA ZogAAHKIAAB3iAAALYkAADmJAABEiQAAU4kAAF2JAABgiQAAjYkAAJCJAAC+iQAAy4kAANGJ AADeiQAAQYoAAFyKAABzigAAf4oAAJ6KAACxigAAy4oAAN6KAAAPiwAAGosAAC2LAAA4iwAA LYwAADiMAAD4jQAA/I0AAN2OAADhjgAALY8AADGPAACgjwAApI8AAJqQAACgkAAA75AAAPOQ AAD1kAAAAJEAAAqRAAAgkQAAMJIAADSSAACLkgAAkpIAANGSAADVkgAA6ZMAAPuTAAALlAAA EpQAAFeUAABmlAAAfZQAAIiUAABslQAAfJUAAECXAABElwAAl5cAAKKXAAColwAArZcAAOiX AAD4lwAABZgAABSYAABdmAAAaZgAAHOYAAB4mAAAVpkAAGKZAACDmQAAmZkAAKmZAAC0mQAA ypkAANWZAACImgAAjJoAAN+aAADymgAA85oAAPiaAABUmwAAX5sAAIabAACbmwAApJsAAKyb AADZmwAA5JsAAOWbAADtmwAA/ZsAAAWcAAAGnAAAF5wAACGcAAAsnAAAPpwAAFScAABnnAAA dpwAAJKcAACenAAAqpwAAK+cAABlnQAAcZ0AAHydAACLnQAAlZ0AAJidAADFnQAAyJ0AAPad AAADngAACZ4AABaeAAAungAAQJ4AAI2eAACfngAAwZ4AANaeAADungAA/p4AABWfAAAhnwAA QJ8AAFOfAABonwAAe58AAPSfAAAHoAAAmaEAAJ2hAADqoQAA/KEAAPiiAAAIowAACaQAABWk AACKpAAAjqQAANynAADgpwAA1KgAANioAAAmqQAAOKkAAGCpAABzqQAAqKkAALepAACQqgAA oqoAANCqAADqqgAAd6sAAI+rAADqqwAA8asAACSsAAAvrAAANawAADqsAABwrAAAg6wAAKCs AACvrAAAFq0AAB2tAACZrQAAr60AAL+tAADKrQAA3K0AAOetAAC/rgAAw64AABavAAAprwAA Kq8AAC+vAABlrwAAeK8AALavAADBrwAA6K8AAP2vAAAGsAAADrAAADuwAABGsAAAR7AAAE+w AACIsAAAk7AAAKWwAAC7sAAAzrAAAOawAAD4sAAADbEAAEqxAABNsQAAcbEAAHSxAACZsQAA prEAAKyxAAC5sQAA67EAAACyAAAYsgAAKLIAAD+yAABLsgAAabIAAHyyAACRsgAApLIAACCz AAAyswAAM7MAADizAAC8swAAzrMAANmzAADrswAA57QAAOu0AAA+tQAAWLUAAF61AABjtQAA irUAAJm1AACxtQAAvbUAAMW1AADKtQAAXbYAAGm2AABytgAAgbYAAKO2AAC4tgAA0LYAAOC2 AAD2tgAAELcAAOC3AADktwAAHrgAACq4AAAyuAAANrgAAEi4AABMuAAAaboAAH+6AABNuwAA UrsAAEC8AABEvAAA2LwAAOS8AADqvAAA77wAAB69AAAtvQAAPb0AAEm9AABzvQAAf70AALi9 AADMvQAA0b0AANa9AAD8vQAAB74AAA6+AAAnvgAALb4AAEO+AABRvgAAZb4AAGu+AAB+vgAA hL4AAJy+AACivgAAuL4AAL6+AADXvgAA3b4AAPO+AAD5vgAAD78AABW/AAAsvwAAM78AAD6/ AABFvwAAWb8AAIO/AACWvwAADMAAABDAAABWwAAAbMAAAHTAAAB4wAAAisAAAI7AAADewAAA 9MAAAJPBAACewQAAC8MAABfDAADZwwAA3cMAAILEAACGxAAAGcUAADfFAACUxQAAn8UAAOLF AADmxQAAc8YAAInGAACPxgAAlMYAAMrGAADdxgAAQscAAEnHAADExwAA08cAAOPHAAD5xwAA HsgAADTIAACwyAAAtMgAAAfJAAAlyQAAKskAAC/JAABVyQAAYMkAAGfJAACAyQAAhskAAJzJ AACqyQAAvskAAMTJAADXyQAA3ckAAPXJAAD7yQAAEcoAABfKAAAwygAANsoAAEzKAABSygAA aMoAAG7KAACFygAAjMoAAJfKAAC2ygAAy8oAAOHKAADxygAABssAABLLAAAvywAATcsAAHbL AACCywAAFswAABrMAABazAAAXswAAKTMAACzzAAAp9AAALbQAAAv0gAAM9IAAI3TAACc0wAA F9QAABvUAABz1gAAd9YAAIjWAACT1gAAqNgAAMPYAADi2QAA5tkAADPaAABC2gAAitoAAJna AAAB3AAAEtwAAGXeAABp3gAACeIAAB3iAAA84gAAS+IAAAbmAAAK5gAAoeYAAKXmAADt5gAA 8eYAAF7nAABi5wAAOugAAD7oAACR6AAAnOgAAKLoAACn6AAA3egAAPDoAAAN6QAAHOkAAIPp AACK6QAA/OkAAAPqAAC86wAAw+sAAIrsAACR7AAADe0AACPtAAAz7QAAPu0AAF7tAABq7QAA M+4AADfuAACK7gAAne4AAKPuAACo7gAALO8AADfvAABe7wAAc+8AAHzvAACE7wAAse8AALzv AAC97wAAxe8AAP7vAAAJ8AAAG/AAADHwAABE8AAAU/AAAIDwAACH8AAAKvIAADnyAABD8gAA RvIAAJLyAACn8gAAv/IAAM/yAADm8gAA8vIAABDzAAAj8wAAQ/MAAFbzAAAB9AAADvQAABP0 AAAa9AAAG/QAAB70AABo9gAAbPYAABv3AAAq9wAAafcAAG33AAC8+AAAw/gAACT7AAAs+wAA 5vwAAO78AAC2/QAAwv0AACr+AAA2/gAAYP4AAG/+AADv/gAA8/4AAEj/AABM/wAAW/8AAGL/ AABKAgEATgIBAPsCAQADAwEA7AMBAPADAQAUBAEAGAQBABkEAQAbBAEAHAQBACAEAQBpBAEA cwQBAAcGAQAUBgEASgYBAFoGAQCdBgEAuAYBAIoHAQCOBwEAtgcBAMUHAQBjCAEAbQgBALQJ AQC8CQEA+wkBAAYKAQAyCgEANgoBALMKAQDACgEAAAsBABULAQABDAEABQwBAF8MAQBkDAEA kQwBAKEMAQCrDAEAuAwBANEMAQDZDAEAIA0BACcNAQDBDQEAyQ0BAMAOAQDEDgEA7A4BAPMO AQB/DwEAgw8BAD4RAQBFEQEAmREBAJ4RAQDLEQEA2xEBAOoRAQD6EQEALBIBADQSAQBvEgEA dhIBAO8SAQDzEgEAHRMBACETAQAwEwEANBMBAK0TAQCxEwEAwxMBAMcTAQBbFAEAXxQBAKwU AQCwFAEA1RQBAN0UAQAOFQEAEhUBAIIVAQCGFQEAVRYBAFkWAQDJFgEAzRYBANIXAQDWFwEA 5hcBAOoXAQAmGAEAMxgBAJAYAQCbGAEAoBgBAKwYAQCxGAEAxxgBAMwYAQDeGAEA4xgBAPYY AQD7GAEADxkBABQZAQAyGQEANxkBAFEZAQCPGQEAmhkBAKkZAQC0GQEA0BkBAOMZAQDuGQEA AhoBABQaAQAkGgEALxoBADoaAQA+GgEATBoBAHMaAQCCGgEAqBoBALYaAQDtGgEA+BoBAPwa AQAKGwEAIhsBAC4bAQA5GwEARRsBAEgbAQBcGwEAYRsBAHcbAQDqGwEA7hsBAB8cAQA1HAEA URwBAGQcAQBvHAEAgxwBAKEcAQCsHAEAsBwBAL4cAQDVHAEA5xwBAPYcAQAIHQEACx0BAB0d AQAfHQEALR0BAFkdAQBsHQEAex0BAI4dAQChHQEAsx0BALYdAQDLHQEA1B0BAOgdAQD3HQEA Cx4BAA4eAQAZHgEAGx4BADAeAQA1HgEAUx4BAGIeAQCAHgEAiR4BAJQeAQCWHgEAqx4BALQe AQDOHgEA3R4BAPceAQAAHwEADx8BABEfAQAmHwEAcB8BAIQfAQCXHwEApR8BAN8fAQD0HwEA CCABABYgAQBGIAEAWSABAMwgAQDQIAEA+SABAAchAQAdIQEAJiEBAEIhAQBNIQEAfCEBAIsh AQCWIQEApSEBAKghAQC7IQEA9CEBAAwiAQAbIgEAMyIBAEQiAQBWIgEAWCIBAGYiAQBvIgEA gSIBAJQiAQCdIgEAUyMBAGEjAQC3IwEAwyMBAPYjAQD7IwEADCQBABUkAQAfJAEAKCQBAJwk AQCgJAEALCUBADclAQBCJQEATCUBAGAlAQBoJQEAayUBAHclAQCaJQEAqSUBAKwlAQDEJQEA 1iUBANklAQDcJQEA5iUBAPklAQAGJgEAESYBABsmAQBFJgEAUyYBAHQmAQB/JgEAgiYBAI4m AQCwJgEAuCYBALsmAQDEJgEACicBABwnAQArJwEAPScBAFYnAQBfJwEAfCcBAIUnAQCkJwEA rScBALgnAQDGJwEABigBABQoAQAcKAEAJigBAC8oAQA8KAEARSgBAFgoAQDKKAEAzigBAAwp AQAUKQEAKikBAD8pAQBIKQEAVSkBAF4pAQBpKQEAcikBAIEpAQCKKQEApSkBAK0pAQC7KQEA 5CkBAPIpAQAVKgEAIyoBAHQqAQB+KgEAiioBAJgqAQCbKgEApSoBALAqAQC6KgEAvSoBAMcq AQDMKgEA2SoBAOQqAQDxKgEA9CoBAP4qAQADKwEAFisBACErAQA0KwEANysBAEErAQBmKwEA cCsBAHUrAQB9KwEAiCsBAJArAQCTKwEAnSsBALgrAQDCKwEAxysBANwrAQDnKwEA/CsBAP8r AQAJLAEADiwBABssAQAmLAEAMywBADYsAQBALAEARSwBAFAsAQBbLAEAZiwBAGksAQBzLAEA eCwBAIcsAQCSLAEAoSwBAKQsAQCuLAEAsywBAM4sAQDdLAEA+CwBAAstAQAeLQEAIS0BAC0t AQA3LQEAQS0BAAMuAQAHLgEAaS4BAHguAQCfLgEArS4BAAcvAQARLwEAJC8BACwvAQAvLwEA Oy8BAF4vAQBoLwEAbi8BAH0vAQCELwEAji8BAN0vAQDsLwEA8S8BAPwvAQALMAEAFjABACYw AQAwMAEAyjABAM4wAQDhMAEA6DABAAkxAQATMQEAhDEBAI4xAQCiMQEArDEBAHwyAQCAMgEA 9TIBAAMzAQAGMwEADTMBADYzAQA9MwEA3jMBAOIzAQA4NAEAPDQBAEQ1AQBPNQEA3TUBAOE1 AQBmNgEAajYBAL82AQDDNgEAqzcBAK83AQB3OAEAezgBAAM6AQALOgEA4zoBAOs6AQAoOwEA LzsBANw7AQDgOwEA6zwBAO88AQBoPgEAbz4BACtAAQAvQAEAkkABAJZAAQAYQgEAHEIBAHJD AQB3QwEA4EMBAOxDAQAHRAEAC0QBAEpEAQBORAEAjEQBAJBEAQCxRQEAtUUBAOlFAQDtRQEA WkYBAF5GAQD8RwEAAEgBANFIAQDVSAEA5EgBAOhIAQBGSQEASkkBAF1JAQBpSQEA7kwBAPJM AQCWTQEAmk0BAMROAQDPTgEAY1ABAGdQAQClUAEAqVABAN1QAQDoUAEA6VABAO1QAQBHUQEA TFEBAGpSAQBuUgEA7FIBAPBSAQCeUwEAolMBAEtUAQBSVAEA0FQBANtUAQDdVAEA5FQBAApW AQAOVgEAhFcBAIhXAQCgWAEApFgBAABZAQAHWQEAI1kBACdZAQB6WQEAgFkBAIxZAQCWWQEA 21kBAN9ZAQAjWgEAKVoBADpaAQBBWgEAR1oBAE9aAQDzWwEA+lsBAPVdAQD5XQEAh14BAI1e AQCdXgEApF4BAOleAQDvXgEAF18BAB5fAQDYXwEA318BAIJgAQCGYAEAUmIBAFViAQAQZgEA FGYBAM9mAQDUZgEA/mYBAAVnAQA/ZwEATmcBAIxnAQCbZwEA0GcBANRnAQDhZwEA5WcBACFo AQAuaAEAg2gBAJJoAQCuaAEAuWgBAMxoAQDYaAEA62gBAAFpAQAUaQEAJmkBADlpAQBMaQEA X2kBAHNpAQCGaQEApGkBALdpAQDRaQEAMGoBAD9qAQBgagEAb2oBAIdqAQCSagEArWoBALhq AQDHagEA0GoBABNrAQAmawEAUGsBAFlrAQBxawEAhWsBAL5rAQDOawEA7GsBAPNrAQAIbAEA FmwBAB5sAQAsbAEA5WwBAOlsAQAsbQEAO20BAM9tAQDdbQEA6W0BAPdtAQCFbgEAjG4BAKNu AQCxbgEAuW4BAMduAQA1bwEAQW8BAFxvAQBobwEAgW8BAJVvAQDVbwEA628BAAZwAQAccAEA K3ABADVwAQB4cAEAi3ABALVwAQC/cAEA13ABAOtwAQBLcQEAUnEBAGdxAQB1cQEAfHEBAIpx AQD4cQEACnIBACVyAQA3cgEAUHIBAGJyAQB9cgEAi3IBADJzAQA2cwEAbnMBAH1zAQCgcwEA r3MBAMhzAQDbcwEA9nMBAAl0AQAYdAEAIXQBAFR0AQBddAEAjXQBAJ90AQDRdAEA5nQBACd1 AQA7dQEAVnUBAGp1AQCDdQEAjnUBAKl1AQC+dQEA/3UBAB12AQA4dgEAVnYBAG92AQB6dgEA lXYBAKp2AQDqdgEABHcBAB93AQA5dwEAUncBAGF3AQB7dwEAkHcBANt3AQDqdwEAJ3gBADZ4 AQCpeAEArXgBAOd4AQD7eAEAenkBAIh5AQC+eQEAzXkBAAB6AQAPegEAJ3oBADx6AQBJegEA U3oBAIN6AQCNegEAwHoBAMx6AQDlegEA83oBACl7AQA4ewEAYXsBAHB7AQCIewEAm3sBAKh7 AQCxewEAyXsBANd7AQDmewEA73sBAAN9AQASfQEAN30BAEZ9AQC4fQEAvH0BAPZ9AQAFfgEA En4BABt+AQA3fgEARn4BAGF+AQB0fgEAmn4BAKN+AQDWfgEA5X4BABR/AQAjfwEAO38BAFN/ AQBvfwEAh38BAMF/AQDTfwEA7n8BAPx/AQA8gAEAToABANqAAQDpgAEAYIEBAG+BAQC5gQEA woEBACWCAQAzggEAXYIBAGaCAQD9ggEAAYMBAEaDAQBVgwEAYIMBAGyDAQCXgwEAn4MBAK+D AQC+gwEA1oMBAOKDAQD9gwEACYQBAK2EAQC8hAEA4IQBAO+EAQBihQEAaoUBABmGAQAohgEA NYYBADqGAQBJhgEAWIYBAHCGAQB5hgEAmIYBAKKGAQC9hgEAwoYBANOGAQDdhgEAiYcBAI2H AQC6hwEAyYcBAPyHAQALiAEAW4gBAGWIAQCDiAEAjogBANaIAQDeiAEAS4kBAFWJAQC/iQEA zokBAOyJAQAEigEAQooBAEyKAQBqigEAbYoBAIuKAQCRigEAuooBAMSKAQD4igEABYsBAD6L AQBDiwEAXYsBAGKLAQDAiwEAzosBAA+MAQAajAEANowBAD6MAQCXjAEAn4wBAKGNAQCljQEA 3Y0BAOyNAQAUjgEAI44BADuOAQBNjgEAaI4BAHqOAQDRjgEA2o4BAGSPAQBtjwEA+Y8BAAKQ AQBMkAEAWpABAKOQAQCykAEA5ZABAPSQAQAMkQEAGpEBAGGRAQBrkQEAtZEBAMKRAQAMkgEA H5IBALySAQDEkgEAOZMBAD2TAQD1kwEACpQBAFSUAQBhlAEAq5QBALaUAQAAlQEAD5UBAFmV AQB0lQEAu5UBAMmVAQBUlgEAYpYBAOaWAQD0lgEAP5cBAE6XAQBvlwEAfpcBAJaXAQCglwEA rZcBALyXAQDjlwEA8pcBAIOYAQCHmAEAwJgBAM6YAQD6mAEABJkBAB+ZAQApmQEAQpkBAEyZ AQCLmQEAmJkBALOZAQDAmQEA2ZkBAOOZAQAimgEANZoBAFCaAQBjmgEAfJoBAIaaAQALmwEA FZsBAFSbAQBcmwEAd5sBAH+bAQCYmwEAopsBAB2cAQAnnAEAZ5wBAHycAQCXnAEArJwBAMWc AQDPnAEADp0BABudAQA2nQEAQ50BAFydAQBmnQEA2p0BAN6dAQA+ngEASZ4BAGSeAQBvngEA iJ4BAJKeAQDRngEA4J4BAPueAQAKnwEAI58BAC2fAQBsnwEAh58BAKKfAQC9nwEA3J8BAO+f AQBGoAEAUKABAJqgAQCpoAEAx6ABANagAQADoQEAEqEBADuhAQBKoQEArKEBALuhAQAxogEA P6IBAPKiAQD2ogEAI6MBADKjAQBcowEAa6MBADmkAQBBpAEAMKUBADalAQCMpQEAm6UBAMil AQDNpQEA/qUBAAOmAQB/pgEAjqYBANCmAQDbpgEA96YBAAKnAQAlpwEAL6cBAEynAQBSpwEA ZqcBAHCnAQAnqAEAK6gBAGOoAQByqAEA1KgBAOOoAQD7qAEAAqkBAA+pAQAeqQEAQqkBAEap AQBdqQEAbKkBAI2pAQCUqQEAvKkBAMKpAQD3qQEA/akBACSqAQArqgEAQ6oBAE2qAQCNqgEA l6oBAKSqAQCzqgEAHasBACyrAQA4qwEAQqsBAH+rAQCGqwEAo6sBAK2rAQDyqwEA+asBAEus AQBVrAEAfqwBAIysAQCZrAEAqKwBACWtAQA0rQEAQK0BAEqtAQC8rQEAwK0BAPutAQACrgEA Eq4BAByuAQAOrwEAEq8BAKCvAQCprwEAC7ABABawAQBdsgEAYbIBAPa6AQA9uwEARrsBAJK7 AQCWuwEAR7wBAEu8AQCjvAEAp7wBAEK9AQBGvQEA874BAPe+AQDkvwEA6L8BAPbFAQD6xQEA askBAILJAQCUyQEAqckBAFvKAQBfygEA2coBAN3KAQBVzgEAWc4BAInOAQCNzgEAr84BALPO AQB5zwEAgs8BAIbPAQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA GwAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHAAMABwADAAcAAwAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAMABwADAAcAAwAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAMABwAAAAAArQEAALgBAADpAgAABQMAAGUD AABvAwAAqgMAAK4DAADwAwAA9QMAAHoEAACvBAAAvgQAAMMEAAABBQAACAUAAFYFAABZBQAA ngUAAKIFAADgBQAA6AUAAEwHAABPBwAAbAcAAHoHAABUCAAAXwgAAJkIAACgCAAA2ggAAO4I AACWCgAAnAoAANgKAADjCgAAHQsAACcLAABmCwAAcwsAAK8LAAC1CwAA+AsAAAMMAACDDAAA jQwAALcMAADPDAAA/AwAAAINAABFDQAATw0AABEOAAAdDgAAow4AAK4OAADsDgAA9w4AADkP AABDDwAAgg8AAIoPAADHDwAA1A8AABQQAAAaEAAAXRAAAGsQAACmEAAAshAAAO8QAAD5EAAA OBEAAEURAAB9EQAAihEAAK8RAADCEQAA+BEAAAMSAABBEgAASRIAAHMSAACFEgAAihMAAJgT AAC3FAAA3RQAAAAVAAAdFQAA+xoAAAYbAADrGwAA+RsAAGsdAAByHQAAsx0AAL0dAAD7HQAA DR4AAD4eAABFHgAAhR4AAJEeAADJHgAA0B4AABEfAAAeHwAAVB8AAFofAADgHwAA5x8AAG4g AABxIAAA9SAAAP4gAAA+IQAAQSEAAIQhAACHIQAAyyEAANIhAABQIgAAXCIAAJIiAACbIgAA 1yIAAN4iAAAcIwAAJyMAAF4jAABmIwAAnyMAAKcjAADlIwAA7CMAADAkAAAyJAAAayQAAHUk AACvJAAAuiQAABElAAAWJQAAWSUAAGElAAChJQAApiUAAG8mAAB4JgAA9CYAAPsmAAA4JwAA QScAAHonAACIJwAAEygAABooAAChKAAAqygAAOcoAADqKAAAKCkAADApAACsKQAAtykAAPQp AAD7KQAAOyoAAEEqAACDKgAAiioAAMoqAADMKgAADysAABUrAABWKwAAWSsAAJ4rAACnKwAA 9CsAAAIsAABHLQAATy0AAPQtAAD+LQAAPS4AAEMuAACGLgAAii4AAM8uAADRLgAAaS8AAG0v AACSLwAAmi8AAOQvAADoLwAAEDAAABgwAABPMAAAWDAAANwwAADiMAAAIjEAACwxAACXMQAA nDEAAOAxAADhMQAAJzIAADEyAACkMgAArjIAABQzAAAiMwAADTQAABY0AAAdNAAAKDQAAJQ0 AACXNAAA3TQAAOI0AAAjNQAAKjUAAKU1AAC3NQAAJjYAAC42AABUNgAAYDYAAKY2AACqNgAA yzYAANM2AAAONwAAJDcAAJk3AAChNwAA4jcAAOs3AACtOAAAsTgAAOo4AAD2OAAANDkAADg5 AAB6OQAAfzkAAJY5AACaOQAAyzkAAM85AAASOgAAFjoAAFE6AABcOgAAYToAAG86AACCOwAA iTsAAMo7AADROwAATzwAAFU8AACpPAAAtzwAALA9AAC3PQAA5j0AAP89AABNPgAAUz4AAJQ+ AACbPgAA2z4AAOI+AAAkPwAAKT8AANI/AADVPwAAF0AAACBAAAArQAAAN0AAAElAAABQQAAA tUAAALxAAAAdQQAAIUEAAFJBAABUQQAA5EEAAOhBAABYQgAAWkIAAFtCAABeQgAAeEIAAHxC AABeQwAAYkMAAL5DAADMQwAAukQAAMFEAAABRQAACUUAADJFAAA4RQAAzEUAANRFAAATRgAA FkYAAFtGAABiRgAAoUYAAKRGAADnRgAA7kYAADBHAAA0RwAAbUcAAHFHAACPRwAAmkcAACBI AAAiSAAAZEgAAG5IAADwSAAA9kgAAEFJAABISQAAh0kAAIpJAADNSQAA0UkAAAlKAAAXSgAA S0oAAFVKAADASgAAx0oAAAFLAAAKSwAA0EsAANdLAAAkTAAAUEwAAG1MAABvTAAAQU0AAENN AACETQAAkk0AAB1OAAAjTgAAZk4AAGpOAACuTgAAsk4AAPNOAAD3TgAAO08AAENPAACDTwAA kU8AAMRPAADOTwAADFAAABNQAAAvUAAAPFAAAK9QAAC1UAAA9VAAAPlQAAA9UQAAQFEAAFhR AABeUQAA01EAANpRAAAZUgAAH1IAAKJSAAClUgAA51IAAPBSAAAuUwAANVMAAKdTAACpUwAA 6lMAAO1TAAAqVAAAP1QAAG9UAAB4VAAAuFQAAMBUAAD5VAAAAFUAAD9VAABBVQAAiFUAAI5V AADEVQAAz1UAAFRWAABZVgAAmFYAAKBWAADYVgAA4VYAAB9XAAAjVwAAZ1cAAGtXAACvVwAA sVcAAPZXAAD4VwAAQFgAAENYAACGWAAAlFgAAB9ZAAAmWQAAaFkAAG9ZAACwWQAAtFkAAPZZ AAD+WQAAP1oAAEtaAADCWgAA0VoAAAZbAAALWwAAWVsAAGBbAACgWwAApVsAAOVbAADuWwAA LFwAADZcAAB0XAAAelwAALdcAADGXAAA1lwAAOBcAAB0XQAAd10AALpdAADEXQAAAV4AAApe AABKXgAAUl4AAJFeAACWXgAA0F4AANteAAAWXwAAG18AAFJfAABkXwAAxV8AAMhfAAAOYAAA F2AAAFNgAABZYAAAjGAAAKRgAAAJYQAADGEAAFBhAABaYQAAmGEAAJphAADiYQAA6mEAAChi AAAsYgAAbmIAAHViAAC2YgAAvGIAAPtiAAAEYwAAPmMAAERjAACHYwAAimMAALtjAADJYwAA VGQAAFpkAADOZAAA1WQAABRlAAAaZQAAWGUAAF9lAABlZQAAb2UAAOJlAADkZQAAGGYAACJm AABeZgAAYmYAAKFmAACpZgAA6mYAAO5mAAAVZwAAI2cAACFoAAAkaAAAZGgAAGxoAACpaAAA s2gAAO5oAADzaAAAeWkAAIFpAADBaQAAyGkAAAVqAAAKagAATmoAAFVqAACkagAAp2oAAO1q AAD1agAAMmsAADtrAADAawAAxGsAACpsAAAwbAAAc2wAAHlsAAClbAAAwWwAANxsAADqbAAA BG4AAAluAABLbgAATW4AAJNuAACZbgAA2W4AAOJuAAAdbwAAI28AAF5vAABlbwAApm8AAKlv AADjbwAA728AAB5wAAAscAAA8nAAAP1wAAA+cQAAS3EAAIBxAACKcQAAyHEAAMpxAADncQAA 8nEAAPpxAAAEcgAAbHIAAHRyAACxcgAAtXIAAM9yAADUcgAAC3MAABBzAABgcwAAb3MAAH1z AACGcwAA1nMAANxzAAAcdAAAIHQAAEV0AABLdAAAZHQAAGx0AAAkdQAAL3UAAGd1AABtdQAA qnUAALF1AADtdQAA83UAADR2AAA3dgAAfHYAAIR2AADFdgAAyXYAAA13AAAQdwAAU3cAAFZ3 AACcdwAAp3cAANl3AADndwAAcngAAHd4AAC7eAAA1HgAABd5AAAeeQAAPXkAAEh5AABneQAA bXkAAI15AACVeQAA0XkAANZ5AAAkegAALHoAAIh6AACQegAAxnoAAM96AADhegAA7HoAAAB7 AAAEewAAMXsAADV7AABiewAAZnsAAJN7AACXewAAxHsAAMh7AAD0ewAA/3sAABB8AAAZfAAA KHwAADB8AACjfAAAsXwAANt8AADffAAAzn0AANZ9AAA7fgAAPn4AAH1+AACIfgAAv34AAMl+ AAAIfwAADX8AAGR/AAByfwAA/X8AAAKAAAA+gAAAV4AAAF6AAABngAAA3YAAAOKAAAAggQAA KIEAAOqBAADygQAArIIAALeCAADvggAA9YIAADKDAAA5gwAAd4MAAHuDAAC+gwAAwYMAAASE AAAKhAAARYQAAEyEAACKhAAAl4QAABGFAAAchQAAWoUAAJWFAACqhQAAuIUAAEOGAABIhgAA jIYAAKWGAAC9hgAAxIYAAOOGAADuhgAADYcAABOHAAA3hwAAP4cAAHuHAACAhwAAyYcAANGH AAATiAAAGogAAHKIAAB3iAAAt4gAAL+IAAC+iQAAzIkAAPaJAAD6iQAABIoAAAeKAAA1igAA OIoAAPmKAAAGiwAAcYsAAHiLAAC0iwAAvosAAPqLAAACjAAACowAABCMAABvjAAAcYwAALmM AAC8jAAA/4wAAAKNAABIjQAAU40AAIuNAACZjQAAJI4AAC+OAABMjgAAWo4AAA6PAAAajwAA do8AAICPAACgjwAApI8AALmPAADAjwAA/Y8AAAaQAABNkAAAVZAAAJCQAACZkAAACpEAACCR AABPkQAAUpEAAJaRAACbkQAAJJIAAC2SAABpkgAAdJIAAKuSAACwkgAAuZIAAMOSAAAYkwAA HZMAAF2TAABmkwAAo5MAAKaTAADpkwAA+5MAAC+UAAAylAAAeJQAAHuUAADBlAAAw5QAAPSU AAABlQAAYZUAAGqVAAColQAAqpUAAOSVAADylQAAJJYAAC6WAABrlgAAcpYAAKyWAACzlgAA 05YAAOGWAABslwAAcZcAAKiXAACtlwAA0pcAANuXAADolwAA+JcAAAWYAAAUmAAAc5gAAHiY AAC2mAAAvpgAAHuZAACDmQAAG5oAACmaAAC0mgAAuZoAAP2aAAAWmwAALpsAADWbAABUmwAA X5sAAH6bAACEmwAApJsAAKybAADomwAA7ZsAADacAAA+nAAAqpwAAK+cAADvnAAA95wAAPad AAAEngAALp4AAECeAABKngAAUJ4AAHGeAAB5ngAAp54AAKueAAC9nwAAyJ8AAM2fAADanwAA D6AAABqgAABhoAAAa6AAAOmgAADroAAALKEAADqhAADHoQAAz6EAAFSiAABXogAAnKIAAJ+i AADkogAA76IAACqjAAAuowAAc6MAAHqjAAC6owAAv6MAAAGkAAADpAAASaQAAE6kAACSpAAA mKQAANSkAADdpAAAG6UAACGlAABdpQAAZaUAAKKlAACmpQAA6qUAAO+lAABppgAAbKYAALGm AAC1pgAA+aYAAPymAAA6pwAAQ6cAALKnAAC2pwAA+KcAAAKoAABBqAAARagAAGeoAAB1qAAA hakAAI2pAADLqQAAzqkAABKqAAAVqgAAkKoAAKKqAADQqgAA6qoAAA6rAAAYqwAAV6sAAFqr AADmqwAA6asAAPmrAAD+qwAANawAADqsAACKrAAAk6wAAKCsAACvrAAAA60AAAmtAABJrQAA Ta0AAHKtAAB4rQAAka0AAJmtAAA1rgAAPq4AAFKuAABgrgAA664AAPCuAAA0rwAATa8AAJCv AACXrwAAtq8AAMGvAADgrwAA5q8AAAawAAAOsAAASrAAAE+wAACdsAAApbAAAPCwAAD2sAAA GLEAABuxAACZsQAAp7EAANGxAADVsQAA5bIAAO6yAAD1sgAA+rIAAD2zAABWswAAX7MAAGKz AAAdtAAAJ7QAAGS0AAButAAAerQAAIi0AAATtQAAGLUAAF61AABjtQAAxbUAAMq1AAAItgAA ELYAAIm2AACNtgAAc7cAAIG3AABIuAAATLgAAHi4AACDuAAAv7gAAMa4AAAHuQAADLkAAEq5 AABRuQAAkrkAAJq5AADYuQAA4LkAAB+6AAAhugAAaboAAH+6AACxugAAtLoAADK7AAA7uwAA wLsAAMy7AACtvAAAsrwAAOq8AADvvAAAFr0AAB69AACNvQAAkr0AANG9AADWvQAA/L0AAAe+ AAAOvgAAEr4AAC2+AAAxvgAAUb4AAFW+AABrvgAAb74AAIS+AACIvgAAor4AAKa+AAC+vgAA wr4AAN2+AADhvgAA+b4AAP2+AAAVvwAAGb8AAJ+/AACtvwAAisAAAI7AAAC7wAAAwMAAAP/A AAAHwQAAQsEAAErBAADSwQAA1sEAABnCAAAkwgAAYcIAAGjCAACmwgAAqsIAAOvCAADvwgAA MsMAADXDAAB6wwAAgMMAANnDAADdwwAA8MMAAPTDAAAxxAAAOsQAAHbEAAB8xAAAv8QAAMLE AAAZxQAAN8UAAGLFAABlxQAApMUAAKvFAAA0xgAAQMYAAEjGAABNxgAAj8YAAJTGAADkxgAA 7cYAADvHAABBxwAAdMcAAHjHAACdxwAAo8cAALzHAADExwAAQ8gAAFHIAADcyAAA4cgAACrJ AAAvyQAAVckAAGDJAABnyQAAa8kAAIbJAACKyQAAqskAAK7JAADEyQAAyMkAAN3JAADhyQAA +8kAAP/JAAAXygAAG8oAADbKAAA6ygAAUsoAAFbKAABuygAAcsoAAJ7KAACiygAAqcsAALfL AACkzAAAs8wAAOrMAADtzAAALM0AADzNAABuzQAAds0AALbNAAC8zQAA+80AAALOAABBzgAA R84AAIvOAACTzgAAz84AANfOAADqzgAA9c4AAP7OAAD/zgAAO88AAEbPAABrzwAAfs8AAIfP AACIzwAAyc8AANLPAAAE0AAACdAAABLQAAAT0AAAV9AAAGDQAAC70AAAw9AAAP/QAAAE0QAA QtEAAErRAACB0QAAi9EAAPLRAAD50QAAL9IAADPSAACg0gAAq9IAAOTSAADs0gAAPNMAAD7T AABG0wAASNMAAI3TAACc0wAAqtMAALjTAACP1AAAktQAANfUAADf1AAAGdUAACHVAABH1QAA UtUAAKrVAACy1QAA89UAAPfVAAAx1gAAPNYAAK7WAAC21gAA+NYAAADXAAA61wAAQ9cAAIDX AACG1wAAxdcAAM/XAABV2AAAW9gAAJvYAACk2AAA5NgAAObYAAAz2QAANtkAAHzZAACA2QAA xdkAAMjZAAAZ2gAAJNoAAF7aAABk2gAAptoAAK7aAADq2gAA89oAAC3bAAA12wAActsAAH3b AAD02wAA+dsAAH7cAACG3AAA+dwAAADdAABA3QAARN0AAIfdAACJ3QAA0N0AANLdAAD43QAA Bt4AANreAADh3gAAHt8AACTfAABk3wAAbN8AAKffAACy3wAA8N8AAPnfAAA14AAAP+AAAK/g AAC04AAAReEAAFDhAACz4QAAvuEAAPjhAAAA4gAAf+IAAIPiAADH4gAAyuIAAD3jAABC4wAA g+MAAIvjAADH4wAA1uMAAAXkAAAQ5AAAP+QAAE7kAACF5AAAkOQAAMrkAADO5AAACeUAABfl AABR5QAAVOUAAJrlAACe5QAABuYAAArmAADN5wAA2+cAAGboAABr6AAAougAAKfoAAD36AAA AOkAAA3pAAAc6QAAcOkAAHbpAAC26QAAuukAAN/pAADl6QAA8+kAAPvpAAAx6gAAOuoAAEzq AABX6gAAa+oAAG/qAACc6gAAoOoAAM3qAADR6gAA/uoAAALrAAAv6wAAM+sAAGDrAABr6wAA fesAAIbrAACV6wAAnesAAKnrAACv6wAA7+sAAPPrAAAY7AAAHuwAAHfsAAB97AAAvewAAMHs AADm7AAA7OwAAAXtAAAN7QAApe0AALXtAADG7QAA1O0AAF/uAABk7gAAo+4AAKjuAAAG7wAA De8AACzvAAA37wAAVu8AAFzvAAB87wAAhO8AAMDvAADF7wAAE/AAABvwAAB38AAAf/AAALXw AAC+8AAA0PAAANvwAADv8AAA8/AAACDxAAAk8QAAUfEAAFXxAACC8QAAhvEAALPxAAC38QAA 4/EAAO7xAAD/8QAACPIAABfyAAAf8gAAePIAAHzyAACH8wAAjvMAAKXzAACr8wAAyvMAAFb0 AABa9AAAXPQAAOf0AADq9AAAJfUAADD1AACz9QAAuPUAAPv1AAAJ9gAAlPYAAJf2AAD19gAA 9/YAAD73AABA9wAAffcAAIn3AADX9wAA2fcAAEv4AABT+AAAkPgAAJn4AADP+AAA0/gAABX5 AAAc+QAAWvkAAGD5AADK+QAA3fkAAFP6AABb+gAAmPoAAJv6AADb+gAA4foAACT7AAAs+wAA qfsAALL7AADt+wAA9fsAAHv8AAB9/AAAv/wAAMb8AAAf/QAAJP0AACz9AAA0/QAA2P0AANr9 AABM/gAATv4AAIL+AACQ/gAAiv8AAJD/AADM/wAA0/8AABIAAQAaAAEAWQABAGAAAQCgAAEA qAABAOkAAQDtAAEAJAEBAC0BAQAxAQEANgEBAHoBAQB8AQEAwAEBAMUBAQAFAgEADAIBADwC AQBFAgEAkAIBAJMCAQDUAgEA3gIBABsDAQAeAwEAXwMBAGcDAQDsAwEA8AMBAGkEAQBzBAEA vwQBAOMEAQDpBAEA8gQBAEIFAQBFBQEAiQUBAJYFAQDSBQEA2gUBAAcGAQAUBgEAZAYBAGkG AQCdBgEAuAYBAAkHAQAMBwEAHQcBACsHAQC2BwEAxQcBABMIAQAWCAEAVggBAFwIAQC4CAEA vwgBAAAJAQAECQEAUwkBAFcJAQCUCQEAngkBALQJAQC8CQEA+wkBAAYKAQAyCgEANgoBAFYK AQBYCgEAmwoBAKQKAQCzCgEAwAoBAAALAQAVCwEAZAsBAGcLAQCUCwEAogsBAC0MAQAyDAEA aQwBAIIMAQCJDAEAjwwBANQMAQDZDAEALQ0BADgNAQCHDQEAjg0BAM4NAQDXDQEAFQ4BABkO AQCeDgEApg4BAK0OAQC5DgEABw8BAAoPAQBKDwEAUQ8BAJMPAQCZDwEA2Q8BAN0PAQAfEAEA KBABAGcQAQBqEAEArRABALMQAQD2EAEA/BABAD4RAQBFEQEAZREBAGoRAQCjEQEAvBEBAMMR AQDJEQEA4hEBAOgRAQABEgEACBIBAIISAQCQEgEAahMBAG8TAQBzEwEAexMBAAMUAQAMFAEA TBQBAE8UAQCTFAEAmhQBANUUAQDaFAEAcRUBAHgVAQCyFQEAuxUBAOgVAQD2FQEAyRYBAM0W AQDdFgEA4BYBAB8XAQAoFwEAYxcBAGoXAQAkGAEAJRgBAGkYAQBsGAEAhhgBAIsYAQCQGAEA mxgBAKAYAQCsGAEAsRgBAMcYAQDMGAEA3hgBAOMYAQD2GAEA+xgBAA8ZAQAUGQEAMhkBADcZ AQBRGQEAVhkBAFwZAQCHGQEAihkBAI8ZAQCaGQEAoRkBAKgZAQC9GQEAxBkBAO4ZAQACGgEA ChoBABMaAQAvGgEAMxoBAGkaAQByGgEAqBoBAKoaAQDXGgEA4BoBACIbAQAuGwEAYRsBAHcb AQB9GwEAixsBABccAQAeHAEAPhwBAEUcAQBvHAEAgxwBAIscAQCUHAEA1RwBAOccAQDuHAEA 9RwBAFEdAQBUHQEAWR0BAGwdAQBzHQEAeh0BAJcdAQCeHQEA1B0BAOgdAQDvHQEA9h0BADUe AQBTHgEAWh4BAGEeAQCJHgEAlB4BALQeAQDOHgEA1R4BANweAQAAHwEADx8BAGgfAQBrHwEA cB8BAIQfAQDXHwEA2h8BAN8fAQD0HwEAPiABAEEgAQBGIAEAWSABAF8gAQBtIAEA+SABAAch AQAOIQEAFyEBAC4hAQA3IQEAdCEBAHchAQB8IQEAiyEBAOwhAQDvIQEA9CEBAAwiAQATIgEA GiIBADwiAQBCIgEAbyIBAIEiAQDqIgEA8CIBABUjAQAYIwEAHSMBACEjAQAoIwEALyMBAD0j AQBEIwEAjSMBAJAjAQCVIwEAnCMBAKMjAQCsIwEABCQBAAckAQAMJAEAFSQBAC8kAQA9JAEA 9iQBAPkkAQD+JAEABSUBAAwlAQATJQEAJCUBACslAQBCJQEARiUBAFYlAQBfJQEAiiUBAJEl AQCaJQEAqSUBAM4lAQDVJQEA8SUBAPglAQARJgEAFSYBAEUmAQBTJgEAWyYBAGImAQBqJgEA cyYBAJgmAQCeJgEApiYBAK8mAQDOJgEA1SYBAAInAQAFJwEACicBABwnAQAjJwEAKicBAEYn AQBNJwEAaicBAHEnAQCQJwEAlycBALgnAQDGJwEA/icBAAEoAQAGKAEAFCgBABwoAQAmKAEA LSgBAD0oAQBDKAEAWSgBAF0oAQBrKAEACikBABUpAQAoKQEAQCkBAEYpAQBWKQEAXCkBAGop AQBwKQEAgikBAK0pAQC7KQEAwSkBAMcpAQDKKQEA0CkBAPcpAQD/KQEARSoBAEgqAQB0KgEA fioBAJsqAQClKgEAzCoBANkqAQADKwEAFisBAEYrAQBPKwEAdSsBAH0rAQCiKwEApisBAMcr AQDcKwEADiwBABssAQBFLAEAUCwBAHgsAQCHLAEAsywBAM4sAQDVLAEA3CwBAAEtAQAKLQEA Ny0BAEEtAQBkLQEAZy0BAJYtAQCkLQEALi4BADYuAQA9LgEARC4BAFYuAQBfLgEAgi4BAIgu AQCQLgEAly4BAJ8uAQCtLgEA3C4BAN8uAQDkLgEA6y4BAPMuAQD8LgEAGi8BACMvAQBCLwEA SS8BAG4vAQB9LwEAhC8BAIgvAQCuLwEAsC8BAMEvAQDHLwEA8S8BAPwvAQADMAEACjABAB8w AQAjMAEAhTABAIowAQCaMAEAnTABAMowAQDOMAEA4TABAOgwAQBjMQEAZzEBAIQxAQCOMQEA ljEBAJ0xAQDCMQEAyDEBAA8yAQAdMgEA9TIBAAMzAQBxMwEAfzMBAHA0AQB+NAEAtjQBALk0 AQD9NAEAADUBAEQ1AQBPNQEAijUBAIw1AQDQNQEA1zUBAN01AQACNgEAHjYBACY2AQCuNgEA vTYBAPQ2AQD9NgEAPjcBAEw3AQDyNwEA9jcBAFQ4AQBXOAEAxTgBAM04AQAZOQEAHTkBACM5 AQAkOQEAezkBAHw5AQDVOQEA3zkBAFQ6AQBdOgEAmToBAKI6AQA3OwEAaDsBAG87AQB9OwEA STwBAFM8AQD2PAEA/jwBAIQ9AQCLPQEAgj4BAIY+AQCKPwEAjj8BAL4/AQDMPwEAj0ABAJZA AQDBQAEA2kABAJVBAQCXQQEAu0EBAMJBAQD1QQEA+EEBABVCAQAcQgEAQUIBAFpCAQDdQgEA 4kIBAPZCAQD/QgEAnEMBAKBDAQCoQwEArEMBANJDAQDZQwEAAUQBAAdEAQAtRAEAMUQBAGBE AQB5RAEAEkUBAB9FAQBERQEAUkUBAOZFAQDtRQEAUkYBAFVGAQCaRgEAnkYBAN5GAQDpRgEA 8kYBAApHAQAQRwEAFUcBAB5HAQA2RwEAO0cBAE5HAQBXRwEAb0cBAI9HAQCdRwEAi0gBAJJI AQAWSQEAHkkBAF1JAQBpSQEApkkBALNJAQDuSQEA90kBADNKAQA5SgEAqEoBAKpKAQAhSwEA KEsBAGBLAQBqSwEAoUsBAK9LAQDnSwEA60sBAFJMAQBaTAEAgUwBAI9MAQB2TQEAeU0BALJN AQC7TQEA200BAOZNAQAITgEAEU4BADJOAQDmuAEA/bgBAPW6AQD2ugEAj8IBAJHCAQDcwwEA 4sMBAOfEAQDwxAEAjMkBAJLJAQC0yQEAt8kBAHrPAQCDzwEAhs8BAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAAwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwADAAcAAwAHAAcAMwAHADMABwAzAAcAMwAHADMABwADAAcAAAAAAGUgAABmIAAA 4zAAAOcwAACNQQAAjkEAAJNBAACsQwAAPkYAAEJGAAAoUAAAKVAAAK9UAACwVAAABVYAAAZW AAAZXgAAGl4AAKFhAACiYQAA3WsAAN5rAAASbwAAE28AAPJxAADzcQAAoJAAAKGQAAAHlAAA B5QAAAWiAAAGogAALqMAAC+jAAAwowAAMKMAADGjAAAxowAAMqMAADKjAAAzowAAM6MAAN2k AADepAAA86QAAPOkAABkpgAAZaYAAIKnAACDpwAAv6cAAMCnAABTqgAAVKoAAGOrAABkqwAA UrYAAFO2AAAxuwAAp7wAAITOAACHzgAA8d0AAPLdAADX5QAAvucAAA/0AAAP9AAAJP0AACX9 AACOAwEAMAQBAHYSAQB3EgEA9boBAPa6AQD3ugEAWLsBAFm7AQCDzwEAhs8BAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMA BAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAcAAwAEAAcABAAHAAAAAAD2ugEA hs8BAAcABwAUAAAABAAAAAgAAADlAAAAAAAAABMAAADiWwAASnIDAGNADwAaVA8A9AcQAB0g HQDKBCsA/jEsAOluXgANCV8AxxRsAClRngBHd6MAQg+yAPYHtwAvE7wAlyjNANBb6ACeCewA wAL0AP9AA4ABAHoSAQB6EgEAvEgeAQEAAQB6EgEAAAAAAHoSAQAAAAAAAhAAAAAAAAAAhc8B AIAAABAAQAAA//8CAAAABwBVAG4AawBuAG8AdwBuAAkAagBhAHcAaQBuAHQAZQByAGIA//8C AAgAAAAAAAAAAAAAAAAAAAAAAAAAAQD//wIAAAAAAAAA//8AAAIA//8AAAAA//8AAAIA//8A AAAABQAAAEcWkAEAAAICBgMFBAUCAwSHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABUAGkAbQBl AHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAA AAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHegAgAAAAgAgAAAAA AAAA/wEAAAAAAABBAHIAaQBhAGwAAAA/NZABAAACBwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAA AP8BAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAANSaQAQAAAgsGBAMFBAQCBId6AGEA AACACAAAAAAAAAD/AQEAAAAAAFQAYQBoAG8AbQBhAAAAIgAEADGIiBgA8NACAABoAQAAAABX DLcGDRO3JgAAAAAJANEAAAAdQgAA2XgBAAEA4gAAAAQAAxAjAwAAHUIAANl4AQABAOIAAAAj AwAAAAAAACEDAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIAEoAW0ALQAgYESNAAAEAAZAGQAAAAZAAAAFLoBABS6AQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAADKD EQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAo8P8PAQABPwAAAAAA ANQwAAD///9/////fwAAAAD///9/////f////39CD7IAAAAAADIAAAAAAAAAAAAAAAAAAQAA AP//EgAAAAAAAABAAEUAQwBSAEkAVAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAg ACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgAFQAAAAAAAAACQBqAGEAdwBpAG4AdABl AHIAYgAJAGoAYQB3AGkAbgB0AGUAcgBiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIA AAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAALQBAAARAAAAAQAAAJAA AAACAAAAmAAAAAMAAADkAAAABAAAAPAAAAAFAAAABAEAAAYAAAAQAQAABwAAABwBAAAIAAAA MAEAAAkAAABEAQAAEgAAAFABAAAKAAAAcAEAAAwAAAB8AQAADQAAAIgBAAAOAAAAlAEAAA8A AACcAQAAEAAAAKQBAAATAAAArAEAAAIAAADkBAAAHgAAAEQAAABFQ1JJVCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUAAAAAB4A AAAEAAAAAAAAAB4AAAAMAAAAamF3aW50ZXJiAAAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAA HgAAAAwAAABOb3JtYWwuZG90AAAeAAAADAAAAGphd2ludGVyYgAAAB4AAAAEAAAAOQAAAB4A AAAYAAAATWljcm9zb2Z0IE9mZmljZSBXb3JkAAAAQAAAAAAmbDIdAAAAQAAAAADiXqewu8cB QAAAAADeUYNOvMcBAwAAAAEAAAADAAAAHUIAAAMAAADZeAEAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAA AAAAAAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAAAsAQAADAAAAAEAAABoAAAADwAAAHAA AAAFAAAAgAAAAAYAAACIAAAAEQAAAJAAAAAXAAAAmAAAAAsAAACgAAAAEAAAAKgAAAATAAAA sAAAABYAAAC4AAAADQAAAMAAAAAMAAAADQEAAAIAAADkBAAAHgAAAAgAAABBbmRyZXcAAAMA AAAjAwAAAwAAAOIAAAADAAAAFLoBAAMAAADEHwsACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAAAQAAAEEAAABFQ1JJVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUAAwQAAACAAAAHgAAAAYAAABUaXRsZQAD AAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAA BwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAA IgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8A AAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAA PQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoA AABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAA WAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUA AABmAAAAZwAAAGgAAABpAAAAagAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAA cwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAA AACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAA jgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAAAJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsA AACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAAowAAAKQAAAClAAAApgAAAKcAAACoAAAA qQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACxAAAAsgAAALMAAAC0AAAAtQAAALYA AAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAA xAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAAAM4AAADPAAAA0AAAANEA AADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA3AAAAN0AAADeAAAA 3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADqAAAA6wAAAOwA AADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgAAAD5AAAA +gAAAPsAAAD8AAAA/QAAAP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcB AAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAA FQEAABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIB AAAjAQAAJAEAACUBAAAmAQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAA MAEAADEBAAAyAQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7AQAAPAEAAD0B AAA+AQAAPwEAAEABAABBAQAAQgEAAEMBAABEAQAARQEAAEYBAABHAQAASAEAAEkBAABKAQAA SwEAAEwBAABNAQAATgEAAE8BAABQAQAAUQEAAFIBAABTAQAAVAEAAFUBAABWAQAAVwEAAFgB AABZAQAAWgEAAFsBAABcAQAAXQEAAF4BAABfAQAAYAEAAGEBAABiAQAAYwEAAGQBAABlAQAA ZgEAAGcBAABoAQAAaQEAAGoBAABrAQAAbAEAAG0BAABuAQAAbwEAAHABAABxAQAAcgEAAHMB AAB0AQAAdQEAAHYBAAB3AQAAeAEAAHkBAAB6AQAAewEAAHwBAAB9AQAAfgEAAH8BAACAAQAA gQEAAIIBAACDAQAAhAEAAP7///+GAQAAhwEAAIgBAACJAQAAigEAAIsBAACMAQAA/v///44B AACPAQAAkAEAAJEBAACSAQAAkwEAAJQBAACVAQAAlgEAAJcBAACYAQAAmQEAAJoBAACbAQAA nAEAAJ0BAACeAQAAnwEAAKABAAChAQAAogEAAKMBAACkAQAApQEAAKYBAACnAQAAqAEAAKkB AACqAQAAqwEAAKwBAACtAQAArgEAAK8BAACwAQAAsQEAALIBAACzAQAAtAEAALUBAAC2AQAA twEAALgBAAC5AQAAugEAALsBAAC8AQAAvQEAAL4BAAC/AQAAwAEAAMEBAADCAQAAwwEAAMQB AADFAQAAxgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0BAADOAQAAzwEAANABAADRAQAA 0gEAANMBAADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA2wEAANwBAADdAQAA3gEAAN8B AADgAQAA4QEAAOIBAADjAQAA5AEAAOUBAADmAQAA5wEAAOgBAADpAQAA6gEAAOsBAADsAQAA 7QEAAO4BAADvAQAA8AEAAPEBAADyAQAA8wEAAPQBAAD1AQAA9gEAAPcBAAD4AQAA+QEAAPoB AAD7AQAA/AEAAP0BAAD+AQAA/wEAAAACAAABAgAAAgIAAAMCAAAEAgAABQIAAAYCAAAHAgAA CAIAAAkCAAAKAgAACwIAAAwCAAANAgAADgIAAA8CAAAQAgAAEQIAABICAAATAgAAFAIAABUC AAAWAgAAFwIAABgCAAAZAgAAGgIAABsCAAAcAgAAHQIAAB4CAAAfAgAAIAIAACECAAAiAgAA IwIAACQCAAAlAgAAJgIAACcCAAAoAgAAKQIAACoCAAArAgAALAIAAC0CAAAuAgAALwIAADAC AAAxAgAAMgIAADMCAAA0AgAANQIAADYCAAA3AgAAOAIAADkCAAA6AgAAOwIAADwCAAA9AgAA PgIAAD8CAABAAgAAQQIAAEICAABDAgAARAIAAEUCAABGAgAARwIAAEgCAABJAgAASgIAAEsC AABMAgAATQIAAE4CAABPAgAAUAIAAFECAABSAgAAUwIAAFQCAABVAgAAVgIAAFcCAABYAgAA WQIAAFoCAABbAgAAXAIAAF0CAABeAgAAXwIAAGACAABhAgAAYgIAAGMCAABkAgAAZQIAAGYC AABnAgAAaAIAAGkCAABqAgAAawIAAGwCAABtAgAAbgIAAG8CAABwAgAAcQIAAHICAABzAgAA dAIAAHUCAAB2AgAAdwIAAHgCAAB5AgAAegIAAHsCAAB8AgAAfQIAAH4CAAB/AgAAgAIAAIEC AACCAgAAgwIAAIQCAACFAgAAhgIAAIcCAACIAgAAiQIAAIoCAACLAgAAjAIAAI0CAACOAgAA jwIAAJACAACRAgAAkgIAAJMCAACUAgAAlQIAAJYCAACXAgAAmAIAAJkCAACaAgAAmwIAAJwC AACdAgAAngIAAJ8CAACgAgAAoQIAAKICAACjAgAApAIAAKUCAACmAgAApwIAAKgCAACpAgAA qgIAAKsCAACsAgAArQIAAK4CAACvAgAAsAIAALECAACyAgAAswIAALQCAAC1AgAAtgIAALcC AAC4AgAAuQIAALoCAAC7AgAAvAIAAL0CAAC+AgAAvwIAAMACAADBAgAAwgIAAMMCAADEAgAA xQIAAMYCAADHAgAAyAIAAMkCAADKAgAAywIAAMwCAADNAgAAzgIAAM8CAADQAgAA0QIAANIC AADTAgAA1AIAANUCAADWAgAA1wIAANgCAADZAgAA2gIAANsCAADcAgAA3QIAAN4CAADfAgAA /v///+ECAADiAgAA4wIAAOQCAADlAgAA5gIAAOcCAAD+////6QIAAOoCAADrAgAA7AIAAO0C AADuAgAA7wIAAP7////9/////f////3////9/////f////3////3AgAA/v////7////+//// ////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIA AAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAAKKJpU68xwH5AgAAgAAAAAAAAABEAGEAdABhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIUB AAAAEAAAAAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIBAQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjQEAALukAgAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAgDAAAAAAAFAFMA dQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAOACAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYA bwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6AIAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAD+//////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQD+/wMK AAD/////BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1l bnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAA wAAAAAAAAEYAAAAAAAAAAAAAAACw3lBVT7zHAf8CAABAAgAAAAAAAEQAYQB0AGEAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhQEAAAAQ AAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAACNAQAAu6QCAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0CAMAAAAAAIECAACCAgAA gwIAAIQCAACFAgAAhgIAAIcCAACIAgAAiQIAAIoCAACLAgAAjAIAAI0CAACOAgAAjwIAAJAC AACRAgAAkgIAAJMCAACUAgAAlQIAAJYCAACXAgAAmAIAAJkCAACaAgAAmwIAAJwCAACdAgAA ngIAAJ8CAACgAgAAoQIAAKICAACjAgAApAIAAKUCAACmAgAApwIAAKgCAACpAgAAqgIAAKsC AACsAgAArQIAAK4CAACvAgAAsAIAALECAACyAgAAswIAALQCAAC1AgAAtgIAALcCAAC4AgAA uQIAALoCAAC7AgAAvAIAAL0CAAC+AgAAvwIAAMACAADBAgAAwgIAAMMCAADEAgAAxQIAAMYC AADHAgAAyAIAAMkCAADKAgAAywIAAMwCAADNAgAAzgIAAM8CAADQAgAA0QIAANICAADTAgAA 1AIAANUCAADWAgAA1wIAANgCAADZAgAA2gIAANsCAADcAgAA3QIAAN4CAADfAgAA/v///+EC AADiAgAA4wIAAOQCAADlAgAA5gIAAOcCAAD+//////////////////////////////////// ///////////9/////f////3////9/////f///////////////////////////////gIAAP3/ ///+/////v////7////9AgAAAQAAAP7///8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAD+//// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8BAAAAJAAAAAAA AIAsAAAAAAAAAAIAAACwBAAAEwAAAAkMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AIAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQA UwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAApAEAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD///// BgkCAAAAAADAAAAAAAAARh8AAABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQACgAA AE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQA AAAF1c3VnC4bEJOXCAArLPmucAEAACwBAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACAAAAA BgAAAIgAAAARAAAAkAAAABcAAACYAAAACwAAAKAAAAAQAAAAqAAAABMAAACwAAAAFgAAALgA AAANAAAAwAAAAAwAAAANAQAAAgAAAOQEAAAeAAAACAAAAEFuZHJldwAAAwAAACMDAAADAAAA 4gAAAAMAAAAUugEAAwAAAMQfCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4Q AAABAAAAQQAAAEVDUklUICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFQADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAADQA AAADAAAAAAAAACAAAAA= --------------020702020604030609040207 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --------------020702020604030609040207-- From ecrit-bounces@ietf.org Wed Jul 04 08:25:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63vJ-0006te-Bi; Wed, 04 Jul 2007 08:25:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I63vI-0006lq-8F for ecrit@ietf.org; Wed, 04 Jul 2007 08:25:32 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I63v2-0007cQ-7i for ecrit@ietf.org; Wed, 04 Jul 2007 08:25:32 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I63uz-0007Pt-49; Wed, 04 Jul 2007 08:25:13 -0400 Message-ID: <468B91A5.2050502@bbn.com> Date: Wed, 04 Jul 2007 08:25:09 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] Authority-to-Individuals Bar-BOF References: <468A47B3.1010402@gmx.net> <8C837214C95C864C9F34F3635C2A657507C99160@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657507C99160@SEA-EXCHVS-2.telecomsys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Me too! --Richard Roger Marshall wrote: > Hannes: > I'd like to attend the BOF. > > Thanks. > > -roger. > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, July 03, 2007 5:57 AM >> To: ECRIT >> Subject: [Ecrit] Authority-to-Individuals Bar-BOF >> >> Hi all, >> >> a year ago Steve gave a presentation about requirements >> regarding authority-to-citizen communication, see >> http://www3.ietf.org/proceedings/06mar/slides/ecrit-1/sld1.htm >> There was interest in the topic but it is clearly outside the >> scope of the scope of the ECRIT working group. >> >> Now, Steve, Henning, Brian and I worked on two documents to >> provide more details and to have a basis for a discussion: >> >> * Requirements for Authority-to-Individuals Communication for >> Emergency Situations >> http://www.tschofenig.priv.at/svn/draft-norreys-ecrit-authority2in >> dividuals/draft-norreys-ecrit-authority2individuals-requiremen >> ts-00.txt >> >> * Session Initiation Protocol (SIP) Event Package for the >> Common Alerting Protocol (CAP) >> http://www.tschofenig.priv.at/svn/draft-rosen-sipping-cap/draft-ro >> sen-sipping-cap-00.txt >> >> We could use the upcoming IETF meeting to brainstorm a bit >> about this topic. We would like to get feedback! >> * Do you think that this is useful work? >> * Would you be willing to work on this subject? >> * Is it the right time to start something soon? >> >> I would suggest to meet on MONDAY, July 23, 2007 during the >> lunch break (1130-1300). >> >> Please let me know if you plan to attend. I need a head count >> to reserve a room. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > > The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please so notify the sender immediately, and delete it and all attachments from your computer and network. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 04 16:48:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Blh-0000fv-Dq; Wed, 04 Jul 2007 16:48:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Blg-0000fq-Ql for ecrit@ietf.org; Wed, 04 Jul 2007 16:48:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6Blc-00016N-Hm for ecrit@ietf.org; Wed, 04 Jul 2007 16:48:08 -0400 Received: (qmail invoked by alias); 04 Jul 2007 20:41:23 -0000 Received: from p549877AB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.119.171] by mail.gmx.net (mp019) with SMTP; 04 Jul 2007 22:41:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18JkAIGrtAJxDdGAgZuYxXy3of0oCs8HufMmnXBml tTKetFLIVuCyiW Message-ID: <468C05F2.2060008@gmx.net> Date: Wed, 04 Jul 2007 22:41:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: keyprov@ietf.org, ECRIT , 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 Cc: Subject: [Ecrit] Submission cut-off date before Chicago X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Please note the submission dates for Internet-Drafts before Chicago. July 9, Monday - Internet Draft final submission cut-off by 09:00 ET (13:00 UTC/GMT) Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 04 20:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6F7v-0000AN-Ka; Wed, 04 Jul 2007 20:23:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6F7u-0000AI-V3 for ecrit@ietf.org; Wed, 04 Jul 2007 20:23:18 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6F7q-0002AS-M1 for ecrit@ietf.org; Wed, 04 Jul 2007 20:23:18 -0400 X-SEF-Processed: 5_0_0_910__2007_07_04_19_31_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 04 Jul 2007 19:31:16 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jul 2007 19:23:12 -0500 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, 4 Jul 2007 19:23:10 -0500 Message-ID: In-Reply-To: <468B4FFA.2030104@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST pre-06 review Thread-Index: Ace+Dz2zG7luAcJjTpidb7wQdA9PTgAipQwg References: <468B4FFA.2030104@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 05 Jul 2007 00:23:12.0148 (UTC) FILETIME=[ABE4AD40:01C7BE9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ecrit] RE: LoST pre-06 review X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have two further comments that I have been mulling over in my mind.=0D=0A=0D= =0ASection 12.2 and 12.3 refer to the geodetic location profiles.=0D=0AI am= concerned that after having read these a few times they contradict=0D=0Awo= rk that we have done in geopriv. In geopriv we have recommended that=0D=0Aw= hen describing your current location with a polygon that you restrict=0D=0A= the number of vertices to 15 (16 points) to ensure interoperability with=0D= =0Aother protocols and to reduce the amount of data transmitted. The=0D=0As= ections I mention above have clear statements that the 16 point=0D=0Arestri= ction does not apply. While I am happy for the protocol to support=0D=0Amor= e than 16 points, I think that a recommendation that client locations=0D=0A= be restricted to now more than 16 points would be useful so that it is=0D=0A= consistent with work being done else where.=0D=0A=0D=0APlease note that thi= s restriction does not apply to service boundaries.=0D=0A=0D=0ACheers=0D=0A= James=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Hannes Tschofeni= g [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Wednesday, 4 July 2007 5:= 45 PM=0D=0A> To: ECRIT=0D=0A> Cc: Winterbottom, James=0D=0A> Subject: LoST = pre-06 review=0D=0A>=20=0D=0A> Hi all,=0D=0A>=20=0D=0A> James did a review = of the LoST draft. Here is the document he sent to=0D=0Ame.=0D=0A> Thank yo= u James.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 04 20:33:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FI2-0003Ct-1c; Wed, 04 Jul 2007 20:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6FI1-0003Co-C8 for ecrit@ietf.org; Wed, 04 Jul 2007 20:33:45 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6FHo-0004Io-Ew for ecrit@ietf.org; Wed, 04 Jul 2007 20:33:45 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l650XNc6004067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jul 2007 20:33:24 -0400 (EDT) In-Reply-To: References: <468B4FFA.2030104@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5BDDCC71-2BE9-4C0A-A7D0-9BA47A73A96E@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] RE: LoST pre-06 review Date: Wed, 4 Jul 2007 20:33:31 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I see no reason to restrict LoST clients to 16 points or to mention that clients (may) have this restriction. This is likely to be counterproductive, as this may yield LoST implementations that are not tested for larger polygons, even though they may occur. LoST makes no such assumptions, so it is not appropriate to document them in the LoST document. Thus, I'm opposed to such a change. On Jul 4, 2007, at 8:23 PM, Winterbottom, James wrote: > I have two further comments that I have been mulling over in my mind. > > Section 12.2 and 12.3 refer to the geodetic location profiles. > I am concerned that after having read these a few times they > contradict > work that we have done in geopriv. In geopriv we have recommended that > when describing your current location with a polygon that you restrict > the number of vertices to 15 (16 points) to ensure interoperability > with > other protocols and to reduce the amount of data transmitted. The > sections I mention above have clear statements that the 16 point > restriction does not apply. While I am happy for the protocol to > support > more than 16 points, I think that a recommendation that client > locations > be restricted to now more than 16 points would be useful so that it is > consistent with work being done else where. > > Please note that this restriction does not apply to service > boundaries. > > Cheers > James > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 04 23:30:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6I3D-0001Qz-O6; Wed, 04 Jul 2007 23:30:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6I3C-0001Qt-2Z for ecrit@ietf.org; Wed, 04 Jul 2007 23:30:38 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6I38-0007I0-Pu for ecrit@ietf.org; Wed, 04 Jul 2007 23:30:38 -0400 X-SEF-Processed: 5_0_0_910__2007_07_04_22_38_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 04 Jul 2007 22:38:36 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jul 2007 22:30:31 -0500 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: [Ecrit] RE: LoST pre-06 review Date: Wed, 4 Jul 2007 22:30:30 -0500 Message-ID: In-Reply-To: <5BDDCC71-2BE9-4C0A-A7D0-9BA47A73A96E@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: LoST pre-06 review Thread-Index: Ace+nBzgZIzSb8J0QXquQQJ/xfdFcgABVeCA References: <468B4FFA.2030104@gmx.net> <5BDDCC71-2BE9-4C0A-A7D0-9BA47A73A96E@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" X-OriginalArrivalTime: 05 Jul 2007 03:30:31.0869 (UTC) FILETIME=[D749FED0:01C7BEB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning,=0D=0A=0D=0AI guess we are at odds then.=0D=0AI am suggesting that = it be made as a recommendation, not a must.=0D=0AI see little reason for a = Device describing my location to use a polygon=0D=0Awith more than 15 verti= ces. Most mechanisms that measure location can't=0D=0Aprovide a polygon any= way, so it will more than likely need to be=0D=0Aprovided manually or dataf= illed somewhere. I want consistency and=0D=0Ainteroperability, something th= at the proposed recommendation would=0D=0Apromote.=0D=0A=0D=0ACheers=0D=0AJ= ames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Henning Schulzrin= ne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Thursday, 5 July 2007 10:34 AM=0D= =0A> To: Winterbottom, James=0D=0A> Cc: Hannes Tschofenig; ECRIT=0D=0A> Sub= ject: Re: [Ecrit] RE: LoST pre-06 review=0D=0A>=20=0D=0A> I see no reason t= o restrict LoST clients to 16 points or to mention=0D=0A> that clients (may= ) have this restriction. This is likely to be=0D=0A> counterproductive, as = this may yield LoST implementations that are=0D=0A> not tested for larger p= olygons, even though they may occur. LoST=0D=0A> makes no such assumptions,= so it is not appropriate to document them=0D=0A> in the LoST document. Thu= s, I'm opposed to such a change.=0D=0A>=20=0D=0A> On Jul 4, 2007, at 8:23 P= M, Winterbottom, James wrote:=0D=0A>=20=0D=0A> > I have two further comment= s that I have been mulling over in my=0D=0Amind.=0D=0A> >=0D=0A> > Section = 12.2 and 12.3 refer to the geodetic location profiles.=0D=0A> > I am concer= ned that after having read these a few times they=0D=0A> > contradict=0D=0A= > > work that we have done in geopriv. In geopriv we have recommended=0D=0A= that=0D=0A> > when describing your current location with a polygon that you=0D= =0Arestrict=0D=0A> > the number of vertices to 15 (16 points) to ensure int= eroperability=0D=0A> > with=0D=0A> > other protocols and to reduce the amou= nt of data transmitted. The=0D=0A> > sections I mention above have clear st= atements that the 16 point=0D=0A> > restriction does not apply. While I am = happy for the protocol to=0D=0A> > support=0D=0A> > more than 16 points, I = think that a recommendation that client=0D=0A> > locations=0D=0A> > be rest= ricted to now more than 16 points would be useful so that it=0D=0Ais=0D=0A>= > consistent with work being done else where.=0D=0A> >=0D=0A> > Please not= e that this restriction does not apply to service=0D=0A> > boundaries.=0D=0A= > >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A>=20=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 16:54:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YKu-00018D-6X; Thu, 05 Jul 2007 16:54:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6YKt-00017w-0x for ecrit@ietf.org; Thu, 05 Jul 2007 16:53:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I6YKo-0000PD-GA for ecrit@ietf.org; Thu, 05 Jul 2007 16:53:59 -0400 Received: (qmail invoked by alias); 05 Jul 2007 20:53:53 -0000 Received: from p54987A6D.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.122.109] by mail.gmx.net (mp031) with SMTP; 05 Jul 2007 22:53:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xWP47dEqx+KQIdQoPZz8hja+NNzJfLd90OWDG6m hHFi7XiRjGlD5+ Message-ID: <468D5A60.9080100@gmx.net> Date: Thu, 05 Jul 2007 22:53:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: 6e922792024732fb1bb6f346e63517e4 Cc: Subject: [Ecrit] [Fwd: Authority-to-Citizen Communication Draft Review] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FYI, a quite detailed review by Leopold Murhammer (active ETSI EMTEL participant) of http://www.ietf.org/internet-drafts/draft-norreys-ecrit-authority2individuals-requirements-00.txt -------- Original Message -------- Subject: Authority-to-Citizen Communication Draft Review Date: Wed, 4 Jul 2007 21:45:12 +0200 From: Murhammer, Leopold To: Hannes Tschofenig Hello Hannes, I read the draft and I have a couple of comments: 1) The requirements here are not requirements of public authorities. 2) In the introduction SMS is mentioned. ETSI TR 102 444 makes clear that SMS is not a technology which shall used for warning the public. 3) In the introduction and later on in the text there is the option, that specific individuals or groups of individuals shall receive the message. The "legal" requirements up to now only have a geographic area where all people shall receive the message (not specific persons independent of their location). Where does this requirement come from? 4) The introduction also describes that gatewaying the message to traditional systems (e.g. PSTN) is needed. Where does such a requirement come from? I'm not aware of any such request by EU or other country. 5) The introduction also says that the user subscribes to such a service. In the ETSI requirement document this is not an option. In the US the default is that the user gets the message. He can opt out but not for presidential alerts. When there is a need for subscription for this service than other warning services in parallel need to be provided whithout subscription to fullfil the legal requirements. 6) The use case in the introduction where parents receive warnings of schools or adults receive warning regarding affected elderly people is not related to the emergency area and possibly not related to messages from authorities. The feature is fine, but it is not "authority to individuals" communication as it is defined by ETSI and used also in ohter bodies. This can be any form of a "general notification service". 7) In chapter 2. 'Terminology' the "Warning Notification Provider" includes also public transportation agencies and private institutions. Until now this was restricted to (government) authorities. It should not be allowed that a "public warning system" is used by e.g. enterprises, hospitals or universities. 8) Req-5: Only specific geographic regions shall be used as target, not specific individuals or groups. 9) Req-8: A confirmation of a warning message does not make sense. Ususally the public warning system does not know who is in a given area. For a private notification service this might be useful. 10) Req-10: I prefer a re-wording. The protocol shall allow to send a message which might contain the text in different languages. The requirement shall not give the impression that the transport network will do any modification of the text provided by the message provider. 11) Req-12: The user will receive what the network will deliver! It is up to the message provider and the equipment of the user to convert the message content. For a PUBLIC WARNING SYSTEM the user shall not be able to select in which form he will get the warning message. This is not required - not from EU, not from ETSI, not from FCC or any other body in US. For a private/commercial notification service where the user subscribes and have to pay this might be an option, but not for a service provided by the government. 12) Req-15: It is not a requirement on the network which details must be provided in the message. This requirement shall be deleted here. 13) Req-18: I prefer a re-wording. The warning message might contain a recommendation on the reaction of the device and the requirement can be that such a 'recommended behavior' must be transported in the message. It is up to national regulation if such a "override" of configurations is allowed or not. 14) Chapter 6: It is OK to mention the 2 documents. The - possible - misuse of them to start a private notification service shall be avoided. 15) The reference on 3GPP TR 22 968 might be a problem. This is a working document of 3GPP. Summary: It shall be clarified if this is for government use - public warning system by authorities or if this is a general commercial notification service (which might also be used by authorities on request). Best regards, Leo _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 18:08:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZUk-00020g-Fd; Thu, 05 Jul 2007 18:08:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ZUj-0001zq-GE for ecrit@ietf.org; Thu, 05 Jul 2007 18:08:13 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6ZUj-0003rt-3t for ecrit@ietf.org; Thu, 05 Jul 2007 18:08:13 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l65M7b8H025090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 18:07:37 -0400 (EDT) In-Reply-To: <468D5A60.9080100@gmx.net> References: <468D5A60.9080100@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 5 Jul 2007 18:07:50 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 Cc: ECRIT Subject: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Some comments inline. On Jul 5, 2007, at 4:53 PM, Hannes Tschofenig wrote: > > FYI, a quite detailed review by Leopold Murhammer (active ETSI > EMTEL participant) of > > http://www.ietf.org/internet-drafts/draft-norreys-ecrit- > authority2individuals-requirements-00.txt > > > -------- Original Message -------- > Subject: Authority-to-Citizen Communication Draft Review > Date: Wed, 4 Jul 2007 21:45:12 +0200 > From: Murhammer, Leopold > To: Hannes Tschofenig > > 1) The requirements here are not requirements of public authorities. > Right - they are protocol requirements and this should probably be amplified. Obviously, the IETF can't obligate public authorities to do anything. > 2) In the introduction SMS is mentioned. ETSI TR 102 444 makes > clear that SMS is not a technology which shall used for warning the > public. > Should be cited. I have seen studies that propose the use of SMS as a delivery vehicle, so it would probably be a good idea to get more background on this, although this is somewhat tangential to the main thrust of the discussion, namely IP-based systems. > 3) In the introduction and later on in the text there is the > option, that specific individuals or groups of individuals shall > receive the message. The "legal" requirements up to now only have a > geographic area where all people shall receive the message (not > specific persons independent of their location). Where does this > requirement come from? We want to do things that go beyond the legal requirements in a particular jurisdiction. At least in the US, there are lots of systems for alerting public safety officials, for example, and it would be nice to be able to have technically similar solutions, even if they are operated as separate systems. > > 4) The introduction also describes that gatewaying the message to > traditional systems (e.g. PSTN) is needed. Where does such a > requirement come from? I'm not aware of any such request by EU or > other country. This will have to happen; lots of voice-based alerting systems are hybrid PSTN-VoIP. These "reverse 911" systems have become very popular in the US, with multiple jurisdictions using them. > > 5) The introduction also says that the user subscribes to such a > service. In the ETSI requirement document this is not an option. In > the US the default is that the user gets the message. He can opt > out but not for presidential alerts. When there is a need for > subscription for this service than other warning services in > parallel need to be provided whithout subscription to fullfil the > legal requirements. Again, this is a technical document, not a legal document. I don't know of any technical means to force a user in an IP network to receive a message they don't want to receive, i.e., didn't subscribe to. We mention multicast, that that also has an implicit subscription mechanism. > > 6) The use case in the introduction where parents receive warnings > of schools or adults receive warning regarding affected elderly > people is not related to the emergency area and possibly not > related to messages from authorities. The feature is fine, but it > is not "authority to individuals" communication as it is defined by > ETSI and used also in ohter bodies. This can be any form of a > "general notification service". At least in the US, these are generally considered closely related. From what I know, many "reverse 911" systems are used for both, as there's no way that a smaller community can afford two systems that essentially do the same thing. Maybe the ETSI definitions needs to be broadened to reflect systems that are already successfully deployed? > > 7) In chapter 2. 'Terminology' the "Warning Notification Provider" > includes also public transportation agencies and private > institutions. Until now this was restricted to (government) > authorities. It should not be allowed that a "public warning > system" is used by e.g. enterprises, hospitals or universities. Again, we're talking about a technology. We should probably amplify this distinction between multiple services and possibly a single underlying technology. As you may or may not know, the public-private distinction in the US is less clear, as all larger universities, public or private, have their own police forces, with full police powers, not just rent-a-cops. Amtrak and the postal service has its own police force and they have many of the same powers as a local police department. > > 8) Req-5: Only specific geographic regions shall be used as target, > not specific individuals or groups. Again, we're not trying to just echo ETSI requirements. The IETF is not a branch of the European Union or ETSI. > > 9) Req-8: A confirmation of a warning message does not make sense. > Ususally the public warning system does not know who is in a given > area. For a private notification service this might be useful. At best, this could be a confirmation of receipt. Many 'reverse 911' systems offer such a feature and call back until receipt has been confirmed. > > 10) Req-10: I prefer a re-wording. The protocol shall allow to send > a message which might contain the text in different languages. The > requirement shall not give the impression that the transport > network will do any modification of the text provided by the > message provider. Good point. > > 11) Req-12: The user will receive what the network will deliver! It > is up to the message provider and the equipment of the user to > convert the message content. For a PUBLIC WARNING SYSTEM the user > shall not be able to select in which form he will get the warning > message. This is not required - not from EU, not from ETSI, not > from FCC or any other body in US. > For a private/commercial notification service where the user > subscribes and have to pay this might be an option, but not for a > service provided by the government. > > 12) Req-15: It is not a requirement on the network which details > must be provided in the message. This requirement shall be deleted > here. Again, this is a technology issue. I suspect that we should separate out transport and content (e.g., CAP), to avoid this discussion. Somebody needs to specify a uniform structured document format. > > 13) Req-18: I prefer a re-wording. The warning message might > contain a recommendation on the reaction of the device and the > requirement can be that such a 'recommended behavior' must be > transported in the message. It is up to national regulation if such > a "override" of configurations is allowed or not. > > 14) Chapter 6: It is OK to mention the 2 documents. The - possible > - misuse of them to start a private notification service shall be > avoided. > > 15) The reference on 3GPP TR 22 968 might be a problem. This is a > working document of 3GPP. > > > Summary: > It shall be clarified if this is for government use - public > warning system by authorities > or if this is a general commercial notification service (which > might also be used by authorities on request). Maybe this is an implicit understanding that should be called out; as a protocol standardization body, the protocol components would clearly be available to any entity that would find them useful. > > Best regards, > Leo > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 18:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aAH-0007bZ-Dk; Thu, 05 Jul 2007 18:51:09 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6aAG-0007bJ-8S for ecrit@ietf.org; Thu, 05 Jul 2007 18:51:08 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6aAF-0003rU-Qw for ecrit@ietf.org; Thu, 05 Jul 2007 18:51:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Jul 2007 18:51:07 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CADsSjUZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="64446880:sNHT36718284" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l65Mp7jj022029; Thu, 5 Jul 2007 18:51:07 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l65Mp7s0002193; Thu, 5 Jul 2007 22:51:07 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:51:06 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 18:51:06 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 17:51:05 -0500 To: Henning Schulzrinne , Hannes Tschofenig From: "James M. Polk" Subject: Re: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] In-Reply-To: <154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> References: <468D5A60.9080100@gmx.net> <154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 05 Jul 2007 22:51:06.0583 (UTC) FILETIME=[F8D01E70:01C7BF56] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8942; t=1183675867; x=1184539867; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Re=3A=20[Fwd=3A=20Authority-to-Citizen=20Co mmunication=20Draft=0A=20=20Review] |Sender:=20 |To:=20Henning=20Schulzrinne=20, =0A=20=20=20=20=20=2 0=20=20Hannes=20Tschofenig=20; bh=3Rpd65Ce8mpVtUqyh02w24oUtWTAB6m9GutsBfq46gc=; b=jyIipqIwGzqFTHq1ob6Gh6S6dvDd05OMg0fF3Bx95cllogN95H0XUfPYZICJuWkBFASYI7tN HAhTVpeQ8M/uWIJacsDf8AQv1hiKKY++ofgEQHFNRdZGEk2t5o43hJ/1; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 05:07 PM 7/5/2007, Henning Schulzrinne wrote: >Some comments inline. > >On Jul 5, 2007, at 4:53 PM, Hannes Tschofenig wrote: > >> >>FYI, a quite detailed review by Leopold Murhammer (active ETSI >>EMTEL participant) of >> >>http://www.ietf.org/internet-drafts/draft-norreys-ecrit- >>authority2individuals-requirements-00.txt >> >> >>-------- Original Message -------- >>Subject: Authority-to-Citizen Communication Draft Review >>Date: Wed, 4 Jul 2007 21:45:12 +0200 >>From: Murhammer, Leopold >>To: Hannes Tschofenig >> >>1) The requirements here are not requirements of public authorities. > >Right - they are protocol requirements and this should probably be >amplified. Obviously, the IETF can't obligate public authorities to >do anything. > > >>2) In the introduction SMS is mentioned. ETSI TR 102 444 makes >>clear that SMS is not a technology which shall used for warning the >>public. > >Should be cited. I have seen studies that propose the use of SMS as a >delivery vehicle, so it would probably be a good idea to get more >background on this, although this is somewhat tangential to the main >thrust of the discussion, namely IP-based systems. fair qualifier, but I don't think ETSI's spec is universal, so SMS can be mentioned as one possibility at least >>3) In the introduction and later on in the text there is the >>option, that specific individuals or groups of individuals shall >>receive the message. The "legal" requirements up to now only have a >>geographic area where all people shall receive the message (not >>specific persons independent of their location). Where does this >>requirement come from? > >We want to do things that go beyond the legal requirements in a >particular jurisdiction. At least in the US, there are lots of >systems for alerting public safety officials, for example, and it >would be nice to be able to have technically similar solutions, even >if they are operated as separate systems. I agree that groups sharing a role or trait have the ability to receive messages that the general public may not. >>4) The introduction also describes that gatewaying the message to >>traditional systems (e.g. PSTN) is needed. Where does such a >>requirement come from? I'm not aware of any such request by EU or >>other country. > >This will have to happen; lots of voice-based alerting systems are >hybrid PSTN-VoIP. These "reverse 911" systems have become very >popular in the US, with multiple jurisdictions using them. I think this is starting to point to the difference between "where did the written requirement from?" and "lets look at a given requirement, then let's look at how similar implementations are used" >>5) The introduction also says that the user subscribes to such a >>service. In the ETSI requirement document this is not an option. In >>the US the default is that the user gets the message. He can opt >>out but not for presidential alerts. When there is a need for >>subscription for this service than other warning services in >>parallel need to be provided whithout subscription to fullfil the >>legal requirements. > >Again, this is a technical document, not a legal document. I don't >know of any technical means to force a user in an IP network to >receive a message they don't want to receive, i.e., didn't subscribe >to. This will be the case when broadcast TV delivered to the masses has IP as an optional transport. The EAS, at least within the US, will have little humor in hearing that oh, the TV didn't subscribe to that alerting service so they didn't know about the tornado approaching. Some mediums will have a mandatory delivery, but maybe not what we usually think of as a mobile IP device like a PDA or laptop or 3G-IP phone. >We mention multicast, that that also has an implicit subscription >mechanism. > > >> >>6) The use case in the introduction where parents receive warnings >>of schools or adults receive warning regarding affected elderly >>people is not related to the emergency area and possibly not >>related to messages from authorities. The feature is fine, but it >>is not "authority to individuals" communication as it is defined by >>ETSI and used also in ohter bodies. This can be any form of a >>"general notification service". > >At least in the US, these are generally considered closely related. > From what I know, many "reverse 911" systems are used for both, as >there's no way that a smaller community can afford two systems that >essentially do the same thing. Maybe the ETSI definitions needs to be >broadened to reflect systems that are already successfully deployed? this application shouldn't be assumed, as the service Leopold describes above is an entirely paid-for service anywhere near this metro area (Dallas/Fort Worth), and therefore likely not an A-to-C service. >>7) In chapter 2. 'Terminology' the "Warning Notification Provider" >>includes also public transportation agencies and private >>institutions. Until now this was restricted to (government) >>authorities. It should not be allowed that a "public warning >>system" is used by e.g. enterprises, hospitals or universities. > >Again, we're talking about a technology. We should probably amplify >this distinction between multiple services and possibly a single >underlying technology. As you may or may not know, the public-private >distinction in the US is less clear, as all larger universities, >public or private, have their own police forces, with full police >powers, not just rent-a-cops. Amtrak and the postal service has its >own police force and they have many of the same powers as a local >police department. > > >> >>8) Req-5: Only specific geographic regions shall be used as target, >>not specific individuals or groups. > >Again, we're not trying to just echo ETSI requirements. The IETF is >not a branch of the European Union or ETSI. > > >> >>9) Req-8: A confirmation of a warning message does not make sense. >>Ususally the public warning system does not know who is in a given >>area. For a private notification service this might be useful. > >At best, this could be a confirmation of receipt. Many 'reverse 911' >systems offer such a feature and call back until receipt has been >confirmed. this won't scale when you get into city wide or region wide events >>10) Req-10: I prefer a re-wording. The protocol shall allow to send >>a message which might contain the text in different languages. The >>requirement shall not give the impression that the transport >>network will do any modification of the text provided by the >>message provider. > >Good point. > > >> >>11) Req-12: The user will receive what the network will deliver! It >>is up to the message provider and the equipment of the user to >>convert the message content. For a PUBLIC WARNING SYSTEM the user >>shall not be able to select in which form he will get the warning >>message. This is not required - not from EU, not from ETSI, not >>from FCC or any other body in US. >>For a private/commercial notification service where the user >>subscribes and have to pay this might be an option, but not for a >>service provided by the government. >> >>12) Req-15: It is not a requirement on the network which details >>must be provided in the message. This requirement shall be deleted >>here. > >Again, this is a technology issue. I suspect that we should separate >out transport and content (e.g., CAP), to avoid this discussion. >Somebody needs to specify a uniform structured document format. > > >> >>13) Req-18: I prefer a re-wording. The warning message might >>contain a recommendation on the reaction of the device and the >>requirement can be that such a 'recommended behavior' must be >>transported in the message. It is up to national regulation if such >>a "override" of configurations is allowed or not. >> >>14) Chapter 6: It is OK to mention the 2 documents. The - possible >>- misuse of them to start a private notification service shall be >>avoided. >> >>15) The reference on 3GPP TR 22 968 might be a problem. This is a >>working document of 3GPP. >> >> >>Summary: >>It shall be clarified if this is for government use - public >>warning system by authorities >>or if this is a general commercial notification service (which >>might also be used by authorities on request). > >Maybe this is an implicit understanding that should be called out; as >a protocol standardization body, the protocol components would >clearly be available to any entity that would find them useful. > > >> >>Best regards, >>Leo > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 20:02:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bH9-0002Zr-3p; Thu, 05 Jul 2007 20:02:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bH7-0002Zm-BA for ecrit@ietf.org; Thu, 05 Jul 2007 20:02:17 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6bH7-0005Ky-4c for ecrit@ietf.org; Thu, 05 Jul 2007 20:02:17 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6601ZhJ015615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 5 Jul 2007 20:01:36 -0400 (EDT) In-Reply-To: References: <468D5A60.9080100@gmx.net> <154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30D3538F-88C9-4E2D-9610-8C1665A2F71C@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] Date: Thu, 5 Jul 2007 20:00:51 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > This will be the case when broadcast TV delivered to the masses has > IP as an optional transport. The EAS, at least within the US, will > have little humor in hearing that oh, the TV didn't subscribe to > that alerting service so they didn't know about the tornado > approaching. Some mediums will have a mandatory delivery, but > maybe not what we usually think of as a mobile IP device like a PDA > or laptop or 3G-IP phone. > I think we should distinguish between several facets of receiving data: (1) network layer delivery to anybody within a certain access network (GSM notifications, IP-TV, L2/L3 multicast, etc.); here, where is no explicit subscription, but somebody has to keep track of where devices are or devices have to tell some entity where they are. This is a form of subscription, even it's if done once after the router is plugged in. (2) explicit protocol mechanisms where an end device tells a server that they are in a specific geographic region >> >> At best, this could be a confirmation of receipt. Many 'reverse 911' >> systems offer such a feature and call back until receipt has been >> confirmed. > > this won't scale when you get into city wide or region wide events > Anything scales with enough (peer-to-peer...) servers :-) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 20:21:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bZe-0005dg-Jw; Thu, 05 Jul 2007 20:21:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bZc-0005d8-BQ for ecrit@ietf.org; Thu, 05 Jul 2007 20:21:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6bZc-00080j-24 for ecrit@ietf.org; Thu, 05 Jul 2007 20:21:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 05 Jul 2007 17:15:59 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFMnjUarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="177330218:sNHT9240514209" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l660FxkZ003683; Thu, 5 Jul 2007 17:15:59 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l660Fxmo004819; Fri, 6 Jul 2007 00:15:59 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 17:15:59 -0700 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 17:15:58 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 19:15:57 -0500 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] In-Reply-To: <30D3538F-88C9-4E2D-9610-8C1665A2F71C@cs.columbia.edu> References: <468D5A60.9080100@gmx.net> <154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> <30D3538F-88C9-4E2D-9610-8C1665A2F71C@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 00:15:58.0815 (UTC) FILETIME=[D4050EF0:01C7BF62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1844; t=1183680959; x=1184544959; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Re=3A=20[Fwd=3A=20Authority-to-Citizen=20Co mmunication=20Draft=0A=20=20Review] |Sender:=20; bh=/x0vWUzV1TYbqUVoO00BeIF+8sCFPyUxHzY0Uqh8/hk=; b=rAN12KpsLekfOHF5ROWSmjkTbWKQfb+cJOsTRt0oEhKD4ASl8Eh4mAgPiQd4yY6pnQcj2jlJ xII33eeNxfHsVWqM9SHfNNZvycgjrvwfEf0O/AIf0bwZQCwClEaPoW3b; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 07:00 PM 7/5/2007, Henning Schulzrinne wrote: >>This will be the case when broadcast TV delivered to the masses has >>IP as an optional transport. The EAS, at least within the US, will >>have little humor in hearing that oh, the TV didn't subscribe to >>that alerting service so they didn't know about the tornado >>approaching. Some mediums will have a mandatory delivery, but >>maybe not what we usually think of as a mobile IP device like a PDA >>or laptop or 3G-IP phone. > >I think we should distinguish between several facets of receiving data: > >(1) network layer delivery to anybody within a certain access network >(GSM notifications, IP-TV, L2/L3 multicast, etc.); here, where is no >explicit subscription, but somebody has to keep track of where >devices are or devices have to tell some entity where they are. This >is a form of subscription, even it's if done once after the router is >plugged in. > >(2) explicit protocol mechanisms where an end device tells a server >that they are in a specific geographic region I agree with both of the above >>>At best, this could be a confirmation of receipt. Many 'reverse 911' >>>systems offer such a feature and call back until receipt has been >>>confirmed. >> >>this won't scale when you get into city wide or region wide events > >Anything scales with enough (peer-to-peer...) servers :-) yeah... until the eastern seaboard of the US gets a hurricane warning, and 100 million devices are supposed to reply within a timely fashion ;-) I think just getting all the enabled devices within a city the size of Houston or Miami to reply will overwhelm most systems within a country's jurisdiction. I'm merely suggesting this not be a wish list item, and some feasibility analysis be done before the piece moves forward >Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 20:38:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bqE-0001Ro-EP; Thu, 05 Jul 2007 20:38:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6bqC-0001Rf-VT for ecrit@ietf.org; Thu, 05 Jul 2007 20:38:33 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6bqC-0001Vc-MW for ecrit@ietf.org; Thu, 05 Jul 2007 20:38:32 -0400 X-SEF-Processed: 5_0_0_910__2007_07_05_19_46_05 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 05 Jul 2007 19:46:05 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jul 2007 19:38:00 -0500 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: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] Date: Thu, 5 Jul 2007 19:37:58 -0500 Message-ID: In-Reply-To: <30D3538F-88C9-4E2D-9610-8C1665A2F71C@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] Thread-Index: Ace/YO3Ih/XFH7SZShawIYsEsGi0vQABK99g References: <468D5A60.9080100@gmx.net><154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> <30D3538F-88C9-4E2D-9610-8C1665A2F71C@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" , "James M. Polk" X-OriginalArrivalTime: 06 Jul 2007 00:38:00.0118 (UTC) FILETIME=[E793E560:01C7BF65] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org When I was talking to Marc Linsner in Prague, the topic of being able to=0D= =0Aregister for these kinds of warnings when you are not in the area was=0D= =0Aalso brought up.=0D=0A=0D=0AFor example if I am at the IETF meeting in C= hicago, and there is a storm=0D=0Aat my home in Wollongong, then I might li= ke to be able to find out.=0D=0A=0D=0AI would like this kind of service con= sidered also as it is not quite the=0D=0Asame as case 2 below.=0D=0A=0D=0AC= heers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Henni= ng Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> Sent: Friday, 6 July 200= 7 10:01 AM=0D=0A> To: James M. Polk=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [E= crit] Re: [Fwd: Authority-to-Citizen Communication=0D=0ADraft=0D=0A> Review= ]=0D=0A>=20=0D=0A> > This will be the case when broadcast TV delivered to t= he masses has=0D=0A> > IP as an optional transport. The EAS, at least with= in the US, will=0D=0A> > have little humor in hearing that oh, the TV didn'= t subscribe to=0D=0A> > that alerting service so they didn't know about the= tornado=0D=0A> > approaching. Some mediums will have a mandatory delivery= , but=0D=0A> > maybe not what we usually think of as a mobile IP device lik= e a PDA=0D=0A> > or laptop or 3G-IP phone.=0D=0A> >=0D=0A>=20=0D=0A> I thin= k we should distinguish between several facets of receiving=0D=0Adata:=0D=0A= >=20=0D=0A> (1) network layer delivery to anybody within a certain access n= etwork=0D=0A> (GSM notifications, IP-TV, L2/L3 multicast, etc.); here, wher= e is no=0D=0A> explicit subscription, but somebody has to keep track of whe= re=0D=0A> devices are or devices have to tell some entity where they are. T= his=0D=0A> is a form of subscription, even it's if done once after the rout= er is=0D=0A> plugged in.=0D=0A>=20=0D=0A> (2) explicit protocol mechanisms = where an end device tells a server=0D=0A> that they are in a specific geogr= aphic region=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> >>=0D=0A> >> At= best, this could be a confirmation of receipt. Many 'reverse=0D=0A911'=0D=0A= > >> systems offer such a feature and call back until receipt has been=0D=0A= > >> confirmed.=0D=0A> >=0D=0A> > this won't scale when you get into city w= ide or region wide events=0D=0A> >=0D=0A>=20=0D=0A> Anything scales with en= ough (peer-to-peer...) servers :-)=0D=0A>=20=0D=0A> Henning=0D=0A>=20=0D=0A= >=20=0D=0A>=20=0D=0A> _______________________________________________=0D=0A= > Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mai= lman/listinfo/ecrit=0D=0A=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0AThis message is f= or the designated recipient only and may=0D=0Acontain privileged, proprieta= ry, or otherwise private information. =20=0D=0AIf you have received it in e= rror, please notify the sender=0D=0Aimmediately and delete the original. A= ny unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------------= ---------------------------------------------------------------------------= -----=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 05 21:23:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cY4-0006d3-RR; Thu, 05 Jul 2007 21:23:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6cY4-0006cq-5T for ecrit@ietf.org; Thu, 05 Jul 2007 21:23:52 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6cXT-0001po-IW for ecrit@ietf.org; Thu, 05 Jul 2007 21:23:52 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2007 21:23:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CANo1jUZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175486400"; d="scan'208"; a="125332357:sNHT32439176" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l661NF5E017915; Thu, 5 Jul 2007 21:23:15 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l661NEs0002551; Fri, 6 Jul 2007 01:23:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:23:14 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.78]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 21:23:14 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Jul 2007 20:23:12 -0500 To: "Winterbottom, James" , "Henning Schulzrinne" From: "James M. Polk" Subject: RE: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication Draft Review] In-Reply-To: References: <468D5A60.9080100@gmx.net> <154D1DEE-991F-4005-9C3C-00A267F4F4A4@cs.columbia.edu> <30D3538F-88C9-4E2D-9610-8C1665A2F71C@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jul 2007 01:23:14.0137 (UTC) FILETIME=[39425490:01C7BF6C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3169; t=1183684995; x=1184548995; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20[Fwd=3A=20Authority-to-Citizen=20Co mmunication=20Draft=0A=20=20Review] |Sender:=20 |To:=20=22Winterbottom, =20James=22=20, =0A= 20=20=20=20=20=20=20=20=22Henning=20Schulzrinne=22=20; bh=9dEmR4dVaZrb2pdljSeGDdWPkzFbyKoXCt9ysmloKg8=; b=px82GoxGCQBvf20JPrjVnm8+eGGAfPup79JrgCiGd4aEMwZ1haNg1Nb/JsjDU+OOfEhoOhbo unZ03tYVNgDxL103C9ubrf3hCdt6D6E1rHPnaNDxzqQScMMtVEjmBeGp; Authentication-Results: rtp-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree with James W. (wondering how long he's staring at his screen in disbelief ;-) This is a very useful function. Likewise, for the ability to keep track of someone/where (remotely) that I (for example) have an interest in (perhaps where my daughter is vacationing - type of thing) James At 07:37 PM 7/5/2007, Winterbottom, James wrote: >When I was talking to Marc Linsner in Prague, the topic of being able to >register for these kinds of warnings when you are not in the area was >also brought up. > >For example if I am at the IETF meeting in Chicago, and there is a storm >at my home in Wollongong, then I might like to be able to find out. > >I would like this kind of service considered also as it is not quite the >same as case 2 below. > >Cheers >James > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Friday, 6 July 2007 10:01 AM > > To: James M. Polk > > Cc: ECRIT > > Subject: Re: [Ecrit] Re: [Fwd: Authority-to-Citizen Communication >Draft > > Review] > > > > > This will be the case when broadcast TV delivered to the masses has > > > IP as an optional transport. The EAS, at least within the US, will > > > have little humor in hearing that oh, the TV didn't subscribe to > > > that alerting service so they didn't know about the tornado > > > approaching. Some mediums will have a mandatory delivery, but > > > maybe not what we usually think of as a mobile IP device like a PDA > > > or laptop or 3G-IP phone. > > > > > > > I think we should distinguish between several facets of receiving >data: > > > > (1) network layer delivery to anybody within a certain access network > > (GSM notifications, IP-TV, L2/L3 multicast, etc.); here, where is no > > explicit subscription, but somebody has to keep track of where > > devices are or devices have to tell some entity where they are. This > > is a form of subscription, even it's if done once after the router is > > plugged in. > > > > (2) explicit protocol mechanisms where an end device tells a server > > that they are in a specific geographic region > > > > > > > > > > >> > > >> At best, this could be a confirmation of receipt. Many 'reverse >911' > > >> systems offer such a feature and call back until receipt has been > > >> confirmed. > > > > > > this won't scale when you get into city wide or region wide events > > > > > > > Anything scales with enough (peer-to-peer...) servers :-) > > > > Henning > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 17:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vln-0002yT-3c; Fri, 06 Jul 2007 17:55:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vlm-0002yC-8P for ecrit@ietf.org; Fri, 06 Jul 2007 17:55:18 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6vlj-0007EC-2C for ecrit@ietf.org; Fri, 06 Jul 2007 17:55:18 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l66LssDD012957 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 6 Jul 2007 17:54:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Fri, 6 Jul 2007 17:54:53 -0400 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] NENA requirement: contact URI for resolving errors in database X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In going through the NENA i3 requirements, I noticed that they require for address validation: "If it is determined that an address is invalid, an error diagnosis should be supplied if appropriate, as well as a contact URI for resolving errors in the database". We do the former, but not the latter. One possible solution that fits into the generic LoST model is to define a new service URN, say urn:service:address-correction, that can be resolved if the querier has an interest in doing so. It would then yield any number of tel, mailto and http URLs that a user could contact to fix problems. This avoids any special new protocol constructs. Any opinions? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 18:02:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vtA-0005q8-Or; Fri, 06 Jul 2007 18:02:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vt8-0005aK-Jp for ecrit@ietf.org; Fri, 06 Jul 2007 18:02:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6vt4-0006c9-AT for ecrit@ietf.org; Fri, 06 Jul 2007 18:02:54 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I6vsq-0000XN-MB; Fri, 06 Jul 2007 17:02:36 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ECRIT'" References: Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Date: Fri, 6 Jul 2007 18:02:46 -0400 Message-ID: <079e01c7c019$6497bdd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfAGFMki+1hFlb1SVqoCGZnbObhVgAAQjGQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That is what I had in mind. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, July 06, 2007 5:55 PM > To: ECRIT > Subject: [Ecrit] NENA requirement: contact URI for resolving errors > indatabase > > In going through the NENA i3 requirements, I noticed that they > require for address validation: > > "If it is determined that an address is invalid, an error diagnosis > should be supplied if appropriate, as well as a contact URI for > resolving errors in the database". > > We do the former, but not the latter. One possible solution that fits > into the generic LoST model is to define a new service URN, say > urn:service:address-correction, that can be resolved if the querier > has an interest in doing so. It would then yield any number of tel, > mailto and http URLs that a user could contact to fix problems. This > avoids any special new protocol constructs. > > Any opinions? > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 18:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vvH-0005R1-R6; Fri, 06 Jul 2007 18:05:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6vvD-0004wb-Hu for ecrit@ietf.org; Fri, 06 Jul 2007 18:05:03 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6vvD-0007s5-9P for ecrit@ietf.org; Fri, 06 Jul 2007 18:05:03 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 18:04:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALBZjkZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,509,1175486400"; d="scan'208"; a="125415564:sNHT59396262602" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l66M4WFL015680; Fri, 6 Jul 2007 18:04:32 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l66M4Ws0012213; Fri, 6 Jul 2007 22:04:32 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 18:04:32 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 18:04:32 -0400 From: "Marc Linsner" To: "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Date: Fri, 6 Jul 2007 18:04:29 -0400 Message-ID: <013d01c7c019$a09e9010$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcfAGFwVoWUA/x9TQMuWttQLHvmeGgAADXTg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-OriginalArrivalTime: 06 Jul 2007 22:04:32.0487 (UTC) FILETIME=[A1D0A770:01C7C019] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=699; t=1183759472; x=1184623472; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20NENA=20requirement=3A=20contact=20URI=20for =20resolving=20errors=20indatabase |Sender:=20 |To:=20=22'Henning=20Schulzrinne'=22=20, =20=22'ECRIT '=22=20; bh=7tWOC0M6bN6pH6FehysKDr5JZ6KyKjRoIFykWkZl05o=; b=a+LSa7OVZX9diElSWPAl1VyI8j8GE+a7/aaF9HB4rpEXDHzc2BbXy69a9Z55QUC5QSxibJVD snLFaQHMcP2c1H+ZB0D/gBZ3ByvWhp637ka5avi7WQL4gC15Fh03Cfy8; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > We do the former, but not the latter. One possible solution > that fits into the generic LoST model is to define a new > service URN, say urn:service:address-correction, that can be > resolved if the querier has an interest in doing so. It would > then yield any number of tel, mailto and http URLs that a > user could contact to fix problems. This avoids any special > new protocol constructs. > > Any opinions? I agree. A new urn: for further (beyond what LoST provides) address validation. -Marc- > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 18:11:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6w14-0002jZ-GY; Fri, 06 Jul 2007 18:11:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6w11-0002iz-1k for ecrit@ietf.org; Fri, 06 Jul 2007 18:11:03 -0400 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6w0w-0008Cv-Io for ecrit@ietf.org; Fri, 06 Jul 2007 18:11:03 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 6 Jul 2007 15:10:57 -0700 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: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Date: Fri, 6 Jul 2007 15:10:57 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] NENA requirement: contact URI for resolving errors indatabase thread-index: AcfAGFsQkCGgZod4QJePzg/ZrDfQagAANdHg References: From: "Roger Marshall" To: "Henning Schulzrinne" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Only one minor adjustment to your example. I'd suggest that instead of: urn:service:address-correction, we use, instead, urn:service:sos.address-correction ^^^ Other non-emergency use cases exist for similar error corrections in location, which might be performed by a municipal planning dept., location company, etc.=20 Sounds like a good use (reuse) of the mechanisms we've got. -roger marshall. > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Friday, July 06, 2007 2:55 PM > To: ECRIT > Subject: [Ecrit] NENA requirement: contact URI for resolving=20 > errors indatabase >=20 > In going through the NENA i3 requirements, I noticed that=20 > they require for address validation: >=20 > "If it is determined that an address is invalid, an error=20 > diagnosis should be supplied if appropriate, as well as a=20 > contact URI for resolving errors in the database". >=20 > We do the former, but not the latter. One possible solution=20 > that fits into the generic LoST model is to define a new=20 > service URN, say urn:service:address-correction, that can be=20 > resolved if the querier has an interest in doing so. It would=20 > then yield any number of tel, mailto and http URLs that a=20 > user could contact to fix problems. This avoids any special=20 > new protocol constructs. >=20 > Any opinions? >=20 > Henning >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 18:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wCj-0002lq-EQ; Fri, 06 Jul 2007 18:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wCi-0002lk-RD for ecrit@ietf.org; Fri, 06 Jul 2007 18:23:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6wCe-00016H-IK for ecrit@ietf.org; Fri, 06 Jul 2007 18:23:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 18:23:04 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAO5cjkZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,509,1175486400"; d="scan'208"; a="125416599:sNHT26624026" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l66MN4fx005147; Fri, 6 Jul 2007 18:23:04 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l66MMvs0016081; Fri, 6 Jul 2007 22:22:57 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 18:22:57 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 18:22:56 -0400 From: "Marc Linsner" To: "'Roger Marshall'" , "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Fri, 6 Jul 2007 18:22:53 -0400 Message-ID: <014801c7c01c$325a1450$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcfAGFsQkCGgZod4QJePzg/ZrDfQagAANdHgAACvh/A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <8C837214C95C864C9F34F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> X-OriginalArrivalTime: 06 Jul 2007 22:22:57.0035 (UTC) FILETIME=[342D4DB0:01C7C01C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=309; t=1183760584; x=1184624584; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20NENA=20requirement=3A=20contact=20URI=20for =20resolving=20errorsindatabase |Sender:=20 |To:=20=22'Roger=20Marshall'=22=20, =0A=20=20=20 =20=20=20=20=20=22'Henning=20Schulzrinne'=22=20, =0A=2 0=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=HF17Tx5wx1sgF6dEYFMN/1U4EtM5yxplU0VhkX2RS1c=; b=dwUO4jm4XzXuf1RBi8DI8PK0/U/ZU9GkihPq/XT7ladtXE3UqsxqcCq9Uim0zPslLRUzZk6p Lmz/4WjBdipAIIie+z/XDfuz+JOJSgY3N9isyixJBoSLUZReQwnjJQ4e; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > > Only one minor adjustment to your example. I'd suggest that > instead of: > > urn:service:address-correction, we use, instead, > urn:service:sos.address-correction > ^^^ A decision for someone other than ecrit......(maybe the entity request/operating the service). -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 18:28:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wI6-0004sc-AB; Fri, 06 Jul 2007 18:28:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wI4-0004VL-Jl for ecrit@ietf.org; Fri, 06 Jul 2007 18:28:40 -0400 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6wI0-0000dg-3x for ecrit@ietf.org; Fri, 06 Jul 2007 18:28:40 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Fri, 6 Jul 2007 15:28:23 -0700 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: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Fri, 6 Jul 2007 15:28:23 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657507C99EDD@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <014801c7c01c$325a1450$220d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase thread-index: AcfAGFsQkCGgZod4QJePzg/ZrDfQagAANdHgAACvh/AAACA5kA== References: <8C837214C95C864C9F34F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <014801c7c01c$325a1450$220d0d0a@amer.cisco.com> From: "Roger Marshall" To: "Marc Linsner" , "Henning Schulzrinne" , "ECRIT" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Marc: What I'm thinking of is the case where two services are available from a single LoST Server, urn:service:pizza vs.=20 urn:service:sos=20 Both types of queries use location, but the resolution of correcting location errors affecting pizza delivery are not going to be the same for those of fixing emergency service location errors. -roger. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com]=20 > Sent: Friday, July 06, 2007 3:23 PM > To: Roger Marshall; 'Henning Schulzrinne'; 'ECRIT' > Subject: RE: [Ecrit] NENA requirement: contact URI for=20 > resolving errorsindatabase >=20 >=20 > >=20 > > Only one minor adjustment to your example. I'd suggest=20 > that instead=20 > > of: > >=20 > > urn:service:address-correction, we use, instead,=20 > > urn:service:sos.address-correction > > ^^^ >=20 > A decision for someone other than ecrit......(maybe the=20 > entity request/operating the service). >=20 > -Marc- >=20 The information contained in this message may be privileged and/or confiden= tial. If you are not the intended recipient, or responsible for delivering = this message to the intended recipient, any review, forwarding, disseminati= on, distribution or copying of this communication or any attachment(s) is s= trictly prohibited. If you have received this message in error, please so n= otify the sender immediately, and delete it and all attachments from your c= omputer and network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 18:50:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wdK-0005jK-Cl; Fri, 06 Jul 2007 18:50:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6wdJ-0005fh-86 for ecrit@ietf.org; Fri, 06 Jul 2007 18:50:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I6wdJ-0002CE-1M for ecrit@ietf.org; Fri, 06 Jul 2007 18:50:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2007 18:50:37 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH5jjkZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,510,1175486400"; d="scan'208"; a="125417948:sNHT25759274" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l66MoaQs028052; Fri, 6 Jul 2007 18:50:36 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l66Moa6a011824; Fri, 6 Jul 2007 22:50:36 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 18:50:36 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jul 2007 18:50:35 -0400 From: "Marc Linsner" To: "'Roger Marshall'" , "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Fri, 6 Jul 2007 18:50:35 -0400 Message-ID: <015601c7c020$10f88f40$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcfAGFsQkCGgZod4QJePzg/ZrDfQagAANdHgAACvh/AAACA5kAAAtLyg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <8C837214C95C864C9F34F3635C2A657507C99EDD@SEA-EXCHVS-2.telecomsys.com> X-OriginalArrivalTime: 06 Jul 2007 22:50:36.0045 (UTC) FILETIME=[110623D0:01C7C020] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=582; t=1183762236; x=1184626236; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20NENA=20requirement=3A=20contact=20URI=20for =20resolving=20errorsindatabase |Sender:=20 |To:=20=22'Roger=20Marshall'=22=20, =0A=20=20=20 =20=20=20=20=20=22'Henning=20Schulzrinne'=22=20, =0A=2 0=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=q62stGgslp2NvQVhVqOgvZcy637yTUZo/8h7naXXqU0=; b=0PJrO+yn5dF06Po+qxvoDJVvCd0YAyY7aUdM1aV8tVx841V5BeKJmP5eUw9F/KKZ0eZ5CMde +vr3hNMD3aqeTL+zuISb9kd3BYUnUCsZ4aUuAjbl7s2jgAS+xBsPIGlg; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Roger, > Both types of queries use location, but the resolution of > correcting location errors affecting pizza delivery are not > going to be the same for those of fixing emergency service > location errors. Hence how crazy it is for emergency service to continue to support a proprietary location labeling system. If the pizza can get delivered using a rusted-out 1968 Datsun with a funny light on top one would think the high-tech emergency responders should be able to find the same location. Oh well, I've digressed enough, not an ecrit problem. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 20:05:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6xnL-0002B7-8V; Fri, 06 Jul 2007 20:05:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6xnK-0002B0-Oe for ecrit@ietf.org; Fri, 06 Jul 2007 20:05:02 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6xnG-0006p7-EI for ecrit@ietf.org; Fri, 06 Jul 2007 20:05:02 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6704sQs018334 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Jul 2007 20:04:55 -0400 (EDT) In-Reply-To: <8C837214C95C864C9F34F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Date: Fri, 6 Jul 2007 20:04:45 -0400 To: Roger Marshall X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In general, we will probably have a need to identify a number of administrative services related to governments that aren't really emergency services. Address correction isn't really an emergency service as currently defined: The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Thus, this is really closer to the "3-1-1" service that some US cities, like NYC, have been deploying. Something like urn:service:public, but there's likely a better name. Henning On Jul 6, 2007, at 6:10 PM, Roger Marshall wrote: > Only one minor adjustment to your example. I'd suggest that > instead of: > > urn:service:address-correction, we use, instead, > urn:service:sos.address-correction > ^^^ > Other non-emergency use cases exist for similar error corrections in > location, which might be performed by a municipal planning dept., > location company, etc. > > Sounds like a good use (reuse) of the mechanisms we've got. > > -roger marshall. > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Friday, July 06, 2007 2:55 PM >> To: ECRIT >> Subject: [Ecrit] NENA requirement: contact URI for resolving >> errors indatabase >> >> In going through the NENA i3 requirements, I noticed that >> they require for address validation: >> >> "If it is determined that an address is invalid, an error >> diagnosis should be supplied if appropriate, as well as a >> contact URI for resolving errors in the database". >> >> We do the former, but not the latter. One possible solution >> that fits into the generic LoST model is to define a new >> service URN, say urn:service:address-correction, that can be >> resolved if the querier has an interest in doing so. It would >> then yield any number of tel, mailto and http URLs that a >> user could contact to fix problems. This avoids any special >> new protocol constructs. >> >> Any opinions? >> >> Henning >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > > The information contained in this message may be privileged and/or > confidential. If you are not the intended recipient, or responsible > for delivering this message to the intended recipient, any review, > forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you > have received this message in error, please so notify the sender > immediately, and delete it and all attachments from your computer > and network. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 06 20:39:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yKF-00024T-9Y; Fri, 06 Jul 2007 20:39:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yKD-0001uQ-PS for ecrit@ietf.org; Fri, 06 Jul 2007 20:39:01 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yK9-0001pP-BO for ecrit@ietf.org; Fri, 06 Jul 2007 20:39:01 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I6yJr-0002cI-QQ; Fri, 06 Jul 2007 19:38:40 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Roger Marshall'" References: <8C837214C95C864C9F34F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Fri, 6 Jul 2007 20:38:51 -0400 Message-ID: <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfAKnGTknwacvgJSLqm2tQovq55GgABBSow X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hmmm. Lots to respond to. First of all, in i3, we have consistent address conventions with municipalities. We may not conform to postal, because the post office doesn't always do what the addressing authorities tell them. There will be both municipal community name and post office community name. In most countries, there is no conflict; the U.S. is a bit odd. Then, we really, really want the entry in LoST for service.sos to be the SAME address data as service.pizza. This means everyone uses the same address database. The LoST server may be different, but the address data is, we hope, the same. Finally, I am planning to write an I-D creating a service:nena namespace, which NENA will administer. Happy to have a generic address location error reporting service, and we'll use it, but we're also quite happy to create a local service for this purpose if others have a problem. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, July 06, 2007 8:05 PM > To: Roger Marshall > Cc: ECRIT > Subject: Re: [Ecrit] NENA requirement: contact URI for resolving > errorsindatabase > > In general, we will probably have a need to identify a number of > administrative services related to governments that aren't really > emergency services. Address correction isn't really an emergency > service as currently defined: > > The 'sos' service type describes emergency services requiring an > immediate response, typically offered by various branches of the > government or other public institutions. > > Thus, this is really closer to the "3-1-1" service that some US > cities, like NYC, have been deploying. Something like > urn:service:public, but there's likely a better name. > > Henning > > On Jul 6, 2007, at 6:10 PM, Roger Marshall wrote: > > > Only one minor adjustment to your example. I'd suggest that > > instead of: > > > > urn:service:address-correction, we use, instead, > > urn:service:sos.address-correction > > ^^^ > > Other non-emergency use cases exist for similar error corrections in > > location, which might be performed by a municipal planning dept., > > location company, etc. > > > > Sounds like a good use (reuse) of the mechanisms we've got. > > > > -roger marshall. > > > >> -----Original Message----- > >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >> Sent: Friday, July 06, 2007 2:55 PM > >> To: ECRIT > >> Subject: [Ecrit] NENA requirement: contact URI for resolving > >> errors indatabase > >> > >> In going through the NENA i3 requirements, I noticed that > >> they require for address validation: > >> > >> "If it is determined that an address is invalid, an error > >> diagnosis should be supplied if appropriate, as well as a > >> contact URI for resolving errors in the database". > >> > >> We do the former, but not the latter. One possible solution > >> that fits into the generic LoST model is to define a new > >> service URN, say urn:service:address-correction, that can be > >> resolved if the querier has an interest in doing so. It would > >> then yield any number of tel, mailto and http URLs that a > >> user could contact to fix problems. This avoids any special > >> new protocol constructs. > >> > >> Any opinions? > >> > >> Henning > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www1.ietf.org/mailman/listinfo/ecrit > >> > > > > > > The information contained in this message may be privileged and/or > > confidential. If you are not the intended recipient, or responsible > > for delivering this message to the intended recipient, any review, > > forwarding, dissemination, distribution or copying of this > > communication or any attachment(s) is strictly prohibited. If you > > have received this message in error, please so notify the sender > > immediately, and delete it and all attachments from your computer > > and network. > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 07 07:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78Hj-00018c-9d; Sat, 07 Jul 2007 07:17:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78Hh-00018V-9p for ecrit@ietf.org; Sat, 07 Jul 2007 07:17:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I78Hg-0001SN-Rh for ecrit@ietf.org; Sat, 07 Jul 2007 07:17:05 -0400 Received: (qmail invoked by alias); 07 Jul 2007 11:16:31 -0000 Received: from p549846AB.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.70.171] by mail.gmx.net (mp034) with SMTP; 07 Jul 2007 13:16:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1942oR6eqR4CvzfJGoYWkb1bmGYSVtqOh1i45Abu0 dzHJDdJ5cq6MpW Message-ID: <468F760D.7080408@gmx.net> Date: Sat, 07 Jul 2007 13:16:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errors in database 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: 8b30eb7682a596edff707698f4a80f7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, thanks for comparing the NENA i3 requirements with the functionality provided by LoST. Your solution proposal sounds good to me. I don't have a strong preference how the URN would look like. I can see Roger's argument ('use urn:service:sos.address-correction instead of urn:service:address-correction) and also Henning's counter argument ('emergency services requiring an immediate response'). Ciao Hannes Henning Schulzrinne wrote: > In going through the NENA i3 requirements, I noticed that they require > for address validation: > > "If it is determined that an address is invalid, an error diagnosis > should be supplied if appropriate, as well as a contact URI for > resolving errors in the database". > > We do the former, but not the latter. One possible solution that fits > into the generic LoST model is to define a new service URN, say > urn:service:address-correction, that can be resolved if the querier > has an interest in doing so. It would then yield any number of tel, > mailto and http URLs that a user could contact to fix problems. This > avoids any special new protocol constructs. > > Any opinions? > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 07 07:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78Mq-0007zU-3Z; Sat, 07 Jul 2007 07:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78Mo-0007zH-E6 for ecrit@ietf.org; Sat, 07 Jul 2007 07:22:22 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I78Mk-00038n-3S for ecrit@ietf.org; Sat, 07 Jul 2007 07:22:22 -0400 X-SEF-Processed: 5_0_0_910__2007_07_07_06_30_23 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 07 Jul 2007 06:30:22 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 7 Jul 2007 06:22:15 -0500 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: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Date: Sat, 7 Jul 2007 06:22:11 -0500 Message-ID: In-Reply-To: <468F760D.7080408@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Thread-Index: AcfAiGXWw0t+I+MXStG+z2kGdfSNigAAGBfg References: <468F760D.7080408@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "Henning Schulzrinne" X-OriginalArrivalTime: 07 Jul 2007 11:22:15.0523 (UTC) FILETIME=[12685B30:01C7C089] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org A couple of thoughts spring to mind.=0D=0A=0D=0AThis is not actually someth= ing that an end-user, you or me, would=0D=0Agenerally be able to detect, it= is more something that a LIS provider or=0D=0Aeven more likely still a PSA= P operator would detect isn't it=3F=0D=0A=0D=0AI would like to understand a= little more about who would use such a=0D=0Ascheme an when. I am certainly= not suggesting that it is a bad or=0D=0Aunnecessary thing.=0D=0A=0D=0AChee= rs=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Hannes T= schofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Saturday, 7 July = 2007 9:17 PM=0D=0A> To: Henning Schulzrinne=0D=0A> Cc: ECRIT=0D=0A> Subject= : Re: [Ecrit] NENA requirement: contact URI for resolving=0D=0Aerrors=0D=0A= > indatabase=0D=0A>=20=0D=0A> Hi Henning,=0D=0A>=20=0D=0A> thanks for compa= ring the NENA i3 requirements with the functionality=0D=0A> provided by LoS= T.=0D=0A>=20=0D=0A> Your solution proposal sounds good to me.=0D=0A>=20=0D=0A= > I don't have a strong preference how the URN would look like. I can=0D=0A= see=0D=0A> Roger's argument ('use urn:service:sos.address-correction instea= d of=0D=0A> urn:service:address-correction) and also Henning's counter argu= ment=0D=0A> ('emergency services requiring an immediate response').=0D=0A> =0D= =0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> Henning Schulzrinne wrote:=0D=0A> = > In going through the NENA i3 requirements, I noticed that they=0D=0Arequi= re=0D=0A> > for address validation:=0D=0A> >=0D=0A> > "If it is determined = that an address is invalid, an error diagnosis=0D=0A> > should be supplied = if appropriate, as well as a contact URI for=0D=0A> > resolving errors in t= he database".=0D=0A> >=0D=0A> > We do the former, but not the latter. One p= ossible solution that=0D=0Afits=0D=0A> > into the generic LoST model is to = define a new service URN, say=0D=0A> > urn:service:address-correction, that= can be resolved if the querier=0D=0A> > has an interest in doing so. It wo= uld then yield any number of tel,=0D=0A> > mailto and http URLs that a user= could contact to fix problems. This=0D=0A> > avoids any special new protoc= ol constructs.=0D=0A> >=0D=0A> > Any opinions=3F=0D=0A> >=0D=0A> > Henning=0D= =0A> >=0D=0A> > _______________________________________________=0D=0A> > Ec= rit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mai= lman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> ____________________________= ___________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> = https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 07 08:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78xG-0000b9-JB; Sat, 07 Jul 2007 08:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I78xE-0000RI-Qu for ecrit@ietf.org; Sat, 07 Jul 2007 08:00:00 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I78xA-0006Ns-Hl for ecrit@ietf.org; Sat, 07 Jul 2007 08:00:00 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l67BxhVk026678 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 7 Jul 2007 07:59:43 -0400 (EDT) In-Reply-To: References: <468F760D.7080408@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6AD600EC-3664-46A0-B4AC-10539F9A2FCB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errors indatabase Date: Sat, 7 Jul 2007 07:59:38 -0400 To: "Winterbottom, James" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I can't speak for the NENA team that developed the requirement list, but I think ECRIT (maybe in its pre-WG state) also discussed some version of this. Let's say a civic address is flagged as "wrong", i.e., in LoST, that one element doesn't agree with another, such as a street address not existing for the town. There are now two possibilities: The user/ISP is wrong and the less likely case that the LoST database is out of sync with reality. Supposedly, in certain fast-growing parts of the US, streets in subdivisions are added faster than the civic authorities can keep up with. Now, whoever generated the location data needs to contact the authorities to fix the problem. Currently, this seems to involve a highly manual process involving fax machines and telephone calls, and I suspect lots of uncorrected errors. The URI would point to a web page, phone number or email address that the end user or other LoST querier could report potential address verification problems to. In some cases, the LoST querier won't be the party that actually can do anything about the problem, since they didn't generate the location information and may not even know who did, but they can presumably relay this information via the SIP location conveyance mechanism to a party that might. Usually, that will involve a human making a judgement. ("I KNOW I just moved to 123 Cedar Lane, even if the asphalt is still steaming." --> contact civic authority via this URL; "I don't know why Verizon believes that I'm living on 123 Belchertown Avenue - that street was renamed ages ago." --> contact Verizon via information in the LI). Thus, we probably need two such URLs, namely one for the location information itself (the source does this do some extent), and the other for LoST. In general, you want to make it easy for people to help fix things ahead of an actual emergency. Henning On Jul 7, 2007, at 7:22 AM, Winterbottom, James wrote: > A couple of thoughts spring to mind. > > This is not actually something that an end-user, you or me, would > generally be able to detect, it is more something that a LIS > provider or > even more likely still a PSAP operator would detect isn't it? > > I would like to understand a little more about who would use such a > scheme an when. I am certainly not suggesting that it is a bad or > unnecessary thing. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 07 08:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I79kT-00038A-VR; Sat, 07 Jul 2007 08:50:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I79kQ-000380-MA for ecrit@ietf.org; Sat, 07 Jul 2007 08:50:50 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I79kM-0002qY-9D for ecrit@ietf.org; Sat, 07 Jul 2007 08:50:50 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I79kE-0001e9-9N; Sat, 07 Jul 2007 07:50:38 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Winterbottom, James'" References: <468F760D.7080408@gmx.net> <6AD600EC-3664-46A0-B4AC-10539F9A2FCB@cs.columbia.edu> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Sat, 7 Jul 2007 08:50:42 -0400 Message-ID: <085f01c7c095$6f820300$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6AD600EC-3664-46A0-B4AC-10539F9A2FCB@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfAkK1hWbdP4vcvQjyfAd8ofEFAZgABGGEQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yep The errors in the LoST database would usually be found by the access network. It's supposed to validate BEFORE it puts locations into its LIS. That error reporting is likely to be highly automated (a web service). The errors in the LIS itself would usually be found by the user. The error reporting is more manual (phone call or web form). The NENA language was primarily directed at the former, but the latter is very important also. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, July 07, 2007 8:00 AM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] NENA requirement: contact URI for resolving > errorsindatabase > > I can't speak for the NENA team that developed the requirement list, > but I think ECRIT (maybe in its pre-WG state) also discussed some > version of this. > > Let's say a civic address is flagged as "wrong", i.e., in LoST, that > one element doesn't agree with another, such as a street address not > existing for the town. There are now two possibilities: The user/ISP > is wrong and the less likely case that the LoST database is out of > sync with reality. Supposedly, in certain fast-growing parts of the > US, streets in subdivisions are added faster than the civic > authorities can keep up with. Now, whoever generated the location > data needs to contact the authorities to fix the problem. Currently, > this seems to involve a highly manual process involving fax machines > and telephone calls, and I suspect lots of uncorrected errors. > > The URI would point to a web page, phone number or email address that > the end user or other LoST querier could report potential address > verification problems to. > > In some cases, the LoST querier won't be the party that actually can > do anything about the problem, since they didn't generate the > location information and may not even know who did, but they can > presumably relay this information via the SIP location conveyance > mechanism to a party that might. Usually, that will involve a human > making a judgement. ("I KNOW I just moved to 123 Cedar Lane, even if > the asphalt is still steaming." --> contact civic authority via this > URL; "I don't know why Verizon believes that I'm living on 123 > Belchertown Avenue - that street was renamed ages ago." --> contact > Verizon via information in the LI). > > Thus, we probably need two such URLs, namely one for the location > information itself (the source does this do some extent), and the > other for LoST. In general, you want to make it easy for people to > help fix things ahead of an actual emergency. > > Henning > > On Jul 7, 2007, at 7:22 AM, Winterbottom, James wrote: > > > A couple of thoughts spring to mind. > > > > This is not actually something that an end-user, you or me, would > > generally be able to detect, it is more something that a LIS > > provider or > > even more likely still a PSAP operator would detect isn't it? > > > > I would like to understand a little more about who would use such a > > scheme an when. I am certainly not suggesting that it is a bad or > > unnecessary thing. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 08 16:00:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7cvE-0006S6-6L; Sun, 08 Jul 2007 15:59:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7cvC-0006LF-PG for ecrit@ietf.org; Sun, 08 Jul 2007 15:59:54 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7cvC-0003Qw-Fy for ecrit@ietf.org; Sun, 08 Jul 2007 15:59:54 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2007 15:59:46 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKbekEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,514,1175486400"; d="scan'208"; a="64627472:sNHT29120650" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l68JxjTu022123; Sun, 8 Jul 2007 15:59:45 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l68Jxjs0028041; Sun, 8 Jul 2007 19:59:45 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Jul 2007 15:59:45 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Jul 2007 15:59:45 -0400 From: "Marc Linsner" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Sun, 8 Jul 2007 15:59:44 -0400 Message-ID: <009401c7c19a$8807b7c0$220d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6AD600EC-3664-46A0-B4AC-10539F9A2FCB@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfAjl6yfQ+IKGItTYSzqMYF+8BMOgBC9Xyg X-OriginalArrivalTime: 08 Jul 2007 19:59:45.0444 (UTC) FILETIME=[88040E40:01C7C19A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3207; t=1183924786; x=1184788786; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20NENA=20requirement=3A=20contact=20URI=20for =20resolving=20errorsindatabase |Sender:=20 |To:=20=22'Henning=20Schulzrinne'=22=20; bh=Zc/4qIAY0ztkM/KeZ0R1LaF6ulNB6aUqu/GNZkLpCzc=; b=RltmUAzbZuoBMWPJeGJ/8lAsRd75qdcHwl7CwbUljMAzxI2/yyOP9SF8AoYcaP1MJR0qQZFU 6CSifN5hoXBL0rBRU6/iNE1Ogz7glDNPnqAr8ePwB1kvb3unfOOUj5FU; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, Just curious....a little off topic. What is going to happen when a location is ambiguous such that the correct tree can't be determined, hence can't get to the correct authoritative data to get the uri to point to where to find help?? -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, July 07, 2007 8:00 AM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] NENA requirement: contact URI for > resolving errorsindatabase > > I can't speak for the NENA team that developed the > requirement list, but I think ECRIT (maybe in its pre-WG > state) also discussed some version of this. > > Let's say a civic address is flagged as "wrong", i.e., in > LoST, that one element doesn't agree with another, such as a > street address not existing for the town. There are now two > possibilities: The user/ISP is wrong and the less likely case > that the LoST database is out of sync with reality. > Supposedly, in certain fast-growing parts of the US, streets > in subdivisions are added faster than the civic authorities > can keep up with. Now, whoever generated the location data > needs to contact the authorities to fix the problem. > Currently, this seems to involve a highly manual process > involving fax machines and telephone calls, and I suspect > lots of uncorrected errors. > > The URI would point to a web page, phone number or email > address that the end user or other LoST querier could report > potential address verification problems to. > > In some cases, the LoST querier won't be the party that > actually can do anything about the problem, since they didn't > generate the location information and may not even know who > did, but they can presumably relay this information via the > SIP location conveyance mechanism to a party that might. > Usually, that will involve a human making a judgement. ("I > KNOW I just moved to 123 Cedar Lane, even if the asphalt is > still steaming." --> contact civic authority via this URL; "I > don't know why Verizon believes that I'm living on 123 > Belchertown Avenue - that street was renamed ages ago." --> > contact Verizon via information in the LI). > > Thus, we probably need two such URLs, namely one for the > location information itself (the source does this do some > extent), and the other for LoST. In general, you want to make > it easy for people to help fix things ahead of an actual emergency. > > Henning > > On Jul 7, 2007, at 7:22 AM, Winterbottom, James wrote: > > > A couple of thoughts spring to mind. > > > > This is not actually something that an end-user, you or me, would > > generally be able to detect, it is more something that a > LIS provider > > or even more likely still a PSAP operator would detect isn't it? > > > > I would like to understand a little more about who would use such a > > scheme an when. I am certainly not suggesting that it is a bad or > > unnecessary thing. > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 08 17:06:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7dxf-000401-Qo; Sun, 08 Jul 2007 17:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7dxe-0003zt-Jx for ecrit@ietf.org; Sun, 08 Jul 2007 17:06:30 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7dxa-00075b-8V for ecrit@ietf.org; Sun, 08 Jul 2007 17:06:30 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l68L6IDN021074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 8 Jul 2007 17:06:18 -0400 (EDT) In-Reply-To: <009401c7c19a$8807b7c0$220d0d0a@amer.cisco.com> References: <009401c7c19a$8807b7c0$220d0d0a@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <545C80F0-4B67-4413-B806-C085794C6AB1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Sun, 8 Jul 2007 17:06:15 -0400 To: "Marc Linsner" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Presumably, it would lead to a LoST failure response, just as if you were asking for a tree that truly doesn't exist even if the location itself is valid. I'm guessing that trees would be at least state- wide, so the likelihood of that information being wrong seems low. On Jul 8, 2007, at 3:59 PM, Marc Linsner wrote: > Henning, > > Just curious....a little off topic. What is going to happen when a > location > is ambiguous such that the correct tree can't be determined, hence > can't get > to the correct authoritative data to get the uri to point to where > to find > help?? > > -Marc- > > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Saturday, July 07, 2007 8:00 AM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] NENA requirement: contact URI for >> resolving errorsindatabase >> >> I can't speak for the NENA team that developed the >> requirement list, but I think ECRIT (maybe in its pre-WG >> state) also discussed some version of this. >> >> Let's say a civic address is flagged as "wrong", i.e., in >> LoST, that one element doesn't agree with another, such as a >> street address not existing for the town. There are now two >> possibilities: The user/ISP is wrong and the less likely case >> that the LoST database is out of sync with reality. >> Supposedly, in certain fast-growing parts of the US, streets >> in subdivisions are added faster than the civic authorities >> can keep up with. Now, whoever generated the location data >> needs to contact the authorities to fix the problem. >> Currently, this seems to involve a highly manual process >> involving fax machines and telephone calls, and I suspect >> lots of uncorrected errors. >> >> The URI would point to a web page, phone number or email >> address that the end user or other LoST querier could report >> potential address verification problems to. >> >> In some cases, the LoST querier won't be the party that >> actually can do anything about the problem, since they didn't >> generate the location information and may not even know who >> did, but they can presumably relay this information via the >> SIP location conveyance mechanism to a party that might. >> Usually, that will involve a human making a judgement. ("I >> KNOW I just moved to 123 Cedar Lane, even if the asphalt is >> still steaming." --> contact civic authority via this URL; "I >> don't know why Verizon believes that I'm living on 123 >> Belchertown Avenue - that street was renamed ages ago." --> >> contact Verizon via information in the LI). >> >> Thus, we probably need two such URLs, namely one for the >> location information itself (the source does this do some >> extent), and the other for LoST. In general, you want to make >> it easy for people to help fix things ahead of an actual emergency. >> >> Henning >> >> On Jul 7, 2007, at 7:22 AM, Winterbottom, James wrote: >> >>> A couple of thoughts spring to mind. >>> >>> This is not actually something that an end-user, you or me, would >>> generally be able to detect, it is more something that a >> LIS provider >>> or even more likely still a PSAP operator would detect isn't it? >>> >>> I would like to understand a little more about who would use such a >>> scheme an when. I am certainly not suggesting that it is a bad or >>> unnecessary thing. >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 08 20:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7hXK-0005YJ-1I; Sun, 08 Jul 2007 20:55:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7hXI-0005QC-WA for ecrit@ietf.org; Sun, 08 Jul 2007 20:55:33 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7hXE-0006In-FN for ecrit@ietf.org; Sun, 08 Jul 2007 20:55:32 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I7hWy-0001nq-Og; Sun, 08 Jul 2007 19:55:13 -0500 From: "Brian Rosen" To: , "'ECRIT'" References: <464177A2.9040104@ntt-at.com> Subject: RE: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt Date: Sun, 8 Jul 2007 20:55:19 -0400 Message-ID: <0bc501c7c1c3$d6f96300$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <464177A2.9040104@ntt-at.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AceSCxSGVYvbe5CXTBKjf1FydkyI8grzH4Eg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I am (finally working on framework-02 and am working through your = comments. See inline > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Wednesday, May 09, 2007 3:26 AM > To: ECRIT > Subject: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt >=20 > Draft: draft-ietf-ecrit-framework-01 > Reviewer: Shida Schubert > Review Date: 2007.05.02 >=20 > Summary: > ---------------------------------------- > - Overall I think it's a well written draft giving a > really good overview of how everything interacts. >=20 > - The draft needs some overhaul reflecting all the recent > discussions in ECRIT, GEOPRIV and SIP WG regarding > location hiding, emergency call verification, L7 LCP etc. >=20 > - The terminology needs to be aligned with the current version > of requirement/LoST draft. >=20 > Technical Comments: > ---------------------------------------- > T1: Chapter 3, 1st paragraph, 1st sentence. > - Although we haven't come to a conclusion on how emergency > call is distinguished, I believe the currently many see it > as either by a emergency dialstring or by service URN. > - The current text seems to allude that dialstring is necessary > to place the (Emergency) service URN. The sentence currently reads: We distinguish (Section 4 (Identifying an Emergency Call)) an emergency = call from any other call by a unique Service = URN[I=E2=80=91D.ietf=E2=80=91ecrit=E2=80=91service=E2=80=91urn] = (Schulzrinne, H., =E2=80=9CA Uniform Resource Name (URN) for = Services,=E2=80=9D August 2006.), which is placed in the initial call = set-up signaling when a home or visited emergancy dialstring is = detected. What other way, other than recognizing the dialstring would there be? "Emergency" buttons are not a good idea, because they cause too many = false calls. The text at this point doesn't say if the endpoint or = server detects the dialstring. The dialstring isn't an emergency call = until it=E2=80=99s detected as such by the endpoint or proxy, at which = time it gets the service URN. Perhaps you could elaborate on your = concern and suggest some changes. >=20 > T2: Chapter 4, 3rd paragraph, 3rd sentence. > - I don't think the following text is true. > "It should be noted that the endpoint would not normally supply > location unless it understood the call to be an emergency call." > > I see this to be somewhat misleading. It's true in case of > an emergency if UA supports location, it should without a doubt > include location information but the statement above is definitely > not correct. If the text is merely a note, it may be good to simply > remove the text. I deleted it because the section is not about location. >=20 > T3. Chapter 5.8, 1st paragraph, 1st sentence. > - Although not a normative text, "Location must be validated" seems = a > bit > too strong. I don't have a strong feeling for this but I prefer > something > like a should rather than a must.. I added "In some jurisdictions" and "and is always recommended' >=20 > Clarification Needed: > ---------------------------------------- > C1: Chapter 2, last 2 paragraphs. > - It's unsure what "this document", "this draft" is pointing at. > From the context it seems to be pointing at the phone-bcp but > it's unclear. I reworded parts of the text. Take a look and see if I have fixed what = you were confused about >=20 > C2: Chapter2, last 2 paragraphs. > - If these paragraphs are indeed about phone-bcp then the last > sentence is incorrect. As far as I understand phone-bcp will > have recommended behavior of LoST, proxy(outbound and others) > and UAs. The paragraphs were supposed to refer to the framework doc. Hopefully, = the edits make it more clear, although it doesn't matter if you read = them as applying to -phonebcp. >=20 > C3: Chapter 3, 3rd paragraph, 3rd sentence. > - The reason why registration is necessary is not mentioned here. > If it's for call-back purpose I think it should be mentioned > as well. What about non-authorized device that can't REGISTER? I added the reason. I added text in location and call back discussing = uninitialized devices. >=20 > C4: Chapter 5.3, 3rd paragraph, 2nd sentence. > - It's unclear what policy you mean by "To facilitate such > policy decision". Fixed >=20 > C5: Chapter 5.3, 3rd paragraph, 3rd sentence. > - What do you mean by the generator of the location information? > Is generator same as whatever goes into the in > PIDF-LO? Fixed. It is "provided-by" >=20 >=20 > Editorial Comments: > ---------------------------------------- > E1: Chapter 3, 1st paragraph, 1st sentence. > - Although we haven't come to a conclusion on how emergency > call is distinguished, I believe the currently many see it > as either by a emergency dialstring or by service URN. > - The current text seems to allude that dialstring is necessary > to place the (Emergency) service URN. See above >=20 > E2: Chapter 3, 2nd paragraph, 3rd bullet, last sentence. > - Term LoST dip is used although one can assume what it means, > it's not the term used in LoST document thus should probably > use the proper term used in LoST document. (Same term is used > in section 6, 2nd last paragraph) Fixed >=20 > E3: Chapter 3, 2nd paragraph, 4th bullet, 1st sentence. > - Service URN is not mentioned as the parameter used to resolve > PSAP URIs. >=20 > OLD: LoST Server - Processes the LoST request for Location to = PSAP-URI > Mapping function, either for an initial request from a UA, or an > in-call routing by the Proxy server in the originating network, = or > possibly by an ESRP. >=20 > NEW: LoST Server - Processes the LoST request for Location + = Service > URN > to PSAP-URI Mapping function, either for an initial request from = a > UA, > or an in-call routing by the Proxy server in the originating > network, > or possibly by an ESRP. Fixed >=20 > E4: Chapter 3, 3rd paragraph, 2nd sentence. > - Acronym LCP is used without any introduction to it. The following > text > change should be made where location configuration protocol is > mentioned. >=20 > OLD: Generally, Alice's UA either has location configured manually, = has > an > integral location measurement mechanism, or it runs a location > configuration protocol to obtain location from the access > (broadband) > network. >=20 > NEW: Generally, Alice's UA either has location configured manually, = has > an > integral location measurement mechanism, or it runs a location > configuration protocol (LCP) to obtain location from the = access > (broadband) > network. Fixed >=20 > E5: Chapter 3, 3rd paragraph, 4th sentence. > - The reason to obtain PSAP URI prior to making an emergency call > is to have something to use in case of LoST failure at emergency > time and also for testing. >=20 > OLD: Next, her UA will perform an initial LoST Location-to-PSAP > SIP(S)-URI > query to learn a URI, for use if the Lost Query fails during = an > emergency call. > NEW: Next, her UA will perform an initial LoST Location-to-PSAP > SIP(S)-URI > query to learn a URI, for use if the Lost Query fails during = an > emergency call or to use it to test emergency call. Fixed >=20 > E6: Chapter 5.3, 4th paragraph, last sentence. > - The reference to location conveyance is currently to that of LoST. > Needs to be > fixed. Fixed >=20 > E7: Chapter 5.5, 3rd paragraph, last sentence. > - The reference is made to LoST which should be changed to = Phone-BCP. Fixed >=20 > E8: Chapter 5.8. > - Although not a normative text, "Location must be validated" seems = a > bit > too strong. Addressed, as above >=20 > E9: Chapter 10, 2nd paragraph, 1st sentence. > - redundant "of". Fixed >=20 >=20 >=20 > I hope it helps. Yes, it did, thank you Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 08:23:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sGt-0000jS-FU; Mon, 09 Jul 2007 08:23:19 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7sGj-000088-8O for ecrit@ietf.org; Mon, 09 Jul 2007 08:23:09 -0400 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7sGi-0005uA-6h for ecrit@ietf.org; Mon, 09 Jul 2007 08:23:09 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-outbound.avaya.com with ESMTP; 09 Jul 2007 08:22:35 -0400 X-IronPort-AV: i="4.16,516,1175486400"; d="txt'?scan'208,217"; a="39988782:sNHT24153480" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C7C223.BC27DC26" Date: Mon, 9 Jul 2007 14:21:53 +0200 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [New-work] OMA New Work - 1 New Work Item Approved - Location inSIP/IP core Thread-Index: Ace/AtN1NDs+xhLvSmq8ByIABQyoOgDINafA From: "Romascanu, Dan (Dan)" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Subject: [Ecrit] FW: [New-work] OMA New Work - 1 New Work Item Approved - Location inSIP/IP core X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C223.BC27DC26 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7C223.BC27DC26" ------_=_NextPart_002_01C7C223.BC27DC26 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 ________________________________ From: Victoria Gray [mailto:Victoria.Gray@forapolis.com]=20 Sent: Thursday, July 05, 2007 3:49 PM To: new-work@ietf.org Subject: [New-work] OMA New Work - 1 New Work Item Approved - Location inSIP/IP core Dear All, OMA would like to inform all the organisations subscribed to the IETF new-work list of the approval of 1 new work item: 1 Location in SIP/IP Core WI: http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_docu ments/OMA-WID_0149-LOCSIP-V1_0-20070704-A.zip =20 Background : OMA has developed various enablers related to location. The MLS enabler has the main purpose to define protocols for exposure of terminal location to applications but do not define any positioning determination mechanisms. SUPL on the other hand defines procedures and protocols for positioning determination of a terminal utilizing an IP connection between server and terminal. Both enablers are to some extent prepared for use in a SIP context e.g. by allowing use of SIP-URI identities. None of them do however support exposure of terminal location to an application within a SIP/IP core network (one example of such a network is an IP Multimedia Subsystem). The implication of this is that a SIP Application Server needing location information to enhance its services needs to implement one or more non-SIP interfaces to Location Servers. By instead defining an interface & procedure using SIP, additional interface technologies can be avoided and routing and addressing mechanisms in the SIP/IP Core as well as existing SIP based OMA enablers (such as XDM) can be reused. Objective: The purpose of this work item is to specify a service enabler for exposing location information to applications in a SIP/IP core network (e.g an IP Multimedia Subsystem). The service enabler is to be specified as a reusable network component in a SIP/IP core network, capable of receiving and responding to location subscriptions over a standardised SIP-based interface. Handling of the location specific functions within a SIP/IP core is to be specified but positioning determination functions within SIP/IP core are out of scope. The LOCSIP enabler will take into account the OMA MLS enabler.=20 The enabler shall specifically consider interworking with other OMA enablers that potentially utilize location information e.g. Presence SIMPLE and PoC. The resulting specification shall preferably reuse available IETF specifications e.g. IETF Geopriv deliverables.=20 Location in SIP/IP core enabler implementations may interwork with applicable positioning determination functions in access networks and/or at UE. Possible positioning determination functions depend on support in IP-CAN and UEs, but are expected to at least include 3GPP/3GPP2 LCS and OMA SUPL (Secure User Plane Location). This work item has been allocated to the OMA LOC (Location) WG for specification development. Best regards, Victoria Gray on behalf of OMA. =20 Victoria Gray FORApolis / DSO Tel +33 (0)4 92 94 49 23 Fax +33 (0)4 92 38 49 23 GSM +33 (0)6 73 99 62 90 victoria.gray@forapolis.com =20 MSN: victoria.gray@forapolis.com Yahoo!: bluevicci Skype: victoria-gray Google: vics.gray@gmail.com =20 ------_=_NextPart_002_01C7C223.BC27DC26 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
 
 
 

From: Victoria Gray=20 [mailto:Victoria.Gray@forapolis.com]
Sent: Thursday, July 05, = 2007=20 3:49 PM
To: new-work@ietf.org
Subject: [New-work] = OMA New=20 Work - 1 New Work Item Approved - Location inSIP/IP = core

Dear All,

OMA would like to inform all the organisations subscribed to the IETF = new-work list of the approval of 1 new=20 work item:

1 Location=20 in SIP/IP Core WI:

http://www.openmobilealliance.org/ftp/Public_documents/TP/Perman= ent_documents/OMA-WID_0149-LOCSIP-V1_0-20070704-A.zip

Background=20 :=20 OMA has developed various enablers related to location. The MLS enabler = has the=20 main purpose to define protocols for exposure of terminal location to=20 applications but do not define any positioning determination mechanisms. = SUPL on=20 the other hand defines procedures and protocols for positioning = determination of=20 a terminal utilizing an IP connection between server and terminal. Both = enablers=20 are to some extent prepared for use in a SIP context e.g. by allowing = use of=20 SIP-URI identities. None of them do however support exposure of terminal = location to an application within a SIP/IP core network (one example of = such a=20 network is an IP Multimedia Subsystem). The implication of this is that = a  SIP Application Server needing = location=20 information to enhance its services needs to implement one or more = non-SIP=20 interfaces to Location Servers. By instead defining an interface & = procedure=20 using SIP, additional interface technologies can be avoided and routing = and=20 addressing mechanisms in the SIP/IP Core as well as existing SIP based = OMA=20 enablers (such as XDM) can be reused.

Objective:=20 The purpose of this work item is to specify a service enabler for = exposing=20 location information to applications in a SIP/IP core network (e.g an IP = Multimedia Subsystem). The service enabler is to be specified as a = reusable=20 network component in a SIP/IP core network, capable of receiving and = responding=20 to location subscriptions over a standardised SIP-based interface. = Handling of=20 the location specific functions within a SIP/IP core  is to be specified but = positioning=20 determination functions within SIP/IP core are out of scope. The LOCSIP enabler will take into account the = OMA MLS=20 enabler.

The enabler shall specifically consider interworking with other = OMA=20 enablers that potentially utilize location information e.g. Presence = SIMPLE and=20 PoC. The resulting specification shall preferably reuse available IETF=20 specifications e.g. IETF Geopriv deliverables. =

Location in SIP/IP core enabler implementations may interwork = with=20 applicable positioning determination functions in access networks and/or = at UE.=20 Possible positioning determination functions depend on support in IP-CAN = and=20 UEs, but are expected to at least include 3GPP/3GPP2 LCS and OMA SUPL = (Secure=20 User Plane Location).

This work=20 item has been allocated to the OMA LOC (Location) WG=20 for specification development.

Best regards,

Victoria Gray on behalf of OMA.

 
Victoria=20 Gray
FORApolis / = DSO
Tel +33 (0)4 92 94 49 = 23
Fax +33 (0)4 92 38 49 = 23
GSM +33 (0)6 73 99 62 = 90
victoria.gray@forapolis.com
 
MSN: victoria.gray@forapolis.com   Yahoo!: bluevicci
Skype: = victoria-gray  Google: = vics.gray@gmail.com
 
------_=_NextPart_002_01C7C223.BC27DC26-- ------_=_NextPart_001_01C7C223.BC27DC26 Content-Type: text/plain; name="ATT1682124.txt" Content-Transfer-Encoding: base64 Content-Description: ATT1682124.txt Content-Disposition: inline; filename="ATT1682124.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldy13b3Jr IG1haWxpbmcgbGlzdA0KTmV3LXdvcmtAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldy13b3JrDQo= ------_=_NextPart_001_01C7C223.BC27DC26 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C7C223.BC27DC26-- From ecrit-bounces@ietf.org Mon Jul 09 11:54:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vZf-0006oY-CH; Mon, 09 Jul 2007 11:54:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7vZe-0006oL-GI for ecrit@ietf.org; Mon, 09 Jul 2007 11:54:54 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7vZP-0002qd-8c for ecrit@ietf.org; Mon, 09 Jul 2007 11:54:54 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I7vZ0-0007HY-1E for ecrit@ietf.org; Mon, 09 Jul 2007 10:54:14 -0500 From: "Brian Rosen" To: "'ECRIT'" Date: Mon, 9 Jul 2007 11:54:20 -0400 Message-ID: <0d4f01c7c241$6b129070$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfCQWlfdxEvXBlkRLeCAWIn56sDbw== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ecrit] draft-ecrit-framework-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org My day job spiked at the wrong time, and I did not have time to adequately rev -framework and -phonebcp. I did put out a rev of -framework, incorporating all comments EXCEPT a lengthy set of comments from Henning (Prof Schulzrinne red penned my work, I think I would have gotten a D-). Until it is announced, you can get a copy at: http://www.brianrosen.net/internet-drafts/draft-ecrit-framework-02.txt http://www.brianrosen.net/internet-drafts/draft-ecrit-framework-02.html As we are still working on details of LoST and location things that directly affect both -framework and -phonebcp I don't feel too badly about missing this cycle. Once we really, truly, get the big picture settled, then it will be the time for us to finish both of these docs. Too me, the huge holes in these docs are related to location issues not settled, like HELD details, dereferencing, location hiding and location integrity ("signing"), as well as how IMS networks conform to the docs. I'd welcome any comments on what is there. I will put out a rev to -phonebcp incorporating all comments received soon, and do a "real" rev of both later reflecting changes in the big picture. We do hope to have both docs in WGLC by the end of the year. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 13:14:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wp1-0006Xv-2O; Mon, 09 Jul 2007 13:14:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7woz-0006Xo-N3 for ecrit@ietf.org; Mon, 09 Jul 2007 13:14:49 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7woq-0004x3-Dm for ecrit@ietf.org; Mon, 09 Jul 2007 13:14:49 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l69HD7df013852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2007 10:13:08 -0700 Received: from [129.46.78.208] (carbuncle.qualcomm.com [129.46.78.208]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l69HD6Td027601; Mon, 9 Jul 2007 10:13:06 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> References: <8C837214C95C864C9F3 4F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> Date: Mon, 9 Jul 2007 10:13:05 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Roger Marshall'" From: Ted Hardie Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 8:38 PM -0400 7/6/07, Brian Rosen wrote: > >Finally, I am planning to write an I-D creating a service:nena namespace, >which NENA will administer. Happy to have a generic address location error >reporting service, and we'll use it, but we're also quite happy to create a >local service for this purpose if others have a problem. > >Brian Hi Brian, I assume you mean a urn namespace . If so, the guarantee of uniqueness rules for URNs make it a bit tricky for the IETF to take part of a namespace and hand it out to another org; it would be easier to register a URN NID for NENA (i.e. urn:nena: , instead of urn:service:nena). What would be the downside of using that approach? Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 13:23:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wxU-0002Ip-18; Mon, 09 Jul 2007 13:23:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wxS-0002IC-Ng for ecrit@ietf.org; Mon, 09 Jul 2007 13:23:34 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7wwY-0006WR-3v for ecrit@ietf.org; Mon, 09 Jul 2007 13:23:34 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I7wwN-0008Bs-MK; Mon, 09 Jul 2007 12:22:27 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Roger Marshall'" References: <8C837214C95C864C9F3 4F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Mon, 9 Jul 2007 13:22:34 -0400 Message-ID: <0d6401c7c24d$bec76f40$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfCTGyuEdjoL4TqSQOwfg2y4JW1TgAAOJrw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 2.5 (++) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The downside is only that it wouldn't meet the wording in the service urn RFC. I don't think it has any practical problem. I fail to see why IETF can't allocate urn:service:nena based on a RFC and then let NENA create subservices (urn:service:nena.address-error-report). There is certainly no uniqueness problem with that. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, July 09, 2007 1:13 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Roger Marshall' > Cc: 'ECRIT' > Subject: RE: [Ecrit] NENA requirement: contact URI for resolving > errorsindatabase > > At 8:38 PM -0400 7/6/07, Brian Rosen wrote: > > > >Finally, I am planning to write an I-D creating a service:nena namespace, > >which NENA will administer. Happy to have a generic address location > error > >reporting service, and we'll use it, but we're also quite happy to create > a > >local service for this purpose if others have a problem. > > > >Brian > > Hi Brian, > I assume you mean a urn namespace . If so, the guarantee of > uniqueness > rules for URNs make it a bit tricky for the IETF to take part of a > namespace > and hand it out to another org; it would be easier to register a URN NID > for NENA (i.e. urn:nena: , instead of urn:service:nena). What would be > the downside of using that approach? > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 13:51:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xOk-0002S3-RW; Mon, 09 Jul 2007 13:51:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7xOj-0002Rq-5o for ecrit@ietf.org; Mon, 09 Jul 2007 13:51:45 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7xOi-0007HZ-AM for ecrit@ietf.org; Mon, 09 Jul 2007 13:51:45 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l69HoKZq030850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2007 10:50:21 -0700 Received: from [129.46.78.208] (carbuncle.qualcomm.com [129.46.78.208]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l69HoJeM028814; Mon, 9 Jul 2007 10:50:20 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <0d6401c7c24d$bec76f40$640fa8c0@cis.neustar.com> References: <8C837214C95C864C9F3 4F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> <0d6401c7c24d$bec76f40$640fa8c0@cis.neustar.com> Date: Mon, 9 Jul 2007 10:50:18 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Roger Marshall'" From: Ted Hardie Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 1:22 PM -0400 7/9/07, Brian Rosen wrote: >The downside is only that it wouldn't meet the wording in the service urn >RFC. I don't think it has any practical problem. > >I fail to see why IETF can't allocate urn:service:nena based on a RFC and >then let NENA create subservices (urn:service:nena.address-error-report). >There is certainly no uniqueness problem with that. > >Brian Brian, If you want this to work, I think you have to convince folks to pull draft-ietf-ecrit-service-urn-06.txt before it becomes a BCP. It sets out a registration mechanism according to RFC 3406 that's a fairly standard NID. As it stands, the document says; Services and sub-services are identified by labels managed by IANA, according to the processes outlined in [3] in a new registry called "Service URN Labels". Thus, creating a new service requires IANA action. The policy for adding top-level service labels is 'Standards Action'. (This document defines the top-level service 'sos' and 'counseling'.) The policy for assigning labels to sub-services may differ for each top-level service designation and MUST be defined by the document describing the top-level service. This says that sub-services are managed by IANA; if you want to define a mechanism where the sub-services may be managed by someone else, I think that is in conflict with what the document currently says. I also think the folks who have been thinking about NIDs for a long time will have a problem with it. The urn:service:sos mechanism is one type of registration (where a class of services is identified at the second level of the syntax) and urn:service:nena is pretty different (the same place in the syntax has the semantic of sub-registrant). Sub-registrants where the primary registrant is IANA needs some real discussion with IANA, as IANA will have to coordinate them (presuming we keep all of the publication by IANA). Having a separate NID is easier, in my opinion. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 14:30:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y08-00007j-3l; Mon, 09 Jul 2007 14:30:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y06-00007I-PR for ecrit@ietf.org; Mon, 09 Jul 2007 14:30:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I7y06-0001ov-BC for ecrit@ietf.org; Mon, 09 Jul 2007 14:30:22 -0400 Received: (qmail invoked by alias); 09 Jul 2007 18:23:01 -0000 Received: from p54987D81.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.125.129] by mail.gmx.net (mp037) with SMTP; 09 Jul 2007 20:23:01 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/XQ0FVaDjXq2BUIaP+SD+gbszRp7g6pYLPWzLQdR CikPAQHcJNe2Kj Message-ID: <46927D01.3010905@gmx.net> Date: Mon, 09 Jul 2007 20:22:57 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] draft-ecrit-framework-02 References: <0d4f01c7c241$6b129070$640fa8c0@cis.neustar.com> In-Reply-To: <0d4f01c7c241$6b129070$640fa8c0@cis.neustar.com> 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: e8a67952aa972b528dd04570d58ad8fe Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, thanks for the update. Brian Rosen wrote: > My day job spiked at the wrong time, and I did not have time to adequately > rev -framework and -phonebcp. I did put out a rev of -framework, > incorporating all comments EXCEPT a lengthy set of comments from Henning > (Prof Schulzrinne red penned my work, I think I would have gotten a D-). > Many of us went through this already :-) Sometimes I thought it would have been better for Henning to re-write the draft right away. > Until it is announced, you can get a copy at: > > http://www.brianrosen.net/internet-drafts/draft-ecrit-framework-02.txt > http://www.brianrosen.net/internet-drafts/draft-ecrit-framework-02.html > > I will review them for the IETF meeting. > As we are still working on details of LoST and location things that directly > affect both -framework and -phonebcp I don't feel too badly about missing > this cycle. Once we really, truly, get the big picture settled, then it > will be the time for us to finish both of these docs. > I agree with you. > Too me, the huge holes in these docs are related to location issues not > settled, like HELD details, dereferencing, location hiding and location > integrity ("signing"), as well as how IMS networks conform to the docs. > Let's try not to cover everything in a single document. It's fine to point to HELD. I would not cover * Location Hiding * Location Signing * Unauthenticated Network Access The interaction with 3GPP IMS is even more difficult. I have an action item to schedule a conf. call between ECRIT and the 3GPP to discuss this issue. > I'd welcome any comments on what is there. I will put out a rev to > -phonebcp incorporating all comments received soon, and do a "real" rev of > both later reflecting changes in the big picture. We do hope to have both > docs in WGLC by the end of the year. > Thanks for the estimate. Ciao Hannes > Brian > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 14:30:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y0G-0000CL-H5; Mon, 09 Jul 2007 14:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y0F-0000C3-Eg for ecrit@ietf.org; Mon, 09 Jul 2007 14:30:31 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7y0A-0000eE-UN for ecrit@ietf.org; Mon, 09 Jul 2007 14:30:31 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I7xzz-00085s-8z; Mon, 09 Jul 2007 13:30:15 -0500 From: "Brian Rosen" To: "'Ted Hardie'" , "'Henning Schulzrinne'" , "'Roger Marshall'" References: <8C837214C95C864C9F3 4F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> <0d6401c7c24d$bec76f40$640fa8c0@cis.neustar.com> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Mon, 9 Jul 2007 14:30:17 -0400 Message-ID: <0e7001c7c257$35021260$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfCUZpJw/h00Vd2RiKxQIt+pDsH0wABB/1A X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have no interest in pulling the service urn draft. I don't really have a problem with asking for a NID. I don't see why a standards track RFC creating service:nena could not allow NENA to manage the subservices. It is after all, required to be standards track, and thus could slightly redefine the service URN to permit the subservice labels to be managed by someone else. It would also be perfectly acceptable to define the process for subservice registration to be IANA managed with a NENA document as the controlling document, possibly with IETF expert review. It's also possible to do this with no IETF work at all, since the domain of the services would be limited to LoST servers that NENA specifies, and these services would NOT be visible to the Internet. I'd prefer to do it with something that DID have a standards track document, and until all such avenues are blocked, I'll be going in that direction. I'll do what the community judges is the "best" and least work way. NENA doesn't care. Brian > -----Original Message----- > From: Ted Hardie [mailto:hardie@qualcomm.com] > Sent: Monday, July 09, 2007 1:50 PM > To: Brian Rosen; 'Henning Schulzrinne'; 'Roger Marshall' > Cc: 'ECRIT' > Subject: RE: [Ecrit] NENA requirement: contact URI for resolving > errorsindatabase > > At 1:22 PM -0400 7/9/07, Brian Rosen wrote: > >The downside is only that it wouldn't meet the wording in the service urn > >RFC. I don't think it has any practical problem. > > > >I fail to see why IETF can't allocate urn:service:nena based on a RFC and > >then let NENA create subservices (urn:service:nena.address-error-report). > >There is certainly no uniqueness problem with that. > > > >Brian > > Brian, > If you want this to work, I think you have to convince folks > to pull draft-ietf-ecrit-service-urn-06.txt before it becomes a BCP. > It sets out a registration mechanism according to RFC 3406 that's > a fairly standard NID. As it stands, the document says; > > Services and sub-services are identified by labels managed by IANA, > according to the processes outlined in [3] in a new registry called > "Service URN Labels". Thus, creating a new service requires IANA > action. The policy for adding top-level service labels is 'Standards > Action'. (This document defines the top-level service 'sos' and > 'counseling'.) The policy for assigning labels to sub-services may > differ for each top-level service designation and MUST be defined by > the document describing the top-level service. > > > This says that sub-services are managed by IANA; if you want > to define a mechanism where the sub-services may be managed > by someone else, I think that is in conflict with what > the document currently says. I also think the folks who > have been thinking about NIDs for a long time will have > a problem with it. The urn:service:sos mechanism is one > type of registration (where a class of services is identified > at the second level of the syntax) and urn:service:nena is > pretty different (the same place in the syntax has the semantic > of sub-registrant). Sub-registrants where the primary registrant > is IANA needs some real discussion with IANA, as IANA will > have to coordinate them (presuming we keep all of the publication > by IANA). > > Having a separate NID is easier, in my opinion. > > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 14:34:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y3w-0001ii-Hv; Mon, 09 Jul 2007 14:34:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7y3v-0001iV-Fv for ecrit@ietf.org; Mon, 09 Jul 2007 14:34:19 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I7y3u-0001y4-W2 for ecrit@ietf.org; Mon, 09 Jul 2007 14:34:19 -0400 Received: (qmail invoked by alias); 09 Jul 2007 18:33:53 -0000 Received: from p54987D81.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.125.129] by mail.gmx.net (mp035) with SMTP; 09 Jul 2007 20:33:53 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18TxEkmZNUT7GE7WVCpVNyGOsJ0x0IN1gyQ2c3kIh xe1MlXHVzjP+xc Message-ID: <46927F7C.4090706@gmx.net> Date: Mon, 09 Jul 2007 20:33:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: [Ecrit] FW: [New-work] OMA New Work - 1 New Work Item Approved - Location inSIP/IP core 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: 5ebbf074524e58e662bc8209a6235027 Cc: GEOPRIV , ECRIT , Robert Sparks X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Dan, thanks for posting this to the list. I wonder whether there is awareness of the work related to * SIP Location Conveyance http://tools.ietf.org/wg/sip/draft-ietf-sip-location-conveyance/ * The ability to use the notify/subscribe concept for obtaining a PIDF-LO * A Document Format for Filtering and Reporting Location Notications in the Presence Information Document Format Location Object (PIDF-LO) http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-01.txt Maybe it is good to start an interaction between SIP & GEOPRIV and the OMA Location Group. Ciao Hannes Romascanu, Dan (Dan) wrote: > > > > > > ________________________________ > > From: Victoria Gray [mailto:Victoria.Gray@forapolis.com] > Sent: Thursday, July 05, 2007 3:49 PM > To: new-work@ietf.org > Subject: [New-work] OMA New Work - 1 New Work Item Approved - Location > inSIP/IP core > > > Dear All, > > OMA would like to inform all the organisations subscribed to the IETF > new-work list of the approval of 1 new work item: > > 1 Location in SIP/IP Core WI: > > http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_docu > ments/OMA-WID_0149-LOCSIP-V1_0-20070704-A.zip > uments/OMA-WID_0149-LOCSIP-V1_0-20070704-A.zip> > > Background : OMA has developed various enablers related to location. The > MLS enabler has the main purpose to define protocols for exposure of > terminal location to applications but do not define any positioning > determination mechanisms. SUPL on the other hand defines procedures and > protocols for positioning determination of a terminal utilizing an IP > connection between server and terminal. Both enablers are to some extent > prepared for use in a SIP context e.g. by allowing use of SIP-URI > identities. None of them do however support exposure of terminal > location to an application within a SIP/IP core network (one example of > such a network is an IP Multimedia Subsystem). The implication of this > is that a SIP Application Server needing location information to > enhance its services needs to implement one or more non-SIP interfaces > to Location Servers. By instead defining an interface & procedure using > SIP, additional interface technologies can be avoided and routing and > addressing mechanisms in the SIP/IP Core as well as existing SIP based > OMA enablers (such as XDM) can be reused. > > Objective: The purpose of this work item is to specify a service enabler > for exposing location information to applications in a SIP/IP core > network (e.g an IP Multimedia Subsystem). The service enabler is to be > specified as a reusable network component in a SIP/IP core network, > capable of receiving and responding to location subscriptions over a > standardised SIP-based interface. Handling of the location specific > functions within a SIP/IP core is to be specified but positioning > determination functions within SIP/IP core are out of scope. The LOCSIP > enabler will take into account the OMA MLS enabler. > > The enabler shall specifically consider interworking with other OMA > enablers that potentially utilize location information e.g. Presence > SIMPLE and PoC. The resulting specification shall preferably reuse > available IETF specifications e.g. IETF Geopriv deliverables. > > Location in SIP/IP core enabler implementations may interwork with > applicable positioning determination functions in access networks and/or > at UE. Possible positioning determination functions depend on support in > IP-CAN and UEs, but are expected to at least include 3GPP/3GPP2 LCS and > OMA SUPL (Secure User Plane Location). > > This work item has been allocated to the OMA LOC (Location) WG for > specification development. > > Best regards, > > Victoria Gray on behalf of OMA. > > > Victoria Gray > FORApolis / DSO > Tel +33 (0)4 92 94 49 23 > Fax +33 (0)4 92 38 49 23 > GSM +33 (0)6 73 99 62 90 > victoria.gray@forapolis.com > > MSN: victoria.gray@forapolis.com > Yahoo!: bluevicci > Skype: victoria-gray Google: vics.gray@gmail.com > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 14:59:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yRz-0001II-5V; Mon, 09 Jul 2007 14:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yRx-0001ID-J0 for ecrit@ietf.org; Mon, 09 Jul 2007 14:59:09 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yRt-0001gb-4L for ecrit@ietf.org; Mon, 09 Jul 2007 14:59:09 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l69Iwthn007613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Jul 2007 11:58:55 -0700 Received: from [129.46.78.208] (carbuncle.qualcomm.com [129.46.78.208]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l69Iwrxt028297; Mon, 9 Jul 2007 11:58:54 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <0e7001c7c257$35021260$640fa8c0@cis.neustar.com> References: <8C837214C95C864C9F3 4F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> <0d6401c7c24d$bec76f40$640fa8c0@cis.neustar.com> <0e7001c7c257$35021260$640fa8c0@cis.neustar.com> Date: Mon, 9 Jul 2007 11:58:51 -0700 To: "Brian Rosen" , "'Henning Schulzrinne'" , "'Roger Marshall'" From: Ted Hardie Subject: RE: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 2:30 PM -0400 7/9/07, Brian Rosen wrote: >I have no interest in pulling the service urn draft. > >I don't really have a problem with asking for a NID. This is the easiest thing to do, as it gives NENA full registration authority, and it is relatively easy to get through the IETF process. I can help with drafting that document, if you like. >I don't see why a standards track RFC creating service:nena could not allow >NENA to manage the subservices. It is after all, required to be standards >track, and thus could slightly redefine the service URN to permit the >subservice labels to be managed by someone else. > >It would also be perfectly acceptable to define the process for subservice >registration to be IANA managed with a NENA document as the controlling >document, possibly with IETF expert review. I think that would work as well, as it leaves IANA/IETF as the nominal registrant and sets up a mechanism by which IANA/IETF can maintain the NID standards. It would be a bit semantically odd to have sos and nena be peers in the syntax, but that's not really a show-stopper. The only real issue I see is if IANA had to deal with multiple sub-registrants. Assigning a NID is a one-off, from the IETF/IANA perspective, where ongoing registration requires a bit more effort. >It's also possible to do this with no IETF work at all, since the domain of >the services would be limited to LoST servers that NENA specifies, and these >services would NOT be visible to the Internet. I'd prefer to do it with >something that DID have a standards track document, and until all such >avenues are blocked, I'll be going in that direction. > >I'll do what the community judges is the "best" and least work way. NENA >doesn't care > >Brian Thanks for your willingness to be flexible on this. Ted > >> -----Original Message----- >> From: Ted Hardie [mailto:hardie@qualcomm.com] >> Sent: Monday, July 09, 2007 1:50 PM >> To: Brian Rosen; 'Henning Schulzrinne'; 'Roger Marshall' >> Cc: 'ECRIT' >> Subject: RE: [Ecrit] NENA requirement: contact URI for resolving >> errorsindatabase >> >> At 1:22 PM -0400 7/9/07, Brian Rosen wrote: >> >The downside is only that it wouldn't meet the wording in the service urn >> >RFC. I don't think it has any practical problem. >> > >> >I fail to see why IETF can't allocate urn:service:nena based on a RFC and >> >then let NENA create subservices (urn:service:nena.address-error-report). >> >There is certainly no uniqueness problem with that. >> > >> >Brian >> >> Brian, >> If you want this to work, I think you have to convince folks >> to pull draft-ietf-ecrit-service-urn-06.txt before it becomes a BCP. >> It sets out a registration mechanism according to RFC 3406 that's >> a fairly standard NID. As it stands, the document says; >> >> Services and sub-services are identified by labels managed by IANA, >> according to the processes outlined in [3] in a new registry called >> "Service URN Labels". Thus, creating a new service requires IANA >> action. The policy for adding top-level service labels is 'Standards >> Action'. (This document defines the top-level service 'sos' and >> 'counseling'.) The policy for assigning labels to sub-services may >> differ for each top-level service designation and MUST be defined by >> the document describing the top-level service. >> >> >> This says that sub-services are managed by IANA; if you want >> to define a mechanism where the sub-services may be managed >> by someone else, I think that is in conflict with what >> the document currently says. I also think the folks who >> have been thinking about NIDs for a long time will have >> a problem with it. The urn:service:sos mechanism is one >> type of registration (where a class of services is identified >> at the second level of the syntax) and urn:service:nena is > > pretty different (the same place in the syntax has the semantic >> of sub-registrant). Sub-registrants where the primary registrant >> is IANA needs some real discussion with IANA, as IANA will >> have to coordinate them (presuming we keep all of the publication >> by IANA). >> >> Having a separate NID is easier, in my opinion. >> >> Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 15:28:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yuS-0006ii-T6; Mon, 09 Jul 2007 15:28:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7yuS-0006iT-1v for ecrit@ietf.org; Mon, 09 Jul 2007 15:28:36 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7yuN-0003Iv-Qn for ecrit@ietf.org; Mon, 09 Jul 2007 15:28:36 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l69JSGve013794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Jul 2007 15:28:24 -0400 (EDT) In-Reply-To: <46927D01.3010905@gmx.net> References: <0d4f01c7c241$6b129070$640fa8c0@cis.neustar.com> <46927D01.3010905@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] draft-ecrit-framework-02 Date: Mon, 9 Jul 2007 15:28:20 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> > Many of us went through this already :-) > Sometimes I thought it would have been better for Henning to re- > write the draft right away. > It's a lot easier to critique something than to write something :-) >> > Let's try not to cover everything in a single document. It's fine > to point to HELD. > I would not cover > * Location Hiding > * Location Signing > * Unauthenticated Network Access All of these seem somewhat orthogonal to the main thrust of the framework and seem like items we can solve later. Also, location hiding may well be a special case and I think there is some general agreement on not having it burden innocent bystanders. I think unauthenticated network access is relatively straightforward as long as the ISP operates a SIP proxy and (possibly) a LoST server and very difficult otherwise. If that's the case, the discussion can be very brief, but I'm not even sure it needs to be in the framework document. This should work within our normal procedures, i.e., discovery of outbound proxy and local LoST server. The only real impact on the phone-bcp would be to make sure that a client tries the DHCP-advertised outbound proxy if necessary. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 09 15:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7z1N-0000Cq-O4; Mon, 09 Jul 2007 15:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7z1L-0000BB-Sn for ecrit@ietf.org; Mon, 09 Jul 2007 15:35:43 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7z1H-0003ZY-JZ for ecrit@ietf.org; Mon, 09 Jul 2007 15:35:43 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l69JZN8i020897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 9 Jul 2007 15:35:31 -0400 (EDT) In-Reply-To: References: <8C837214C95C864C9F3 4F3635C2A657507C99EC0@SEA-EXCHVS-2.telecomsys.com> <07bf01c7c02f$3280b480$640fa8c0@cis.neustar.com> <0d6401c7c24d$bec76f40$640fa8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] NENA requirement: contact URI for resolving errorsindatabase Date: Mon, 9 Jul 2007 15:35:27 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org It's hard to know what exactly the nena URN is supposed to do, but in general I share Ted's concern. I see no reason for urn:service to be the new playground for all non-document URNs. The slippery slope is that once you have urn:service:nena, it's hard to say no to urn:service:amazon and urn:service:google. As far as I can tell, even LoST doesn't really care that the URN starts with urn:service as opposed to urn:foobar, although we probably need to open up the language a bit if that's a concern. Henning On Jul 9, 2007, at 1:50 PM, Ted Hardie wrote: > At 1:22 PM -0400 7/9/07, Brian Rosen wrote: >> The downside is only that it wouldn't meet the wording in the >> service urn >> RFC. I don't think it has any practical problem. >> >> I fail to see why IETF can't allocate urn:service:nena based on a >> RFC and >> then let NENA create subservices (urn:service:nena.address-error- >> report). >> There is certainly no uniqueness problem with that. >> >> Brian > > Brian, > If you want this to work, I think you have to convince folks > to pull draft-ietf-ecrit-service-urn-06.txt before it becomes a BCP. > It sets out a registration mechanism according to RFC 3406 that's > a fairly standard NID. As it stands, the document says; > > Services and sub-services are identified by labels managed by IANA, > according to the processes outlined in [3] in a new registry called > "Service URN Labels". Thus, creating a new service requires IANA > action. The policy for adding top-level service labels is > 'Standards > Action'. (This document defines the top-level service 'sos' and > 'counseling'.) The policy for assigning labels to sub-services may > differ for each top-level service designation and MUST be > defined by > the document describing the top-level service. > > > This says that sub-services are managed by IANA; if you want > to define a mechanism where the sub-services may be managed > by someone else, I think that is in conflict with what > the document currently says. I also think the folks who > have been thinking about NIDs for a long time will have > a problem with it. The urn:service:sos mechanism is one > type of registration (where a class of services is identified > at the second level of the syntax) and urn:service:nena is > pretty different (the same place in the syntax has the semantic > of sub-registrant). Sub-registrants where the primary registrant > is IANA needs some real discussion with IANA, as IANA will > have to coordinate them (presuming we keep all of the publication > by IANA). > > Having a separate NID is easier, in my opinion. > > Ted > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 10 00:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I87oK-0006Ax-H3; Tue, 10 Jul 2007 00:58:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I87oJ-0006As-GC for ecrit@ietf.org; Tue, 10 Jul 2007 00:58:51 -0400 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I87o4-0001gD-5X for ecrit@ietf.org; Tue, 10 Jul 2007 00:58:51 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6A4vxxE002070; Mon, 9 Jul 2007 22:57:59 -0600 Message-ID: <469311CE.6080708@ntt-at.com> Date: Mon, 09 Jul 2007 21:57:50 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Review: draft-ietf-ecrit-framework-01.txt References: <464177A2.9040104@ntt-at.com> <0bc501c7c1c3$d6f96300$640fa8c0@cis.neustar.com> In-Reply-To: <0bc501c7c1c3$d6f96300$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by agnada.com id l6A4vxxE002070 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian; My comments inline.. The rest looked good, thank. >> Technical Comments: >> ---------------------------------------- >> T1: Chapter 3, 1st paragraph, 1st sentence. >> - Although we haven't come to a conclusion on how emergency >> call is distinguished, I believe the currently many see it >> as either by a emergency dialstring or by service URN. >> - The current text seems to allude that dialstring is necessary >> to place the (Emergency) service URN. >> =20 > The sentence currently reads: > We distinguish (Section 4 (Identifying an Emergency Call)) an emergency= call from any other call by a unique Service URN[I=E2=80=91D.ietf=E2=80=91= ecrit=E2=80=91service=E2=80=91urn] (Schulzrinne, H., =E2=80=9CA Uniform R= esource Name (URN) for Services,=E2=80=9D August 2006.), which is placed = in the initial call set-up signaling when a home or visited emergancy dia= lstring is detected. > > What other way, other than recognizing the dialstring would there be? > "Emergency" buttons are not a good idea, because they cause too many fa= lse calls. The text at this point doesn't say if the endpoint or server = detects the dialstring. The dialstring isn't an emergency call until it=E2= =80=99s detected as such by the endpoint or proxy, at which time it gets = the service URN. Perhaps you could elaborate on your concern and suggest= some changes. > =20 I guess my concern was that the text seems to allude that dialstring is=20 the only way for a service URN to be placed in the signaling and that the=20 current text was too restrictive. For non SIP device such as Jabber client where E.164 is not used frequently, it may use different means to contact PSAP, it may actually set the serviceURN directly into the target address witho= ut the need to detect the dial-string. Payphone with emergency button for example may not use dial-string but set serviceURN without the need of a dial-string. Regards Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 10 03:22:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8A2s-0007Ug-Es; Tue, 10 Jul 2007 03:22:02 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8A2q-0007Lv-Ph for ecrit@ietf.org; Tue, 10 Jul 2007 03:22:00 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8A2q-0004eH-Gf for ecrit@ietf.org; Tue, 10 Jul 2007 03:22:00 -0400 Received: (qmail invoked by alias); 10 Jul 2007 07:21:27 -0000 Received: from p54985C02.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.92.2] by mail.gmx.net (mp004) with SMTP; 10 Jul 2007 09:21:27 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/9/1k2Au/9R6OkSPdnVhVsRSqdeD6/Cvour8hwFk 0rPJLQh4vwxKME Message-ID: <46933374.6000009@gmx.net> Date: Tue, 10 Jul 2007 09:21:24 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] Tentative Agenda for ECRIT meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Here is the first try: http://www3.ietf.org/proceedings/07jul/agenda/ecrit.txt Feedback appreciated. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 10 13:55:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JvX-0007E2-S6; Tue, 10 Jul 2007 13:55:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JvW-0007A8-RB for ecrit@ietf.org; Tue, 10 Jul 2007 13:55:06 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8JvW-0004IZ-9T for ecrit@ietf.org; Tue, 10 Jul 2007 13:55:06 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Jul 2007 10:55:04 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAKdjk0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,523,1175497200"; d="scan'208"; a="501726801:sNHT532420976" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6AHt3vD019851; Tue, 10 Jul 2007 10:55:03 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6AHt3mo027346; Tue, 10 Jul 2007 17:55:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 13:55:02 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.81]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 13:55:02 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 10 Jul 2007 12:55:02 -0500 To: "Romascanu, Dan (Dan)" , "ECRIT" From: "James M. Polk" Subject: Re: [Ecrit] FW: [New-work] OMA New Work - 1 New Work Item Approved - Location inSIP/IP core In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 10 Jul 2007 17:55:02.0418 (UTC) FILETIME=[709C6720:01C7C31B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4039; t=1184090103; x=1184954103; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20FW=3A=20[New-work]=20OMA=20New=20Work=20-=2 01=20New=20Work=20Item=0A=20=20Approved=20-=20Location=20inSIP/IP=20core |Sender:=20; bh=iMTli2SS43r4fp47TqRuEn/vVoYI3DLSAS53W1J6Qng=; b=iuhS1KEkNmBhjnbvlpZt7xTALAhKbXigSfQs6sW67qH+qhy5zn7yBIbGTiXdSADBL+AoCxTd QPnkCecrummSAz2SUg2qkUgZUlMuYA0cm5Ronfs6PWgSbXXgAHaaRiAd; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org How is this different than the SIP Location Conveyance ID (that's past WGLC)? Or is this just competing for the same space? At 07:21 AM 7/9/2007, Romascanu, Dan (Dan) wrote: > > >---------- >From: Victoria Gray [mailto:Victoria.Gray@forapolis.com] >Sent: Thursday, July 05, 2007 3:49 PM >To: new-work@ietf.org >Subject: [New-work] OMA New Work - 1 New Work Item Approved - >Location inSIP/IP core > >Dear All, > >OMA would like to inform all the organisations subscribed to the >IETF new-work list of the approval of 1 new work item: > >1 Location in SIP/IP Core WI: > >http://www.openmobilealliance.org/ftp/Public_documents/TP/Permanent_documents/OMA-WID_0149-LOCSIP-V1_0-20070704-A.zip > >Background : OMA has developed various enablers related to location. >The MLS enabler has the main purpose to define protocols for >exposure of terminal location to applications but do not define any >positioning determination mechanisms. SUPL on the other hand defines >procedures and protocols for positioning determination of a terminal >utilizing an IP connection between server and terminal. Both >enablers are to some extent prepared for use in a SIP context e.g. >by allowing use of SIP-URI identities. None of them do however >support exposure of terminal location to an application within a >SIP/IP core network (one example of such a network is an IP >Multimedia Subsystem). The implication of this is that a SIP >Application Server needing location information to enhance its >services needs to implement one or more non-SIP interfaces to >Location Servers. By instead defining an interface & procedure using >SIP, additional interface technologies can be avoided and routing >and addressing mechanisms in the SIP/IP Core as well as existing SIP >based OMA enablers (such as XDM) can be reused. > >Objective: The purpose of this work item is to specify a service >enabler for exposing location information to applications in a >SIP/IP core network (e.g an IP Multimedia Subsystem). The service >enabler is to be specified as a reusable network component in a >SIP/IP core network, capable of receiving and responding to location >subscriptions over a standardised SIP-based interface. Handling of >the location specific functions within a SIP/IP core is to be >specified but positioning determination functions within SIP/IP core >are out of scope. The LOCSIP enabler will take into account the OMA >MLS enabler. > >The enabler shall specifically consider interworking with other OMA >enablers that potentially utilize location information e.g. Presence >SIMPLE and PoC. The resulting specification shall preferably reuse >available IETF specifications e.g. IETF Geopriv deliverables. > >Location in SIP/IP core enabler implementations may interwork with >applicable positioning determination functions in access networks >and/or at UE. Possible positioning determination functions depend on >support in IP-CAN and UEs, but are expected to at least include >3GPP/3GPP2 LCS and OMA SUPL (Secure User Plane Location). > >This work item has been allocated to the OMA LOC (Location) WG for >specification development. > >Best regards, > >Victoria Gray on behalf of OMA. > >Victoria Gray >FORApolis / DSO >Tel +33 (0)4 92 94 49 23 >Fax +33 (0)4 92 38 49 23 >GSM +33 (0)6 73 99 62 90 >victoria.gray@forapolis.com > >MSN: >victoria.gray@forapolis.com >Yahoo!: bluevicci >Skype: victoria-gray Google: vics.gray@gmail.com > >_______________________________________________ >New-work mailing list >New-work@ietf.org >https://www1.ietf.org/mailman/listinfo/new-work >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 10 15:59:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LrY-0005V7-Ra; Tue, 10 Jul 2007 15:59:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8LrY-0005V2-DK for ecrit@ietf.org; Tue, 10 Jul 2007 15:59:08 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8LrI-0000J9-VZ for ecrit@ietf.org; Tue, 10 Jul 2007 15:59:08 -0400 Received: (qmail invoked by alias); 10 Jul 2007 19:58:16 -0000 Received: from p5498565A.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.86.90] by mail.gmx.net (mp039) with SMTP; 10 Jul 2007 21:58:16 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18beys8l5Qb5zi8bjN+QOxqBCWpEAIWfgbcIXVIgr uhU1BHf9p/MDtF Message-ID: <4693E4D4.1000905@gmx.net> Date: Tue, 10 Jul 2007 21:58:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 3.6 (+++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, during the WGLC we have received a number of comments. Then, we delayed the completion of the work because of the location hiding discussions. Now, you can find the latest version of the document at: http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-lost-06.txt We have also updated the DHCP-based LoST discovery draft (based on the comments we received from the DHC working group). The document can be found here: http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-ietf-ecrit-dhc-lost-discovery-02.txt Now, here is the unfortunate news: It seems that we did not submit the LoST draft :-( Everyone was assuming that someone else is going to submit it. Ciao Hannes PS: James has recently sent a number of comments. Some of them got reflected in the document (namely the editorial onces). Others got intentionally postponed since we discussed them already in the past. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 10 16:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M7M-0006P9-50; Tue, 10 Jul 2007 16:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M6x-0005mu-O5; Tue, 10 Jul 2007 16:15:03 -0400 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8M6w-0008Kw-7S; Tue, 10 Jul 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B248E26EB9; Tue, 10 Jul 2007 20:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8M6v-0004WB-Hv; Tue, 10 Jul 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 16:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-framework-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen Filename : draft-ietf-ecrit-framework-02.txt Pages : 34 Date : 2007-7-10 Summoning emergency help by the public is a core feature of telephone networks. This document describes how various IETF protocols and mechanisms are combined to place emergency calls. This includes how these calls are routed to the correct Public Safety Answering Point (PSAP) based on the physical location of the caller, while providing the call taker the necessary information to dispatch a first responder to that location and to call back the caller if necessary. It describes at a high level how the pieces (recognizing a call as an emergency call, marking it as such, determining the location of the caller, routing the call based on location) go together, and references the Internet standards that define the details of these mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10152411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10152411.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Jul 10 16:16:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M85-0007yx-G2; Tue, 10 Jul 2007 16:16:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8M7Q-0006bu-SY; Tue, 10 Jul 2007 16:15:32 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8M7Q-0000hC-Kq; Tue, 10 Jul 2007 16:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 3B73D17621; Tue, 10 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8M6v-0004Wh-Pc; Tue, 10 Jul 2007 16:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 16:15:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-mapping-arch-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Location-to-URL Mapping Architecture and Framework Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-mapping-arch-02.txt Pages : 17 Date : 2007-7-10 This document describes an architecture for a global, scalable, resilient and administratively distributed system for mapping geographic location information to URLs, using the Location-to- Service (LoST) protocol. The architecture generalizes well-known approaches found in hierarchical lookup systems such as DNS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-mapping-arch-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10154611.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-mapping-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-mapping-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10154611.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Tue Jul 10 16:47:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8McH-0002Up-Ag; Tue, 10 Jul 2007 16:47:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8MFz-0000YT-Gz for ecrit@ietf.org; Tue, 10 Jul 2007 16:24:24 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8MFu-0003bQ-6u for ecrit@ietf.org; Tue, 10 Jul 2007 16:24:23 -0400 Received: from [128.59.23.102] (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6AKNktj010318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Jul 2007 16:23:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <71347713-3745-4F60-BA09-ED4CF59FD107@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Tue, 10 Jul 2007 16:23:53 -0400 X-Mailer: Apple Mail (2.752.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ecrit] draft-ietf-ecrit-mapping-arch-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Has been posted, but it does not incorporate all the changes as my estimate of late-Sunday time availability was overly optimistic. I plan to incorporate the editorial and other changes suggested later this week and then post a 03 version once the gates open again. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 02:00:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8VFk-00038X-KG; Wed, 11 Jul 2007 02:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8VFi-00038S-Rp for ecrit@ietf.org; Wed, 11 Jul 2007 02:00:42 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8VFe-0005m5-Fs for ecrit@ietf.org; Wed, 11 Jul 2007 02:00:42 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_01_08_49 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 01:08:49 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 01:00:37 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 01:00:36 -0500 Message-ID: In-Reply-To: <4693E4D4.1000905@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDLMkeJOkkyRulR6Oei19U8KWu2AAU56lw References: <4693E4D4.1000905@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 11 Jul 2007 06:00:37.0976 (UTC) FILETIME=[CDD35D80:01C7C380] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AWhat exactly do you mean by postponed=3F=0D=0A=0D=0AC= heers=0D=0AJames=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D= =0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> Sent= : Wednesday, 11 July 2007 5:58 AM=0D=0A> To: ECRIT=0D=0A> Subject: [Ecrit] = LoST=0D=0A>=20=0D=0A> Hi all,=0D=0A>=20=0D=0A> during the WGLC we have rece= ived a number of comments. Then, we=0D=0Adelayed=0D=0A> the completion of t= he work because of the location hiding discussions.=0D=0A>=20=0D=0A> Now, y= ou can find the latest version of the document at:=0D=0A>=0D=0Ahttp://www.t= schofenig.com/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los=0D=0At-=0D=0A>= 06.txt=0D=0A>=20=0D=0A> We have also updated the DHCP-based LoST discovery= draft (based on the=0D=0A> comments we received from the DHC working group= ). The document can be=0D=0A> found here:=0D=0A>=0D=0Ahttp://www.tschofenig= =2Ecom/svn/draft-tschofenig-dhc-lost-discovery/draft-=0D=0A> ietf-ecrit-dhc= -lost-discovery-02.txt=0D=0A>=20=0D=0A> Now, here is the unfortunate news: = It seems that we did not submit the=0D=0A> LoST draft :-(=0D=0A> Everyone w= as assuming that someone else is going to submit it.=0D=0A>=20=0D=0A> Ciao=0D= =0A> Hannes=0D=0A>=20=0D=0A> PS: James has recently sent a number of commen= ts. Some of them got=0D=0A> reflected in the document (namely the editorial= onces). Others got=0D=0A> intentionally postponed since we discussed them = already in the past.=0D=0A>=20=0D=0A> _____________________________________= __________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://w= ww1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------------------------= --------------------------------------------------------------------=0D=0AT= his message is for the designated recipient only and may=0D=0Acontain privi= leged, proprietary, or otherwise private information. =20=0D=0AIf you have = received it in error, please notify the sender=0D=0Aimmediately and delete = the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 02:58:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8W9e-0002kF-Cr; Wed, 11 Jul 2007 02:58:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8W9d-0002kA-Go for ecrit@ietf.org; Wed, 11 Jul 2007 02:58:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8W9c-00084d-VN for ecrit@ietf.org; Wed, 11 Jul 2007 02:58:29 -0400 Received: (qmail invoked by alias); 11 Jul 2007 06:57:55 -0000 Received: from p54987267.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.114.103] by mail.gmx.net (mp019) with SMTP; 11 Jul 2007 08:57:55 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/B1hAgLrjBVg119IwDGgogAa6PoKS1nAgxM9usia QgYR6I8C3S/+YU Message-ID: <46947F6E.1000805@gmx.net> Date: Wed, 11 Jul 2007 08:57:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] LoST References: <4693E4D4.1000905@gmx.net> 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: 32b73d73e8047ed17386f9799119ce43 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, let me pick a concrete example: LoST server discovery. Currently, we have specified the usage of DHCP and DNS. Only the former allows to discover the LoST server in the access network. I am, however, aware of the work on HELD discovery, see http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-01.txt, that aims to discover a HELD server in the access network using DNS mechanisms. Now, even though the current LoST draft does not describe how to discover a LoST server using DNS in the access network that can be extended later when the above document is generalized (which I think would be a good idea). Does that make sense to you? Ciao Hannes Winterbottom, James wrote: > Hi Hannes, > > What exactly do you mean by postponed? > > Cheers > James > > > > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, 11 July 2007 5:58 AM >> To: ECRIT >> Subject: [Ecrit] LoST >> >> Hi all, >> >> during the WGLC we have received a number of comments. Then, we >> > delayed > >> the completion of the work because of the location hiding discussions. >> >> Now, you can find the latest version of the document at: >> >> > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los > t- > >> 06.txt >> >> We have also updated the DHCP-based LoST discovery draft (based on the >> comments we received from the DHC working group). The document can be >> found here: >> >> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft- > >> ietf-ecrit-dhc-lost-discovery-02.txt >> >> Now, here is the unfortunate news: It seems that we did not submit the >> LoST draft :-( >> Everyone was assuming that someone else is going to submit it. >> >> Ciao >> Hannes >> >> PS: James has recently sent a number of comments. Some of them got >> reflected in the document (namely the editorial onces). Others got >> intentionally postponed since we discussed them already in the past. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 04:43:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XnT-0007vC-E1; Wed, 11 Jul 2007 04:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XnS-0007v5-5s for ecrit@ietf.org; Wed, 11 Jul 2007 04:43:42 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8XnO-0000yq-QZ for ecrit@ietf.org; Wed, 11 Jul 2007 04:43:42 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_03_51_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 03:51:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 03:43:35 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 03:43:33 -0500 Message-ID: In-Reply-To: <46947F6E.1000805@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDiNAmqwr5a2FlTfuUpxpLll65tgADmgCw References: <4693E4D4.1000905@gmx.net> <46947F6E.1000805@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 08:43:35.0917 (UTC) FILETIME=[91EEC1D0:01C7C397] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AThat makes perfect sense.=0D=0A=0D=0AThe issue that I= am most concerned about is the limitation in the shape=0D=0Arepresentation= in the basic location profile. As it currently stands I=0D=0Acannot use st= andard GPS related shapes, my end-point has to interpret=0D=0Alocation and = put into a profile. This is incompatible with a large=0D=0Anumber of soluti= ons deployed today on which many deployments will be=0D=0Abased, at least i= nitially. I strongly urge this WG to reconsider this=0D=0Arestriction and i= nclude circle, and ellipse at a minimum.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hann= es.Tschofenig@gmx.net]=0D=0A> Sent: Wednesday, 11 July 2007 4:58 PM=0D=0A> = To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] LoST=0D= =0A>=20=0D=0A> Hi James,=0D=0A>=20=0D=0A> let me pick a concrete example: L= oST server discovery.=0D=0A> Currently, we have specified the usage of DHCP= and DNS. Only the=0D=0Aformer=0D=0A> allows to discover the LoST server in= the access network. I am,=0D=0Ahowever,=0D=0A> aware of the work on HELD d= iscovery, see=0D=0A> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv= -lis-discovery-=0D=0A> 01.txt,=0D=0A> that aims to discover a HELD server i= n the access network using DNS=0D=0A> mechanisms.=0D=0A>=20=0D=0A> Now, eve= n though the current LoST draft does not describe how to=0D=0A> discover a = LoST server using DNS in the access network that can be=0D=0A> extended lat= er when the above document is generalized (which I think=0D=0A> would be a = good idea).=0D=0A>=20=0D=0A> Does that make sense to you=3F=0D=0A>=20=0D=0A= > Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> Winterbottom, James wrote:=0D=0A> > H= i Hannes,=0D=0A> >=0D=0A> > What exactly do you mean by postponed=3F=0D=0A>= >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A= > >=0D=0A> >> -----Original Message-----=0D=0A> >> From: Hannes Tschofenig = [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> >> Sent: Wednesday, 11 July 2007 = 5:58 AM=0D=0A> >> To: ECRIT=0D=0A> >> Subject: [Ecrit] LoST=0D=0A> >>=0D=0A= > >> Hi all,=0D=0A> >>=0D=0A> >> during the WGLC we have received a number = of comments. Then, we=0D=0A> >>=0D=0A> > delayed=0D=0A> >=0D=0A> >> the com= pletion of the work because of the location hiding=0D=0Adiscussions.=0D=0A>= >>=0D=0A> >> Now, you can find the latest version of the document at:=0D=0A= > >>=0D=0A> >>=0D=0A> >=0D=0Ahttp://www.tschofenig.priv.at/svn/draft-ietf-ecrit= -lost/draft-ietf-ecrit-los=0D=0A> > t-=0D=0A> >=0D=0A> >> 06.txt=0D=0A> >>=0D= =0A> >> We have also updated the DHCP-based LoST discovery draft (based on=0D= =0Athe=0D=0A> >> comments we received from the DHC working group). The docu= ment can=0D=0Abe=0D=0A> >> found here:=0D=0A> >>=0D=0A> >>=0D=0A> >=0D=0Aht= tp://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft-=0D=0A= > >=0D=0A> >> ietf-ecrit-dhc-lost-discovery-02.txt=0D=0A> >>=0D=0A> >> Now,= here is the unfortunate news: It seems that we did not submit=0D=0Athe=0D=0A= > >> LoST draft :-(=0D=0A> >> Everyone was assuming that someone else is go= ing to submit it.=0D=0A> >>=0D=0A> >> Ciao=0D=0A> >> Hannes=0D=0A> >>=0D=0A= > >> PS: James has recently sent a number of comments. Some of them got=0D=0A= > >> reflected in the document (namely the editorial onces). Others got=0D=0A= > >> intentionally postponed since we discussed them already in the=0D=0Apa= st.=0D=0A> >>=0D=0A> >> _______________________________________________=0D=0A= > >> Ecrit mailing list=0D=0A> >> Ecrit@ietf.org=0D=0A> >> https://www1.iet= f.org/mailman/listinfo/ecrit=0D=0A> >>=0D=0A> >=0D=0A> >=0D=0A-------------= -----------------------------------------------------------=0D=0A> --------= ----------------=0D=0A> > This message is for the designated recipient only= and may=0D=0A> > contain privileged, proprietary, or otherwise private inf= ormation.=0D=0A> > If you have received it in error, please notify the send= er=0D=0A> > immediately and delete the original. Any unauthorized use of=0D= =0A> > this email is prohibited.=0D=0A> >=0D=0A----------------------------= --------------------------------------------=0D=0A> -----------------------= -=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A=0D=0A-------------------= ---------------------------------------------------------------------------= --=0D=0AThis message is for the designated recipient only and may=0D=0Acont= ain privileged, proprietary, or otherwise private information. =20=0D=0AIf = you have received it in error, please notify the sender=0D=0Aimmediately an= d delete the original. Any unauthorized use of=0D=0Athis email is prohibit= ed.=0D=0A------------------------------------------------------------------= ------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 04:55:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XzF-00047t-5p; Wed, 11 Jul 2007 04:55:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8XzE-00045I-GI for ecrit@ietf.org; Wed, 11 Jul 2007 04:55:52 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8XzD-0002EO-RO for ecrit@ietf.org; Wed, 11 Jul 2007 04:55:52 -0400 Received: (qmail invoked by alias); 11 Jul 2007 08:55:34 -0000 Received: from p54987267.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.114.103] by mail.gmx.net (mp004) with SMTP; 11 Jul 2007 10:55:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/cdWcSHSvcYadeHTufIWfeM/WvKv0osOQ9ceuZ6n ZaqVxfzY6fISIv Message-ID: <46949AFF.3040103@gmx.net> Date: Wed, 11 Jul 2007 10:55:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] LoST References: <4693E4D4.1000905@gmx.net> <46947F6E.1000805@gmx.net> 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: 88b11fc64c1bfdb4425294ef5374ca07 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, Winterbottom, James wrote: > Hi Hannes, > > That makes perfect sense. > > The issue that I am most concerned about is the limitation in the shape > representation in the basic location profile. As it currently stands I > cannot use standard GPS related shapes, my end-point has to interpret > location and put into a profile. This is incompatible with a large > number of solutions deployed today on which many deployments will be > based, at least initially. I strongly urge this WG to reconsider this > restriction and include circle, and ellipse at a minimum. > Some time back we also discussed this issue and the conclusion was the following: * Let us build a mechanism in there to have a mechanism to extend the location shapes. * Let us specify simple location shapes first. I know that there is this limitation with geodetic shapes and a separate location profile would be needed to address GPS and the cellular world. On the cellular aspect we also had a discussion with the 3GPP. There they are currently not using LoST at the end point since they are focusing on a different architecture (see http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-00). Even if they would use LoST at the end point they most likely want to hide the location information of the end point or to make use of information like cell ids (as recorded in the issue tracker a while ago: http://www.tschofenig.priv.at:8080/lost/issue16). Now, everything boils down to the question of GPS. Since GPS produces data in a format that is not PIDF-LO alike we can already assume that the end host has to understand the format. It can now encode it in different ways. In previous discussions a couple of us wanted to add a polygon as a location profile to the LoST document since it would also address the location hiding requirement. Since this issue came also up in the location hiding context we postpone this topic entirely. Hence, it is up to us to come up with a location profile that supports * a circle * an ellipse * a polygon, * a combination of the above * cell-ids if we think there is a need todo so. Ciao Hannes > Cheers > James > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, 11 July 2007 4:58 PM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] LoST >> >> Hi James, >> >> let me pick a concrete example: LoST server discovery. >> Currently, we have specified the usage of DHCP and DNS. Only the >> > former > >> allows to discover the LoST server in the access network. I am, >> > however, > >> aware of the work on HELD discovery, see >> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery- >> 01.txt, >> that aims to discover a HELD server in the access network using DNS >> mechanisms. >> >> Now, even though the current LoST draft does not describe how to >> discover a LoST server using DNS in the access network that can be >> extended later when the above document is generalized (which I think >> would be a good idea). >> >> Does that make sense to you? >> >> Ciao >> Hannes >> >> Winterbottom, James wrote: >> >>> Hi Hannes, >>> >>> What exactly do you mean by postponed? >>> >>> Cheers >>> James >>> >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Wednesday, 11 July 2007 5:58 AM >>>> To: ECRIT >>>> Subject: [Ecrit] LoST >>>> >>>> Hi all, >>>> >>>> during the WGLC we have received a number of comments. Then, we >>>> >>>> >>> delayed >>> >>> >>>> the completion of the work because of the location hiding >>>> > discussions. > >>>> Now, you can find the latest version of the document at: >>>> >>>> >>>> > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los > >>> t- >>> >>> >>>> 06.txt >>>> >>>> We have also updated the DHCP-based LoST discovery draft (based on >>>> > the > >>>> comments we received from the DHC working group). The document can >>>> > be > >>>> found here: >>>> >>>> >>>> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft- > >>>> ietf-ecrit-dhc-lost-discovery-02.txt >>>> >>>> Now, here is the unfortunate news: It seems that we did not submit >>>> > the > >>>> LoST draft :-( >>>> Everyone was assuming that someone else is going to submit it. >>>> >>>> Ciao >>>> Hannes >>>> >>>> PS: James has recently sent a number of comments. Some of them got >>>> reflected in the document (namely the editorial onces). Others got >>>> intentionally postponed since we discussed them already in the >>>> > past. > >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> [mf2] >>> >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:04:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Y7n-0005NM-V7; Wed, 11 Jul 2007 05:04:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Y7n-0005NE-L3 for ecrit@ietf.org; Wed, 11 Jul 2007 05:04:43 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Y7j-0001SN-5w for ecrit@ietf.org; Wed, 11 Jul 2007 05:04:43 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_04_12_50 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 04:12:50 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 04:04:38 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 04:04:35 -0500 Message-ID: In-Reply-To: <46949AFF.3040103@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDmT+i9JV7iqmcS3KivWMi8Od7LQAAKW3Q References: <4693E4D4.1000905@gmx.net> <46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 09:04:38.0643 (UTC) FILETIME=[82937430:01C7C39A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AThe concern I have is that GPS is not only cellular.=0D= =0AIt is being used in WiFI and will be used from the get go in WiMAX.=0D=0A= The only profiles that will be mandatory to support are those in the=0D=0Ab= asic LoST specification, so the decision is generally unacceptable from=0D=0A= a deployment perspective.=0D=0A=0D=0AI don't agree with the assessment belo= w either.=0D=0AI can easily see that LIS could provide a PIDF-LO to me that= I have=0D=0Aprovided satellite pseudo-ranges for. So again I remain unconv= inced by=0D=0Athis debate. It is far simpler to interpret the ellipse and c= ircle types=0D=0Athan a polygon, and to be frank from an end-point or measu= re location=0D=0Aperspective far more likely to be provided.=0D=0A=0D=0A=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Hannes Tschofenig [mailt= o:Hannes.Tschofenig@gmx.net]=0D=0A> Sent: Wednesday, 11 July 2007 6:55 PM=0D= =0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] L= oST=0D=0A>=20=0D=0A> Hi James,=0D=0A>=20=0D=0A> Winterbottom, James wrote:=0D= =0A> > Hi Hannes,=0D=0A> >=0D=0A> > That makes perfect sense.=0D=0A> >=0D=0A= > > The issue that I am most concerned about is the limitation in the=0D=0A= shape=0D=0A> > representation in the basic location profile. As it currentl= y stands=0D=0AI=0D=0A> > cannot use standard GPS related shapes, my end-poi= nt has to=0D=0Ainterpret=0D=0A> > location and put into a profile. This is = incompatible with a large=0D=0A> > number of solutions deployed today on wh= ich many deployments will be=0D=0A> > based, at least initially. I strongly= urge this WG to reconsider=0D=0Athis=0D=0A> > restriction and include circ= le, and ellipse at a minimum.=0D=0A> >=0D=0A> Some time back we also discus= sed this issue and the conclusion was the=0D=0A> following:=0D=0A> * Let us= build a mechanism in there to have a mechanism to extend the=0D=0A> locati= on shapes.=0D=0A> * Let us specify simple location shapes first.=0D=0A>=20=0D= =0A> I know that there is this limitation with geodetic shapes and a=0D=0As= eparate=0D=0A> location profile would be needed to address GPS and the cell= ular=0D=0Aworld.=0D=0A> On the cellular aspect we also had a discussion wit= h the 3GPP. There=0D=0A> they are currently not using LoST at the end point= since they are=0D=0A> focusing on a different architecture (see=0D=0A>=0D=0A= http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview-=0D= =0A> 00).=0D=0A> Even if they would use LoST at the end point they most lik= ely want to=0D=0A> hide the location information of the end point or to mak= e use of=0D=0A> information like cell ids (as recorded in the issue tracker= a while=0D=0Aago:=0D=0A> http://www.tschofenig.priv.at:8080/lost/issue16).=0D=0A= >=20=0D=0A> Now, everything boils down to the question of GPS. Since GPS pr= oduces=0D=0A> data in a format that is not PIDF-LO alike we can already ass= ume that=0D=0A> the end host has to understand the format. It can now encod= e it in=0D=0A> different ways. In previous discussions a couple of us wante= d to add a=0D=0A> polygon as a location profile to the LoST document since = it would also=0D=0A> address the location hiding requirement. Since this is= sue came also up=0D=0A> in the location hiding context we postpone this top= ic entirely.=0D=0A>=20=0D=0A> Hence, it is up to us to come up with a locat= ion profile that supports=0D=0A> * a circle=0D=0A> * an ellipse=0D=0A> * a = polygon,=0D=0A> * a combination of the above=0D=0A> * cell-ids=0D=0A> if we= think there is a need todo so.=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A> =0D= =0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> >> -----Original Mess= age-----=0D=0A> >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.ne= t]=0D=0A> >> Sent: Wednesday, 11 July 2007 4:58 PM=0D=0A> >> To: Winterbott= om, James=0D=0A> >> Cc: ECRIT=0D=0A> >> Subject: Re: [Ecrit] LoST=0D=0A> >>=0D= =0A> >> Hi James,=0D=0A> >>=0D=0A> >> let me pick a concrete example: LoST = server discovery.=0D=0A> >> Currently, we have specified the usage of DHCP = and DNS. Only the=0D=0A> >>=0D=0A> > former=0D=0A> >=0D=0A> >> allows to di= scover the LoST server in the access network. I am,=0D=0A> >>=0D=0A> > howe= ver,=0D=0A> >=0D=0A> >> aware of the work on HELD discovery, see=0D=0A> >>=0D= =0Ahttp://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-=0D= =0A> >> 01.txt,=0D=0A> >> that aims to discover a HELD server in the access= network using DNS=0D=0A> >> mechanisms.=0D=0A> >>=0D=0A> >> Now, even thou= gh the current LoST draft does not describe how to=0D=0A> >> discover a LoS= T server using DNS in the access network that can be=0D=0A> >> extended lat= er when the above document is generalized (which I=0D=0Athink=0D=0A> >> wou= ld be a good idea).=0D=0A> >>=0D=0A> >> Does that make sense to you=3F=0D=0A= > >>=0D=0A> >> Ciao=0D=0A> >> Hannes=0D=0A> >>=0D=0A> >> Winterbottom, Jame= s wrote:=0D=0A> >>=0D=0A> >>> Hi Hannes,=0D=0A> >>>=0D=0A> >>> What exactly= do you mean by postponed=3F=0D=0A> >>>=0D=0A> >>> Cheers=0D=0A> >>> James=0D= =0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>= -----Original Message-----=0D=0A> >>>> From: Hannes Tschofenig [mailto:Han= nes.Tschofenig@gmx.net]=0D=0A> >>>> Sent: Wednesday, 11 July 2007 5:58 AM=0D= =0A> >>>> To: ECRIT=0D=0A> >>>> Subject: [Ecrit] LoST=0D=0A> >>>>=0D=0A> >>= >> Hi all,=0D=0A> >>>>=0D=0A> >>>> during the WGLC we have received a numbe= r of comments. Then, we=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>> delayed=0D=0A> >= >>=0D=0A> >>>=0D=0A> >>>> the completion of the work because of the locatio= n hiding=0D=0A> >>>>=0D=0A> > discussions.=0D=0A> >=0D=0A> >>>> Now, you ca= n find the latest version of the document at:=0D=0A> >>>>=0D=0A> >>>>=0D=0A= > >>>>=0D=0A> >=0D=0Ahttp://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/dr= aft-ietf-ecrit-los=0D=0A> >=0D=0A> >>> t-=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>>= 06.txt=0D=0A> >>>>=0D=0A> >>>> We have also updated the DHCP-based LoST di= scovery draft (based=0D=0Aon=0D=0A> >>>>=0D=0A> > the=0D=0A> >=0D=0A> >>>> = comments we received from the DHC working group). The document=0D=0Acan=0D=0A= > >>>>=0D=0A> > be=0D=0A> >=0D=0A> >>>> found here:=0D=0A> >>>>=0D=0A> >>>>=0D= =0A> >>>>=0D=0A> >=0D=0Ahttp://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-= lost-discovery/draft-=0D=0A> >=0D=0A> >>>> ietf-ecrit-dhc-lost-discovery-02= =2Etxt=0D=0A> >>>>=0D=0A> >>>> Now, here is the unfortunate news: It seems = that we did not=0D=0Asubmit=0D=0A> >>>>=0D=0A> > the=0D=0A> >=0D=0A> >>>> L= oST draft :-(=0D=0A> >>>> Everyone was assuming that someone else is going = to submit it.=0D=0A> >>>>=0D=0A> >>>> Ciao=0D=0A> >>>> Hannes=0D=0A> >>>>=0D= =0A> >>>> PS: James has recently sent a number of comments. Some of them=0D= =0Agot=0D=0A> >>>> reflected in the document (namely the editorial onces). = Others=0D=0Agot=0D=0A> >>>> intentionally postponed since we discussed them= already in the=0D=0A> >>>>=0D=0A> > past.=0D=0A> >=0D=0A> >>>> ___________= ____________________________________=0D=0A> >>>> Ecrit mailing list=0D=0A> = >>>> Ecrit@ietf.org=0D=0A> >>>> https://www1.ietf.org/mailman/listinfo/ecri= t=0D=0A> >>>>=0D=0A> >>>>=0D=0A> >>>=0D=0A> >=0D=0A------------------------= ------------------------------------------------=0D=0A> >=0D=0A> >> -------= -----------------=0D=0A> >>=0D=0A> >>> This message is for the designated r= ecipient only and may=0D=0A> >>> contain privileged, proprietary, or otherw= ise private information.=0D=0A> >>> If you have received it in error, pleas= e notify the sender=0D=0A> >>> immediately and delete the original. Any un= authorized use of=0D=0A> >>> this email is prohibited.=0D=0A> >>>=0D=0A> >>= >=0D=0A> >=0D=0A-----------------------------------------------------------= -------------=0D=0A> >=0D=0A> >> ------------------------=0D=0A> >>=0D=0A> = >>> [mf2]=0D=0A> >>>=0D=0A> >>>=0D=0A> >>>=0D=0A> >=0D=0A> >=0D=0A---------= ---------------------------------------------------------------=0D=0A> ----= --------------------=0D=0A> > This message is for the designated recipient = only and may=0D=0A> > contain privileged, proprietary, or otherwise private= information.=0D=0A> > If you have received it in error, please notify the = sender=0D=0A> > immediately and delete the original. Any unauthorized use = of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A-----------------------= -------------------------------------------------=0D=0A> ------------------= ------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A=0D=0A--------------= ---------------------------------------------------------------------------= -------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:23:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YPh-0005Bo-QS; Wed, 11 Jul 2007 05:23:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YPg-0005Az-D8 for ecrit@ietf.org; Wed, 11 Jul 2007 05:23:12 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8YPb-0001uD-U6 for ecrit@ietf.org; Wed, 11 Jul 2007 05:23:12 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_04_31_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 04:31:19 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 04:23:07 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 04:22:56 -0500 Message-ID: In-Reply-To: <46949AFF.3040103@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDmUtZVbqYrdnNTi6rgXGDwBzG/wAArH2g References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" , "Winterbottom, James" X-OriginalArrivalTime: 11 Jul 2007 09:23:07.0285 (UTC) FILETIME=[1760CC50:01C7C39D] X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AThis seems a bit bogged down in the here and now... A= LIS for almost any=0D=0Aaccess technology, with or without GPS, could prod= uce a geo-shape as a=0D=0Aconsequence of the location-determination techniq= ue it employs. What=0D=0A3GPP may be thinking now doesn't seem particularly= pertinent.=0D=0A=0D=0AThere's already a pdif-lo-profile draft ([sic] is th= e spelling ever=0D=0Agoing to get corrected btw or is a title immutable=3F)= that states what=0D=0Ashapes should be used and defines what the LIS clien= ts can expect to=0D=0Areceive.=0D=0A=0D=0AWhile I accept that a LoST implem= entor could add support for that=0D=0Aprofile, as long as it is optional to= do so, the client cannot be sure=0D=0Athat anything other than a point wil= l be supported. This adds the dual=0D=0Aissue of making the client always c= onvert to a point form and/or=0D=0Aeliminating the prospect of LoST servers= being able to do more=0D=0Asophisticated routing based on weighted coverag= e by uncertainty.=0D=0A=0D=0ARather than invite the compatibility issue at = a later date, wouldn't it=0D=0Abe more prudent just to add the requirement = now=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0ASent:= Wednesday, 11 July 2007 6:55 PM=0D=0ATo: Winterbottom, James=0D=0ACc: ECRI= T=0D=0ASubject: Re: [Ecrit] LoST=0D=0A=0D=0AHi James,=0D=0A=0D=0AWinterbott= om, James wrote:=0D=0A> Hi Hannes,=0D=0A>=0D=0A> That makes perfect sense.=0D= =0A>=0D=0A> The issue that I am most concerned about is the limitation in t= he=0D=0Ashape=0D=0A> representation in the basic location profile. As it cu= rrently stands I=0D=0A> cannot use standard GPS related shapes, my end-poin= t has to interpret=0D=0A> location and put into a profile. This is incompat= ible with a large=0D=0A> number of solutions deployed today on which many d= eployments will be=0D=0A> based, at least initially. I strongly urge this W= G to reconsider this=0D=0A> restriction and include circle, and ellipse at = a minimum.=0D=0A> =20=0D=0ASome time back we also discussed this issue and= the conclusion was the=20=0D=0Afollowing:=0D=0A* Let us build a mechanism = in there to have a mechanism to extend the=20=0D=0Alocation shapes.=0D=0A* = Let us specify simple location shapes first.=0D=0A=0D=0AI know that there i= s this limitation with geodetic shapes and a separate=0D=0A=0D=0Alocation p= rofile would be needed to address GPS and the cellular world.=0D=0AOn the c= ellular aspect we also had a discussion with the 3GPP. There=20=0D=0Athey a= re currently not using LoST at the end point since they are=20=0D=0Afocusin= g on a different architecture (see=20=0D=0Ahttp://tools.ietf.org/html/draft= -tschofenig-ecrit-architecture-overview-=0D=0A00).=20=0D=0AEven if they wou= ld use LoST at the end point they most likely want to=20=0D=0Ahide the loca= tion information of the end point or to make use of=20=0D=0Ainformation lik= e cell ids (as recorded in the issue tracker a while ago:=0D=0A=0D=0Ahttp:/= /www.tschofenig.priv.at:8080/lost/issue16).=0D=0A=0D=0ANow, everything boils do= wn to the question of GPS. Since GPS produces=20=0D=0Adata in a format that= is not PIDF-LO alike we can already assume that=20=0D=0Athe end host has t= o understand the format. It can now encode it in=20=0D=0Adifferent ways. In= previous discussions a couple of us wanted to add a=20=0D=0Apolygon as a l= ocation profile to the LoST document since it would also=20=0D=0Aaddress th= e location hiding requirement. Since this issue came also up=20=0D=0Ain the= location hiding context we postpone this topic entirely.=0D=0A=0D=0AHence,= it is up to us to come up with a location profile that supports=0D=0A* a c= ircle=0D=0A* an ellipse=0D=0A* a polygon,=0D=0A* a combination of the above=0D= =0A* cell-ids=0D=0Aif we think there is a need todo so.=0D=0A=0D=0ACiao=0D=0A= Hannes=0D=0A=0D=0A> Cheers=0D=0A> James=0D=0A>=0D=0A> =20=0D=0A>> -----Ori= ginal Message-----=0D=0A>> From: Hannes Tschofenig [mailto:Hannes.Tschofeni= g@gmx.net]=0D=0A>> Sent: Wednesday, 11 July 2007 4:58 PM=0D=0A>> To: Winter= bottom, James=0D=0A>> Cc: ECRIT=0D=0A>> Subject: Re: [Ecrit] LoST=0D=0A>>=0D= =0A>> Hi James,=0D=0A>>=0D=0A>> let me pick a concrete example: LoST server= discovery.=0D=0A>> Currently, we have specified the usage of DHCP and DNS.= Only the=0D=0A>> =20=0D=0A> former=0D=0A> =20=0D=0A>> allows to discov= er the LoST server in the access network. I am,=0D=0A>> =20=0D=0A> howev= er,=0D=0A> =20=0D=0A>> aware of the work on HELD discovery, see=0D=0A>> ht= tp://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-=0D=0A>>= 01.txt,=0D=0A>> that aims to discover a HELD server in the access network = using DNS=0D=0A>> mechanisms.=0D=0A>>=0D=0A>> Now, even though the current = LoST draft does not describe how to=0D=0A>> discover a LoST server using DN= S in the access network that can be=0D=0A>> extended later when the above d= ocument is generalized (which I think=0D=0A>> would be a good idea).=0D=0A>= >=0D=0A>> Does that make sense to you=3F=0D=0A>>=0D=0A>> Ciao=0D=0A>> Hanne= s=0D=0A>>=0D=0A>> Winterbottom, James wrote:=0D=0A>> =20=0D=0A>>> Hi Han= nes,=0D=0A>>>=0D=0A>>> What exactly do you mean by postponed=3F=0D=0A>>>=0D= =0A>>> Cheers=0D=0A>>> James=0D=0A>>>=0D=0A>>>=0D=0A>>>=0D=0A>>>=0D=0A>>>=0D= =0A>>> =20=0D=0A>>>> -----Original Message-----=0D=0A>>>> From: Hannes= Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>>>> Sent: Wednesday, 1= 1 July 2007 5:58 AM=0D=0A>>>> To: ECRIT=0D=0A>>>> Subject: [Ecrit] LoST=0D=0A= >>>>=0D=0A>>>> Hi all,=0D=0A>>>>=0D=0A>>>> during the WGLC we have received= a number of comments. Then, we=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>> del= ayed=0D=0A>>>=0D=0A>>> =20=0D=0A>>>> the completion of the work becaus= e of the location hiding=0D=0A>>>> =20=0D=0A> discussions.=0D=0A> =0D= =0A>>>> Now, you can find the latest version of the document at:=0D=0A>>>>=0D= =0A>>>>=0D=0A>>>> =20=0D=0A>=0D=0Ahttp://www.tschofenig.priv.at/svn/draf= t-ietf-ecrit-lost/draft-ietf-ecrit-los=0D=0A> =20=0D=0A>>> t-=0D=0A>>>=0D=0A= >>> =20=0D=0A>>>> 06.txt=0D=0A>>>>=0D=0A>>>> We have also updated the = DHCP-based LoST discovery draft (based on=0D=0A>>>> =20=0D=0A> the=0D= =0A> =20=0D=0A>>>> comments we received from the DHC working group). The d= ocument can=0D=0A>>>> =20=0D=0A> be=0D=0A> =20=0D=0A>>>> found here= :=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> =20=0D=0A>=0D=0Ahttp://www.tschofeni= g.com/svn/draft-tschofenig-dhc-lost-discovery/draft-=0D=0A> =20=0D=0A>>>> = ietf-ecrit-dhc-lost-discovery-02.txt=0D=0A>>>>=0D=0A>>>> Now, here is the u= nfortunate news: It seems that we did not submit=0D=0A>>>> =20=0D=0A= > the=0D=0A> =20=0D=0A>>>> LoST draft :-(=0D=0A>>>> Everyone was assuming = that someone else is going to submit it.=0D=0A>>>>=0D=0A>>>> Ciao=0D=0A>>>>= Hannes=0D=0A>>>>=0D=0A>>>> PS: James has recently sent a number of comment= s. Some of them got=0D=0A>>>> reflected in the document (namely the editori= al onces). Others got=0D=0A>>>> intentionally postponed since we discussed = them already in the=0D=0A>>>> =20=0D=0A> past.=0D=0A> =20=0D=0A>>>>= _______________________________________________=0D=0A>>>> Ecrit mailing li= st=0D=0A>>>> Ecrit@ietf.org=0D=0A>>>> https://www1.ietf.org/mailman/listinf= o/ecrit=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>> =20=0D=0A>=0D=0A------= ------------------------------------------------------------------=0D=0A> = =20=0D=0A>> ------------------------=0D=0A>> =20=0D=0A>>> This message i= s for the designated recipient only and may=0D=0A>>> contain privileged, pr= oprietary, or otherwise private information.=0D=0A>>> If you have received = it in error, please notify the sender=0D=0A>>> immediately and delete the o= riginal. Any unauthorized use of=0D=0A>>> this email is prohibited.=0D=0A>= >>=0D=0A>>> =20=0D=0A>=0D=0A------------------------------------------= ------------------------------=0D=0A> =20=0D=0A>> ------------------------=0D= =0A>> =20=0D=0A>>> [mf2]=0D=0A>>>=0D=0A>>>=0D=0A>>> =20=0D=0A>=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A------------------------=0D=0A> This message is for the designate= d recipient only and may=0D=0A> contain privileged, proprietary, or otherwi= se private information. =20=0D=0A> If you have received it in error, please= notify the sender=0D=0A> immediately and delete the original. Any unautho= rized use of=0D=0A> this email is prohibited.=0D=0A>=0D=0A-----------------= -------------------------------------------------------=0D=0A--------------= ----------=0D=0A> [mf2]=0D=0A>=0D=0A> =20=0D=0A=0D=0A=0D=0A_______________= ________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.or= g=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------------= ---------------------------------------------------------------------------= ---------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YSg-0001Ge-A1; Wed, 11 Jul 2007 05:26:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YSe-0001Fw-O2 for ecrit@ietf.org; Wed, 11 Jul 2007 05:26:16 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I8YSa-0001yp-0K for ecrit@ietf.org; Wed, 11 Jul 2007 05:26:16 -0400 Received: (qmail invoked by alias); 11 Jul 2007 09:26:08 -0000 Received: from p54987267.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.114.103] by mail.gmx.net (mp001) with SMTP; 11 Jul 2007 11:26:08 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+mDjt9zxOm5vJzJkODMOGpuMjTuIgaRlmXJuQrmU AaBckkVEUscjxf Message-ID: <4694A229.2070002@gmx.net> Date: Wed, 11 Jul 2007 11:26:01 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Winterbottom, James" Subject: Re: [Ecrit] LoST References: <4693E4D4.1000905@gmx.net> <46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> 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: bc102ac530ba955ef81f1f75b8bebe44 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi James, Winterbottom, James wrote: > Hi Hannes, > > The concern I have is that GPS is not only cellular. > I know that GPS has nothing todo with cellular systems. I haven't said that. > It is being used in WiFI and will be used from the get go in WiMAX. > The only profiles that will be mandatory to support are those in the > basic LoST specification, so the decision is generally unacceptable from > a deployment perspective. > You can also define extensions that a mandatory to implement in another document. > I don't agree with the assessment below either. > With with point in particular? > I can easily see that LIS could provide a PIDF-LO to me that I have > provided satellite pseudo-ranges for. Let's assume the GPS that is being used today. There is no PIDF-LO in use. > So again I remain unconvinced by > this debate. It is far simpler to interpret the ellipse and circle types > than a polygon, and to be frank from an end-point or measure location > perspective far more likely to be provided. > That's fine since we don't have a polygon in the LoST document either. Ciao Hanes > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, 11 July 2007 6:55 PM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] LoST >> >> Hi James, >> >> Winterbottom, James wrote: >> >>> Hi Hannes, >>> >>> That makes perfect sense. >>> >>> The issue that I am most concerned about is the limitation in the >>> > shape > >>> representation in the basic location profile. As it currently stands >>> > I > >>> cannot use standard GPS related shapes, my end-point has to >>> > interpret > >>> location and put into a profile. This is incompatible with a large >>> number of solutions deployed today on which many deployments will be >>> based, at least initially. I strongly urge this WG to reconsider >>> > this > >>> restriction and include circle, and ellipse at a minimum. >>> >>> >> Some time back we also discussed this issue and the conclusion was the >> following: >> * Let us build a mechanism in there to have a mechanism to extend the >> location shapes. >> * Let us specify simple location shapes first. >> >> I know that there is this limitation with geodetic shapes and a >> > separate > >> location profile would be needed to address GPS and the cellular >> > world. > >> On the cellular aspect we also had a discussion with the 3GPP. There >> they are currently not using LoST at the end point since they are >> focusing on a different architecture (see >> >> > http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview- > >> 00). >> Even if they would use LoST at the end point they most likely want to >> hide the location information of the end point or to make use of >> information like cell ids (as recorded in the issue tracker a while >> > ago: > >> http://www.tschofenig.priv.at:8080/lost/issue16). >> >> Now, everything boils down to the question of GPS. Since GPS produces >> data in a format that is not PIDF-LO alike we can already assume that >> the end host has to understand the format. It can now encode it in >> different ways. In previous discussions a couple of us wanted to add a >> polygon as a location profile to the LoST document since it would also >> address the location hiding requirement. Since this issue came also up >> in the location hiding context we postpone this topic entirely. >> >> Hence, it is up to us to come up with a location profile that supports >> * a circle >> * an ellipse >> * a polygon, >> * a combination of the above >> * cell-ids >> if we think there is a need todo so. >> >> Ciao >> Hannes >> >> >>> Cheers >>> James >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Wednesday, 11 July 2007 4:58 PM >>>> To: Winterbottom, James >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] LoST >>>> >>>> Hi James, >>>> >>>> let me pick a concrete example: LoST server discovery. >>>> Currently, we have specified the usage of DHCP and DNS. Only the >>>> >>>> >>> former >>> >>> >>>> allows to discover the LoST server in the access network. I am, >>>> >>>> >>> however, >>> >>> >>>> aware of the work on HELD discovery, see >>>> >>>> > http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery- > >>>> 01.txt, >>>> that aims to discover a HELD server in the access network using DNS >>>> mechanisms. >>>> >>>> Now, even though the current LoST draft does not describe how to >>>> discover a LoST server using DNS in the access network that can be >>>> extended later when the above document is generalized (which I >>>> > think > >>>> would be a good idea). >>>> >>>> Does that make sense to you? >>>> >>>> Ciao >>>> Hannes >>>> >>>> Winterbottom, James wrote: >>>> >>>> >>>>> Hi Hannes, >>>>> >>>>> What exactly do you mean by postponed? >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Wednesday, 11 July 2007 5:58 AM >>>>>> To: ECRIT >>>>>> Subject: [Ecrit] LoST >>>>>> >>>>>> Hi all, >>>>>> >>>>>> during the WGLC we have received a number of comments. Then, we >>>>>> >>>>>> >>>>>> >>>>> delayed >>>>> >>>>> >>>>> >>>>>> the completion of the work because of the location hiding >>>>>> >>>>>> >>> discussions. >>> >>> >>>>>> Now, you can find the latest version of the document at: >>>>>> >>>>>> >>>>>> >>>>>> > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los > >>>>> t- >>>>> >>>>> >>>>> >>>>>> 06.txt >>>>>> >>>>>> We have also updated the DHCP-based LoST discovery draft (based >>>>>> > on > >>> the >>> >>> >>>>>> comments we received from the DHC working group). The document >>>>>> > can > >>> be >>> >>> >>>>>> found here: >>>>>> >>>>>> >>>>>> >>>>>> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft- > >>>>>> ietf-ecrit-dhc-lost-discovery-02.txt >>>>>> >>>>>> Now, here is the unfortunate news: It seems that we did not >>>>>> > submit > >>> the >>> >>> >>>>>> LoST draft :-( >>>>>> Everyone was assuming that someone else is going to submit it. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> PS: James has recently sent a number of comments. Some of them >>>>>> > got > >>>>>> reflected in the document (namely the editorial onces). Others >>>>>> > got > >>>>>> intentionally postponed since we discussed them already in the >>>>>> >>>>>> >>> past. >>> >>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> > ------------------------------------------------------------------------ > >>>> ------------------------ >>>> >>>> >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ > >>>> ------------------------ >>>> >>>> >>>>> [mf2] >>>>> >>>>> >>>>> >>>>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >>> [mf2] >>> >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:32:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YZ7-00021x-Ay; Wed, 11 Jul 2007 05:32:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YZ6-00021o-81 for ecrit@ietf.org; Wed, 11 Jul 2007 05:32:56 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8YZ5-00035d-GO for ecrit@ietf.org; Wed, 11 Jul 2007 05:32:56 -0400 Received: (qmail invoked by alias); 11 Jul 2007 09:32:38 -0000 Received: from p54987267.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.114.103] by mail.gmx.net (mp032) with SMTP; 11 Jul 2007 11:32:38 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18z6vk+jY8zpsXrPPgfwqgGEDQQdI34GS4RSAwlaE W8r8Ify/HeNG6u Message-ID: <4694A3AE.2090506@gmx.net> Date: Wed, 11 Jul 2007 11:32:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Ecrit] LoST References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> 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: fac892abe0c719c7bb99f6e7c710cdae Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, Dawson, Martin wrote: > Hi Hannes, > > This seems a bit bogged down in the here and now... A LIS for almost any > access technology, with or without GPS, could produce a geo-shape as a > consequence of the location-determination technique it employs. What > 3GPP may be thinking now doesn't seem particularly pertinent. > True. A LCS (this is the correct terminology now) can indeed produce a PIDF-LO with the Geo-Shapes format. When you use a GPS receiver today (and probably for a long time) then it does not produce a format in XML format since there is just no LCP involved. > There's already a pdif-lo-profile draft ([sic] is the spelling ever > going to get corrected btw or is a title immutable?) that states what > shapes should be used and defines what the LIS clients can expect to > receive. > We decided not to change the file name. When the document gets published as RFC then the filename does not matter anway. Btw, we recognized the wrong spelling with version -04 or so. > While I accept that a LoST implementor could add support for that > profile, as long as it is optional to do so, the client cannot be sure > that anything other than a point will be supported. A new document can also say that the new location profile is mandatory to implement. Do you think that will be a problem? > This adds the dual > issue of making the client always convert to a point form and/or > eliminating the prospect of LoST servers being able to do more > sophisticated routing based on weighted coverage by uncertainty. > > Rather than invite the compatibility issue at a later date, wouldn't it > be more prudent just to add the requirement now? > No doubt that we could add an additional location profile right now. I am just repeating what we agreed earlier in the working group on this particular issue. If the working group now thinks that this is a problem then we should re-consider it. I just want to open-up previously closed or postponed issues too quickly. Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, 11 July 2007 6:55 PM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] LoST > > Hi James, > > Winterbottom, James wrote: > >> Hi Hannes, >> >> That makes perfect sense. >> >> The issue that I am most concerned about is the limitation in the >> > shape > >> representation in the basic location profile. As it currently stands I >> cannot use standard GPS related shapes, my end-point has to interpret >> location and put into a profile. This is incompatible with a large >> number of solutions deployed today on which many deployments will be >> based, at least initially. I strongly urge this WG to reconsider this >> restriction and include circle, and ellipse at a minimum. >> >> > Some time back we also discussed this issue and the conclusion was the > following: > * Let us build a mechanism in there to have a mechanism to extend the > location shapes. > * Let us specify simple location shapes first. > > I know that there is this limitation with geodetic shapes and a separate > > location profile would be needed to address GPS and the cellular world. > On the cellular aspect we also had a discussion with the 3GPP. There > they are currently not using LoST at the end point since they are > focusing on a different architecture (see > http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview- > 00). > Even if they would use LoST at the end point they most likely want to > hide the location information of the end point or to make use of > information like cell ids (as recorded in the issue tracker a while ago: > > http://www.tschofenig.priv.at:8080/lost/issue16). > > Now, everything boils down to the question of GPS. Since GPS produces > data in a format that is not PIDF-LO alike we can already assume that > the end host has to understand the format. It can now encode it in > different ways. In previous discussions a couple of us wanted to add a > polygon as a location profile to the LoST document since it would also > address the location hiding requirement. Since this issue came also up > in the location hiding context we postpone this topic entirely. > > Hence, it is up to us to come up with a location profile that supports > * a circle > * an ellipse > * a polygon, > * a combination of the above > * cell-ids > if we think there is a need todo so. > > Ciao > Hannes > > >> Cheers >> James >> >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Wednesday, 11 July 2007 4:58 PM >>> To: Winterbottom, James >>> Cc: ECRIT >>> Subject: Re: [Ecrit] LoST >>> >>> Hi James, >>> >>> let me pick a concrete example: LoST server discovery. >>> Currently, we have specified the usage of DHCP and DNS. Only the >>> >>> >> former >> >> >>> allows to discover the LoST server in the access network. I am, >>> >>> >> however, >> >> >>> aware of the work on HELD discovery, see >>> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery- >>> 01.txt, >>> that aims to discover a HELD server in the access network using DNS >>> mechanisms. >>> >>> Now, even though the current LoST draft does not describe how to >>> discover a LoST server using DNS in the access network that can be >>> extended later when the above document is generalized (which I think >>> would be a good idea). >>> >>> Does that make sense to you? >>> >>> Ciao >>> Hannes >>> >>> Winterbottom, James wrote: >>> >>> >>>> Hi Hannes, >>>> >>>> What exactly do you mean by postponed? >>>> >>>> Cheers >>>> James >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Wednesday, 11 July 2007 5:58 AM >>>>> To: ECRIT >>>>> Subject: [Ecrit] LoST >>>>> >>>>> Hi all, >>>>> >>>>> during the WGLC we have received a number of comments. Then, we >>>>> >>>>> >>>>> >>>> delayed >>>> >>>> >>>> >>>>> the completion of the work because of the location hiding >>>>> >>>>> >> discussions. >> >> >>>>> Now, you can find the latest version of the document at: >>>>> >>>>> >>>>> >>>>> > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los > >> >> >>>> t- >>>> >>>> >>>> >>>>> 06.txt >>>>> >>>>> We have also updated the DHCP-based LoST discovery draft (based on >>>>> >>>>> >> the >> >> >>>>> comments we received from the DHC working group). The document can >>>>> >>>>> >> be >> >> >>>>> found here: >>>>> >>>>> >>>>> >>>>> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft- > >> >> >>>>> ietf-ecrit-dhc-lost-discovery-02.txt >>>>> >>>>> Now, here is the unfortunate news: It seems that we did not submit >>>>> >>>>> >> the >> >> >>>>> LoST draft :-( >>>>> Everyone was assuming that someone else is going to submit it. >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> PS: James has recently sent a number of comments. Some of them got >>>>> reflected in the document (namely the editorial onces). Others got >>>>> intentionally postponed since we discussed them already in the >>>>> >>>>> >> past. >> >> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>> >>>> >>>> > ------------------------------------------------------------------------ > >> >> >>> ------------------------ >>> >>> >>>> This message is for the designated recipient only and may >>>> contain privileged, proprietary, or otherwise private information. >>>> If you have received it in error, please notify the sender >>>> immediately and delete the original. Any unauthorized use of >>>> this email is prohibited. >>>> >>>> >>>> > ------------------------------------------------------------------------ > >> >> >>> ------------------------ >>> >>> >>>> [mf2] >>>> >>>> >>>> >>>> >> > ------------------------------------------------------------------------ > ------------------------ > >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> >> > ------------------------------------------------------------------------ > ------------------------ > >> [mf2] >> >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:42:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YiD-0002xW-Im; Wed, 11 Jul 2007 05:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YiC-0002xN-Hg for ecrit@ietf.org; Wed, 11 Jul 2007 05:42:20 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8Yi7-0002Sa-UV for ecrit@ietf.org; Wed, 11 Jul 2007 05:42:20 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_04_50_26 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 04:50:26 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 04:42:14 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 04:41:14 -0500 Message-ID: In-Reply-To: <4694A3AE.2090506@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDnm13WxQN9iwBR4qFa3SvoiccoQAADUDQ References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A3AE.2090506@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 09:42:14.0037 (UTC) FILETIME=[C2E54450:01C7C39F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks Hannes,=0D=0A=0D=0AYes, I'm suggesting that since the profile spec i= s about to go RFC, that=0D=0Athe LoST spec might just as well reference it = so we have a consistent=0D=0Aecology of specs. I think that having a subseq= uent spec make the profile=0D=0Amandatory would only be an issue if it came= after LoST was implemented.=0D=0AOn the other hand, if we assume it will h= appen before LoST is=0D=0Aimplemented, then why not just include the requir= ement now.=0D=0A=0D=0AWith respect to GPS - a LIS (LCS, whatever) could uti= lize any suitable=0D=0Aprotocol, including SUPL, to do GPS interactions wit= h the client - it=0D=0Astill casts the result as a PIDF-LO in the response.= I'm not really=0D=0Athinking of the situation where the device does a GPS = fix or gets it=0D=0Afrom some other non-PIDF-LO source. In that case, I'd c= ertainly agree=0D=0Athat the device may as well transcode it into the basic= form. I'm not=0D=0Areally concerned about that situation.=0D=0A=0D=0ACheer= s,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Hannes Tsch= ofenig [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0ASent: Wednesday, 11 July = 2007 7:33 PM=0D=0ATo: Dawson, Martin=0D=0ACc: Winterbottom, James; ECRIT=0D= =0ASubject: Re: [Ecrit] LoST=0D=0A=0D=0AHi Martin,=0D=0A=0D=0ADawson, Marti= n wrote:=0D=0A> Hi Hannes,=0D=0A>=0D=0A> This seems a bit bogged down in th= e here and now... A LIS for almost=0D=0Aany=0D=0A> access technology, with = or without GPS, could produce a geo-shape as a=0D=0A> consequence of the lo= cation-determination technique it employs. What=0D=0A> 3GPP may be thinking= now doesn't seem particularly pertinent.=0D=0A> =20=0D=0ATrue. A LCS (thi= s is the correct terminology now) can indeed produce a=20=0D=0APIDF-LO with= the Geo-Shapes format.=0D=0A=0D=0AWhen you use a GPS receiver today (and p= robably for a long time) then it=0D=0A=0D=0Adoes not produce a format in XM= L format since there is just no LCP=20=0D=0Ainvolved.=0D=0A=0D=0A> There's = already a pdif-lo-profile draft ([sic] is the spelling ever=0D=0A> going to= get corrected btw or is a title immutable=3F) that states what=0D=0A> shap= es should be used and defines what the LIS clients can expect to=0D=0A> rec= eive.=0D=0A> =20=0D=0AWe decided not to change the file name. When the doc= ument gets published=0D=0A=0D=0Aas RFC then the filename does not matter an= way.=0D=0ABtw, we recognized the wrong spelling with version -04 or so.=0D=0A=0D= =0A> While I accept that a LoST implementor could add support for that=0D=0A= > profile, as long as it is optional to do so, the client cannot be sure=0D= =0A> that anything other than a point will be supported.=0D=0AA new documen= t can also say that the new location profile is mandatory=20=0D=0Ato implem= ent. Do you think that will be a problem=3F=0D=0A=0D=0A> This adds the dua= l=0D=0A> issue of making the client always convert to a point form and/or=0D= =0A> eliminating the prospect of LoST servers being able to do more=0D=0A> = sophisticated routing based on weighted coverage by uncertainty.=0D=0A>=0D=0A= > Rather than invite the compatibility issue at a later date, wouldn't=0D=0A= it=0D=0A> be more prudent just to add the requirement now=3F=0D=0A> =20=0D= =0ANo doubt that we could add an additional location profile right now.=0D=0A=0D= =0AI am just repeating what we agreed earlier in the working group on this =0D= =0Aparticular issue. If the working group now thinks that this is a problem=0D= =0A=0D=0Athen we should re-consider it. I just want to open-up previously c= losed=20=0D=0Aor postponed issues too quickly.=0D=0A=0D=0A=0D=0ACiao=0D=0AH= annes=0D=0A=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D=0A> -----Original Messag= e-----=0D=0A> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] =0D= =0A> Sent: Wednesday, 11 July 2007 6:55 PM=0D=0A> To: Winterbottom, James=0D= =0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] LoST=0D=0A>=0D=0A> Hi James,=0D=0A= >=0D=0A> Winterbottom, James wrote:=0D=0A> =20=0D=0A>> Hi Hannes,=0D=0A>>=0D= =0A>> That makes perfect sense.=0D=0A>>=0D=0A>> The issue that I am most co= ncerned about is the limitation in the=0D=0A>> =20=0D=0A> shape=0D=0A> = =20=0D=0A>> representation in the basic location profile. As it currently s= tands=0D=0AI=0D=0A>> cannot use standard GPS related shapes, my end-point h= as to interpret=0D=0A>> location and put into a profile. This is incompatib= le with a large=0D=0A>> number of solutions deployed today on which many de= ployments will be=0D=0A>> based, at least initially. I strongly urge this W= G to reconsider this=0D=0A>> restriction and include circle, and ellipse at= a minimum.=0D=0A>> =20=0D=0A>> =20=0D=0A> Some time back we also discu= ssed this issue and the conclusion was the=0D=0A=0D=0A> following:=0D=0A> *= Let us build a mechanism in there to have a mechanism to extend the=20=0D=0A= > location shapes.=0D=0A> * Let us specify simple location shapes first.=0D= =0A>=0D=0A> I know that there is this limitation with geodetic shapes and a=0D= =0Aseparate=0D=0A>=0D=0A> location profile would be needed to address GPS a= nd the cellular=0D=0Aworld.=0D=0A> On the cellular aspect we also had a dis= cussion with the 3GPP. There=20=0D=0A> they are currently not using LoST at= the end point since they are=20=0D=0A> focusing on a different architectur= e (see=20=0D=0A>=0D=0Ahttp://tools.ietf.org/html/draft-tschofenig-ecrit-arc= hitecture-overview-=0D=0A> 00).=20=0D=0A> Even if they would use LoST at th= e end point they most likely want to=20=0D=0A> hide the location informatio= n of the end point or to make use of=20=0D=0A> information like cell ids (a= s recorded in the issue tracker a while=0D=0Aago:=0D=0A>=0D=0A> http://www.= tschofenig.priv.at:8080/lost/issue16).=0D=0A>=0D=0A> Now, everything boils down= to the question of GPS. Since GPS produces=20=0D=0A> data in a format that= is not PIDF-LO alike we can already assume that=20=0D=0A> the end host has= to understand the format. It can now encode it in=20=0D=0A> different ways= =2E In previous discussions a couple of us wanted to add a=0D=0A=0D=0A> pol= ygon as a location profile to the LoST document since it would also=0D=0A=0D= =0A> address the location hiding requirement. Since this issue came also up=0D= =0A=0D=0A> in the location hiding context we postpone this topic entirely.=0D= =0A>=0D=0A> Hence, it is up to us to come up with a location profile that s= upports=0D=0A> * a circle=0D=0A> * an ellipse=0D=0A> * a polygon,=0D=0A> * = a combination of the above=0D=0A> * cell-ids=0D=0A> if we think there is a = need todo so.=0D=0A>=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=0D=0A> =20=0D=0A>> C= heers=0D=0A>> James=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>>> -----Origi= nal Message-----=0D=0A>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig= @gmx.net]=0D=0A>>> Sent: Wednesday, 11 July 2007 4:58 PM=0D=0A>>> To: Winte= rbottom, James=0D=0A>>> Cc: ECRIT=0D=0A>>> Subject: Re: [Ecrit] LoST=0D=0A>= >>=0D=0A>>> Hi James,=0D=0A>>>=0D=0A>>> let me pick a concrete example: LoS= T server discovery.=0D=0A>>> Currently, we have specified the usage of DHCP= and DNS. Only the=0D=0A>>> =20=0D=0A>>> =20=0D=0A>> former=0D=0A>>= =20=0D=0A>> =20=0D=0A>>> allows to discover the LoST server in the acc= ess network. I am,=0D=0A>>> =20=0D=0A>>> =20=0D=0A>> however,=0D=0A= >> =20=0D=0A>> =20=0D=0A>>> aware of the work on HELD discovery, see=0D= =0A>>>=0D=0Ahttp://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-disc= overy-=0D=0A>>> 01.txt,=0D=0A>>> that aims to discover a HELD server in the= access network using DNS=0D=0A>>> mechanisms.=0D=0A>>>=0D=0A>>> Now, even = though the current LoST draft does not describe how to=0D=0A>>> discover a = LoST server using DNS in the access network that can be=0D=0A>>> extended l= ater when the above document is generalized (which I think=0D=0A>>> would b= e a good idea).=0D=0A>>>=0D=0A>>> Does that make sense to you=3F=0D=0A>>>=0D= =0A>>> Ciao=0D=0A>>> Hannes=0D=0A>>>=0D=0A>>> Winterbottom, James wrote:=0D= =0A>>> =20=0D=0A>>> =20=0D=0A>>>> Hi Hannes,=0D=0A>>>>=0D=0A>>>> Wh= at exactly do you mean by postponed=3F=0D=0A>>>>=0D=0A>>>> Cheers=0D=0A>>>>= James=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> =0D= =0A>>>> =20=0D=0A>>>>> -----Original Message-----=0D=0A>>>>> From: H= annes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>>>>> Sent: Wednes= day, 11 July 2007 5:58 AM=0D=0A>>>>> To: ECRIT=0D=0A>>>>> Subject: [Ecrit] = LoST=0D=0A>>>>>=0D=0A>>>>> Hi all,=0D=0A>>>>>=0D=0A>>>>> during the WGLC we= have received a number of comments. Then, we=0D=0A>>>>>=0D=0A>>>>> = =20=0D=0A>>>>> =20=0D=0A>>>> delayed=0D=0A>>>>=0D=0A>>>> =20=0D= =0A>>>> =20=0D=0A>>>>> the completion of the work because of the loc= ation hiding=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>> discussi= ons.=0D=0A>> =20=0D=0A>> =20=0D=0A>>>>> Now, you can find the latest ve= rsion of the document at:=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A= >>>>> =20=0D=0A>=0D=0Ahttp://www.tschofenig.priv.at/svn/draft-ietf-ecr= it-lost/draft-ietf-ecrit-los=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>= >>> t-=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>> 06.txt=0D= =0A>>>>>=0D=0A>>>>> We have also updated the DHCP-based LoST discovery draf= t (based on=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>> the=0D=0A= >> =20=0D=0A>> =20=0D=0A>>>>> comments we received from the DHC working= group). The document can=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A= >> be=0D=0A>> =20=0D=0A>> =20=0D=0A>>>>> found here:=0D=0A>>>>>=0D=0A>>= >>>=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>=0D=0Ahttp://www.ts= chofenig.com/svn/draft-tschofenig-dhc-lost-discovery/draft-=0D=0A> =20=0D=0A= >> =20=0D=0A>> =20=0D=0A>>>>> ietf-ecrit-dhc-lost-discovery-02.txt=0D=0A= >>>>>=0D=0A>>>>> Now, here is the unfortunate news: It seems that we did no= t submit=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>> the=0D=0A>> = =20=0D=0A>> =20=0D=0A>>>>> LoST draft :-(=0D=0A>>>>> Everyone was assum= ing that someone else is going to submit it.=0D=0A>>>>>=0D=0A>>>>> Ciao=0D=0A= >>>>> Hannes=0D=0A>>>>>=0D=0A>>>>> PS: James has recently sent a number of = comments. Some of them got=0D=0A>>>>> reflected in the document (namely the= editorial onces). Others got=0D=0A>>>>> intentionally postponed since we d= iscussed them already in the=0D=0A>>>>> =20=0D=0A>>>>> =20=0D= =0A>> past.=0D=0A>> =20=0D=0A>> =20=0D=0A>>>>> ________________________= _______________________=0D=0A>>>>> Ecrit mailing list=0D=0A>>>>> Ecrit@ietf= =2Eorg=0D=0A>>>>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>>>>>=0D= =0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>> =20=0D=0A>>>> = =20=0D=0A>=0D=0A------------------------------------------------------= ------------------=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> -------= -----------------=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> This message = is for the designated recipient only and may=0D=0A>>>> contain privileged, = proprietary, or otherwise private information.=0D=0A>>>> If you have receiv= ed it in error, please notify the sender=0D=0A>>>> immediately and delete t= he original. Any unauthorized use of=0D=0A>>>> this email is prohibited.=0D= =0A>>>>=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>=0D=0A---------------= ---------------------------------------------------------=0D=0A> =20=0D=0A= >> =20=0D=0A>> =20=0D=0A>>> ------------------------=0D=0A>>> =20=0D= =0A>>> =20=0D=0A>>>> [mf2]=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> =20=0D=0A= >>>> =20=0D=0A>> =20=0D=0A>=0D=0A--------------------------------= ----------------------------------------=0D=0A> ------------------------=0D= =0A> =20=0D=0A>> This message is for the designated recipient only and may=0D= =0A>> contain privileged, proprietary, or otherwise private information. =0D= =0A>> If you have received it in error, please notify the sender=0D=0A>> im= mediately and delete the original. Any unauthorized use of=0D=0A>> this em= ail is prohibited.=0D=0A>>=0D=0A>> =20=0D=0A>=0D=0A---------------------= ---------------------------------------------------=0D=0A> ----------------= --------=0D=0A> =20=0D=0A>> [mf2]=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A= >=0D=0A>=0D=0A> _______________________________________________=0D=0A> Ecri= t mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/l= istinfo/ecrit=0D=0A>=0D=0A>=0D=0A------------------------------------------= ------------------------------=0D=0A------------------------=0D=0A> This me= ssage is for the designated recipient only and may=0D=0A> contain privilege= d, proprietary, or otherwise private information. =20=0D=0A> If you have re= ceived it in error, please notify the sender=0D=0A> immediately and delete = the original. Any unauthorized use of=0D=0A> this email is prohibited.=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A------------------------=0D=0A> [mf2]=0D=0A>=0D=0A> =20=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:55:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YuX-00074g-Vr; Wed, 11 Jul 2007 05:55:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YuX-00074W-JG for ecrit@ietf.org; Wed, 11 Jul 2007 05:55:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8YuW-0003Xu-Ls for ecrit@ietf.org; Wed, 11 Jul 2007 05:55:05 -0400 Received: (qmail invoked by alias); 11 Jul 2007 09:54:46 -0000 Received: from p54987C44.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.68] by mail.gmx.net (mp056) with SMTP; 11 Jul 2007 11:54:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1927mcKfXp2Mv+hkCy+7qLD3GlZ476CkTeEwnVzi+ f1TXLJyAtiPgqu Message-ID: <4694A8DE.7010202@gmx.net> Date: Wed, 11 Jul 2007 11:54:38 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Ecrit] LoST References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A3AE.2090506@gmx.net> 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: 8f3b9db08b8c0fe2301a77f547096e31 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, Dawson, Martin wrote: > Thanks Hannes, > > Yes, I'm suggesting that since the profile spec is about to go RFC, that > the LoST spec might just as well reference it so we have a consistent > ecology of specs. I think that having a subsequent spec make the profile > mandatory would only be an issue if it came after LoST was implemented. > On the other hand, if we assume it will happen before LoST is > implemented, then why not just include the requirement now. > I would like to let the group decide. > With respect to GPS - a LIS (LCS, whatever) could utilize any suitable > protocol, including SUPL, to do GPS interactions with the client - it > still casts the result as a PIDF-LO in the response. I'm not really > thinking of the situation where the device does a GPS fix or gets it > from some other non-PIDF-LO source. In that case, I'd certainly agree > that the device may as well transcode it into the basic form. I'm not > really concerned about that situation. > > I know about this feature in SUPL. Still, do most GPS devices today use SUPL? Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, 11 July 2007 7:33 PM > To: Dawson, Martin > Cc: Winterbottom, James; ECRIT > Subject: Re: [Ecrit] LoST > > Hi Martin, > > Dawson, Martin wrote: > >> Hi Hannes, >> >> This seems a bit bogged down in the here and now... A LIS for almost >> > any > >> access technology, with or without GPS, could produce a geo-shape as a >> consequence of the location-determination technique it employs. What >> 3GPP may be thinking now doesn't seem particularly pertinent. >> >> > True. A LCS (this is the correct terminology now) can indeed produce a > PIDF-LO with the Geo-Shapes format. > > When you use a GPS receiver today (and probably for a long time) then it > > does not produce a format in XML format since there is just no LCP > involved. > > >> There's already a pdif-lo-profile draft ([sic] is the spelling ever >> going to get corrected btw or is a title immutable?) that states what >> shapes should be used and defines what the LIS clients can expect to >> receive. >> >> > We decided not to change the file name. When the document gets published > > as RFC then the filename does not matter anway. > Btw, we recognized the wrong spelling with version -04 or so. > > >> While I accept that a LoST implementor could add support for that >> profile, as long as it is optional to do so, the client cannot be sure >> that anything other than a point will be supported. >> > A new document can also say that the new location profile is mandatory > to implement. Do you think that will be a problem? > > >> This adds the dual >> issue of making the client always convert to a point form and/or >> eliminating the prospect of LoST servers being able to do more >> sophisticated routing based on weighted coverage by uncertainty. >> >> Rather than invite the compatibility issue at a later date, wouldn't >> > it > >> be more prudent just to add the requirement now? >> >> > No doubt that we could add an additional location profile right now. > > I am just repeating what we agreed earlier in the working group on this > particular issue. If the working group now thinks that this is a problem > > then we should re-consider it. I just want to open-up previously closed > or postponed issues too quickly. > > > Ciao > Hannes > > >> Cheers, >> Martin >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, 11 July 2007 6:55 PM >> To: Winterbottom, James >> Cc: ECRIT >> Subject: Re: [Ecrit] LoST >> >> Hi James, >> >> Winterbottom, James wrote: >> >> >>> Hi Hannes, >>> >>> That makes perfect sense. >>> >>> The issue that I am most concerned about is the limitation in the >>> >>> >> shape >> >> >>> representation in the basic location profile. As it currently stands >>> > I > >>> cannot use standard GPS related shapes, my end-point has to interpret >>> location and put into a profile. This is incompatible with a large >>> number of solutions deployed today on which many deployments will be >>> based, at least initially. I strongly urge this WG to reconsider this >>> restriction and include circle, and ellipse at a minimum. >>> >>> >>> >> Some time back we also discussed this issue and the conclusion was the >> > > >> following: >> * Let us build a mechanism in there to have a mechanism to extend the >> location shapes. >> * Let us specify simple location shapes first. >> >> I know that there is this limitation with geodetic shapes and a >> > separate > >> location profile would be needed to address GPS and the cellular >> > world. > >> On the cellular aspect we also had a discussion with the 3GPP. There >> they are currently not using LoST at the end point since they are >> focusing on a different architecture (see >> >> > http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview- > >> 00). >> Even if they would use LoST at the end point they most likely want to >> hide the location information of the end point or to make use of >> information like cell ids (as recorded in the issue tracker a while >> > ago: > >> http://www.tschofenig.priv.at:8080/lost/issue16). >> >> Now, everything boils down to the question of GPS. Since GPS produces >> data in a format that is not PIDF-LO alike we can already assume that >> the end host has to understand the format. It can now encode it in >> different ways. In previous discussions a couple of us wanted to add a >> > > >> polygon as a location profile to the LoST document since it would also >> > > >> address the location hiding requirement. Since this issue came also up >> > > >> in the location hiding context we postpone this topic entirely. >> >> Hence, it is up to us to come up with a location profile that supports >> * a circle >> * an ellipse >> * a polygon, >> * a combination of the above >> * cell-ids >> if we think there is a need todo so. >> >> Ciao >> Hannes >> >> >> >>> Cheers >>> James >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Wednesday, 11 July 2007 4:58 PM >>>> To: Winterbottom, James >>>> Cc: ECRIT >>>> Subject: Re: [Ecrit] LoST >>>> >>>> Hi James, >>>> >>>> let me pick a concrete example: LoST server discovery. >>>> Currently, we have specified the usage of DHCP and DNS. Only the >>>> >>>> >>>> >>> former >>> >>> >>> >>>> allows to discover the LoST server in the access network. I am, >>>> >>>> >>>> >>> however, >>> >>> >>> >>>> aware of the work on HELD discovery, see >>>> >>>> > http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery- > >>>> 01.txt, >>>> that aims to discover a HELD server in the access network using DNS >>>> mechanisms. >>>> >>>> Now, even though the current LoST draft does not describe how to >>>> discover a LoST server using DNS in the access network that can be >>>> extended later when the above document is generalized (which I think >>>> would be a good idea). >>>> >>>> Does that make sense to you? >>>> >>>> Ciao >>>> Hannes >>>> >>>> Winterbottom, James wrote: >>>> >>>> >>>> >>>>> Hi Hannes, >>>>> >>>>> What exactly do you mean by postponed? >>>>> >>>>> Cheers >>>>> James >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Wednesday, 11 July 2007 5:58 AM >>>>>> To: ECRIT >>>>>> Subject: [Ecrit] LoST >>>>>> >>>>>> Hi all, >>>>>> >>>>>> during the WGLC we have received a number of comments. Then, we >>>>>> >>>>>> >>>>>> >>>>>> >>>>> delayed >>>>> >>>>> >>>>> >>>>> >>>>>> the completion of the work because of the location hiding >>>>>> >>>>>> >>>>>> >>> discussions. >>> >>> >>> >>>>>> Now, you can find the latest version of the document at: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los > >> >> >>> >>> >>> >>>>> t- >>>>> >>>>> >>>>> >>>>> >>>>>> 06.txt >>>>>> >>>>>> We have also updated the DHCP-based LoST discovery draft (based on >>>>>> >>>>>> >>>>>> >>> the >>> >>> >>> >>>>>> comments we received from the DHC working group). The document can >>>>>> >>>>>> >>>>>> >>> be >>> >>> >>> >>>>>> found here: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft- > >> >> >>> >>> >>> >>>>>> ietf-ecrit-dhc-lost-discovery-02.txt >>>>>> >>>>>> Now, here is the unfortunate news: It seems that we did not submit >>>>>> >>>>>> >>>>>> >>> the >>> >>> >>> >>>>>> LoST draft :-( >>>>>> Everyone was assuming that someone else is going to submit it. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> PS: James has recently sent a number of comments. Some of them got >>>>>> reflected in the document (namely the editorial onces). Others got >>>>>> intentionally postponed since we discussed them already in the >>>>>> >>>>>> >>>>>> >>> past. >>> >>> >>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ > >> >> >>> >>> >>> >>>> ------------------------ >>>> >>>> >>>> >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> >>>>> >>>>> >>>>> > ------------------------------------------------------------------------ > >> >> >>> >>> >>> >>>> ------------------------ >>>> >>>> >>>> >>>>> [mf2] >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >> >>> [mf2] >>> >>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> >> > ------------------------------------------------------------------------ > ------------------------ > >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> >> > ------------------------------------------------------------------------ > ------------------------ > >> [mf2] >> >> >> > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 05:59:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YyR-0005es-Ji; Wed, 11 Jul 2007 05:59:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8YyR-0005cN-2M for ecrit@ietf.org; Wed, 11 Jul 2007 05:59:07 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8YyQ-0003eX-Py for ecrit@ietf.org; Wed, 11 Jul 2007 05:59:06 -0400 Received: (qmail invoked by alias); 11 Jul 2007 09:58:41 -0000 Received: from p54987C44.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.68] by mail.gmx.net (mp026) with SMTP; 11 Jul 2007 11:58:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/i/QQbpLTiJfRxZpWT/jpDvzVksZKvwHbSeLG9Tt 2s8zfCDJBTvGEe Message-ID: <4694A9C8.9030306@gmx.net> Date: Wed, 11 Jul 2007 11:58:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] ECRIT WG Status Update (July 2007) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, a new WG status update is available: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EcritStatusUpdate Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 06:07:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Z6y-0006YT-52; Wed, 11 Jul 2007 06:07:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8Z6w-0006PK-Ph for ecrit@ietf.org; Wed, 11 Jul 2007 06:07:54 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8Z6w-0003ri-49 for ecrit@ietf.org; Wed, 11 Jul 2007 06:07:54 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_05_15_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 05:15:33 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 05:07:21 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 05:06:40 -0500 Message-ID: In-Reply-To: <4694A8DE.7010202@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDoYXk8D3yBsJFToeYacyyB68McQAANkkw References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A3AE.2090506@gmx.net> <4694A8DE.7010202@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 10:07:21.0151 (UTC) FILETIME=[45349CF0:01C7C3A3] X-Spam-Score: 1.8 (+) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi again,=0D=0A=0D=0ACertainly - let the group decide... just casting my vo= te/opinion.=0D=0A=0D=0AI don't know why it matters how many GPS devices use= SUPL... I'm just=0D=0Asaying that a LIS will return a geo-shape for whatev= er reason. It may=0D=0Anot even use GPS; it might be serving a WiMAX access= and be using signal=0D=0Atiming and base station location to determine the= location/shape. The=0D=0Adevice doesn't know or care. The point is that if= the LIS is using the=0D=0APIDF-LO profile requirements to select a shape t= o provide, the device=0D=0Amight end up with one that the LoST server doesn= 't support unless LoST=0D=0Ais specified as also supporting at least these = shapes.=0D=0A=0D=0AIf the question was just btw - I'd have to say that most= GPS devices=0D=0Adon't use SUPL... I think most GPS devices are autonomous= at this stage.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Mes= sage-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] =0D= =0ASent: Wednesday, 11 July 2007 7:55 PM=0D=0ATo: Dawson, Martin=0D=0ACc: W= interbottom, James; ECRIT=0D=0ASubject: Re: [Ecrit] LoST=0D=0A=0D=0AHi Mart= in,=0D=0A=0D=0ADawson, Martin wrote:=0D=0A> Thanks Hannes,=0D=0A>=0D=0A> Ye= s, I'm suggesting that since the profile spec is about to go RFC,=0D=0Athat=0D= =0A> the LoST spec might just as well reference it so we have a consistent=0D= =0A> ecology of specs. I think that having a subsequent spec make the=0D=0A= profile=0D=0A> mandatory would only be an issue if it came after LoST was=0D= =0Aimplemented.=0D=0A> On the other hand, if we assume it will happen befor= e LoST is=0D=0A> implemented, then why not just include the requirement now= =2E=0D=0A> =20=0D=0AI would like to let the group decide.=0D=0A=0D=0A> Wit= h respect to GPS - a LIS (LCS, whatever) could utilize any suitable=0D=0A> = protocol, including SUPL, to do GPS interactions with the client - it=0D=0A= > still casts the result as a PIDF-LO in the response. I'm not really=0D=0A= > thinking of the situation where the device does a GPS fix or gets it=0D=0A= > from some other non-PIDF-LO source. In that case, I'd certainly agree=0D=0A= > that the device may as well transcode it into the basic form. I'm not=0D=0A= > really concerned about that situation.=0D=0A>=0D=0A> =20=0D=0AI know abo= ut this feature in SUPL.=0D=0AStill, do most GPS devices today use SUPL=3F=0D= =0A=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=0D= =0A> -----Original Message-----=0D=0A> From: Hannes Tschofenig [mailto:Hann= es.Tschofenig@gmx.net]=20=0D=0A> Sent: Wednesday, 11 July 2007 7:33 PM=0D=0A= > To: Dawson, Martin=0D=0A> Cc: Winterbottom, James; ECRIT=0D=0A> Subject: = Re: [Ecrit] LoST=0D=0A>=0D=0A> Hi Martin,=0D=0A>=0D=0A> Dawson, Martin wrot= e:=0D=0A> =20=0D=0A>> Hi Hannes,=0D=0A>>=0D=0A>> This seems a bit bogged d= own in the here and now... A LIS for almost=0D=0A>> =20=0D=0A> any=0D=0A= > =20=0D=0A>> access technology, with or without GPS, could produce a geo-= shape as=0D=0Aa=0D=0A>> consequence of the location-determination technique= it employs. What=0D=0A>> 3GPP may be thinking now doesn't seem particularl= y pertinent.=0D=0A>> =20=0D=0A>> =20=0D=0A> True. A LCS (this is the co= rrect terminology now) can indeed produce a=0D=0A=0D=0A> PIDF-LO with the G= eo-Shapes format.=0D=0A>=0D=0A> When you use a GPS receiver today (and prob= ably for a long time) then=0D=0Ait=0D=0A>=0D=0A> does not produce a format = in XML format since there is just no LCP=20=0D=0A> involved.=0D=0A>=0D=0A> = =20=0D=0A>> There's already a pdif-lo-profile draft ([sic] is the spelling= ever=0D=0A>> going to get corrected btw or is a title immutable=3F) that s= tates what=0D=0A>> shapes should be used and defines what the LIS clients c= an expect to=0D=0A>> receive.=0D=0A>> =20=0D=0A>> =20=0D=0A> We decided= not to change the file name. When the document gets=0D=0Apublished=0D=0A>=0D= =0A> as RFC then the filename does not matter anway.=0D=0A> Btw, we recogni= zed the wrong spelling with version -04 or so.=0D=0A>=0D=0A> =20=0D=0A>> W= hile I accept that a LoST implementor could add support for that=0D=0A>> pr= ofile, as long as it is optional to do so, the client cannot be=0D=0Asure=0D= =0A>> that anything other than a point will be supported.=0D=0A>> =20=0D= =0A> A new document can also say that the new location profile is mandatory=0D= =0A=0D=0A> to implement. Do you think that will be a problem=3F=0D=0A>=0D=0A= > =20=0D=0A>> This adds the dual=0D=0A>> issue of making the client alway= s convert to a point form and/or=0D=0A>> eliminating the prospect of LoST s= ervers being able to do more=0D=0A>> sophisticated routing based on weighte= d coverage by uncertainty.=0D=0A>>=0D=0A>> Rather than invite the compatibi= lity issue at a later date, wouldn't=0D=0A>> =20=0D=0A> it=0D=0A> =20=0D= =0A>> be more prudent just to add the requirement now=3F=0D=0A>> =20=0D=0A= >> =20=0D=0A> No doubt that we could add an additional location profile = right now.=0D=0A>=0D=0A> I am just repeating what we agreed earlier in the = working group on=0D=0Athis=20=0D=0A> particular issue. If the working group= now thinks that this is a=0D=0Aproblem=0D=0A>=0D=0A> then we should re-con= sider it. I just want to open-up previously=0D=0Aclosed=20=0D=0A> or postpo= ned issues too quickly.=0D=0A>=0D=0A>=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=0D=0A= > =20=0D=0A>> Cheers,=0D=0A>> Martin=0D=0A>>=0D=0A>> -----Original Message= -----=0D=0A>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] =0D= =0A>> Sent: Wednesday, 11 July 2007 6:55 PM=0D=0A>> To: Winterbottom, James=0D= =0A>> Cc: ECRIT=0D=0A>> Subject: Re: [Ecrit] LoST=0D=0A>>=0D=0A>> Hi James,=0D= =0A>>=0D=0A>> Winterbottom, James wrote:=0D=0A>> =20=0D=0A>> =20=0D=0A>= >> Hi Hannes,=0D=0A>>>=0D=0A>>> That makes perfect sense.=0D=0A>>>=0D=0A>>>= The issue that I am most concerned about is the limitation in the=0D=0A>>>= =20=0D=0A>>> =20=0D=0A>> shape=0D=0A>> =20=0D=0A>> =20=0D=0A>>= > representation in the basic location profile. As it currently stands=0D=0A= >>> =20=0D=0A> I=0D=0A> =20=0D=0A>>> cannot use standard GPS related = shapes, my end-point has to=0D=0Ainterpret=0D=0A>>> location and put into a= profile. This is incompatible with a large=0D=0A>>> number of solutions de= ployed today on which many deployments will be=0D=0A>>> based, at least ini= tially. I strongly urge this WG to reconsider=0D=0Athis=0D=0A>>> restrictio= n and include circle, and ellipse at a minimum.=0D=0A>>> =20=0D=0A>>> =0D= =0A>>> =20=0D=0A>> Some time back we also discussed this issue and the= conclusion was=0D=0Athe=0D=0A>> =20=0D=0A>=0D=0A> =20=0D=0A>> followin= g:=0D=0A>> * Let us build a mechanism in there to have a mechanism to exten= d the=0D=0A=0D=0A>> location shapes.=0D=0A>> * Let us specify simple locati= on shapes first.=0D=0A>>=0D=0A>> I know that there is this limitation with = geodetic shapes and a=0D=0A>> =20=0D=0A> separate=0D=0A> =20=0D=0A>> lo= cation profile would be needed to address GPS and the cellular=0D=0A>> =0D= =0A> world.=0D=0A> =20=0D=0A>> On the cellular aspect we also had a discus= sion with the 3GPP. There=20=0D=0A>> they are currently not using LoST at t= he end point since they are=20=0D=0A>> focusing on a different architecture= (see=20=0D=0A>>=0D=0A>> =20=0D=0A>=0D=0Ahttp://tools.ietf.org/html/draf= t-tschofenig-ecrit-architecture-overview-=0D=0A> =20=0D=0A>> 00).=20=0D=0A= >> Even if they would use LoST at the end point they most likely want to=0D= =0A=0D=0A>> hide the location information of the end point or to make use o= f=20=0D=0A>> information like cell ids (as recorded in the issue tracker a = while=0D=0A>> =20=0D=0A> ago:=0D=0A> =20=0D=0A>> http://www.tschofenig.= com:8080/lost/issue16).=0D=0A>>=0D=0A>> Now, everything boils down to the q= uestion of GPS. Since GPS produces=0D=0A=0D=0A>> data in a format that is n= ot PIDF-LO alike we can already assume that=0D=0A=0D=0A>> the end host has = to understand the format. It can now encode it in=20=0D=0A>> different ways= =2E In previous discussions a couple of us wanted to add=0D=0Aa=0D=0A>> = =20=0D=0A>=0D=0A> =20=0D=0A>> polygon as a location profile to the LoST do= cument since it would=0D=0Aalso=0D=0A>> =20=0D=0A>=0D=0A> =20=0D=0A>> a= ddress the location hiding requirement. Since this issue came also=0D=0Aup=0D= =0A>> =20=0D=0A>=0D=0A> =20=0D=0A>> in the location hiding context we p= ostpone this topic entirely.=0D=0A>>=0D=0A>> Hence, it is up to us to come = up with a location profile that=0D=0Asupports=0D=0A>> * a circle=0D=0A>> * = an ellipse=0D=0A>> * a polygon,=0D=0A>> * a combination of the above=0D=0A>= > * cell-ids=0D=0A>> if we think there is a need todo so.=0D=0A>>=0D=0A>> C= iao=0D=0A>> Hannes=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>>> Cheers=0D=0A= >>> James=0D=0A>>>=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>= > -----Original Message-----=0D=0A>>>> From: Hannes Tschofenig [mailto:Hann= es.Tschofenig@gmx.net]=0D=0A>>>> Sent: Wednesday, 11 July 2007 4:58 PM=0D=0A= >>>> To: Winterbottom, James=0D=0A>>>> Cc: ECRIT=0D=0A>>>> Subject: Re: [Ec= rit] LoST=0D=0A>>>>=0D=0A>>>> Hi James,=0D=0A>>>>=0D=0A>>>> let me pick a c= oncrete example: LoST server discovery.=0D=0A>>>> Currently, we have specif= ied the usage of DHCP and DNS. Only the=0D=0A>>>> =20=0D=0A>>>> =0D= =0A>>>> =20=0D=0A>>> former=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> = =20=0D=0A>>>> allows to discover the LoST server in the access network.= I am,=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>> ho= wever,=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> aware of t= he work on HELD discovery, see=0D=0A>>>>=0D=0A>>>> =20=0D=0A> http:/= /tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery-=0D=0A> =0D= =0A>>>> 01.txt,=0D=0A>>>> that aims to discover a HELD server in the access= network using DNS=0D=0A>>>> mechanisms.=0D=0A>>>>=0D=0A>>>> Now, even thou= gh the current LoST draft does not describe how to=0D=0A>>>> discover a LoS= T server using DNS in the access network that can be=0D=0A>>>> extended lat= er when the above document is generalized (which I=0D=0Athink=0D=0A>>>> wou= ld be a good idea).=0D=0A>>>>=0D=0A>>>> Does that make sense to you=3F=0D=0A= >>>>=0D=0A>>>> Ciao=0D=0A>>>> Hannes=0D=0A>>>>=0D=0A>>>> Winterbottom, Jame= s wrote:=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>= > Hi Hannes,=0D=0A>>>>>=0D=0A>>>>> What exactly do you mean by postponed=3F=0D= =0A>>>>>=0D=0A>>>>> Cheers=0D=0A>>>>> James=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>= >=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>= > =20=0D=0A>>>>>> -----Original Message-----=0D=0A>>>>>> From: Han= nes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>>>>>> Sent: Wednesd= ay, 11 July 2007 5:58 AM=0D=0A>>>>>> To: ECRIT=0D=0A>>>>>> Subject: [Ecrit]= LoST=0D=0A>>>>>>=0D=0A>>>>>> Hi all,=0D=0A>>>>>>=0D=0A>>>>>> during the WG= LC we have received a number of comments. Then, we=0D=0A>>>>>>=0D=0A>>>>>> = =20=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>> d= elayed=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> = =20=0D=0A>>>>>> the completion of the work because of the location hid= ing=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>> discussions.=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>>>>>> Now, you can find the latest version of the document at:=0D=0A>>>= >>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>>= =20=0D=0A>=0D=0Ahttp://www.tschofenig.priv.at/svn/draft-ietf-ecrit-= lost/draft-ietf-ecrit-los=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> = =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>>> t-=0D=0A>>>>>=0D=0A>>>>> = =20=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>>> 06.txt=0D= =0A>>>>>>=0D=0A>>>>>> We have also updated the DHCP-based LoST discovery dr= aft (based=0D=0Aon=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>= >>> =20=0D=0A>>> the=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> = =20=0D=0A>>>>>> comments we received from the DHC working group). The docu= ment=0D=0Acan=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>> be=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>>>>>> found here:=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>= >>>>> =20=0D=0A>>>>>> =20=0D=0A>=0D=0Ahttp://www.tschof= enig.com/svn/draft-tschofenig-dhc-lost-discovery/draft-=0D=0A> =20=0D=0A>>= =20=0D=0A>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>= >>>>> ietf-ecrit-dhc-lost-discovery-02.txt=0D=0A>>>>>>=0D=0A>>>>>> Now, her= e is the unfortunate news: It seems that we did not=0D=0Asubmit=0D=0A>>>>>>= =20=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>> th= e=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>>>> LoST draft :-= (=0D=0A>>>>>> Everyone was assuming that someone else is going to submit it= =2E=0D=0A>>>>>>=0D=0A>>>>>> Ciao=0D=0A>>>>>> Hannes=0D=0A>>>>>>=0D=0A>>>>>>= PS: James has recently sent a number of comments. Some of them=0D=0Agot=0D= =0A>>>>>> reflected in the document (namely the editorial onces). Others=0D= =0Agot=0D=0A>>>>>> intentionally postponed since we discussed them already = in the=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>> past.=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A= >>>>>> _______________________________________________=0D=0A>>>>>> Ecrit ma= iling list=0D=0A>>>>>> Ecrit@ietf.org=0D=0A>>>>>> https://www1.ietf.org/mai= lman/listinfo/ecrit=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> =20=0D= =0A>>>>> =20=0D=0A>=0D=0A-----------------------------------------= -------------------------------=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A= >>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> ----------------------= --=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>> This= message is for the designated recipient only and may=0D=0A>>>>> contain pr= ivileged, proprietary, or otherwise private information.=0D=0A>>>>> If you = have received it in error, please notify the sender=0D=0A>>>>> immediately = and delete the original. Any unauthorized use of=0D=0A>>>>> this email is = prohibited.=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>>= =20=0D=0A>=0D=0A-------------------------------------------------= -----------------------=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> =0D= =0A>>> =20=0D=0A>>> =20=0D=0A>>>> ------------------------=0D=0A>>>= > =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>> [mf2]=0D=0A>>>>= >=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> = =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>=0D=0A-------------------------= -----------------------------------------------=0D=0A> =20=0D=0A>> -------= -----------------=0D=0A>> =20=0D=0A>> =20=0D=0A>>> This message is for = the designated recipient only and may=0D=0A>>> contain privileged, propriet= ary, or otherwise private information. =20=0D=0A>>> If you have received it= in error, please notify the sender=0D=0A>>> immediately and delete the ori= ginal. Any unauthorized use of=0D=0A>>> this email is prohibited.=0D=0A>>>=0D= =0A>>> =20=0D=0A>>> =20=0D=0A>=0D=0A-------------------------------= -----------------------------------------=0D=0A> =20=0D=0A>> -------------= -----------=0D=0A>> =20=0D=0A>> =20=0D=0A>>> [mf2]=0D=0A>>>=0D=0A>>> =0D= =0A>>> =20=0D=0A>>> =20=0D=0A>> ___________________________________= ____________=0D=0A>> Ecrit mailing list=0D=0A>> Ecrit@ietf.org=0D=0A>> http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>>=0D=0A>>=0D=0A>> =20=0D=0A= >=0D=0A--------------------------------------------------------------------= ----=0D=0A> ------------------------=0D=0A> =20=0D=0A>> This message is fo= r the designated recipient only and may=0D=0A>> contain privileged, proprie= tary, or otherwise private information. =20=0D=0A>> If you have received it= in error, please notify the sender=0D=0A>> immediately and delete the orig= inal. Any unauthorized use of=0D=0A>> this email is prohibited.=0D=0A>>=0D= =0A>> =20=0D=0A>=0D=0A--------------------------------------------------= ----------------------=0D=0A> ------------------------=0D=0A> =20=0D=0A>> = [mf2]=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>=0D=0A>=0D=0A>=0D=0A-------= -----------------------------------------------------------------=0D=0A----= --------------------=0D=0A> This message is for the designated recipient on= ly and may=0D=0A> contain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0A> If you have received it in error, please notify the se= nder=0D=0A> immediately and delete the original. Any unauthorized use of=0D= =0A> this email is prohibited.=0D=0A>=0D=0A--------------------------------= ----------------------------------------=0D=0A------------------------=0D=0A= > [mf2]=0D=0A>=0D=0A> =20=0D=0A=0D=0A=0D=0A-------------------------------= -----------------------------------------------------------------=0D=0AThis= message is for the designated recipient only and may=0D=0Acontain privileg= ed, proprietary, or otherwise private information. =20=0D=0AIf you have rec= eived it in error, please notify the sender=0D=0Aimmediately and delete the= original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A---= ---------------------------------------------------------------------------= ------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 06:59:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZuR-0001FN-U7; Wed, 11 Jul 2007 06:59:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZuQ-00019n-Pc for ecrit@ietf.org; Wed, 11 Jul 2007 06:59:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8ZuP-0004wU-N6 for ecrit@ietf.org; Wed, 11 Jul 2007 06:59:02 -0400 Received: (qmail invoked by alias); 11 Jul 2007 10:58:54 -0000 Received: from p54987C44.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.124.68] by mail.gmx.net (mp045) with SMTP; 11 Jul 2007 12:58:54 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19ycBhXJftylLd7oeQv5hCOBXfx10JAHF+n89ZOLS 6RPNKTZtATXgDB Message-ID: <4694B7EC.3010003@gmx.net> Date: Wed, 11 Jul 2007 12:58:52 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Ecrit] LoST References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A3AE.2090506@gmx.net> <4694A8DE.7010202@gmx.net> 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: 20c6ed26ee4f226a67d90641b17dfc32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, the question of the shape support is a question of deployment environments. For (most) WLANs / DSL / PacketCable environments civic location is probably the best choice. There are certainly some WLANs (moving train, bus, plane, ship, etc.) where civic location information does not make a lot of sense but there a lot depends on the way how the WLAN is connected to another network. For Wimax environment it depends on whether you talk about the work in the Wimax Forum or about the deployment of IEEE 802.16/802.16e networks in general. For the Wimax Forum no decision has been made with regard to the usage of specific protocols, as far as I know. For IEEE 802.16 again civic location is g good choice since it is essentially a replacement for DSL access. With IEEE 802.16e I could imagine that location hiding is again an important property for them. For 3GPP / 3GPP we are talking about an environment where location hiding is probably most appropriate (when it comes to the information that is made available to the end host). That's what we learned in previous discussions. For GPS usage at the end host only you are certainly right that circles & ellipse is a good choice. The big question is here: * is it a big issue to translate them to a point * does it introduce big error rates Please also note that we are talking about emergency call routing in the context of LoST and not about dispatch. To approximate a circle with a radius of 3 meters with a point might not be a big problem. Does this classification make sense to you? This raises a related question: What location shapes would you introduce to LoST now that really require to be there (and where it cannot wait a little longer)? Ciao Hannes Dawson, Martin wrote: > Hi again, > > Certainly - let the group decide... just casting my vote/opinion. > > I don't know why it matters how many GPS devices use SUPL... I'm just > saying that a LIS will return a geo-shape for whatever reason. It may > not even use GPS; it might be serving a WiMAX access and be using signal > timing and base station location to determine the location/shape. The > device doesn't know or care. The point is that if the LIS is using the > PIDF-LO profile requirements to select a shape to provide, the device > might end up with one that the LoST server doesn't support unless LoST > is specified as also supporting at least these shapes. > > If the question was just btw - I'd have to say that most GPS devices > don't use SUPL... I think most GPS devices are autonomous at this stage. > > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, 11 July 2007 7:55 PM > To: Dawson, Martin > Cc: Winterbottom, James; ECRIT > Subject: Re: [Ecrit] LoST > > Hi Martin, > > Dawson, Martin wrote: > >> Thanks Hannes, >> >> Yes, I'm suggesting that since the profile spec is about to go RFC, >> > that > >> the LoST spec might just as well reference it so we have a consistent >> ecology of specs. I think that having a subsequent spec make the >> > profile > >> mandatory would only be an issue if it came after LoST was >> > implemented. > >> On the other hand, if we assume it will happen before LoST is >> implemented, then why not just include the requirement now. >> >> > I would like to let the group decide. > > >> With respect to GPS - a LIS (LCS, whatever) could utilize any suitable >> protocol, including SUPL, to do GPS interactions with the client - it >> still casts the result as a PIDF-LO in the response. I'm not really >> thinking of the situation where the device does a GPS fix or gets it >> from some other non-PIDF-LO source. In that case, I'd certainly agree >> that the device may as well transcode it into the basic form. I'm not >> really concerned about that situation. >> >> >> > I know about this feature in SUPL. > Still, do most GPS devices today use SUPL? > > > Ciao > Hannes > > >> Cheers, >> Martin >> >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, 11 July 2007 7:33 PM >> To: Dawson, Martin >> Cc: Winterbottom, James; ECRIT >> Subject: Re: [Ecrit] LoST >> >> Hi Martin, >> >> Dawson, Martin wrote: >> >> >>> Hi Hannes, >>> >>> This seems a bit bogged down in the here and now... A LIS for almost >>> >>> >> any >> >> >>> access technology, with or without GPS, could produce a geo-shape as >>> > a > >>> consequence of the location-determination technique it employs. What >>> 3GPP may be thinking now doesn't seem particularly pertinent. >>> >>> >>> >> True. A LCS (this is the correct terminology now) can indeed produce a >> > > >> PIDF-LO with the Geo-Shapes format. >> >> When you use a GPS receiver today (and probably for a long time) then >> > it > >> does not produce a format in XML format since there is just no LCP >> involved. >> >> >> >>> There's already a pdif-lo-profile draft ([sic] is the spelling ever >>> going to get corrected btw or is a title immutable?) that states what >>> shapes should be used and defines what the LIS clients can expect to >>> receive. >>> >>> >>> >> We decided not to change the file name. When the document gets >> > published > >> as RFC then the filename does not matter anway. >> Btw, we recognized the wrong spelling with version -04 or so. >> >> >> >>> While I accept that a LoST implementor could add support for that >>> profile, as long as it is optional to do so, the client cannot be >>> > sure > >>> that anything other than a point will be supported. >>> >>> >> A new document can also say that the new location profile is mandatory >> > > >> to implement. Do you think that will be a problem? >> >> >> >>> This adds the dual >>> issue of making the client always convert to a point form and/or >>> eliminating the prospect of LoST servers being able to do more >>> sophisticated routing based on weighted coverage by uncertainty. >>> >>> Rather than invite the compatibility issue at a later date, wouldn't >>> >>> >> it >> >> >>> be more prudent just to add the requirement now? >>> >>> >>> >> No doubt that we could add an additional location profile right now. >> >> I am just repeating what we agreed earlier in the working group on >> > this > >> particular issue. If the working group now thinks that this is a >> > problem > >> then we should re-consider it. I just want to open-up previously >> > closed > >> or postponed issues too quickly. >> >> >> Ciao >> Hannes >> >> >> >>> Cheers, >>> Martin >>> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Wednesday, 11 July 2007 6:55 PM >>> To: Winterbottom, James >>> Cc: ECRIT >>> Subject: Re: [Ecrit] LoST >>> >>> Hi James, >>> >>> Winterbottom, James wrote: >>> >>> >>> >>>> Hi Hannes, >>>> >>>> That makes perfect sense. >>>> >>>> The issue that I am most concerned about is the limitation in the >>>> >>>> >>>> >>> shape >>> >>> >>> >>>> representation in the basic location profile. As it currently stands >>>> >>>> >> I >> >> >>>> cannot use standard GPS related shapes, my end-point has to >>>> > interpret > >>>> location and put into a profile. This is incompatible with a large >>>> number of solutions deployed today on which many deployments will be >>>> based, at least initially. I strongly urge this WG to reconsider >>>> > this > >>>> restriction and include circle, and ellipse at a minimum. >>>> >>>> >>>> >>>> >>> Some time back we also discussed this issue and the conclusion was >>> > the > >>> >>> >> >> >>> following: >>> * Let us build a mechanism in there to have a mechanism to extend the >>> > > >>> location shapes. >>> * Let us specify simple location shapes first. >>> >>> I know that there is this limitation with geodetic shapes and a >>> >>> >> separate >> >> >>> location profile would be needed to address GPS and the cellular >>> >>> >> world. >> >> >>> On the cellular aspect we also had a discussion with the 3GPP. There >>> they are currently not using LoST at the end point since they are >>> focusing on a different architecture (see >>> >>> >>> > http://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-overview- > >> >> >>> 00). >>> Even if they would use LoST at the end point they most likely want to >>> > > >>> hide the location information of the end point or to make use of >>> information like cell ids (as recorded in the issue tracker a while >>> >>> >> ago: >> >> >>> http://www.tschofenig.priv.at:8080/lost/issue16). >>> >>> Now, everything boils down to the question of GPS. Since GPS produces >>> > > >>> data in a format that is not PIDF-LO alike we can already assume that >>> > > >>> the end host has to understand the format. It can now encode it in >>> different ways. In previous discussions a couple of us wanted to add >>> > a > >>> >>> >> >> >>> polygon as a location profile to the LoST document since it would >>> > also > >>> >>> >> >> >>> address the location hiding requirement. Since this issue came also >>> > up > >>> >>> >> >> >>> in the location hiding context we postpone this topic entirely. >>> >>> Hence, it is up to us to come up with a location profile that >>> > supports > >>> * a circle >>> * an ellipse >>> * a polygon, >>> * a combination of the above >>> * cell-ids >>> if we think there is a need todo so. >>> >>> Ciao >>> Hannes >>> >>> >>> >>> >>>> Cheers >>>> James >>>> >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Wednesday, 11 July 2007 4:58 PM >>>>> To: Winterbottom, James >>>>> Cc: ECRIT >>>>> Subject: Re: [Ecrit] LoST >>>>> >>>>> Hi James, >>>>> >>>>> let me pick a concrete example: LoST server discovery. >>>>> Currently, we have specified the usage of DHCP and DNS. Only the >>>>> >>>>> >>>>> >>>>> >>>> former >>>> >>>> >>>> >>>> >>>>> allows to discover the LoST server in the access network. I am, >>>>> >>>>> >>>>> >>>>> >>>> however, >>>> >>>> >>>> >>>> >>>>> aware of the work on HELD discovery, see >>>>> >>>>> >>>>> >> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-lis-discovery- >> >> >>>>> 01.txt, >>>>> that aims to discover a HELD server in the access network using DNS >>>>> mechanisms. >>>>> >>>>> Now, even though the current LoST draft does not describe how to >>>>> discover a LoST server using DNS in the access network that can be >>>>> extended later when the above document is generalized (which I >>>>> > think > >>>>> would be a good idea). >>>>> >>>>> Does that make sense to you? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> Winterbottom, James wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Hi Hannes, >>>>>> >>>>>> What exactly do you mean by postponed? >>>>>> >>>>>> Cheers >>>>>> James >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Wednesday, 11 July 2007 5:58 AM >>>>>>> To: ECRIT >>>>>>> Subject: [Ecrit] LoST >>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> during the WGLC we have received a number of comments. Then, we >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> delayed >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> the completion of the work because of the location hiding >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> discussions. >>>> >>>> >>>> >>>> >>>>>>> Now, you can find the latest version of the document at: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los > >> >> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>>> t- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> 06.txt >>>>>>> >>>>>>> We have also updated the DHCP-based LoST discovery draft (based >>>>>>> > on > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> the >>>> >>>> >>>> >>>> >>>>>>> comments we received from the DHC working group). The document >>>>>>> > can > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> be >>>> >>>> >>>> >>>> >>>>>>> found here: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > http://www.tschofenig.priv.at/svn/draft-tschofenig-dhc-lost-discovery/draft- > >> >> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>>>> ietf-ecrit-dhc-lost-discovery-02.txt >>>>>>> >>>>>>> Now, here is the unfortunate news: It seems that we did not >>>>>>> > submit > >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> the >>>> >>>> >>>> >>>> >>>>>>> LoST draft :-( >>>>>>> Everyone was assuming that someone else is going to submit it. >>>>>>> >>>>>>> Ciao >>>>>>> Hannes >>>>>>> >>>>>>> PS: James has recently sent a number of comments. Some of them >>>>>>> > got > >>>>>>> reflected in the document (namely the editorial onces). Others >>>>>>> > got > >>>>>>> intentionally postponed since we discussed them already in the >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> past. >>>> >>>> >>>> >>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www1.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > ------------------------------------------------------------------------ > >> >> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> ------------------------ >>>>> >>>>> >>>>> >>>>> >>>>>> This message is for the designated recipient only and may >>>>>> contain privileged, proprietary, or otherwise private information. >>>>>> If you have received it in error, please notify the sender >>>>>> immediately and delete the original. Any unauthorized use of >>>>>> this email is prohibited. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > ------------------------------------------------------------------------ > >> >> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> ------------------------ >>>>> >>>>> >>>>> >>>>> >>>>>> [mf2] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> > ------------------------------------------------------------------------ > >> >> >>> ------------------------ >>> >>> >>> >>>> This message is for the designated recipient only and may >>>> contain privileged, proprietary, or otherwise private information. >>>> If you have received it in error, please notify the sender >>>> immediately and delete the original. Any unauthorized use of >>>> this email is prohibited. >>>> >>>> >>>> >>>> > ------------------------------------------------------------------------ > >> >> >>> ------------------------ >>> >>> >>> >>>> [mf2] >>>> >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> >>> >>> > ------------------------------------------------------------------------ > >> ------------------------ >> >> >>> [mf2] >>> >>> >>> >>> >> >> > ------------------------------------------------------------------------ > ------------------------ > >> This message is for the designated recipient only and may >> contain privileged, proprietary, or otherwise private information. >> If you have received it in error, please notify the sender >> immediately and delete the original. Any unauthorized use of >> this email is prohibited. >> >> > ------------------------------------------------------------------------ > ------------------------ > >> [mf2] >> >> >> > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 08:54:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8biL-0006wp-Eh; Wed, 11 Jul 2007 08:54:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8biJ-0006wX-V2 for ecrit@ietf.org; Wed, 11 Jul 2007 08:54:40 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8biA-0007RC-OT for ecrit@ietf.org; Wed, 11 Jul 2007 08:54:39 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6BCroK9028055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Jul 2007 08:53:54 -0400 (EDT) In-Reply-To: <4694B7EC.3010003@gmx.net> References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A3AE.2090506@gmx.net> <4694A8DE.7010202@gmx.net> <4694B7EC.3010003@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5289F402-146E-4AE1-9EA7-988B4F6D9A52@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Date: Wed, 11 Jul 2007 08:53:49 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Three quick comments: As far as I know, GPS devices produce a point plus (small) uncertainty, e.g., in the common NMEA output format (http://vancouver- webpages.com/peter/nmeafaq.txt). The uncertainty is so small and tends to fluctuate so much that including it in location mapping is pretty pointless, and it's probably of dubious value even for dispatch. (When I went geocaching recently with my kids, uncertainty on a modern SiRF-based device was around 18 - 25', under dense tree cover.) That said, I think the complexity of including circles, arc band and ellipse is minimal. In all cases, the description includes a center point, which the LoST machinery could easily use to do the actual lookup. Thus, the additional complexity is mainly parsing these XML structures, which strikes me as not a big deal. What gets complex is if a LoST resolver is forced to map shapes to multiple branches of the tree, what we have discussed in the past as the "forking" problem. For example, if a geo shape straddles the boundary between the US and Canada, you really don't want the LoST resolver gather results from both trees, decide how long it needs to wait for one or the other, and other issues. This requires significantly more protocol work, creates additional error conditions and increases implementation complexity. A third point relates more to HELD than LoST: It's probably a good idea to be able to request a specific location profile, in the same spirit as in LoST, so that if newer, complex shapes can be accommodated easily in the future. We can then decide whether to define a LoST-like profile for HELD that only includes the current geo shapes, without endangering interoperability. In summary: I'm not opposed to including the three additional shapes, as long as it is clear that the LoST server MAY use the center point for mapping. Henning On Jul 11, 2007, at 6:58 AM, Hannes Tschofenig wrote: > > For GPS usage at the end host only you are certainly right that > circles & ellipse is a good choice. The big question is here: > * is it a big issue to translate them to a point > * does it introduce big error rates > Please also note that we are talking about emergency call routing > in the context of LoST and not about dispatch. To approximate a > circle with a radius of 3 meters with a point might not be a big > problem. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 09:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cAj-0007l3-28; Wed, 11 Jul 2007 09:24:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cAh-0007kG-Ph for ecrit@ietf.org; Wed, 11 Jul 2007 09:23:59 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cAh-0000Fk-BO for ecrit@ietf.org; Wed, 11 Jul 2007 09:23:59 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6BDNStR013154 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 11 Jul 2007 09:23:29 -0400 (EDT) In-Reply-To: <46947F6E.1000805@gmx.net> References: <4693E4D4.1000905@gmx.net> <46947F6E.1000805@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST Date: Wed, 11 Jul 2007 09:23:28 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 11, 2007, at 2:57 AM, Hannes Tschofenig wrote: > > Now, even though the current LoST draft does not describe how to > discover a LoST server using DNS in the access network that can be > extended later when the above document is generalized (which I > think would be a good idea). This isn't quite true; this is currently defined in Section 4 of LoST-06. The sentence Clients learn the LoST server's host name by means beyond the scope of this specification, such as SIP configuration and DHCP. should probably be made a tad more precise. Copying from draft-ietf- sipping-config-framework: --- begin --- LoST servers may be operated by the local access network, a voice service provider and other parties. If not manually pre-configured, a LoST client discovers one or more LoST resolvers first in the local access network, then those provided by the VSP and then elsewhere. It attempts to access the resolvers in that order. Clients that support DHCP MUST attempt to obtain the local IP network domain during the DHCP process described in [RFC2132] and [RFC4704]. Clients using SIP first consult their local SIP configuration information. If that does not contain LoST resolver information, they extract the LoST host name as the 'hostname' portion of the address- of-record (AoR). If only a numeric IP address is provided in the AoR, the client MAY attempt to perform a reverse DNS lookup on that address. Other discovery mechanisms may be defined in the future. --- end --- I think it would be a good idea to add this paragraph or two at the end of Section 4, as it allows for interoperable implementations. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 10:05:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cpF-0004F3-CL; Wed, 11 Jul 2007 10:05:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8cpD-0004DB-Ld for ecrit@ietf.org; Wed, 11 Jul 2007 10:05:51 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8cp8-00017F-Rp for ecrit@ietf.org; Wed, 11 Jul 2007 10:05:51 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_09_13_58 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 09:13:58 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 09:05:45 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 09:04:47 -0500 Message-ID: In-Reply-To: <4694B7EC.3010003@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDqnwZXwJdwpbkRmajUANkQaunPAAGSFUg References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A3AE.2090506@gmx.net> <4694A8DE.7010202@gmx.net> <4694B7EC.3010003@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 14:05:45.0969 (UTC) FILETIME=[938A9E10:01C7C3C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AThe pidf-lo-profile spec, as far as I know, is inclus= ive of the shapes=0D=0Adefined for 3G. This makes it a comprehensive set as= far existing LCS=0D=0Ainfrastructure is concerned (I'm using LCS in its ex= isting 3GPP context=0D=0Ahere - not as a simile for LIS). This makes it the= safest set to require=0D=0ALoST support for. I really don't think there's = any point in trying to=0D=0Aanalyse the current, or anticipate the future, = status-quo other than=0D=0Athat. Technology is emerging all over the place.=0D= =0A=0D=0AI agree with Henning; it's not necessary to require the LoST serve= r to=0D=0Aactually utilize the shapes - that's an internal procedure. It's = only=0D=0Athe external semantics that I'm concerned about as far as compati= bility=0D=0Aissues go.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Origi= nal Message-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx= =2Enet]=20=0D=0ASent: Wednesday, 11 July 2007 8:59 PM=0D=0ATo: Dawson, Mart= in=0D=0ACc: Winterbottom, James; ECRIT=0D=0ASubject: Re: [Ecrit] LoST=0D=0A=0D= =0AHi Martin,=0D=0A=0D=0Athe question of the shape support is a question of= deployment=0D=0Aenvironments.=0D=0A=0D=0AFor (most) WLANs / DSL / PacketCa= ble environments civic location is=20=0D=0Aprobably the best choice. There = are certainly some WLANs (moving train,=20=0D=0Abus, plane, ship, etc.) whe= re civic location information does not make a=0D=0A=0D=0Alot of sense but t= here a lot depends on the way how the WLAN is=20=0D=0Aconnected to another = network.=0D=0A=0D=0AFor Wimax environment it depends on whether you talk ab= out the work in=20=0D=0Athe Wimax Forum or about the deployment of IEEE 802= =2E16/802.16e networks=20=0D=0Ain general. For the Wimax Forum no decision = has been made with regard to=0D=0A=0D=0Athe usage of specific protocols, as= far as I know. For IEEE 802.16 again=0D=0A=0D=0Acivic location is g good c= hoice since it is essentially a replacement=20=0D=0Afor DSL access. With IE= EE 802.16e I could imagine that location hiding=20=0D=0Ais again an importa= nt property for them.=0D=0A=0D=0AFor 3GPP / 3GPP we are talking about an en= vironment where location=20=0D=0Ahiding is probably most appropriate (when = it comes to the information=20=0D=0Athat is made available to the end host)= =2E That's what we learned in=20=0D=0Aprevious discussions.=0D=0A=0D=0AFor = GPS usage at the end host only you are certainly right that circles=20=0D=0A= & ellipse is a good choice. The big question is here:=0D=0A* is it a big is= sue to translate them to a point=0D=0A* does it introduce big error rates=0D= =0APlease also note that we are talking about emergency call routing in the=0D= =0A=0D=0Acontext of LoST and not about dispatch. To approximate a circle wi= th a=20=0D=0Aradius of 3 meters with a point might not be a big problem.=0D= =0A=0D=0ADoes this classification make sense to you=3F=0D=0A=0D=0AThis rais= es a related question: What location shapes would you introduce=0D=0A=0D=0A= to LoST now that really require to be there (and where it cannot wait a=20=0D= =0Alittle longer)=3F=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D=0ADawson, Martin = wrote:=0D=0A> Hi again,=0D=0A>=0D=0A> Certainly - let the group decide... j= ust casting my vote/opinion.=0D=0A>=0D=0A> I don't know why it matters how = many GPS devices use SUPL... I'm just=0D=0A> saying that a LIS will return = a geo-shape for whatever reason. It may=0D=0A> not even use GPS; it might b= e serving a WiMAX access and be using=0D=0Asignal=0D=0A> timing and base st= ation location to determine the location/shape. The=0D=0A> device doesn't k= now or care. The point is that if the LIS is using the=0D=0A> PIDF-LO profi= le requirements to select a shape to provide, the device=0D=0A> might end u= p with one that the LoST server doesn't support unless LoST=0D=0A> is speci= fied as also supporting at least these shapes.=0D=0A>=0D=0A> If the questio= n was just btw - I'd have to say that most GPS devices=0D=0A> don't use SUP= L... I think most GPS devices are autonomous at this=0D=0Astage.=0D=0A>=0D=0A= > Cheers,=0D=0A> Martin=0D=0A>=0D=0A> -----Original Message-----=0D=0A> Fro= m: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0A> Sent: Wed= nesday, 11 July 2007 7:55 PM=0D=0A> To: Dawson, Martin=0D=0A> Cc: Winterbot= tom, James; ECRIT=0D=0A> Subject: Re: [Ecrit] LoST=0D=0A>=0D=0A> Hi Martin,=0D= =0A>=0D=0A> Dawson, Martin wrote:=0D=0A> =20=0D=0A>> Thanks Hannes,=0D=0A>= >=0D=0A>> Yes, I'm suggesting that since the profile spec is about to go RF= C,=0D=0A>> =20=0D=0A> that=0D=0A> =20=0D=0A>> the LoST spec might just = as well reference it so we have a consistent=0D=0A>> ecology of specs. I th= ink that having a subsequent spec make the=0D=0A>> =20=0D=0A> profile=0D= =0A> =20=0D=0A>> mandatory would only be an issue if it came after LoST wa= s=0D=0A>> =20=0D=0A> implemented.=0D=0A> =20=0D=0A>> On the other hand,= if we assume it will happen before LoST is=0D=0A>> implemented, then why n= ot just include the requirement now.=0D=0A>> =20=0D=0A>> =20=0D=0A> I w= ould like to let the group decide.=0D=0A>=0D=0A> =20=0D=0A>> With respect = to GPS - a LIS (LCS, whatever) could utilize any=0D=0Asuitable=0D=0A>> prot= ocol, including SUPL, to do GPS interactions with the client - it=0D=0A>> s= till casts the result as a PIDF-LO in the response. I'm not really=0D=0A>> = thinking of the situation where the device does a GPS fix or gets it=0D=0A>= > from some other non-PIDF-LO source. In that case, I'd certainly agree=0D=0A= >> that the device may as well transcode it into the basic form. I'm not=0D= =0A>> really concerned about that situation.=0D=0A>>=0D=0A>> =20=0D=0A>> = =20=0D=0A> I know about this feature in SUPL.=0D=0A> Still, do most GPS d= evices today use SUPL=3F=0D=0A>=0D=0A>=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=0D=0A= > =20=0D=0A>> Cheers,=0D=0A>> Martin=0D=0A>>=0D=0A>> -----Original Message= -----=0D=0A>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] =0D= =0A>> Sent: Wednesday, 11 July 2007 7:33 PM=0D=0A>> To: Dawson, Martin=0D=0A= >> Cc: Winterbottom, James; ECRIT=0D=0A>> Subject: Re: [Ecrit] LoST=0D=0A>>=0D= =0A>> Hi Martin,=0D=0A>>=0D=0A>> Dawson, Martin wrote:=0D=0A>> =20=0D=0A>>= =20=0D=0A>>> Hi Hannes,=0D=0A>>>=0D=0A>>> This seems a bit bogged down = in the here and now... A LIS for almost=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>> any=0D=0A>> =20=0D=0A>> =20=0D=0A>>> access technology, with or w= ithout GPS, could produce a geo-shape as=0D=0A>>> =20=0D=0A> a=0D=0A> = =20=0D=0A>>> consequence of the location-determination technique it employ= s. What=0D=0A>>> 3GPP may be thinking now doesn't seem particularly pertine= nt.=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>> True. A LCS (th= is is the correct terminology now) can indeed produce=0D=0Aa=0D=0A>> =0D= =0A>=0D=0A> =20=0D=0A>> PIDF-LO with the Geo-Shapes format.=0D=0A>>=0D=0A>= > When you use a GPS receiver today (and probably for a long time) then=0D=0A= >> =20=0D=0A> it=0D=0A> =20=0D=0A>> does not produce a format in XML fo= rmat since there is just no LCP=20=0D=0A>> involved.=0D=0A>>=0D=0A>> =20=0D= =0A>> =20=0D=0A>>> There's already a pdif-lo-profile draft ([sic] is the= spelling ever=0D=0A>>> going to get corrected btw or is a title immutable=3F= ) that states=0D=0Awhat=0D=0A>>> shapes should be used and defines what the= LIS clients can expect to=0D=0A>>> receive.=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>>> =20=0D=0A>> We decided not to change the file name. When the do= cument gets=0D=0A>> =20=0D=0A> published=0D=0A> =20=0D=0A>> as RFC then= the filename does not matter anway.=0D=0A>> Btw, we recognized the wrong s= pelling with version -04 or so.=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>>= > While I accept that a LoST implementor could add support for that=0D=0A>>= > profile, as long as it is optional to do so, the client cannot be=0D=0A>>= > =20=0D=0A> sure=0D=0A> =20=0D=0A>>> that anything other than a poin= t will be supported.=0D=0A>>> =20=0D=0A>>> =20=0D=0A>> A new docume= nt can also say that the new location profile is=0D=0Amandatory=0D=0A>> = =20=0D=0A>=0D=0A> =20=0D=0A>> to implement. Do you think that will be a pr= oblem=3F=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>>> This adds the dual=0D= =0A>>> issue of making the client always convert to a point form and/or=0D=0A= >>> eliminating the prospect of LoST servers being able to do more=0D=0A>>>= sophisticated routing based on weighted coverage by uncertainty.=0D=0A>>>=0D= =0A>>> Rather than invite the compatibility issue at a later date, wouldn't=0D= =0A>>> =20=0D=0A>>> =20=0D=0A>> it=0D=0A>> =20=0D=0A>> =20=0D=0A= >>> be more prudent just to add the requirement now=3F=0D=0A>>> =20=0D=0A>= >> =20=0D=0A>>> =20=0D=0A>> No doubt that we could add an additiona= l location profile right now.=0D=0A>>=0D=0A>> I am just repeating what we a= greed earlier in the working group on=0D=0A>> =20=0D=0A> this=20=0D=0A> = =20=0D=0A>> particular issue. If the working group now thinks that this is= a=0D=0A>> =20=0D=0A> problem=0D=0A> =20=0D=0A>> then we should re-cons= ider it. I just want to open-up previously=0D=0A>> =20=0D=0A> closed=20=0D= =0A> =20=0D=0A>> or postponed issues too quickly.=0D=0A>>=0D=0A>>=0D=0A>> = Ciao=0D=0A>> Hannes=0D=0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>>> Cheers,=0D= =0A>>> Martin=0D=0A>>>=0D=0A>>> -----Original Message-----=0D=0A>>> From: H= annes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20=0D=0A>>> Sent: Wedne= sday, 11 July 2007 6:55 PM=0D=0A>>> To: Winterbottom, James=0D=0A>>> Cc: EC= RIT=0D=0A>>> Subject: Re: [Ecrit] LoST=0D=0A>>>=0D=0A>>> Hi James,=0D=0A>>>=0D= =0A>>> Winterbottom, James wrote:=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> = =20=0D=0A>>>> Hi Hannes,=0D=0A>>>>=0D=0A>>>> That makes perfect sense.=0D= =0A>>>>=0D=0A>>>> The issue that I am most concerned about is the limitatio= n in the=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>> = shape=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> representat= ion in the basic location profile. As it currently=0D=0Astands=0D=0A>>>> = =20=0D=0A>>>> =20=0D=0A>> I=0D=0A>> =20=0D=0A>> =20=0D=0A>>>>= cannot use standard GPS related shapes, my end-point has to=0D=0A>>>> = =20=0D=0A> interpret=0D=0A> =20=0D=0A>>>> location and put into a profi= le. This is incompatible with a large=0D=0A>>>> number of solutions deploye= d today on which many deployments will=0D=0Abe=0D=0A>>>> based, at least in= itially. I strongly urge this WG to reconsider=0D=0A>>>> =20=0D=0A> = this=0D=0A> =20=0D=0A>>>> restriction and include circle, and ellipse at a= minimum.=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> = =20=0D=0A>>> Some time back we also discussed this issue and the conclus= ion was=0D=0A>>> =20=0D=0A> the=0D=0A> =20=0D=0A>>> =20=0D=0A>>> = =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> following:=0D=0A>>> * Let us b= uild a mechanism in there to have a mechanism to extend=0D=0Athe=0D=0A>>> = =20=0D=0A>=0D=0A> =20=0D=0A>>> location shapes.=0D=0A>>> * Let us spec= ify simple location shapes first.=0D=0A>>>=0D=0A>>> I know that there is th= is limitation with geodetic shapes and a=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>> separate=0D=0A>> =20=0D=0A>> =20=0D=0A>>> location profile would = be needed to address GPS and the cellular=0D=0A>>> =20=0D=0A>>> =0D= =0A>> world.=0D=0A>> =20=0D=0A>> =20=0D=0A>>> On the cellular aspect we= also had a discussion with the 3GPP. There=0D=0A=0D=0A>>> they are current= ly not using LoST at the end point since they are=20=0D=0A>>> focusing on a= different architecture (see=20=0D=0A>>>=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>=0D=0Ahttp://tools.ietf.org/html/draft-tschofenig-ecrit-architecture-ov= erview-=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> 00).=20=0D=0A>>> E= ven if they would use LoST at the end point they most likely want=0D=0Ato=0D= =0A>>> =20=0D=0A>=0D=0A> =20=0D=0A>>> hide the location information o= f the end point or to make use of=20=0D=0A>>> information like cell ids (as= recorded in the issue tracker a while=0D=0A>>> =20=0D=0A>>> =20=0D= =0A>> ago:=0D=0A>> =20=0D=0A>> =20=0D=0A>>> http://www.tschofenig.priv.at:8= 080/lost/issue16).=0D=0A>>>=0D=0A>>> Now, everything boils down to the ques= tion of GPS. Since GPS=0D=0Aproduces=0D=0A>>> =20=0D=0A>=0D=0A> =20=0D= =0A>>> data in a format that is not PIDF-LO alike we can already assume=0D=0A= that=0D=0A>>> =20=0D=0A>=0D=0A> =20=0D=0A>>> the end host has to unde= rstand the format. It can now encode it in=20=0D=0A>>> different ways. In p= revious discussions a couple of us wanted to add=0D=0A>>> =20=0D=0A> a=0D= =0A> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>> =20=0D=0A>> =20=0D=0A= >>> polygon as a location profile to the LoST document since it would=0D=0A= >>> =20=0D=0A> also=0D=0A> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A= >> =20=0D=0A>> =20=0D=0A>>> address the location hiding requirement. Si= nce this issue came also=0D=0A>>> =20=0D=0A> up=0D=0A> =20=0D=0A>>> = =20=0D=0A>>> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> in the locatio= n hiding context we postpone this topic entirely.=0D=0A>>>=0D=0A>>> Hence, = it is up to us to come up with a location profile that=0D=0A>>> =20=0D= =0A> supports=0D=0A> =20=0D=0A>>> * a circle=0D=0A>>> * an ellipse=0D=0A>>= > * a polygon,=0D=0A>>> * a combination of the above=0D=0A>>> * cell-ids=0D= =0A>>> if we think there is a need todo so.=0D=0A>>>=0D=0A>>> Ciao=0D=0A>>>= Hannes=0D=0A>>>=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> = Cheers=0D=0A>>>> James=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> = =20=0D=0A>>>> =20=0D=0A>>>>> -----Original Message-----=0D=0A>>= >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>>>>> S= ent: Wednesday, 11 July 2007 4:58 PM=0D=0A>>>>> To: Winterbottom, James=0D=0A= >>>>> Cc: ECRIT=0D=0A>>>>> Subject: Re: [Ecrit] LoST=0D=0A>>>>>=0D=0A>>>>> = Hi James,=0D=0A>>>>>=0D=0A>>>>> let me pick a concrete example: LoST server= discovery.=0D=0A>>>>> Currently, we have specified the usage of DHCP and D= NS. Only the=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> =20=0D= =0A>>>>> =20=0D=0A>>>> former=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A= >>>> =20=0D=0A>>>> =20=0D=0A>>>>> allows to discover the LoST s= erver in the access network. I am,=0D=0A>>>>> =20=0D=0A>>>>> =20=0D= =0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>> however,=0D=0A>>>> =0D= =0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>> aware of = the work on HELD discovery, see=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>>= =20=0D=0A>> http://tools.ietf.org/wg/geopriv/draft-thomson-geopri= v-lis-discovery-=0D=0A>> =20=0D=0A>> =20=0D=0A>>>>> 01.txt,=0D=0A>>>>> = that aims to discover a HELD server in the access network using=0D=0ADNS=0D= =0A>>>>> mechanisms.=0D=0A>>>>>=0D=0A>>>>> Now, even though the current LoS= T draft does not describe how to=0D=0A>>>>> discover a LoST server using DN= S in the access network that can be=0D=0A>>>>> extended later when the abov= e document is generalized (which I=0D=0A>>>>> =20=0D=0A> think=0D=0A= > =20=0D=0A>>>>> would be a good idea).=0D=0A>>>>>=0D=0A>>>>> Does that ma= ke sense to you=3F=0D=0A>>>>>=0D=0A>>>>> Ciao=0D=0A>>>>> Hannes=0D=0A>>>>>=0D= =0A>>>>> Winterbottom, James wrote:=0D=0A>>>>> =20=0D=0A>>>>> =20=0D= =0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>>> Hi Hannes,=0D=0A>>>= >>>=0D=0A>>>>>> What exactly do you mean by postponed=3F=0D=0A>>>>>>=0D=0A>= >>>>> Cheers=0D=0A>>>>>> James=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>= >>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>>>>> =20=0D=0A>>>>>>> -----Original Message----= -=0D=0A>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D= =0A>>>>>>> Sent: Wednesday, 11 July 2007 5:58 AM=0D=0A>>>>>>> To: ECRIT=0D=0A= >>>>>>> Subject: [Ecrit] LoST=0D=0A>>>>>>>=0D=0A>>>>>>> Hi all,=0D=0A>>>>>>= >=0D=0A>>>>>>> during the WGLC we have received a number of comments. Then,= we=0D=0A>>>>>>>=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>= >>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>>> delayed=0D=0A= >>>>>>=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> =0D= =0A>>>>>> =20=0D=0A>>>>>>> the completion of the work because of= the location hiding=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A= >>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>> discussions.=0D= =0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A= >>>>>>> Now, you can find the latest version of the document at:=0D=0A>>>>>= >>=0D=0A>>>>>>>=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>= >>> =20=0D=0A>>>>>>> =20=0D=0A>=0D=0Ahttp://www.tsc= hofenig.com/svn/draft-ietf-ecrit-lost/draft-ietf-ecrit-los=0D=0A> =20=0D=0A= >> =20=0D=0A>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A= >>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>= >>> t-=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>>>>> =20=0D=0A>>>>>>> 06.txt=0D=0A>>>>>>>=0D= =0A>>>>>>> We have also updated the DHCP-based LoST discovery draft (based=0D= =0A>>>>>>> =20=0D=0A> on=0D=0A> =20=0D=0A>>>>>>> =20=0D= =0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> = =20=0D=0A>>>> the=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A= >>>> =20=0D=0A>>>>>>> comments we received from the DHC working grou= p). The document=0D=0A>>>>>>> =20=0D=0A> can=0D=0A> =20=0D=0A= >>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D= =0A>>>>>>> =20=0D=0A>>>> be=0D=0A>>>> =20=0D=0A>>>> =20=0D= =0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>>>> found here:=0D=0A>>>>>>>=0D= =0A>>>>>>>=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> = =20=0D=0A>>>>>>> =20=0D=0A>=0D=0Ahttp://www.tschofen= ig.com/svn/draft-tschofenig-dhc-lost-discovery/draft-=0D=0A> =20=0D=0A>> = =20=0D=0A>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>= > =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>>>= > ietf-ecrit-dhc-lost-discovery-02.txt=0D=0A>>>>>>>=0D=0A>>>>>>> Now, here = is the unfortunate news: It seems that we did not=0D=0A>>>>>>> = =20=0D=0A> submit=0D=0A> =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> = =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>> t= he=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D= =0A>>>>>>> LoST draft :-(=0D=0A>>>>>>> Everyone was assuming that someone e= lse is going to submit it.=0D=0A>>>>>>>=0D=0A>>>>>>> Ciao=0D=0A>>>>>>> Hann= es=0D=0A>>>>>>>=0D=0A>>>>>>> PS: James has recently sent a number of commen= ts. Some of them=0D=0A>>>>>>> =20=0D=0A> got=0D=0A> =20=0D=0A= >>>>>>> reflected in the document (namely the editorial onces). Others=0D=0A= >>>>>>> =20=0D=0A> got=0D=0A> =20=0D=0A>>>>>>> intentionally = postponed since we discussed them already in the=0D=0A>>>>>>> =20=0D= =0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> = =20=0D=0A>>>> past.=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D= =0A>>>> =20=0D=0A>>>>>>> ___________________________________________= ____=0D=0A>>>>>>> Ecrit mailing list=0D=0A>>>>>>> Ecrit@ietf.org=0D=0A>>>>>= >> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>>>>>>>=0D=0A>>>>>>> = =20=0D=0A>>>>>>> =20=0D=0A>>>>>>> =20=0D=0A>>>>>>= > =20=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> = =20=0D=0A>>>>>> =20=0D=0A>=0D=0A-----------------------= -------------------------------------------------=0D=0A> =20=0D=0A>> =20=0D= =0A>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> =0D= =0A>>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>>>> ---------= ---------------=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> =0D= =0A>>>>> =20=0D=0A>>>>>> This message is for the designated recipi= ent only and may=0D=0A>>>>>> contain privileged, proprietary, or otherwise = private=0D=0Ainformation.=0D=0A>>>>>> If you have received it in error, ple= ase notify the sender=0D=0A>>>>>> immediately and delete the original. Any= unauthorized use of=0D=0A>>>>>> this email is prohibited.=0D=0A>>>>>>=0D=0A= >>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>>>>= =20=0D=0A>=0D=0A-----------------------------------------------= -------------------------=0D=0A> =20=0D=0A>> =20=0D=0A>> =20=0D=0A>>> = =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A= >>>> =20=0D=0A>>>> =20=0D=0A>>>>> ------------------------=0D=0A= >>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>> = =20=0D=0A>>>>>> [mf2]=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>= >>> =20=0D=0A>>>>>> =20=0D=0A>>>>>> =20=0D=0A>>>= > =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A> =20=0D=0A= >> =20=0D=0A>> =20=0D=0A>>> ------------------------=0D=0A>>> =20=0D=0A= >>> =20=0D=0A>>> =20=0D=0A>>>> This message is for the designated r= ecipient only and may=0D=0A>>>> contain privileged, proprietary, or otherwi= se private information.=0D=0A=0D=0A>>>> If you have received it in error, p= lease notify the sender=0D=0A>>>> immediately and delete the original. Any= unauthorized use of=0D=0A>>>> this email is prohibited.=0D=0A>>>>=0D=0A>>>= > =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>=0D=0A--------------= ----------------------------------------------------------=0D=0A> =20=0D=0A= >> =20=0D=0A>> =20=0D=0A>>> ------------------------=0D=0A>>> =20=0D=0A= >>> =20=0D=0A>>> =20=0D=0A>>>> [mf2]=0D=0A>>>>=0D=0A>>>> =20=0D=0A= >>>> =20=0D=0A>>>> =20=0D=0A>>>> =20=0D=0A>>> ______________= _________________________________=0D=0A>>> Ecrit mailing list=0D=0A>>> Ecri= t@ietf.org=0D=0A>>> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>>>=0D= =0A>>>=0D=0A>>> =20=0D=0A>>> =20=0D=0A>=0D=0A----------------------= --------------------------------------------------=0D=0A> =20=0D=0A>> ----= --------------------=0D=0A>> =20=0D=0A>> =20=0D=0A>>> This message is f= or the designated recipient only and may=0D=0A>>> contain privileged, propr= ietary, or otherwise private information. =20=0D=0A>>> If you have received= it in error, please notify the sender=0D=0A>>> immediately and delete the = original. Any unauthorized use of=0D=0A>>> this email is prohibited.=0D=0A= >>>=0D=0A>>> =20=0D=0A>>> =20=0D=0A>=0D=0A-------------------------= -----------------------------------------------=0D=0A> =20=0D=0A>> -------= -----------------=0D=0A>> =20=0D=0A>> =20=0D=0A>>> [mf2]=0D=0A>>>=0D=0A= >>> =20=0D=0A>>> =20=0D=0A>>> =20=0D=0A>>=0D=0A>> =20=0D=0A>=0D= =0A------------------------------------------------------------------------=0D= =0A> ------------------------=0D=0A> =20=0D=0A>> This message is for the d= esignated recipient only and may=0D=0A>> contain privileged, proprietary, o= r otherwise private information. =20=0D=0A>> If you have received it in err= or, please notify the sender=0D=0A>> immediately and delete the original. = Any unauthorized use of=0D=0A>> this email is prohibited.=0D=0A>>=0D=0A>> = =20=0D=0A>=0D=0A---------------------------------------------------------= ---------------=0D=0A> ------------------------=0D=0A> =20=0D=0A>> [mf2]=0D= =0A>>=0D=0A>> =20=0D=0A>> =20=0D=0A>=0D=0A>=0D=0A>=0D=0A---------------= ---------------------------------------------------------=0D=0A------------= ------------=0D=0A> This message is for the designated recipient only and m= ay=0D=0A> contain privileged, proprietary, or otherwise private information= =2E =20=0D=0A> If you have received it in error, please notify the sender=0D= =0A> immediately and delete the original. Any unauthorized use of=0D=0A> t= his email is prohibited.=0D=0A>=0D=0A--------------------------------------= ----------------------------------=0D=0A------------------------=0D=0A> [mf= 2]=0D=0A>=0D=0A> =20=0D=0A=0D=0A=0D=0A------------------------------------= ------------------------------------------------------------=0D=0AThis mess= age is for the designated recipient only and may=0D=0Acontain privileged, p= roprietary, or otherwise private information. =20=0D=0AIf you have received= it in error, please notify the sender=0D=0Aimmediately and delete the orig= inal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A--------= ---------------------------------------------------------------------------= -------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 11 14:15:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8gj6-0006sl-D8; Wed, 11 Jul 2007 14:15:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8giO-0005aC-LS; Wed, 11 Jul 2007 14:15:04 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8giM-000152-CF; Wed, 11 Jul 2007 14:15:04 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 56D8532A4C; Wed, 11 Jul 2007 18:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8giM-0003DI-7M; Wed, 11 Jul 2007 14:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 14:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-dhc-lost-discovery-02.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure Author(s) : H. Schulzrinne, et al. Filename : draft-ietf-ecrit-dhc-lost-discovery-02.txt Pages : 9 Date : 2007-7-11 The Location-to-Service Translation Protocol (LoST) describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere but a placement closer to the end host, e.g., in the access network, is desireable. Such a LoST server placement provides benefits in disaster situations with intermittent network connectivity regarding the resiliency of emergency service communication. This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-dhc-lost-discovery-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11134137.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-dhc-lost-discovery-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11134137.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Wed Jul 11 19:05:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lFq-00040t-AM; Wed, 11 Jul 2007 19:05:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8lFo-00040V-Qp for ecrit@ietf.org; Wed, 11 Jul 2007 19:05:52 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8lFZ-00037d-Fn for ecrit@ietf.org; Wed, 11 Jul 2007 19:05:52 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_18_13_17 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 18:13:17 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 18:05:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] LoST Date: Wed, 11 Jul 2007 18:05:03 -0500 Message-ID: In-Reply-To: <4694A229.2070002@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDnYUV5XZ9nX9PQD6CP4JrQhpGzwAcgaqQ References: <4693E4D4.1000905@gmx.net> <46947F6E.1000805@gmx.net> <46949AFF.3040103@gmx.net> <4694A229.2070002@gmx.net> From: "Winterbottom, James" To: "Hannes Tschofenig" X-OriginalArrivalTime: 11 Jul 2007 23:05:04.0683 (UTC) FILETIME=[EAD687B0:01C7C40F] X-Spam-Score: 1.8 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1010314797==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1010314797== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C40F.EA9470F9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C40F.EA9470F9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes,=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A=20=0D=0A=0D=0A> > So = again I remain unconvinced by=0D=0A=0D=0A> > this debate. It is far simpler= to interpret the ellipse and circle=0D=0Atypes=0D=0A=0D=0A> > than a polyg= on, and to be frank from an end-point or measure=0D=0Alocation=0D=0A=0D=0A>= > perspective far more likely to be provided.=0D=0A=0D=0A> >=0D=0A=0D=0A> = That's fine since we don't have a polygon in the LoST document either.=0D=0A=0D= =0A=20=0D=0A=0D=0A[AJW] Really=3F What is section 12.3 for then=3F=0D=0A=0D= =0A=20=0D=0A=0D=0ACheers=0D=0A=0D=0AJames=0D=0A=0D=0A----------------------= --------------------------------------------------------------------------=0D= =0AThis message is for the designated recipient only and may=0D=0Acontain p= rivileged, proprietary, or otherwise private information. =20=0D=0AIf you h= ave received it in error, please notify the sender=0D=0Aimmediately and del= ete the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C7C40F.EA9470F9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

Hi Hannes,

=0D=0A=0D=0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A

 

=0D=0A=0D=0A

> &g= t;  So again I remain unconvinced by

=0D=0A=0D=0A

> > this debate. It is far simpler to interpret t= he ellipse and=0D=0Acircle types

=0D=0A=0D=0A

> > than a polygon, and to be frank from an end-point or m= easure=0D=0Alocation

=0D=0A=0D=0A

<= font size=3D2 face=3D"Courier New">&= gt; > perspective far more likely to be provided.

=0D=0A=0D= =0A

> >

=0D=0A=0D=0A

> That's fine since we don't have a polygon in the LoST docum= ent=0D=0Aeither.

=0D=0A=0D=0A

 =0D=0A=0D=0A

[AJW] Really=3F What is=0D=0Asection 12.3 for then=3F

=0D=0A=0D=0A

 

=0D=0A=0D=0A

Cheers<= /o:p>

=0D=0A=0D=0A

James

=0D=0A=0D= =0A
=0D=0A=0D=0A

<= tr>

----------------------------------------------------------------= --------------------------------
=0D=0AThis message is fo= r the designated recipient only and may
=0D= =0Acontain privileged, proprietary, or otherwise p= rivate information.  
=0D=0AIf you have re= ceived it in error, please notify the se= nder
=0D=0Aimmediately and delete the original. = ; Any unauthorized use of
=0D=0Athis email = ;is prohibited.
=0D=0A---------------------------------------------= ---------------------------------------------------
=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C7C40F.EA9470F9-- --===============1010314797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1010314797==-- From ecrit-bounces@ietf.org Wed Jul 11 20:40:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mjh-0001hw-4m; Wed, 11 Jul 2007 20:40:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mjg-0001hj-1h for ecrit@ietf.org; Wed, 11 Jul 2007 20:40:48 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8mjb-0004mY-M9 for ecrit@ietf.org; Wed, 11 Jul 2007 20:40:48 -0400 X-SEF-Processed: 5_0_0_910__2007_07_11_19_48_55 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 11 Jul 2007 19:48:55 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jul 2007 19:40:43 -0500 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: [Ecrit] LoST Date: Wed, 11 Jul 2007 19:40:41 -0500 Message-ID: In-Reply-To: <5289F402-146E-4AE1-9EA7-988B4F6D9A52@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfDuqf3qq33AZTGSwmD22FZ1vVJfgAYeX+g References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net><46949AFF.3040103@gmx.net><4694A3AE.2090506@gmx.net><4694A8DE.7010202@gmx.net><4694B7EC.3010003@gmx.net> <5289F402-146E-4AE1-9EA7-988B4F6D9A52@cs.columbia.edu> From: "Winterbottom, James" To: "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 12 Jul 2007 00:40:43.0272 (UTC) FILETIME=[474DB880:01C7C41D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning,=0D=0A=0D=0AComments inline.=0D=0A=0D=0A> -----Original Message-= ----=0D=0A> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=0D=0A> S= ent: Wednesday, 11 July 2007 10:54 PM=0D=0A> To: Hannes Tschofenig=0D=0A> C= c: ECRIT=0D=0A> Subject: Re: [Ecrit] LoST=0D=0A>=20=0D=0A> Three quick comm= ents:=0D=0A>=20=0D=0A> As far as I know, GPS devices produce a point plus (= small)=0D=0A> uncertainty, e.g., in the common NMEA output format (http://v= ancouver-=0D=0A> webpages.com/peter/nmeafaq.txt). The uncertainty is so sma= ll and=0D=0A> tends to fluctuate so much that including it in location mapp= ing is=0D=0A> pretty pointless, and it's probably of dubious value even for=0D= =0A> dispatch. (When I went geocaching recently with my kids, uncertainty=0D= =0A> on a modern SiRF-based device was around 18 - 25', under dense tree=0D= =0A> cover.)=0D=0A>=0D=0A[AJW] This can be larger if the device is cold-sta= rted and/or receives=0D=0Aassistance data. From handset-based phone testing= we have done in the=0D=0Apast, 30 metre averages are not atypical.=0D=0A=0D= =0A=20=0D=0A> That said, I think the complexity of including circles, arc b= and and=0D=0A> ellipse is minimal. In all cases, the description includes a= center=0D=0A> point, which the LoST machinery could easily use to do the a= ctual=0D=0A> lookup. Thus, the additional complexity is mainly parsing thes= e XML=0D=0A> structures, which strikes me as not a big deal.=0D=0A>=0D=0A=0D= =0A[AJW] Agreed.=0D=0A=0D=0A=20=0D=0A> What gets complex is if a LoST resol= ver is forced to map shapes to=0D=0A> multiple branches of the tree, what w= e have discussed in the past as=0D=0A> the "forking" problem. For example, = if a geo shape straddles the=0D=0A> boundary between the US and Canada, you= really don't want the LoST=0D=0A> resolver gather results from both trees,= decide how long it needs to=0D=0A> wait for one or the other, and other is= sues. This requires=0D=0A> significantly more protocol work, creates additi= onal error conditions=0D=0A> and increases implementation complexity.=0D=0A= >=0D=0A[AJW] Agreed, I am happy for the internals of a LoST server to stay=0D= =0Ainternal. If people want to opt for complex GIS systems to manage=0D=0Ab= oundary cases then that is a matter of choice. I would like the option=0D=0A= of passing the geoshape to the LoST server however.=20=0D=0A=20=0D=0A> A th= ird point relates more to HELD than LoST: It's probably a good=0D=0A> idea = to be able to request a specific location profile, in the same=0D=0A> spiri= t as in LoST, so that if newer, complex shapes can be=0D=0A> accommodated e= asily in the future. We can then decide whether to=0D=0A> define a LoST-lik= e profile for HELD that only includes the current=0D=0A> geo shapes, withou= t endangering interoperability.=0D=0A=0D=0A[AJW] let me think on this one a= bit. We can talk in Chicago if you=0D=0Alike.=0D=0A=0D=0A=20=0D=0A> In sum= mary: I'm not opposed to including the three additional shapes,=0D=0A> as l= ong as it is clear that the LoST server MAY use the center point=0D=0A> for= mapping.=0D=0A=0D=0A[AJW] Agreed.=0D=0A=0D=0A=0D=0A>=20=0D=0A> Henning=0D=0A= >=20=0D=0A> On Jul 11, 2007, at 6:58 AM, Hannes Tschofenig wrote:=0D=0A> =0D= =0A> >=0D=0A> > For GPS usage at the end host only you are certainly right = that=0D=0A> > circles & ellipse is a good choice. The big question is here:=0D= =0A> > * is it a big issue to translate them to a point=0D=0A> > * does it = introduce big error rates=0D=0A> > Please also note that we are talking abo= ut emergency call routing=0D=0A> > in the context of LoST and not about dis= patch. To approximate a=0D=0A> > circle with a radius of 3 meters with a po= int might not be a big=0D=0A> > problem.=0D=0A> >=0D=0A>=20=0D=0A>=20=0D=0A= > _______________________________________________=0D=0A> Ecrit mailing list=0D= =0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D= =0A------------------------------------------------------------------------= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 12 02:40:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sLe-0001vA-LZ; Thu, 12 Jul 2007 02:40:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sLd-0001v4-DP for ecrit@ietf.org; Thu, 12 Jul 2007 02:40:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I8sLO-0000DO-08 for ecrit@ietf.org; Thu, 12 Jul 2007 02:40:21 -0400 Received: (qmail invoked by alias); 12 Jul 2007 06:39:24 -0000 Received: from p549862D4.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.98.212] by mail.gmx.net (mp053) with SMTP; 12 Jul 2007 08:39:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19caXxsK2JceS8cyzMm0EPWrOQWdu8tbDjeN+1Eaa N3+dc6e2WiAMXo Message-ID: <4695CC9A.3090700@gmx.net> Date: Thu, 12 Jul 2007 08:39:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Winterbottom, James" References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net><46949AFF.3040103@gmx.net><4694A3AE.2090506@gmx.net><4694A8DE.7010202@gmx.net><4694B7EC.3010003@gmx.net> <5289F402-146E-4AE1-9EA7-988B4F6D9A52@cs.columbia.edu> 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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ECRIT Subject: [Ecrit] LoST Location Profile -- Input from the group needed X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, James and Henning have stated their opinion regarding the extension of location profiles. It would be good to hear other opinions as well. Ciao Hannes Henning wrote: >> That said, I think the complexity of including circles, arc band and >> ellipse is minimal. In all cases, the description includes a center >> point, which the LoST machinery could easily use to do the actual >> lookup. Thus, the additional complexity is mainly parsing these XML >> structures, which strikes me as not a big deal. >> >> > > [AJW] Agreed. > > Henning wrote: > > >> What gets complex is if a LoST resolver is forced to map shapes to >> multiple branches of the tree, what we have discussed in the past as >> the "forking" problem. For example, if a geo shape straddles the >> boundary between the US and Canada, you really don't want the LoST >> resolver gather results from both trees, decide how long it needs to >> wait for one or the other, and other issues. This requires >> significantly more protocol work, creates additional error conditions >> and increases implementation complexity. >> >> > [AJW] Agreed, I am happy for the internals of a LoST server to stay > internal. If people want to opt for complex GIS systems to manage > boundary cases then that is a matter of choice. I would like the option > of passing the geoshape to the LoST server however. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 12 10:17:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zTt-0004Bn-DM; Thu, 12 Jul 2007 10:17:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zTs-0004Ai-CA for ecrit@ietf.org; Thu, 12 Jul 2007 10:17:20 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8zTo-0003lZ-3s for ecrit@ietf.org; Thu, 12 Jul 2007 10:17:20 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8zTn-00024z-5S for ecrit@ietf.org; Thu, 12 Jul 2007 10:17:15 -0400 Message-ID: <469637E9.8080209@bbn.com> Date: Thu, 12 Jul 2007 10:17:13 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] draft-barnes-ecrit-auth-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org As a follow-up to my "VSP verification" ideas in the location-hiding debate, I've posted a new draft that proposes several options for authorized entities to assert, and for proxies to verify that a call is an emergency call. The draft treats the problem in two parts, (1) the "authenticator" used, i.e., the information that proves that the call is an emergency call, and (2) the SIP messages used to carry the authenticator. Three authenticators are presented, including the standard "location + service URN" authenticator as well as two cryptographic options. For the SIP embedding, I've declined to list specific proposals, and instead listed some requirements. The document is available at Cheers, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 12 13:05:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I926B-0004U2-4Q; Thu, 12 Jul 2007 13:05:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9269-0004TW-80 for ecrit@ietf.org; Thu, 12 Jul 2007 13:05:01 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I925t-0003dW-Tj for ecrit@ietf.org; Thu, 12 Jul 2007 13:05:01 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l6CH3NTi019331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2007 10:03:24 -0700 Received: from [76.102.92.155] (vpn-10-50-0-133.qualcomm.com [10.50.0.133]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l6CH3LJO006527; Thu, 12 Jul 2007 10:03:22 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net><46949AFF.3040103@gmx.net><4694A3AE.2090506@gmx.net><4694A8DE.7010202@gmx.net> <4694B7EC.3010 003@gmx.net> <5289F402-146E-4AE1-9EA7-988B4F6D9A52@cs.columbia.edu> Date: Thu, 12 Jul 2007 10:03:20 -0700 To: "Winterbottom, James" , "Henning Schulzrinne" , "Hannes Tschofenig" From: Ted Hardie Subject: RE: [Ecrit] LoST Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 7:40 PM -0500 7/11/07, Winterbottom, James wrote: >[AJW] This can be larger if the device is cold-started and/or receives >assistance data. From handset-based phone testing we have done in the >past, 30 metre averages are not atypical. > How does receiving assistance data fit into this? Do you mean in the case where there are few satellites visible to the device? If so, I think that is the aspect of operation which should be highlighted, not the use of assistance data. Has the handset testing data you've done on this been released? Is it available for the WG to review? > > In summary: I'm not opposed to including the three additional shapes, >> as long as it is clear that the LoST server MAY use the center point >> for mapping. > >[AJW] Agreed. > This sounds like a reasonable compromise to me. regards, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 12 17:47:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I96Vd-0006j6-JV; Thu, 12 Jul 2007 17:47:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I96Vc-0006f8-Nf for ecrit@ietf.org; Thu, 12 Jul 2007 17:47:36 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I96Vc-0002NQ-Dh for ecrit@ietf.org; Thu, 12 Jul 2007 17:47:36 -0400 X-SEF-Processed: 5_0_0_910__2007_07_12_16_55_47 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 12 Jul 2007 16:55:47 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jul 2007 16:47:33 -0500 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: [Ecrit] LoST Date: Thu, 12 Jul 2007 16:47:24 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST Thread-Index: AcfEpo9QN+qst3o7T2i1PeSbdvCMIwAJDJgg References: <4693E4D4.1000905@gmx.net><46947F6E.1000805@gmx.net><46949AFF.3040103@gmx.net><4694A3AE.2090506@gmx.net><4694A8DE.7010202@gmx.net> <4694B7EC.3010 003@gmx.net> <5289F402-146E-4AE1-9EA7-988B4F6D9A52@cs.columbia.edu> From: "Winterbottom, James" To: "Ted Hardie" , "Henning Schulzrinne" , "Hannes Tschofenig" X-OriginalArrivalTime: 12 Jul 2007 21:47:33.0784 (UTC) FILETIME=[41196980:01C7C4CE] X-Spam-Score: 1.8 (+) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ted,=0D=0A=0D=0AThis is probably a little off topic now. I shall answer as = best I can=0D=0Ahere and if you are interested in further discussion in Chi= cago we can=0D=0Ado that.=0D=0A=0D=0AMy experience with GPS systems has bee= n that the amount of error gets=0D=0Aless the longer the thing is on. I am = certainly not a GPS expert (though=0D=0Awe do have some in our office). Man= y of the handheld GPS systems sold=0D=0Anow contain differential GPS techno= logy and almost all GPS systems in=0D=0Acellular devices do not. With the f= ormer providing considerably accuracy=0D=0Aimprovements over the latter.=0D= =0A=0D=0AIf I have a mobile system that is cold-started and I give it assis= tance=0D=0Adata it will try and get a fix ASAP, indeed in most situations i= t has a=0D=0Avery strict time in which it needs to provide a location or it= needn't=0D=0Abother. The number of satellites that the handset can see cer= tainly=0D=0Aenters into the equation, I know for example that there is a mi= nimum=0D=0Anumber (4 I think), but I don't know how much better the locatio= n gets=0D=0Aif you have more than that, or how much longer it takes to get=0D= =0Ameasurements with more satellites. Certainly handset implementations=0D=0A= vary from set to set for MS-Based solutions and so the location results=0D=0A= vary also. Carriers prefer consistency in this area and this is one=0D=0Are= ason that some cellular providers are moving towards MS-Assisted=0D=0Asolut= ions.=0D=0A=0D=0AI don't know if this particular handset data has been rele= ased, but I=0D=0Acan ask. I doubt that the handset vendor's name will have = been released=0D=0Ahowever.=0D=0A=0D=0AThere may also be public submissions= that have been made in general by=0D=0Anetwork operators opting for GPS as= their wireless Phase II compliance=0D=0Amethod.=0D=0A=0D=0ACheers=0D=0AJam= es=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: T= ed Hardie [mailto:hardie@qualcomm.com]=0D=0A> Sent: Friday, 13 July 2007 3:= 03 AM=0D=0A> To: Winterbottom, James; Henning Schulzrinne; Hannes Tschofeni= g=0D=0A> Cc: ECRIT=0D=0A> Subject: RE: [Ecrit] LoST=0D=0A>=20=0D=0A> At 7:4= 0 PM -0500 7/11/07, Winterbottom, James wrote:=0D=0A> >[AJW] This can be la= rger if the device is cold-started and/or=0D=0Areceives=0D=0A> >assistance = data. From handset-based phone testing we have done in the=0D=0A> >past, 30= metre averages are not atypical.=0D=0A> >=0D=0A>=20=0D=0A> How does receiv= ing assistance data fit into this=3F Do you mean in the=0D=0A> case where = there are few satellites visible to the device=3F If so,=0D=0A> I think th= at is the aspect of operation which should be highlighted,=0D=0A> not the u= se of assistance data.=0D=0A>=20=0D=0A> Has the handset testing data you've= done on this been released=3F Is=0D=0A> it available for the WG to review= =3F=0D=0A>=20=0D=0A> > > In summary: I'm not opposed to including the three= additional=0D=0Ashapes,=0D=0A> >> as long as it is clear that the LoST ser= ver MAY use the center=0D=0Apoint=0D=0A> >> for mapping.=0D=0A> >=0D=0A> >[= AJW] Agreed.=0D=0A> >=0D=0A>=20=0D=0A> This sounds like a reasonable compro= mise to me.=0D=0A> =09=09=09regards,=0D=0A> =09=09=09=09Ted=0D=0A>=20=0D=0A= >=20=0D=0A>=20=0D=0A=0D=0A-------------------------------------------------= -----------------------------------------------=0D=0AThis message is for th= e designated recipient only and may=0D=0Acontain privileged, proprietary, o= r otherwise private information. =20=0D=0AIf you have received it in error,= please notify the sender=0D=0Aimmediately and delete the original. Any un= authorized use of=0D=0Athis email is prohibited.=0D=0A---------------------= ---------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 13 08:51:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Kck-0007IM-IR; Fri, 13 Jul 2007 08:51:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Kcj-0007IA-Hg for ecrit@ietf.org; Fri, 13 Jul 2007 08:51:53 -0400 Received: from mail.skype.net ([193.88.6.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Kce-0006Ed-Tv for ecrit@ietf.org; Fri, 13 Jul 2007 08:51:53 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 4DECD110178 for ; Fri, 13 Jul 2007 14:48:25 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkWxpOajnbZx for ; Fri, 13 Jul 2007 14:48:21 +0200 (CEST) Received: from [172.16.22.25] (unknown [194.126.108.2]) by mail.skype.net (Postfix) with ESMTP id E62B511017E for ; Fri, 13 Jul 2007 14:48:18 +0200 (CEST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 13 Jul 2007 15:51:20 +0300 From: Andres K=?ISO-8859-1?B?/A==?=tt To: Message-ID: Thread-Topic: Comments on the Location Hiding Requirements document Thread-Index: AcfFTIJxwUuX5DE/Edy5RgAX8i4icA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Ecrit] Comments on the Location Hiding Requirements document X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi, I have some comments as to the document at http://tools.ietf.org/wg/ecrit/draft-schulzrinne-ecrit-location-hiding-requ= i rements-00.txt - 1.2. I don't think it is accurate to try to point out reasons why ISP/IAP would like to hide location information. The server load is just one aspect= , but most probably they would be too greedy to give out valuable information for free.=20 - REQ-C. That's a strange requirement. In case the call goes through VSP infrastructure they know (in case they trust LoST) that the URI is a genuin= e one and control the termination process. In case the call does not go through a VSP, there is really no way of knowing where the call ends up at. Or I don't understand the point of the requirement - Req-1. I would rather say that a relationship with IAP (the people who se= t up a rogue wifi AP) can not be assumed but a relationship with ISP could be feasible (although highly underireable) under certain circumstances. For example, it might be OK to state that emergency calls with that phone only work in a particular country where deals with a couple of major players could give sufficient coverage - Thank you for Req-5, it's really important for folks like Skype - Req-9 is irrelevant as any operation before the call adds latency and it depends on the implementation whether or not that particular deduction adds significiant latency or not. I would rather say that the solution MUST seek to minimize the call setup time - Aren't Req-10 and Req-11 the same? If I have the PSAP/ESRP URL, don't I also have the dial string? - Req-12 is ambiquous. What is minimal impact? In terms of performance, resource requirements, development, code complexity or what? UAs need to be updated anyway and it is unlikely that any solution drives any resource requirements through the roof. And when that happens, it's the problem of the UA vendor, not this standards body, I think. - Req-14. The same as REQ-C. The VSP needs to be able to trust the LoST service anyway=20 - Req-15. What has it to do with locations? We already said that the calls might not be SIP calls which implies some sort of a proxy and the fact that the calls do not always originate directly from the UA. Which makes the issue of having or not having yet another proxy on the call's path irrelevant - Req-16. This is how Req-9 should be worded Yours, Andres K=FCtt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 13 17:11:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9SQC-0007Y1-Si; Fri, 13 Jul 2007 17:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9SQB-0007Vj-VQ for ecrit@ietf.org; Fri, 13 Jul 2007 17:11:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I9SQ7-00086c-F0 for ecrit@ietf.org; Fri, 13 Jul 2007 17:11:27 -0400 Received: (qmail invoked by alias); 13 Jul 2007 21:11:22 -0000 Received: from p54985A56.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.90.86] by mail.gmx.net (mp034) with SMTP; 13 Jul 2007 23:11:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18wssFHIYgwnvEHFTec2eZ9JfMw0iPt1hjfrl43fi xem728bwia6hzp Message-ID: <4697EA76.60606@gmx.net> Date: Fri, 13 Jul 2007 23:11:18 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Ecrit] Phone BCP Draft Comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Hi James, Hi all, I like the document, as I expressed several times in the past. There are, however, a few issues with it. Henning and myself have recently written an ECRIT overview document. See http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture-overview-00.txt One thing that was quite important for us to highlight was that the IETF emergency service architecture has a very nice property, namely the fact that different VoIP protocols may be supported between the end host and the VoIP provider. There is no need to implement SIP only. Now, this document does not give me the impression that this aspect is given enough consideration. The IETF emergency service architecture realistically requires that the emergency calls are routed through the VSP in order to get identity information attached to an emergency call. Having said all that I believe that one important aspect, which is also different to architecturs investigated by other SDOs, is that the PSAP has to support a certain functionality. This functionality is described in the document but might not be too visible to the working group or at least hasn't be advertised a lot. I believe we have to indicate quite close what the different entities have to support rather than meshing everything together. This impacts the document structure a bit. Here is a suggested structure for the document: * Introduction Shorten the introduction It contains a lot of info that is already available in the framework. This document has to be read in the context of the architecture anyway. Btw, the introduction must not use RFC 2119 language. * Terminology Classical RFC boilerplate and pointers to the requirements document. * End Host Profile This section just describes what is absolutely necessary for an end point to support the This is essentially the location part, the LoST part. This would essentially be Section 4.2, 4.3, 4.4, and 4.5. The LoST stuff can be found in Section 6.3. * ISP Profile This is the location part. The server side of Section 4.2. Optionally, LoST may be provided by the ISP. * VSP Profile Some parts from Section 5 and Section 6 could go in here. Might want to separate this into a separate sub-section to have a way to reference it from the "End Host Profile" section to say something like "When the end host implements SIP then the VSP might want to use the same functionality already at the client." The detailed considerations about SIP location conveyance are not necessary since they can already be found in the SIP Location Conveyance document already. Section 6.2 does not work with the general IETF emergency architecture, as described in the ECRIT framework document. For example, the proxy does not obtain location information since it cannot do so in the generic case. Section 8 is also relevant. * PSAP Profile Section 6.5 is relevant but only to the extend where the PSAP operator network faces the outside world. I don't think it is too relevant for this document to talk about PSAP network interal operator, such as transferring a call to another PSAP operator. Section 8 is also relevant. * Security Considerations Don't go too much into the details since we talk about all the stuff in other docs. The testing section is fine. -- I am not so sure about the location update section. In any case: Try to make the document as short as possible. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 16:44:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9oTI-0006sm-UR; Sat, 14 Jul 2007 16:44:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9oTI-0006sd-1t for ecrit@ietf.org; Sat, 14 Jul 2007 16:44:08 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9oTB-000312-Jl for ecrit@ietf.org; Sat, 14 Jul 2007 16:44:07 -0400 Received: from [63.243.41.34] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I9oSp-0004gp-Tg; Sat, 14 Jul 2007 15:43:40 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <4697EA76.60606@gmx.net> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 16:43:52 -0400 Message-ID: <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4697EA76.60606@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfFklvWZSG3KF32TlqMtNR6DxFYEAAq3KIw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org See in line > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, July 13, 2007 5:11 PM > To: ECRIT > Subject: [Ecrit] Phone BCP Draft Comments > > Hi Brian, > Hi James, > Hi all, > > I like the document, as I expressed several times in the past. > > There are, however, a few issues with it. > > Henning and myself have recently written an ECRIT overview document. See > http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- > overview-00.txt > > One thing that was quite important for us to highlight was that the IETF > emergency service architecture has a very nice property, namely the fact > that different VoIP protocols may be supported between the end host and > the VoIP provider. There is no need to implement SIP only. > > Now, this document does not give me the impression that this aspect is > given enough consideration. There are two things that came to mind when I read this. One is that you are right, and we can be more clear that any protocol can be used between the endpoint and some kind of gateway that interworks to a protocol that the PSAP implements. The other is that SIP need not be the only protocol the PSAP implements. However. There are some requirements on what the protocol needs to do. We should list them, and I think probably that discussion belongs in -framework. LoST already can return multiple URIs with different schemes corresponding to what it implements. > > The IETF emergency service architecture realistically requires that the > emergency calls are routed through the VSP in order to get identity > information attached to an emergency call. NO!!!! That is NOT true. The PSAPs I work with will take calls that don't come from a VSP over the internet. They may well have some suspicion on such calls due to the lack of a verifiable identity but they will take the call anyway. I've had numerous conversations with PSAP people who want to make sure I understand the "rules" they have (validated location for examples). When I press them for what they want to do when something goes wrong and it doesn't happen (like, validation fails, do they want unvalidated location or no location), they ALWAYS want the call, and they want the data you have. They may treat the call with suspiscion. They may go back later and try to figure out why they didn't get what they wanted but they take the call and ask questions later. So please don't make that assumption. Ysa, we expect nearly all calls to go through a VSP, but the system works if Marc Linsner's proxy in his house sends the call to the PSAP. > > Having said all that I believe that one important aspect, which is also > different to architecturs investigated by other SDOs, is that the PSAP > has to support a certain functionality. This functionality is described > in the document but might not be too visible to the working group or at > least hasn't be advertised a lot. Yes, this is true. We could make that more explicit. > > I believe we have to indicate quite close what the different entities > have to support rather than meshing everything together. This impacts > the document structure a bit. Yes, we have thought about that a lot, and have had some suggestions in that the direction, the goal being to have all the BCPs for phones in one place, those for the access network in another place, etc. > > Here is a suggested structure for the document: > > * Introduction > > Shorten the introduction > > It contains a lot of info that is already available in the framework. > This document has to be read in the context of the architecture anyway. We will do that > > Btw, the introduction must not use RFC 2119 language. Yes > > * Terminology > > Classical RFC boilerplate and pointers to the requirements document. > > * End Host Profile > > This section just describes what is absolutely necessary for an end > point to support the > > This is essentially the location part, the LoST part. > This would essentially be Section 4.2, 4.3, 4.4, and 4.5. > The LoST stuff can be found in Section 6.3. > > * ISP Profile > > This is the location part. The server side of Section 4.2. > Optionally, LoST may be provided by the ISP. You see where the problem is? You have the location part in both End Host and ISP. Same with LoST. This is the problem with this suggestion. It actually makes as much sense to keep all the location information together as it does to keep all the end host information together. My best idea to address this is to leave the structure as is, but to make the BCP elements pulled out and labeled as to whom they apply (endpoint, VSP, ISP, PSAP). Then, after the functional sections, we can copy the BCP elements (only, not the other text) and sort them by who they apply to. > > * VSP Profile > > Some parts from Section 5 and Section 6 could go in here. Might want to > separate this into a separate sub-section to have a way to reference it > from the "End Host Profile" section to say something like > "When the end host implements SIP then the VSP might want to use the > same functionality already at the client." > > The detailed considerations about SIP location conveyance are not > necessary since they can already be found in the SIP Location Conveyance > document already. Actually, I think a lot of this text has to stay as it describes how you use the -conveyance mechanism. We'll take a sharp look at it for deletions. > > Section 6.2 does not work with the general IETF emergency architecture, > as described in the ECRIT framework document. For example, the proxy > does not obtain location information since it cannot do so in the > generic case. I don't want IETF to be in the position of not supporting proxy insertion of location as, for example, 3GPP does. I think we explicitly allow it but explain the difficulties. > > Section 8 is also relevant. > > > * PSAP Profile > > Section 6.5 is relevant but only to the extend where the PSAP operator > network faces the outside world. I don't think it is too relevant for > this document to talk about PSAP network interal operator, such as > transferring a call to another PSAP operator. Probably right, but the endpoint requirements to support transfer must stay > > Section 8 is also relevant. > > > > * Security Considerations > > Don't go too much into the details since we talk about all the stuff in > other docs. If you say so. I'm not sure we can get away with this. Can we ask you to get a security reviewer assigned sooner rather than later and we can work with him to see what we can accomplish with just references to other docs? > > The testing section is fine. Albeit it mixes endpoint and PSAP BCP statements. > > > > -- I am not so sure about the location update section. There is nothing to reference. It has to be somewhere else, and referenced here, or here. This is a use of presence (and presumably HELD). > > In any case: Try to make the document as short as possible. Okay Thanks for the suggestions _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 17:39:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pKa-0003qM-2c; Sat, 14 Jul 2007 17:39:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pKZ-0003li-7j for ecrit@ietf.org; Sat, 14 Jul 2007 17:39:11 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9pKY-0004Ny-E3 for ecrit@ietf.org; Sat, 14 Jul 2007 17:39:11 -0400 Received: (qmail invoked by alias); 14 Jul 2007 21:38:28 -0000 Received: from p54984608.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.70.8] by mail.gmx.net (mp029) with SMTP; 14 Jul 2007 23:38:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ZGf8mQ70Zgerctk0qVOeBUylHdSFvQp5D/7D99N pXf9Sy8dcJWLfD Message-ID: <46994251.5050201@gmx.net> Date: Sat, 14 Jul 2007 23:38:25 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> In-Reply-To: <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> 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: bfe538a859d88717fa3c8a6377d62f90 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, thanks for the quick response. Please see my comments below: Brian Rosen wrote: > See in line > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, July 13, 2007 5:11 PM >> To: ECRIT >> Subject: [Ecrit] Phone BCP Draft Comments >> >> Hi Brian, >> Hi James, >> Hi all, >> >> I like the document, as I expressed several times in the past. >> >> There are, however, a few issues with it. >> >> Henning and myself have recently written an ECRIT overview document. See >> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- >> overview-00.txt >> >> One thing that was quite important for us to highlight was that the IETF >> emergency service architecture has a very nice property, namely the fact >> that different VoIP protocols may be supported between the end host and >> the VoIP provider. There is no need to implement SIP only. >> >> Now, this document does not give me the impression that this aspect is >> given enough consideration. >> > There are two things that came to mind when I read this. One is that you > are right, and we can be more clear that any protocol can be used between > the endpoint and some kind of gateway that interworks to a protocol that the > PSAP implements. > > The other is that SIP need not be the only protocol the PSAP implements. > That's certainly true. We do, however, have to start somewhere. We cannot describe what Skype protocol features a PSAP has to implement for an emergency service scenario. Hence, we focus only on SIP. That's already enough for a PSAP to implement. We do, however, only mandate functionality that is absolutely necessary for interoperability. > However. There are some requirements on what the protocol needs to do. We > should list them, and I think probably that discussion belongs in > -framework. LoST already can return multiple URIs with different schemes > corresponding to what it implements. > > It might be a good idea to state what protocols have to support -- there aren't too many things anyway. >> The IETF emergency service architecture realistically requires that the >> emergency calls are routed through the VSP in order to get identity >> information attached to an emergency call. >> > NO!!!! > > That is NOT true. The PSAPs I work with will take calls that don't come > >from a VSP over the internet. I guess you need to describe in more detail what you have seen. > They may well have some suspicion on such > calls due to the lack of a verifiable identity but they will take the call > anyway. I've had numerous conversations with PSAP people who want to make > sure I understand the "rules" they have (validated location for examples). > When I press them for what they want to do when something goes wrong and it > doesn't happen (like, validation fails, do they want unvalidated location or > no location), they ALWAYS want the call, and they want the data you have. > They may treat the call with suspiscion. They may go back later and try to > figure out why they didn't get what they wanted but they take the call and > ask questions later. > > So please don't make that assumption. Ysa, we expect nearly all calls to go > through a VSP, but the system works if Marc Linsner's proxy in his house > sends the call to the PSAP. > That's fine. It is just the question what we write into the document. What is the default behavior? We sent the calls directly to the PSAP or via the VSP? This has impact for the phone BCP document. If you assume that calls are routed through the VSP then the protocol run by the end point does not matter too much. If you assume that the end host MUST be able to route directly to the PSAP as well then you have to mandate a certain functionality at the end point. So, what behavior do we want? >> Having said all that I believe that one important aspect, which is also >> different to architecturs investigated by other SDOs, is that the PSAP >> has to support a certain functionality. This functionality is described >> in the document but might not be too visible to the working group or at >> least hasn't be advertised a lot. >> > Yes, this is true. We could make that more explicit. > > >> I believe we have to indicate quite close what the different entities >> have to support rather than meshing everything together. This impacts >> the document structure a bit. >> > Yes, we have thought about that a lot, and have had some suggestions in that > the direction, the goal being to have all the BCPs for phones in one place, > those for the access network in another place, etc. > It's OK to have the required functionality listed in one document even though they address all the involved parties in the architecture. >> Here is a suggested structure for the document: >> >> * Introduction >> >> Shorten the introduction >> >> It contains a lot of info that is already available in the framework. >> This document has to be read in the context of the architecture anyway. >> > We will do that > > >> Btw, the introduction must not use RFC 2119 language. >> > Yes > > >> * Terminology >> >> Classical RFC boilerplate and pointers to the requirements document. >> > > > >> * End Host Profile >> >> This section just describes what is absolutely necessary for an end >> point to support the >> >> This is essentially the location part, the LoST part. >> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. >> The LoST stuff can be found in Section 6.3. >> >> * ISP Profile >> >> This is the location part. The server side of Section 4.2. >> Optionally, LoST may be provided by the ISP. >> > You see where the problem is? You have the location part in both End Host > and ISP. Same with LoST. > > This is the problem with this suggestion. It actually makes as much sense > to keep all the location information together as it does to keep all the end > host information together. > > My best idea to address this is to leave the structure as is, but to make > the BCP elements pulled out and labeled as to whom they apply (endpoint, > VSP, ISP, PSAP). Then, after the functional sections, we can copy the BCP > elements (only, not the other text) and sort them by who they apply to. > > It's not a big problem to consider location aspects at the ISP and at the end host since the demanded functionality is, to some extend, different. In this particular document we, for example, say that the ISP has to implement one of the location protocols and the client implements all of them. >> * VSP Profile >> >> Some parts from Section 5 and Section 6 could go in here. Might want to >> separate this into a separate sub-section to have a way to reference it >> from the "End Host Profile" section to say something like >> "When the end host implements SIP then the VSP might want to use the >> same functionality already at the client." >> >> The detailed considerations about SIP location conveyance are not >> necessary since they can already be found in the SIP Location Conveyance >> document already. >> > Actually, I think a lot of this text has to stay as it describes how you use > the -conveyance mechanism. We'll take a sharp look at it for deletions. > > >> Section 6.2 does not work with the general IETF emergency architecture, >> as described in the ECRIT framework document. For example, the proxy >> does not obtain location information since it cannot do so in the >> generic case. >> > I don't want IETF to be in the position of not supporting proxy insertion of > location as, for example, 3GPP does. I think we explicitly allow it but > explain the difficulties. > The problem is that it does not work together with the framework document. The framework document does not have a case for it. It's fine that the SIP Location Conveyance document has something in there that could potentially be useful for the 3GPP. The interesting case, however, is that the emergency services architecture of the 3GPP has the functionality of the P-CSCF and the E-CSCF in the local network and hence they don't standardize the interaction with the PSAP, unlike we do because the PSAP in the IETF emergency services architecture might get the call from an arbitrary entity rather than from the local network operator. > >> Section 8 is also relevant. >> >> >> * PSAP Profile >> >> Section 6.5 is relevant but only to the extend where the PSAP operator >> network faces the outside world. I don't think it is too relevant for >> this document to talk about PSAP network interal operator, such as >> transferring a call to another PSAP operator. >> > Probably right, but the endpoint requirements to support transfer must stay > That's fine >> Section 8 is also relevant. >> >> >> >> * Security Considerations >> >> Don't go too much into the details since we talk about all the stuff in >> other docs. >> > If you say so. I'm not sure we can get away with this. Can we ask you to > get a security reviewer assigned sooner rather than later and we can work > with him to see what we can accomplish with just references to other docs? > Good idea. We should do that. >> The testing section is fine. >> > Albeit it mixes endpoint and PSAP BCP statements. > >> >> -- I am not so sure about the location update section. >> > There is nothing to reference. It has to be somewhere else, and referenced > here, or here. This is a use of presence (and presumably HELD). > > Hmm. I have to re-read that part. >> In any case: Try to make the document as short as possible. >> > Okay > > Thanks for the suggestions > Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 18:01:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pg0-0003aM-3p; Sat, 14 Jul 2007 18:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pfy-0003Wl-JT for ecrit@ietf.org; Sat, 14 Jul 2007 18:01:18 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9pft-0005xD-US for ecrit@ietf.org; Sat, 14 Jul 2007 18:01:18 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I9pff-0008VZ-IA; Sat, 14 Jul 2007 17:00:59 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 18:01:10 -0400 Message-ID: <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <46994251.5050201@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfGX0s/WedovXnQQJGQNvuksCLCrQAApkNA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The text now says that the phone applies normal outbound processing. That would mean it sends calls to the VSP. That's what we want. Marc's phone would normally send calls to his house proxy. That is what we want. Let us try my way with the organization and see if it accomplishes what you want. If it's a mess, I'll look at doing it your way. I'll make sure we discuss proxy insertion of location in both -framework and -phonebcp. I think it is best to state it is acceptable if the limitations implied (VSP has a relationship with ISP, has a good identifier that ISP can use) hold. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Saturday, July 14, 2007 5:38 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Phone BCP Draft Comments > > Hi Brian, > > thanks for the quick response. Please see my comments below: > > Brian Rosen wrote: > > See in line > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Friday, July 13, 2007 5:11 PM > >> To: ECRIT > >> Subject: [Ecrit] Phone BCP Draft Comments > >> > >> Hi Brian, > >> Hi James, > >> Hi all, > >> > >> I like the document, as I expressed several times in the past. > >> > >> There are, however, a few issues with it. > >> > >> Henning and myself have recently written an ECRIT overview document. > See > >> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- > >> overview-00.txt > >> > >> One thing that was quite important for us to highlight was that the > IETF > >> emergency service architecture has a very nice property, namely the > fact > >> that different VoIP protocols may be supported between the end host and > >> the VoIP provider. There is no need to implement SIP only. > >> > >> Now, this document does not give me the impression that this aspect is > >> given enough consideration. > >> > > There are two things that came to mind when I read this. One is that > you > > are right, and we can be more clear that any protocol can be used > between > > the endpoint and some kind of gateway that interworks to a protocol that > the > > PSAP implements. > > > > The other is that SIP need not be the only protocol the PSAP implements. > > > That's certainly true. We do, however, have to start somewhere. We > cannot describe what Skype protocol features a PSAP has to implement for > an emergency service scenario. > > Hence, we focus only on SIP. That's already enough for a PSAP to > implement. > We do, however, only mandate functionality that is absolutely necessary > for interoperability. > > > However. There are some requirements on what the protocol needs to do. > We > > should list them, and I think probably that discussion belongs in > > -framework. LoST already can return multiple URIs with different > schemes > > corresponding to what it implements. > > > > > It might be a good idea to state what protocols have to support -- there > aren't too many things anyway. > > >> The IETF emergency service architecture realistically requires that the > >> emergency calls are routed through the VSP in order to get identity > >> information attached to an emergency call. > >> > > NO!!!! > > > > That is NOT true. The PSAPs I work with will take calls that don't come > > >from a VSP over the internet. > > I guess you need to describe in more detail what you have seen. > > > They may well have some suspicion on such > > calls due to the lack of a verifiable identity but they will take the > call > > anyway. I've had numerous conversations with PSAP people who want to > make > > sure I understand the "rules" they have (validated location for > examples). > > When I press them for what they want to do when something goes wrong and > it > > doesn't happen (like, validation fails, do they want unvalidated > location or > > no location), they ALWAYS want the call, and they want the data you > have. > > They may treat the call with suspiscion. They may go back later and try > to > > figure out why they didn't get what they wanted but they take the call > and > > ask questions later. > > > > So please don't make that assumption. Ysa, we expect nearly all calls > to go > > through a VSP, but the system works if Marc Linsner's proxy in his house > > sends the call to the PSAP. > > > > That's fine. It is just the question what we write into the document. > What is the default behavior? > We sent the calls directly to the PSAP or via the VSP? > > This has impact for the phone BCP document. If you assume that calls are > routed through the VSP then the protocol run by the end point does not > matter too much. > If you assume that the end host MUST be able to route directly to the > PSAP as well then you have to mandate a certain functionality at the end > point. > > So, what behavior do we want? > > >> Having said all that I believe that one important aspect, which is also > >> different to architecturs investigated by other SDOs, is that the PSAP > >> has to support a certain functionality. This functionality is described > >> in the document but might not be too visible to the working group or at > >> least hasn't be advertised a lot. > >> > > Yes, this is true. We could make that more explicit. > > > > > >> I believe we have to indicate quite close what the different entities > >> have to support rather than meshing everything together. This impacts > >> the document structure a bit. > >> > > Yes, we have thought about that a lot, and have had some suggestions in > that > > the direction, the goal being to have all the BCPs for phones in one > place, > > those for the access network in another place, etc. > > > > It's OK to have the required functionality listed in one document even > though they address all the involved parties in the architecture. > > >> Here is a suggested structure for the document: > >> > >> * Introduction > >> > >> Shorten the introduction > >> > >> It contains a lot of info that is already available in the framework. > >> This document has to be read in the context of the architecture anyway. > >> > > We will do that > > > > > >> Btw, the introduction must not use RFC 2119 language. > >> > > Yes > > > > > >> * Terminology > >> > >> Classical RFC boilerplate and pointers to the requirements document. > >> > > > > > > > >> * End Host Profile > >> > >> This section just describes what is absolutely necessary for an end > >> point to support the > >> > >> This is essentially the location part, the LoST part. > >> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. > >> The LoST stuff can be found in Section 6.3. > >> > >> * ISP Profile > >> > >> This is the location part. The server side of Section 4.2. > >> Optionally, LoST may be provided by the ISP. > >> > > You see where the problem is? You have the location part in both End > Host > > and ISP. Same with LoST. > > > > This is the problem with this suggestion. It actually makes as much > sense > > to keep all the location information together as it does to keep all the > end > > host information together. > > > > My best idea to address this is to leave the structure as is, but to > make > > the BCP elements pulled out and labeled as to whom they apply (endpoint, > > VSP, ISP, PSAP). Then, after the functional sections, we can copy the > BCP > > elements (only, not the other text) and sort them by who they apply to. > > > > > > It's not a big problem to consider location aspects at the ISP and at > the end host since the demanded functionality is, to some extend, > different. > In this particular document we, for example, say that the ISP has to > implement one of the location protocols and the client implements all of > them. > > >> * VSP Profile > >> > >> Some parts from Section 5 and Section 6 could go in here. Might want to > >> separate this into a separate sub-section to have a way to reference it > >> from the "End Host Profile" section to say something like > >> "When the end host implements SIP then the VSP might want to use the > >> same functionality already at the client." > >> > >> The detailed considerations about SIP location conveyance are not > >> necessary since they can already be found in the SIP Location > Conveyance > >> document already. > >> > > Actually, I think a lot of this text has to stay as it describes how you > use > > the -conveyance mechanism. We'll take a sharp look at it for deletions. > > > > > >> Section 6.2 does not work with the general IETF emergency architecture, > >> as described in the ECRIT framework document. For example, the proxy > >> does not obtain location information since it cannot do so in the > >> generic case. > >> > > I don't want IETF to be in the position of not supporting proxy > insertion of > > location as, for example, 3GPP does. I think we explicitly allow it but > > explain the difficulties. > > > The problem is that it does not work together with the framework document. > The framework document does not have a case for it. > > It's fine that the SIP Location Conveyance document has something in > there that could potentially be useful for the 3GPP. The interesting > case, however, is that the emergency services architecture of the 3GPP > has the functionality of the P-CSCF and the E-CSCF in the local network > and hence they don't standardize the interaction with the PSAP, unlike > we do because the PSAP in the IETF emergency services architecture might > get the call from an arbitrary entity rather than from the local network > operator. > > > > > > >> Section 8 is also relevant. > >> > >> > >> * PSAP Profile > >> > >> Section 6.5 is relevant but only to the extend where the PSAP operator > >> network faces the outside world. I don't think it is too relevant for > >> this document to talk about PSAP network interal operator, such as > >> transferring a call to another PSAP operator. > >> > > Probably right, but the endpoint requirements to support transfer must > stay > > > That's fine > > >> Section 8 is also relevant. > >> > >> > >> > >> * Security Considerations > >> > >> Don't go too much into the details since we talk about all the stuff in > >> other docs. > >> > > If you say so. I'm not sure we can get away with this. Can we ask you > to > > get a security reviewer assigned sooner rather than later and we can > work > > with him to see what we can accomplish with just references to other > docs? > > > Good idea. We should do that. > > >> The testing section is fine. > >> > > Albeit it mixes endpoint and PSAP BCP statements. > > > >> > >> -- I am not so sure about the location update section. > >> > > There is nothing to reference. It has to be somewhere else, and > referenced > > here, or here. This is a use of presence (and presumably HELD). > > > > > Hmm. I have to re-read that part. > > >> In any case: Try to make the document as short as possible. > >> > > Okay > > > > Thanks for the suggestions > > > > Ciao > Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 18:08:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pnJ-0001PF-8x; Sat, 14 Jul 2007 18:08:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pnH-0001Oz-GV for ecrit@ietf.org; Sat, 14 Jul 2007 18:08:51 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9pnD-00067c-9W for ecrit@ietf.org; Sat, 14 Jul 2007 18:08:51 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6EM8XJM012322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2007 18:08:37 -0400 (EDT) In-Reply-To: <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 18:08:31 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 14, 2007, at 6:01 PM, Brian Rosen wrote: > The text now says that the phone applies normal outbound > processing. That > would mean it sends calls to the VSP. That's what we want. > > Marc's phone would normally send calls to his house proxy. That is > what we > want. > Brian, Note that outbound proxies are NOT mandatory for SIP, whether a VSP is in place or not. I see no reason to change that basic architecture for emergency calls, even if the vast majority of calls do use an outbound proxy (or, in enterprises, just the 'local' proxy.) Do you have a pointer in the SIP documents that mandate an outbound proxy? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 19:26:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9r0k-0007qS-4Z; Sat, 14 Jul 2007 19:26:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9r0i-0007qD-GL for ecrit@ietf.org; Sat, 14 Jul 2007 19:26:48 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9r0e-0007jL-7b for ecrit@ietf.org; Sat, 14 Jul 2007 19:26:48 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I9r0P-0002W8-42; Sat, 14 Jul 2007 18:26:29 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 19:26:40 -0400 Message-ID: <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfGY4R6LAbe0CupTMC6NLgG2Sce6gACi5Sg X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning I said "normal outbound processing". Whatever that is for that phone. If it's configured for an outbound proxy, use that. If it's not, send it to the PSAP directly. I went and looked, and actually, it says: The call would normally be sent to the first hop proxy of the communications service I really do want it to be whatever is normal for that UA. Got a suggested wording? Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, July 14, 2007 6:09 PM > To: Brian Rosen > Cc: ECRIT > Subject: Re: [Ecrit] Phone BCP Draft Comments > > > On Jul 14, 2007, at 6:01 PM, Brian Rosen wrote: > > > The text now says that the phone applies normal outbound > > processing. That > > would mean it sends calls to the VSP. That's what we want. > > > > Marc's phone would normally send calls to his house proxy. That is > > what we > > want. > > > > Brian, > > Note that outbound proxies are NOT mandatory for SIP, whether a VSP > is in place or not. I see no reason to change that basic architecture > for emergency calls, even if the vast majority of calls do use an > outbound proxy (or, in enterprises, just the 'local' proxy.) > > Do you have a pointer in the SIP documents that mandate an outbound > proxy? > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 19:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rMD-0003sk-5p; Sat, 14 Jul 2007 19:49:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rMC-0003rx-OJ for ecrit@ietf.org; Sat, 14 Jul 2007 19:49:00 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9rLx-00071c-H0 for ecrit@ietf.org; Sat, 14 Jul 2007 19:49:00 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6ENm7K1014592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2007 19:48:11 -0400 (EDT) In-Reply-To: <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 19:48:04 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Brian, I would omit anything that could be seen as implying that SIP behavior for emergency calls is different from normal calls, unless it actually is. Thus, I'd simply omit statements such as the one below, since there's no need to repeat what's already documented elsewhere. Also makes the document shorter... Henning On Jul 14, 2007, at 7:26 PM, Brian Rosen wrote: > Henning > > I said "normal outbound processing". Whatever that is for that > phone. If > it's configured for an outbound proxy, use that. If it's not, send > it to > the PSAP directly. > > I went and looked, and actually, it says: > The call would normally be sent to the first hop proxy of the > communications > service > > I really do want it to be whatever is normal for that UA. Got a > suggested > wording? > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 20:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rtF-0002gV-O4; Sat, 14 Jul 2007 20:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9rtE-0002gP-IY for ecrit@ietf.org; Sat, 14 Jul 2007 20:23:08 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9rtA-0000NQ-9q for ecrit@ietf.org; Sat, 14 Jul 2007 20:23:08 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1I9rsu-0006Ux-RD; Sat, 14 Jul 2007 19:22:49 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 20:23:00 -0400 Message-ID: <0e7d01c7c676$4f055aa0$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfGcWfkRtfhv8TASmW6qOVqsgiS0QABMhVA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't like that suggestion because I think some readers would think they SHOULD skip normal outbound processing and send the call directly. I think it would be better to be explicit. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, July 14, 2007 7:48 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Phone BCP Draft Comments > > Brian, > > I would omit anything that could be seen as implying that SIP > behavior for emergency calls is different from normal calls, unless > it actually is. Thus, I'd simply omit statements such as the one > below, since there's no need to repeat what's already documented > elsewhere. Also makes the document shorter... > > Henning > > On Jul 14, 2007, at 7:26 PM, Brian Rosen wrote: > > > Henning > > > > I said "normal outbound processing". Whatever that is for that > > phone. If > > it's configured for an outbound proxy, use that. If it's not, send > > it to > > the PSAP directly. > > > > I went and looked, and actually, it says: > > The call would normally be sent to the first hop proxy of the > > communications > > service > > > > I really do want it to be whatever is normal for that UA. Got a > > suggested > > wording? > > > > Brian > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 14 20:30:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9s0N-0002Pa-ME; Sat, 14 Jul 2007 20:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9s0M-0002PU-Jb for ecrit@ietf.org; Sat, 14 Jul 2007 20:30:30 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9s0I-0000VT-CE for ecrit@ietf.org; Sat, 14 Jul 2007 20:30:30 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6F0UOHL018342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 14 Jul 2007 20:30:25 -0400 (EDT) In-Reply-To: <0e7d01c7c676$4f055aa0$c6e6a8c0@cis.neustar.com> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> <0e7d01c7c676$4f055aa0$c6e6a8c0@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sat, 14 Jul 2007 20:30:21 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just state up front "SIP call processing for emergency calls is exactly the same as for non-emergency calls, except where this document explicitly describes alternate behavior." This should remove all doubt, not just for this case. On Jul 14, 2007, at 8:23 PM, Brian Rosen wrote: > I don't like that suggestion because I think some readers would > think they > SHOULD skip normal outbound processing and send the call directly. > I think > it would be better to be explicit. > > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 04:12:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zCy-0000WK-Ls; Sun, 15 Jul 2007 04:12:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zCx-0000WE-NP for ecrit@ietf.org; Sun, 15 Jul 2007 04:11:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9zCw-0006NH-OG for ecrit@ietf.org; Sun, 15 Jul 2007 04:11:59 -0400 Received: (qmail invoked by alias); 15 Jul 2007 08:11:24 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp038) with SMTP; 15 Jul 2007 10:11:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19rwQM/ez9rXSy//CyXV+gDpgZ/3FUdQovcFQFe0n R7aFcnhJ4GXOwf Message-ID: <4699D6AA.2040104@gmx.net> Date: Sun, 15 Jul 2007 10:11:22 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> In-Reply-To: <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> 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: 23336e92cd9b2f166f17126afcdd84ec Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Brian Rosen wrote: > The text now says that the phone applies normal outbound processing. That > would mean it sends calls to the VSP. That's what we want. > > Marc's phone would normally send calls to his house proxy. That is what we > want. > Typically, it would be the proxy of Marc's VoIP provider. > Let us try my way with the organization and see if it accomplishes what you > want. If it's a mess, I'll look at doing it your way. > > I'll make sure we discuss proxy insertion of location in both -framework and > -phonebcp. I think it is best to state it is acceptable if the limitations > implied (VSP has a relationship with ISP, has a good identifier that ISP can > use) hold. > I don't think we have a place in our current architecture for the proxy insertion for location. We should first discuss that aspect from an architectural point of view. Ciao Hannes > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Saturday, July 14, 2007 5:38 PM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Phone BCP Draft Comments >> >> Hi Brian, >> >> thanks for the quick response. Please see my comments below: >> >> Brian Rosen wrote: >> >>> See in line >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Friday, July 13, 2007 5:11 PM >>>> To: ECRIT >>>> Subject: [Ecrit] Phone BCP Draft Comments >>>> >>>> Hi Brian, >>>> Hi James, >>>> Hi all, >>>> >>>> I like the document, as I expressed several times in the past. >>>> >>>> There are, however, a few issues with it. >>>> >>>> Henning and myself have recently written an ECRIT overview document. >>>> >> See >> >>>> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- >>>> overview-00.txt >>>> >>>> One thing that was quite important for us to highlight was that the >>>> >> IETF >> >>>> emergency service architecture has a very nice property, namely the >>>> >> fact >> >>>> that different VoIP protocols may be supported between the end host and >>>> the VoIP provider. There is no need to implement SIP only. >>>> >>>> Now, this document does not give me the impression that this aspect is >>>> given enough consideration. >>>> >>>> >>> There are two things that came to mind when I read this. One is that >>> >> you >> >>> are right, and we can be more clear that any protocol can be used >>> >> between >> >>> the endpoint and some kind of gateway that interworks to a protocol that >>> >> the >> >>> PSAP implements. >>> >>> The other is that SIP need not be the only protocol the PSAP implements. >>> >>> >> That's certainly true. We do, however, have to start somewhere. We >> cannot describe what Skype protocol features a PSAP has to implement for >> an emergency service scenario. >> >> Hence, we focus only on SIP. That's already enough for a PSAP to >> implement. >> We do, however, only mandate functionality that is absolutely necessary >> for interoperability. >> >> >>> However. There are some requirements on what the protocol needs to do. >>> >> We >> >>> should list them, and I think probably that discussion belongs in >>> -framework. LoST already can return multiple URIs with different >>> >> schemes >> >>> corresponding to what it implements. >>> >>> >>> >> It might be a good idea to state what protocols have to support -- there >> aren't too many things anyway. >> >> >>>> The IETF emergency service architecture realistically requires that the >>>> emergency calls are routed through the VSP in order to get identity >>>> information attached to an emergency call. >>>> >>>> >>> NO!!!! >>> >>> That is NOT true. The PSAPs I work with will take calls that don't come >>> >from a VSP over the internet. >>> >> I guess you need to describe in more detail what you have seen. >> >> >>> They may well have some suspicion on such >>> calls due to the lack of a verifiable identity but they will take the >>> >> call >> >>> anyway. I've had numerous conversations with PSAP people who want to >>> >> make >> >>> sure I understand the "rules" they have (validated location for >>> >> examples). >> >>> When I press them for what they want to do when something goes wrong and >>> >> it >> >>> doesn't happen (like, validation fails, do they want unvalidated >>> >> location or >> >>> no location), they ALWAYS want the call, and they want the data you >>> >> have. >> >>> They may treat the call with suspiscion. They may go back later and try >>> >> to >> >>> figure out why they didn't get what they wanted but they take the call >>> >> and >> >>> ask questions later. >>> >>> So please don't make that assumption. Ysa, we expect nearly all calls >>> >> to go >> >>> through a VSP, but the system works if Marc Linsner's proxy in his house >>> sends the call to the PSAP. >>> >>> >> That's fine. It is just the question what we write into the document. >> What is the default behavior? >> We sent the calls directly to the PSAP or via the VSP? >> >> This has impact for the phone BCP document. If you assume that calls are >> routed through the VSP then the protocol run by the end point does not >> matter too much. >> If you assume that the end host MUST be able to route directly to the >> PSAP as well then you have to mandate a certain functionality at the end >> point. >> >> So, what behavior do we want? >> >> >>>> Having said all that I believe that one important aspect, which is also >>>> different to architecturs investigated by other SDOs, is that the PSAP >>>> has to support a certain functionality. This functionality is described >>>> in the document but might not be too visible to the working group or at >>>> least hasn't be advertised a lot. >>>> >>>> >>> Yes, this is true. We could make that more explicit. >>> >>> >>> >>>> I believe we have to indicate quite close what the different entities >>>> have to support rather than meshing everything together. This impacts >>>> the document structure a bit. >>>> >>>> >>> Yes, we have thought about that a lot, and have had some suggestions in >>> >> that >> >>> the direction, the goal being to have all the BCPs for phones in one >>> >> place, >> >>> those for the access network in another place, etc. >>> >>> >> It's OK to have the required functionality listed in one document even >> though they address all the involved parties in the architecture. >> >> >>>> Here is a suggested structure for the document: >>>> >>>> * Introduction >>>> >>>> Shorten the introduction >>>> >>>> It contains a lot of info that is already available in the framework. >>>> This document has to be read in the context of the architecture anyway. >>>> >>>> >>> We will do that >>> >>> >>> >>>> Btw, the introduction must not use RFC 2119 language. >>>> >>>> >>> Yes >>> >>> >>> >>>> * Terminology >>>> >>>> Classical RFC boilerplate and pointers to the requirements document. >>>> >>>> >>> >>> >>>> * End Host Profile >>>> >>>> This section just describes what is absolutely necessary for an end >>>> point to support the >>>> >>>> This is essentially the location part, the LoST part. >>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. >>>> The LoST stuff can be found in Section 6.3. >>>> >>>> * ISP Profile >>>> >>>> This is the location part. The server side of Section 4.2. >>>> Optionally, LoST may be provided by the ISP. >>>> >>>> >>> You see where the problem is? You have the location part in both End >>> >> Host >> >>> and ISP. Same with LoST. >>> >>> This is the problem with this suggestion. It actually makes as much >>> >> sense >> >>> to keep all the location information together as it does to keep all the >>> >> end >> >>> host information together. >>> >>> My best idea to address this is to leave the structure as is, but to >>> >> make >> >>> the BCP elements pulled out and labeled as to whom they apply (endpoint, >>> VSP, ISP, PSAP). Then, after the functional sections, we can copy the >>> >> BCP >> >>> elements (only, not the other text) and sort them by who they apply to. >>> >>> >>> >> It's not a big problem to consider location aspects at the ISP and at >> the end host since the demanded functionality is, to some extend, >> different. >> In this particular document we, for example, say that the ISP has to >> implement one of the location protocols and the client implements all of >> them. >> >> >>>> * VSP Profile >>>> >>>> Some parts from Section 5 and Section 6 could go in here. Might want to >>>> separate this into a separate sub-section to have a way to reference it >>>> from the "End Host Profile" section to say something like >>>> "When the end host implements SIP then the VSP might want to use the >>>> same functionality already at the client." >>>> >>>> The detailed considerations about SIP location conveyance are not >>>> necessary since they can already be found in the SIP Location >>>> >> Conveyance >> >>>> document already. >>>> >>>> >>> Actually, I think a lot of this text has to stay as it describes how you >>> >> use >> >>> the -conveyance mechanism. We'll take a sharp look at it for deletions. >>> >>> >>> >>>> Section 6.2 does not work with the general IETF emergency architecture, >>>> as described in the ECRIT framework document. For example, the proxy >>>> does not obtain location information since it cannot do so in the >>>> generic case. >>>> >>>> >>> I don't want IETF to be in the position of not supporting proxy >>> >> insertion of >> >>> location as, for example, 3GPP does. I think we explicitly allow it but >>> explain the difficulties. >>> >>> >> The problem is that it does not work together with the framework document. >> The framework document does not have a case for it. >> >> It's fine that the SIP Location Conveyance document has something in >> there that could potentially be useful for the 3GPP. The interesting >> case, however, is that the emergency services architecture of the 3GPP >> has the functionality of the P-CSCF and the E-CSCF in the local network >> and hence they don't standardize the interaction with the PSAP, unlike >> we do because the PSAP in the IETF emergency services architecture might >> get the call from an arbitrary entity rather than from the local network >> operator. >> >> >> >> >>>> Section 8 is also relevant. >>>> >>>> >>>> * PSAP Profile >>>> >>>> Section 6.5 is relevant but only to the extend where the PSAP operator >>>> network faces the outside world. I don't think it is too relevant for >>>> this document to talk about PSAP network interal operator, such as >>>> transferring a call to another PSAP operator. >>>> >>>> >>> Probably right, but the endpoint requirements to support transfer must >>> >> stay >> >> That's fine >> >> >>>> Section 8 is also relevant. >>>> >>>> >>>> >>>> * Security Considerations >>>> >>>> Don't go too much into the details since we talk about all the stuff in >>>> other docs. >>>> >>>> >>> If you say so. I'm not sure we can get away with this. Can we ask you >>> >> to >> >>> get a security reviewer assigned sooner rather than later and we can >>> >> work >> >>> with him to see what we can accomplish with just references to other >>> >> docs? >> >> Good idea. We should do that. >> >> >>>> The testing section is fine. >>>> >>>> >>> Albeit it mixes endpoint and PSAP BCP statements. >>> >>> >>>> -- I am not so sure about the location update section. >>>> >>>> >>> There is nothing to reference. It has to be somewhere else, and >>> >> referenced >> >>> here, or here. This is a use of presence (and presumably HELD). >>> >>> >>> >> Hmm. I have to re-read that part. >> >> >>>> In any case: Try to make the document as short as possible. >>>> >>>> >>> Okay >>> >>> Thanks for the suggestions >>> >>> >> Ciao >> Hannes >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 04:13:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zE6-0002vu-Rn; Sun, 15 Jul 2007 04:13:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zE5-0002pB-F7 for ecrit@ietf.org; Sun, 15 Jul 2007 04:13:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9zE5-0006Ot-0u for ecrit@ietf.org; Sun, 15 Jul 2007 04:13:09 -0400 Received: (qmail invoked by alias); 15 Jul 2007 08:13:07 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp002) with SMTP; 15 Jul 2007 10:13:07 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18CcKErTiwCEPlP4jKjniq2hMlXFy/yxWXl3Y08RO aMv99VlJ3qicBB Message-ID: <4699D711.50103@gmx.net> Date: Sun, 15 Jul 2007 10:13:05 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> 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: 8b30eb7682a596edff707698f4a80f7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, do you think that the emergency call should go directly to the PSAP without traveling through the VSP? Btw, I noticed that we say nothing about NAT traversal in the Phone BCP. That seems to be mandatory functionality, however. Ciao Hannes Henning Schulzrinne wrote: > > On Jul 14, 2007, at 6:01 PM, Brian Rosen wrote: > >> The text now says that the phone applies normal outbound processing. >> That >> would mean it sends calls to the VSP. That's what we want. >> >> Marc's phone would normally send calls to his house proxy. That is >> what we >> want. >> > > Brian, > > Note that outbound proxies are NOT mandatory for SIP, whether a VSP is > in place or not. I see no reason to change that basic architecture for > emergency calls, even if the vast majority of calls do use an outbound > proxy (or, in enterprises, just the 'local' proxy.) > > Do you have a pointer in the SIP documents that mandate an outbound > proxy? > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 04:18:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zIm-0001aV-Sa; Sun, 15 Jul 2007 04:18:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9zIZ-0001VO-5q for ecrit@ietf.org; Sun, 15 Jul 2007 04:17:47 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1I9zIY-0006UZ-Na for ecrit@ietf.org; Sun, 15 Jul 2007 04:17:47 -0400 Received: (qmail invoked by alias); 15 Jul 2007 08:17:29 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp049) with SMTP; 15 Jul 2007 10:17:29 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+xGOs6jE2xkBB23eEFcR/u7avs5ANpfim9t9c/ts NA84efI5Qt/cvE Message-ID: <4699D817.1040607@gmx.net> Date: Sun, 15 Jul 2007 10:17:27 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> 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: 50a516d93fd399dc60588708fd9a3002 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, Hi Henning, this is, however, an important design consideration that would essentially open the door to have absolutely no identity information available for the PSAP. Ciao Hannes Henning Schulzrinne wrote: > Brian, > > I would omit anything that could be seen as implying that SIP behavior > for emergency calls is different from normal calls, unless it actually > is. Thus, I'd simply omit statements such as the one below, since > there's no need to repeat what's already documented elsewhere. Also > makes the document shorter... > > Henning > > On Jul 14, 2007, at 7:26 PM, Brian Rosen wrote: > >> Henning >> >> I said "normal outbound processing". Whatever that is for that >> phone. If >> it's configured for an outbound proxy, use that. If it's not, send >> it to >> the PSAP directly. >> >> I went and looked, and actually, it says: >> The call would normally be sent to the first hop proxy of the >> communications >> service >> >> I really do want it to be whatever is normal for that UA. Got a >> suggested >> wording? >> >> Brian >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 09:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA3zO-0006BK-7Y; Sun, 15 Jul 2007 09:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA3zM-00063O-Mb for ecrit@ietf.org; Sun, 15 Jul 2007 09:18:16 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA3zH-0002xp-TU for ecrit@ietf.org; Sun, 15 Jul 2007 09:18:16 -0400 Received: from [63.243.41.34] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IA3z9-00045m-93; Sun, 15 Jul 2007 08:18:03 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 09:18:10 -0400 Message-ID: <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4699D6AA.2040104@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfGt7wSBMh4KRDwRBajwcDLaf7tDQAKpt/w X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 4de5d7f989d6c039c8b887f1940f36ab Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes I believe your opinion runs counter to consensus, and I'll bring this up for a hum at the meeting. I think most of us think endpoint insertion of location is preferred, but proxy insertion, under the right circumstances, is acceptable. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, July 15, 2007 4:11 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Phone BCP Draft Comments > > Hi Brian, > > Brian Rosen wrote: > > The text now says that the phone applies normal outbound processing. > That > > would mean it sends calls to the VSP. That's what we want. > > > > Marc's phone would normally send calls to his house proxy. That is what > we > > want. > > > Typically, it would be the proxy of Marc's VoIP provider. > > Let us try my way with the organization and see if it accomplishes what > you > > want. If it's a mess, I'll look at doing it your way. > > > > I'll make sure we discuss proxy insertion of location in both -framework > and > > -phonebcp. I think it is best to state it is acceptable if the > limitations > > implied (VSP has a relationship with ISP, has a good identifier that ISP > can > > use) hold. > > > > I don't think we have a place in our current architecture for the proxy > insertion for location. > We should first discuss that aspect from an architectural point of view. > > Ciao > Hannes > > > > Brian > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Saturday, July 14, 2007 5:38 PM > >> To: Brian Rosen > >> Cc: 'ECRIT' > >> Subject: Re: [Ecrit] Phone BCP Draft Comments > >> > >> Hi Brian, > >> > >> thanks for the quick response. Please see my comments below: > >> > >> Brian Rosen wrote: > >> > >>> See in line > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Friday, July 13, 2007 5:11 PM > >>>> To: ECRIT > >>>> Subject: [Ecrit] Phone BCP Draft Comments > >>>> > >>>> Hi Brian, > >>>> Hi James, > >>>> Hi all, > >>>> > >>>> I like the document, as I expressed several times in the past. > >>>> > >>>> There are, however, a few issues with it. > >>>> > >>>> Henning and myself have recently written an ECRIT overview document. > >>>> > >> See > >> > >>>> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- > >>>> overview-00.txt > >>>> > >>>> One thing that was quite important for us to highlight was that the > >>>> > >> IETF > >> > >>>> emergency service architecture has a very nice property, namely the > >>>> > >> fact > >> > >>>> that different VoIP protocols may be supported between the end host > and > >>>> the VoIP provider. There is no need to implement SIP only. > >>>> > >>>> Now, this document does not give me the impression that this aspect > is > >>>> given enough consideration. > >>>> > >>>> > >>> There are two things that came to mind when I read this. One is that > >>> > >> you > >> > >>> are right, and we can be more clear that any protocol can be used > >>> > >> between > >> > >>> the endpoint and some kind of gateway that interworks to a protocol > that > >>> > >> the > >> > >>> PSAP implements. > >>> > >>> The other is that SIP need not be the only protocol the PSAP > implements. > >>> > >>> > >> That's certainly true. We do, however, have to start somewhere. We > >> cannot describe what Skype protocol features a PSAP has to implement > for > >> an emergency service scenario. > >> > >> Hence, we focus only on SIP. That's already enough for a PSAP to > >> implement. > >> We do, however, only mandate functionality that is absolutely necessary > >> for interoperability. > >> > >> > >>> However. There are some requirements on what the protocol needs to do. > >>> > >> We > >> > >>> should list them, and I think probably that discussion belongs in > >>> -framework. LoST already can return multiple URIs with different > >>> > >> schemes > >> > >>> corresponding to what it implements. > >>> > >>> > >>> > >> It might be a good idea to state what protocols have to support -- > there > >> aren't too many things anyway. > >> > >> > >>>> The IETF emergency service architecture realistically requires that > the > >>>> emergency calls are routed through the VSP in order to get identity > >>>> information attached to an emergency call. > >>>> > >>>> > >>> NO!!!! > >>> > >>> That is NOT true. The PSAPs I work with will take calls that don't > come > >>> >from a VSP over the internet. > >>> > >> I guess you need to describe in more detail what you have seen. > >> > >> > >>> They may well have some suspicion on such > >>> calls due to the lack of a verifiable identity but they will take the > >>> > >> call > >> > >>> anyway. I've had numerous conversations with PSAP people who want to > >>> > >> make > >> > >>> sure I understand the "rules" they have (validated location for > >>> > >> examples). > >> > >>> When I press them for what they want to do when something goes wrong > and > >>> > >> it > >> > >>> doesn't happen (like, validation fails, do they want unvalidated > >>> > >> location or > >> > >>> no location), they ALWAYS want the call, and they want the data you > >>> > >> have. > >> > >>> They may treat the call with suspiscion. They may go back later and > try > >>> > >> to > >> > >>> figure out why they didn't get what they wanted but they take the call > >>> > >> and > >> > >>> ask questions later. > >>> > >>> So please don't make that assumption. Ysa, we expect nearly all calls > >>> > >> to go > >> > >>> through a VSP, but the system works if Marc Linsner's proxy in his > house > >>> sends the call to the PSAP. > >>> > >>> > >> That's fine. It is just the question what we write into the document. > >> What is the default behavior? > >> We sent the calls directly to the PSAP or via the VSP? > >> > >> This has impact for the phone BCP document. If you assume that calls > are > >> routed through the VSP then the protocol run by the end point does not > >> matter too much. > >> If you assume that the end host MUST be able to route directly to the > >> PSAP as well then you have to mandate a certain functionality at the > end > >> point. > >> > >> So, what behavior do we want? > >> > >> > >>>> Having said all that I believe that one important aspect, which is > also > >>>> different to architecturs investigated by other SDOs, is that the > PSAP > >>>> has to support a certain functionality. This functionality is > described > >>>> in the document but might not be too visible to the working group or > at > >>>> least hasn't be advertised a lot. > >>>> > >>>> > >>> Yes, this is true. We could make that more explicit. > >>> > >>> > >>> > >>>> I believe we have to indicate quite close what the different entities > >>>> have to support rather than meshing everything together. This impacts > >>>> the document structure a bit. > >>>> > >>>> > >>> Yes, we have thought about that a lot, and have had some suggestions > in > >>> > >> that > >> > >>> the direction, the goal being to have all the BCPs for phones in one > >>> > >> place, > >> > >>> those for the access network in another place, etc. > >>> > >>> > >> It's OK to have the required functionality listed in one document even > >> though they address all the involved parties in the architecture. > >> > >> > >>>> Here is a suggested structure for the document: > >>>> > >>>> * Introduction > >>>> > >>>> Shorten the introduction > >>>> > >>>> It contains a lot of info that is already available in the framework. > >>>> This document has to be read in the context of the architecture > anyway. > >>>> > >>>> > >>> We will do that > >>> > >>> > >>> > >>>> Btw, the introduction must not use RFC 2119 language. > >>>> > >>>> > >>> Yes > >>> > >>> > >>> > >>>> * Terminology > >>>> > >>>> Classical RFC boilerplate and pointers to the requirements document. > >>>> > >>>> > >>> > >>> > >>>> * End Host Profile > >>>> > >>>> This section just describes what is absolutely necessary for an end > >>>> point to support the > >>>> > >>>> This is essentially the location part, the LoST part. > >>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. > >>>> The LoST stuff can be found in Section 6.3. > >>>> > >>>> * ISP Profile > >>>> > >>>> This is the location part. The server side of Section 4.2. > >>>> Optionally, LoST may be provided by the ISP. > >>>> > >>>> > >>> You see where the problem is? You have the location part in both End > >>> > >> Host > >> > >>> and ISP. Same with LoST. > >>> > >>> This is the problem with this suggestion. It actually makes as much > >>> > >> sense > >> > >>> to keep all the location information together as it does to keep all > the > >>> > >> end > >> > >>> host information together. > >>> > >>> My best idea to address this is to leave the structure as is, but to > >>> > >> make > >> > >>> the BCP elements pulled out and labeled as to whom they apply > (endpoint, > >>> VSP, ISP, PSAP). Then, after the functional sections, we can copy the > >>> > >> BCP > >> > >>> elements (only, not the other text) and sort them by who they apply > to. > >>> > >>> > >>> > >> It's not a big problem to consider location aspects at the ISP and at > >> the end host since the demanded functionality is, to some extend, > >> different. > >> In this particular document we, for example, say that the ISP has to > >> implement one of the location protocols and the client implements all > of > >> them. > >> > >> > >>>> * VSP Profile > >>>> > >>>> Some parts from Section 5 and Section 6 could go in here. Might want > to > >>>> separate this into a separate sub-section to have a way to reference > it > >>>> from the "End Host Profile" section to say something like > >>>> "When the end host implements SIP then the VSP might want to use the > >>>> same functionality already at the client." > >>>> > >>>> The detailed considerations about SIP location conveyance are not > >>>> necessary since they can already be found in the SIP Location > >>>> > >> Conveyance > >> > >>>> document already. > >>>> > >>>> > >>> Actually, I think a lot of this text has to stay as it describes how > you > >>> > >> use > >> > >>> the -conveyance mechanism. We'll take a sharp look at it for > deletions. > >>> > >>> > >>> > >>>> Section 6.2 does not work with the general IETF emergency > architecture, > >>>> as described in the ECRIT framework document. For example, the proxy > >>>> does not obtain location information since it cannot do so in the > >>>> generic case. > >>>> > >>>> > >>> I don't want IETF to be in the position of not supporting proxy > >>> > >> insertion of > >> > >>> location as, for example, 3GPP does. I think we explicitly allow it > but > >>> explain the difficulties. > >>> > >>> > >> The problem is that it does not work together with the framework > document. > >> The framework document does not have a case for it. > >> > >> It's fine that the SIP Location Conveyance document has something in > >> there that could potentially be useful for the 3GPP. The interesting > >> case, however, is that the emergency services architecture of the 3GPP > >> has the functionality of the P-CSCF and the E-CSCF in the local network > >> and hence they don't standardize the interaction with the PSAP, unlike > >> we do because the PSAP in the IETF emergency services architecture > might > >> get the call from an arbitrary entity rather than from the local > network > >> operator. > >> > >> > >> > >> > >>>> Section 8 is also relevant. > >>>> > >>>> > >>>> * PSAP Profile > >>>> > >>>> Section 6.5 is relevant but only to the extend where the PSAP > operator > >>>> network faces the outside world. I don't think it is too relevant for > >>>> this document to talk about PSAP network interal operator, such as > >>>> transferring a call to another PSAP operator. > >>>> > >>>> > >>> Probably right, but the endpoint requirements to support transfer must > >>> > >> stay > >> > >> That's fine > >> > >> > >>>> Section 8 is also relevant. > >>>> > >>>> > >>>> > >>>> * Security Considerations > >>>> > >>>> Don't go too much into the details since we talk about all the stuff > in > >>>> other docs. > >>>> > >>>> > >>> If you say so. I'm not sure we can get away with this. Can we ask > you > >>> > >> to > >> > >>> get a security reviewer assigned sooner rather than later and we can > >>> > >> work > >> > >>> with him to see what we can accomplish with just references to other > >>> > >> docs? > >> > >> Good idea. We should do that. > >> > >> > >>>> The testing section is fine. > >>>> > >>>> > >>> Albeit it mixes endpoint and PSAP BCP statements. > >>> > >>> > >>>> -- I am not so sure about the location update section. > >>>> > >>>> > >>> There is nothing to reference. It has to be somewhere else, and > >>> > >> referenced > >> > >>> here, or here. This is a use of presence (and presumably HELD). > >>> > >>> > >>> > >> Hmm. I have to re-read that part. > >> > >> > >>>> In any case: Try to make the document as short as possible. > >>>> > >>>> > >>> Okay > >>> > >>> Thanks for the suggestions > >>> > >>> > >> Ciao > >> Hannes > >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 09:21:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA42G-0007vz-HG; Sun, 15 Jul 2007 09:21:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA42F-0007vu-7y for ecrit@ietf.org; Sun, 15 Jul 2007 09:21:15 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA420-0001Al-0R for ecrit@ietf.org; Sun, 15 Jul 2007 09:21:15 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FDKOss025198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 09:20:24 -0400 (EDT) In-Reply-To: <4699D817.1040607@gmx.net> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <0e7601c7c66e$70398af0$c6e6a8c0@cis.neustar.com> <4699D817.1040607@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <691DE3BC-3E80-4F3D-9417-EF8AF42A84D1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 09:20:19 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The lack of identity information doesn't really change whether Marc uses his home proxy or not. I think this is the case where we reach the limits of what an IETF BCP can do. Something like "you should be going through a proxy that can assert your identity and is known to the PSAP/widely known" might be nice, but this is pretty vague. I suspect that the necessity of spam filtering will generally have this result, even for non- emergency calls, but this seems like something that's better addressed by other standards bodies, such as NENA, who can take local conditions and laws into account. The RIAA/MPAA seem to have no problem using IP address information to drag people into court for a civil matter; I suspect the same will be true in the absence of authentication for criminal offenses such as making a false emergency call. Henning On Jul 15, 2007, at 4:17 AM, Hannes Tschofenig wrote: > Hi Brian, > Hi Henning, > > this is, however, an important design consideration that would > essentially open the door to have absolutely no identity > information available for the PSAP. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 09:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA48A-0007Gg-Op; Sun, 15 Jul 2007 09:27:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA489-0007Ga-GZ for ecrit@ietf.org; Sun, 15 Jul 2007 09:27:21 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA485-0003CJ-7C for ecrit@ietf.org; Sun, 15 Jul 2007 09:27:21 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FDR1gd007064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 09:27:10 -0400 (EDT) In-Reply-To: <4699D711.50103@gmx.net> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D711.50103@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 09:26:22 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 15, 2007, at 4:13 AM, Hannes Tschofenig wrote: > Henning, do you think that the emergency call should go directly to > the PSAP without traveling through the VSP? > An emergency call should behave like any other SIP call from that end system. If the device uses a proxy to place calls to grandma, it should use that same proxy to reach 911. If it reaches destinations directly, it should do the same thing for emergency calls. This is far more likely to work than special-casing emergency calls. (I realize that the unauthenticated network access case is an unfortunate exception, but it should remain that.) > Btw, I noticed that we say nothing about NAT traversal in the Phone > BCP. That seems to be mandatory functionality, however. > We don't want to write a "How to deploy SIP" manual in ECRIT. I think you recently suggested trimming the document size; filling it with boilerplate and bromides just obscures the important parts. "Traverse NATs" is not testable behavior, given that there is no solution that can be guaranteed to work for all NATs under all circumstances. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 09:49:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4Tn-0006gi-Hn; Sun, 15 Jul 2007 09:49:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4Tl-0006gL-KV for ecrit@ietf.org; Sun, 15 Jul 2007 09:49:41 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IA4Tk-0001jl-I1 for ecrit@ietf.org; Sun, 15 Jul 2007 09:49:41 -0400 Received: (qmail invoked by alias); 15 Jul 2007 13:49:06 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp003) with SMTP; 15 Jul 2007 15:49:06 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19R5UoZWR1RPXIn8rMefVwPerBtplyuVOo3RKkf72 D5V0VKbbWOWdKo Message-ID: <469A25CF.5070302@gmx.net> Date: Sun, 15 Jul 2007 15:49:03 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> In-Reply-To: <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> 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: d3308915082aec5bdcb405956a0eb0ae Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Brian, sure that's fine. But the problem is the following: What proxy should add location information other than a proxy in the access network. So far, such a proxy does not exist in our emergency services architecture. Right? Ciao Hannes Brian Rosen wrote: > Hannes > > I believe your opinion runs counter to consensus, and I'll bring this up for > a hum at the meeting. I think most of us think endpoint insertion of > location is preferred, but proxy insertion, under the right circumstances, > is acceptable. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Sunday, July 15, 2007 4:11 AM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Phone BCP Draft Comments >> >> Hi Brian, >> >> Brian Rosen wrote: >> >>> The text now says that the phone applies normal outbound processing. >>> >> That >> >>> would mean it sends calls to the VSP. That's what we want. >>> >>> Marc's phone would normally send calls to his house proxy. That is what >>> >> we >> >>> want. >>> >>> >> Typically, it would be the proxy of Marc's VoIP provider. >> >>> Let us try my way with the organization and see if it accomplishes what >>> >> you >> >>> want. If it's a mess, I'll look at doing it your way. >>> >>> I'll make sure we discuss proxy insertion of location in both -framework >>> >> and >> >>> -phonebcp. I think it is best to state it is acceptable if the >>> >> limitations >> >>> implied (VSP has a relationship with ISP, has a good identifier that ISP >>> >> can >> >>> use) hold. >>> >>> >> I don't think we have a place in our current architecture for the proxy >> insertion for location. >> We should first discuss that aspect from an architectural point of view. >> >> Ciao >> Hannes >> >> >> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Saturday, July 14, 2007 5:38 PM >>>> To: Brian Rosen >>>> Cc: 'ECRIT' >>>> Subject: Re: [Ecrit] Phone BCP Draft Comments >>>> >>>> Hi Brian, >>>> >>>> thanks for the quick response. Please see my comments below: >>>> >>>> Brian Rosen wrote: >>>> >>>> >>>>> See in line >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Friday, July 13, 2007 5:11 PM >>>>>> To: ECRIT >>>>>> Subject: [Ecrit] Phone BCP Draft Comments >>>>>> >>>>>> Hi Brian, >>>>>> Hi James, >>>>>> Hi all, >>>>>> >>>>>> I like the document, as I expressed several times in the past. >>>>>> >>>>>> There are, however, a few issues with it. >>>>>> >>>>>> Henning and myself have recently written an ECRIT overview document. >>>>>> >>>>>> >>>> See >>>> >>>> >>>>>> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- >>>>>> overview-00.txt >>>>>> >>>>>> One thing that was quite important for us to highlight was that the >>>>>> >>>>>> >>>> IETF >>>> >>>> >>>>>> emergency service architecture has a very nice property, namely the >>>>>> >>>>>> >>>> fact >>>> >>>> >>>>>> that different VoIP protocols may be supported between the end host >>>>>> >> and >> >>>>>> the VoIP provider. There is no need to implement SIP only. >>>>>> >>>>>> Now, this document does not give me the impression that this aspect >>>>>> >> is >> >>>>>> given enough consideration. >>>>>> >>>>>> >>>>>> >>>>> There are two things that came to mind when I read this. One is that >>>>> >>>>> >>>> you >>>> >>>> >>>>> are right, and we can be more clear that any protocol can be used >>>>> >>>>> >>>> between >>>> >>>> >>>>> the endpoint and some kind of gateway that interworks to a protocol >>>>> >> that >> >>>> the >>>> >>>> >>>>> PSAP implements. >>>>> >>>>> The other is that SIP need not be the only protocol the PSAP >>>>> >> implements. >> >>>>> >>>> That's certainly true. We do, however, have to start somewhere. We >>>> cannot describe what Skype protocol features a PSAP has to implement >>>> >> for >> >>>> an emergency service scenario. >>>> >>>> Hence, we focus only on SIP. That's already enough for a PSAP to >>>> implement. >>>> We do, however, only mandate functionality that is absolutely necessary >>>> for interoperability. >>>> >>>> >>>> >>>>> However. There are some requirements on what the protocol needs to do. >>>>> >>>>> >>>> We >>>> >>>> >>>>> should list them, and I think probably that discussion belongs in >>>>> -framework. LoST already can return multiple URIs with different >>>>> >>>>> >>>> schemes >>>> >>>> >>>>> corresponding to what it implements. >>>>> >>>>> >>>>> >>>>> >>>> It might be a good idea to state what protocols have to support -- >>>> >> there >> >>>> aren't too many things anyway. >>>> >>>> >>>> >>>>>> The IETF emergency service architecture realistically requires that >>>>>> >> the >> >>>>>> emergency calls are routed through the VSP in order to get identity >>>>>> information attached to an emergency call. >>>>>> >>>>>> >>>>>> >>>>> NO!!!! >>>>> >>>>> That is NOT true. The PSAPs I work with will take calls that don't >>>>> >> come >> >>>>> >from a VSP over the internet. >>>>> >>>>> >>>> I guess you need to describe in more detail what you have seen. >>>> >>>> >>>> >>>>> They may well have some suspicion on such >>>>> calls due to the lack of a verifiable identity but they will take the >>>>> >>>>> >>>> call >>>> >>>> >>>>> anyway. I've had numerous conversations with PSAP people who want to >>>>> >>>>> >>>> make >>>> >>>> >>>>> sure I understand the "rules" they have (validated location for >>>>> >>>>> >>>> examples). >>>> >>>> >>>>> When I press them for what they want to do when something goes wrong >>>>> >> and >> >>>> it >>>> >>>> >>>>> doesn't happen (like, validation fails, do they want unvalidated >>>>> >>>>> >>>> location or >>>> >>>> >>>>> no location), they ALWAYS want the call, and they want the data you >>>>> >>>>> >>>> have. >>>> >>>> >>>>> They may treat the call with suspiscion. They may go back later and >>>>> >> try >> >>>> to >>>> >>>> >>>>> figure out why they didn't get what they wanted but they take the call >>>>> >>>>> >>>> and >>>> >>>> >>>>> ask questions later. >>>>> >>>>> So please don't make that assumption. Ysa, we expect nearly all calls >>>>> >>>>> >>>> to go >>>> >>>> >>>>> through a VSP, but the system works if Marc Linsner's proxy in his >>>>> >> house >> >>>>> sends the call to the PSAP. >>>>> >>>>> >>>>> >>>> That's fine. It is just the question what we write into the document. >>>> What is the default behavior? >>>> We sent the calls directly to the PSAP or via the VSP? >>>> >>>> This has impact for the phone BCP document. If you assume that calls >>>> >> are >> >>>> routed through the VSP then the protocol run by the end point does not >>>> matter too much. >>>> If you assume that the end host MUST be able to route directly to the >>>> PSAP as well then you have to mandate a certain functionality at the >>>> >> end >> >>>> point. >>>> >>>> So, what behavior do we want? >>>> >>>> >>>> >>>>>> Having said all that I believe that one important aspect, which is >>>>>> >> also >> >>>>>> different to architecturs investigated by other SDOs, is that the >>>>>> >> PSAP >> >>>>>> has to support a certain functionality. This functionality is >>>>>> >> described >> >>>>>> in the document but might not be too visible to the working group or >>>>>> >> at >> >>>>>> least hasn't be advertised a lot. >>>>>> >>>>>> >>>>>> >>>>> Yes, this is true. We could make that more explicit. >>>>> >>>>> >>>>> >>>>> >>>>>> I believe we have to indicate quite close what the different entities >>>>>> have to support rather than meshing everything together. This impacts >>>>>> the document structure a bit. >>>>>> >>>>>> >>>>>> >>>>> Yes, we have thought about that a lot, and have had some suggestions >>>>> >> in >> >>>> that >>>> >>>> >>>>> the direction, the goal being to have all the BCPs for phones in one >>>>> >>>>> >>>> place, >>>> >>>> >>>>> those for the access network in another place, etc. >>>>> >>>>> >>>>> >>>> It's OK to have the required functionality listed in one document even >>>> though they address all the involved parties in the architecture. >>>> >>>> >>>> >>>>>> Here is a suggested structure for the document: >>>>>> >>>>>> * Introduction >>>>>> >>>>>> Shorten the introduction >>>>>> >>>>>> It contains a lot of info that is already available in the framework. >>>>>> This document has to be read in the context of the architecture >>>>>> >> anyway. >> >>>>>> >>>>> We will do that >>>>> >>>>> >>>>> >>>>> >>>>>> Btw, the introduction must not use RFC 2119 language. >>>>>> >>>>>> >>>>>> >>>>> Yes >>>>> >>>>> >>>>> >>>>> >>>>>> * Terminology >>>>>> >>>>>> Classical RFC boilerplate and pointers to the requirements document. >>>>>> >>>>>> >>>>>> >>>>> >>>>>> * End Host Profile >>>>>> >>>>>> This section just describes what is absolutely necessary for an end >>>>>> point to support the >>>>>> >>>>>> This is essentially the location part, the LoST part. >>>>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. >>>>>> The LoST stuff can be found in Section 6.3. >>>>>> >>>>>> * ISP Profile >>>>>> >>>>>> This is the location part. The server side of Section 4.2. >>>>>> Optionally, LoST may be provided by the ISP. >>>>>> >>>>>> >>>>>> >>>>> You see where the problem is? You have the location part in both End >>>>> >>>>> >>>> Host >>>> >>>> >>>>> and ISP. Same with LoST. >>>>> >>>>> This is the problem with this suggestion. It actually makes as much >>>>> >>>>> >>>> sense >>>> >>>> >>>>> to keep all the location information together as it does to keep all >>>>> >> the >> >>>> end >>>> >>>> >>>>> host information together. >>>>> >>>>> My best idea to address this is to leave the structure as is, but to >>>>> >>>>> >>>> make >>>> >>>> >>>>> the BCP elements pulled out and labeled as to whom they apply >>>>> >> (endpoint, >> >>>>> VSP, ISP, PSAP). Then, after the functional sections, we can copy the >>>>> >>>>> >>>> BCP >>>> >>>> >>>>> elements (only, not the other text) and sort them by who they apply >>>>> >> to. >> >>>>> >>>>> >>>> It's not a big problem to consider location aspects at the ISP and at >>>> the end host since the demanded functionality is, to some extend, >>>> different. >>>> In this particular document we, for example, say that the ISP has to >>>> implement one of the location protocols and the client implements all >>>> >> of >> >>>> them. >>>> >>>> >>>> >>>>>> * VSP Profile >>>>>> >>>>>> Some parts from Section 5 and Section 6 could go in here. Might want >>>>>> >> to >> >>>>>> separate this into a separate sub-section to have a way to reference >>>>>> >> it >> >>>>>> from the "End Host Profile" section to say something like >>>>>> "When the end host implements SIP then the VSP might want to use the >>>>>> same functionality already at the client." >>>>>> >>>>>> The detailed considerations about SIP location conveyance are not >>>>>> necessary since they can already be found in the SIP Location >>>>>> >>>>>> >>>> Conveyance >>>> >>>> >>>>>> document already. >>>>>> >>>>>> >>>>>> >>>>> Actually, I think a lot of this text has to stay as it describes how >>>>> >> you >> >>>> use >>>> >>>> >>>>> the -conveyance mechanism. We'll take a sharp look at it for >>>>> >> deletions. >> >>>>> >>>>> >>>>>> Section 6.2 does not work with the general IETF emergency >>>>>> >> architecture, >> >>>>>> as described in the ECRIT framework document. For example, the proxy >>>>>> does not obtain location information since it cannot do so in the >>>>>> generic case. >>>>>> >>>>>> >>>>>> >>>>> I don't want IETF to be in the position of not supporting proxy >>>>> >>>>> >>>> insertion of >>>> >>>> >>>>> location as, for example, 3GPP does. I think we explicitly allow it >>>>> >> but >> >>>>> explain the difficulties. >>>>> >>>>> >>>>> >>>> The problem is that it does not work together with the framework >>>> >> document. >> >>>> The framework document does not have a case for it. >>>> >>>> It's fine that the SIP Location Conveyance document has something in >>>> there that could potentially be useful for the 3GPP. The interesting >>>> case, however, is that the emergency services architecture of the 3GPP >>>> has the functionality of the P-CSCF and the E-CSCF in the local network >>>> and hence they don't standardize the interaction with the PSAP, unlike >>>> we do because the PSAP in the IETF emergency services architecture >>>> >> might >> >>>> get the call from an arbitrary entity rather than from the local >>>> >> network >> >>>> operator. >>>> >>>> >>>> >>>> >>>> >>>>>> Section 8 is also relevant. >>>>>> >>>>>> >>>>>> * PSAP Profile >>>>>> >>>>>> Section 6.5 is relevant but only to the extend where the PSAP >>>>>> >> operator >> >>>>>> network faces the outside world. I don't think it is too relevant for >>>>>> this document to talk about PSAP network interal operator, such as >>>>>> transferring a call to another PSAP operator. >>>>>> >>>>>> >>>>>> >>>>> Probably right, but the endpoint requirements to support transfer must >>>>> >>>>> >>>> stay >>>> >>>> That's fine >>>> >>>> >>>> >>>>>> Section 8 is also relevant. >>>>>> >>>>>> >>>>>> >>>>>> * Security Considerations >>>>>> >>>>>> Don't go too much into the details since we talk about all the stuff >>>>>> >> in >> >>>>>> other docs. >>>>>> >>>>>> >>>>>> >>>>> If you say so. I'm not sure we can get away with this. Can we ask >>>>> >> you >> >>>> to >>>> >>>> >>>>> get a security reviewer assigned sooner rather than later and we can >>>>> >>>>> >>>> work >>>> >>>> >>>>> with him to see what we can accomplish with just references to other >>>>> >>>>> >>>> docs? >>>> >>>> Good idea. We should do that. >>>> >>>> >>>> >>>>>> The testing section is fine. >>>>>> >>>>>> >>>>>> >>>>> Albeit it mixes endpoint and PSAP BCP statements. >>>>> >>>>> >>>>> >>>>>> -- I am not so sure about the location update section. >>>>>> >>>>>> >>>>>> >>>>> There is nothing to reference. It has to be somewhere else, and >>>>> >>>>> >>>> referenced >>>> >>>> >>>>> here, or here. This is a use of presence (and presumably HELD). >>>>> >>>>> >>>>> >>>>> >>>> Hmm. I have to re-read that part. >>>> >>>> >>>> >>>>>> In any case: Try to make the document as short as possible. >>>>>> >>>>>> >>>>>> >>>>> Okay >>>>> >>>>> Thanks for the suggestions >>>>> >>>>> >>>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4he-0007VS-V6; Sun, 15 Jul 2007 10:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4he-0007VN-D8 for ecrit@ietf.org; Sun, 15 Jul 2007 10:04:02 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IA4hZ-00041D-VO for ecrit@ietf.org; Sun, 15 Jul 2007 10:04:02 -0400 Received: (qmail invoked by alias); 15 Jul 2007 14:03:56 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp058) with SMTP; 15 Jul 2007 16:03:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19zGgBQmypz8i8QsPVnSaQ97gCes8FfqhYza6j7PS Nqhu1vnXbY/zjQ Message-ID: <469A2949.50904@gmx.net> Date: Sun, 15 Jul 2007 16:03:53 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D711.50103@gmx.net> 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: c1c65599517f9ac32519d043c37c5336 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > > On Jul 15, 2007, at 4:13 AM, Hannes Tschofenig wrote: > >> Henning, do you think that the emergency call should go directly to >> the PSAP without traveling through the VSP? >> > > An emergency call should behave like any other SIP call from that end > system. If the device uses a proxy to place calls to grandma, it > should use that same proxy to reach 911. If it reaches destinations > directly, it should do the same thing for emergency calls. This is far > more likely to work than special-casing emergency calls. (I realize > that the unauthenticated network access case is an unfortunate > exception, but it should remain that.) > I agree; that's a nice property. But it is quite likely that systems that provide some level of robustness also route calls through their VSP rather than sending them directly to some entities. > >> Btw, I noticed that we say nothing about NAT traversal in the Phone >> BCP. That seems to be mandatory functionality, however. >> > > We don't want to write a "How to deploy SIP" manual in ECRIT. I think > you recently suggested trimming the document size; filling it with > boilerplate and bromides just obscures the important parts. "Traverse > NATs" is not testable behavior, given that there is no solution that > can be guaranteed to work for all NATs under all circumstances. Consider your previous statement: Emergency calls should be sent directly to the PSAP without routing them through the VSP. Now, consider a DSL network that typically has a NAT box in your home network. How likely is it that this stuff works without any statement about functionality that has to be available for the end point and the PSAP with regard to NAT traversal? Ciao Hannes > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4op-0007ks-Hs; Sun, 15 Jul 2007 10:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4op-0007kX-54 for ecrit@ietf.org; Sun, 15 Jul 2007 10:11:27 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA4ol-00047b-CN for ecrit@ietf.org; Sun, 15 Jul 2007 10:11:27 -0400 Received: from [63.243.41.34] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IA4ob-0002Ei-OZ; Sun, 15 Jul 2007 09:11:14 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 10:11:21 -0400 Message-ID: <0f1f01c7c6ea$05ba2280$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <469A25CF.5070302@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfG5ubIBw0+w2bXTLW/C/IeVAdqQQAAu1VA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That is up to the VSP. In the 3GPP case, they send emergency calls to the E-CSCF. Others may do it on the first hop outbound (what would be the P-CSCF). I don't think we care, and I don't think we even discuss it. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, July 15, 2007 9:49 AM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Phone BCP Draft Comments > > Hi Brian, > > sure that's fine. But the problem is the following: What proxy should > add location information other than a proxy in the access network. > So far, such a proxy does not exist in our emergency services > architecture. Right? > > Ciao > Hannes > > Brian Rosen wrote: > > Hannes > > > > I believe your opinion runs counter to consensus, and I'll bring this up > for > > a hum at the meeting. I think most of us think endpoint insertion of > > location is preferred, but proxy insertion, under the right > circumstances, > > is acceptable. > > > > Brian > > > > > >> -----Original Message----- > >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Sunday, July 15, 2007 4:11 AM > >> To: Brian Rosen > >> Cc: 'ECRIT' > >> Subject: Re: [Ecrit] Phone BCP Draft Comments > >> > >> Hi Brian, > >> > >> Brian Rosen wrote: > >> > >>> The text now says that the phone applies normal outbound processing. > >>> > >> That > >> > >>> would mean it sends calls to the VSP. That's what we want. > >>> > >>> Marc's phone would normally send calls to his house proxy. That is > what > >>> > >> we > >> > >>> want. > >>> > >>> > >> Typically, it would be the proxy of Marc's VoIP provider. > >> > >>> Let us try my way with the organization and see if it accomplishes > what > >>> > >> you > >> > >>> want. If it's a mess, I'll look at doing it your way. > >>> > >>> I'll make sure we discuss proxy insertion of location in both - > framework > >>> > >> and > >> > >>> -phonebcp. I think it is best to state it is acceptable if the > >>> > >> limitations > >> > >>> implied (VSP has a relationship with ISP, has a good identifier that > ISP > >>> > >> can > >> > >>> use) hold. > >>> > >>> > >> I don't think we have a place in our current architecture for the proxy > >> insertion for location. > >> We should first discuss that aspect from an architectural point of > view. > >> > >> Ciao > >> Hannes > >> > >> > >> > >>> Brian > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>> Sent: Saturday, July 14, 2007 5:38 PM > >>>> To: Brian Rosen > >>>> Cc: 'ECRIT' > >>>> Subject: Re: [Ecrit] Phone BCP Draft Comments > >>>> > >>>> Hi Brian, > >>>> > >>>> thanks for the quick response. Please see my comments below: > >>>> > >>>> Brian Rosen wrote: > >>>> > >>>> > >>>>> See in line > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>>>>> Sent: Friday, July 13, 2007 5:11 PM > >>>>>> To: ECRIT > >>>>>> Subject: [Ecrit] Phone BCP Draft Comments > >>>>>> > >>>>>> Hi Brian, > >>>>>> Hi James, > >>>>>> Hi all, > >>>>>> > >>>>>> I like the document, as I expressed several times in the past. > >>>>>> > >>>>>> There are, however, a few issues with it. > >>>>>> > >>>>>> Henning and myself have recently written an ECRIT overview > document. > >>>>>> > >>>>>> > >>>> See > >>>> > >>>> > >>>>>> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- > >>>>>> overview-00.txt > >>>>>> > >>>>>> One thing that was quite important for us to highlight was that the > >>>>>> > >>>>>> > >>>> IETF > >>>> > >>>> > >>>>>> emergency service architecture has a very nice property, namely the > >>>>>> > >>>>>> > >>>> fact > >>>> > >>>> > >>>>>> that different VoIP protocols may be supported between the end host > >>>>>> > >> and > >> > >>>>>> the VoIP provider. There is no need to implement SIP only. > >>>>>> > >>>>>> Now, this document does not give me the impression that this aspect > >>>>>> > >> is > >> > >>>>>> given enough consideration. > >>>>>> > >>>>>> > >>>>>> > >>>>> There are two things that came to mind when I read this. One is > that > >>>>> > >>>>> > >>>> you > >>>> > >>>> > >>>>> are right, and we can be more clear that any protocol can be used > >>>>> > >>>>> > >>>> between > >>>> > >>>> > >>>>> the endpoint and some kind of gateway that interworks to a protocol > >>>>> > >> that > >> > >>>> the > >>>> > >>>> > >>>>> PSAP implements. > >>>>> > >>>>> The other is that SIP need not be the only protocol the PSAP > >>>>> > >> implements. > >> > >>>>> > >>>> That's certainly true. We do, however, have to start somewhere. We > >>>> cannot describe what Skype protocol features a PSAP has to implement > >>>> > >> for > >> > >>>> an emergency service scenario. > >>>> > >>>> Hence, we focus only on SIP. That's already enough for a PSAP to > >>>> implement. > >>>> We do, however, only mandate functionality that is absolutely > necessary > >>>> for interoperability. > >>>> > >>>> > >>>> > >>>>> However. There are some requirements on what the protocol needs to > do. > >>>>> > >>>>> > >>>> We > >>>> > >>>> > >>>>> should list them, and I think probably that discussion belongs in > >>>>> -framework. LoST already can return multiple URIs with different > >>>>> > >>>>> > >>>> schemes > >>>> > >>>> > >>>>> corresponding to what it implements. > >>>>> > >>>>> > >>>>> > >>>>> > >>>> It might be a good idea to state what protocols have to support -- > >>>> > >> there > >> > >>>> aren't too many things anyway. > >>>> > >>>> > >>>> > >>>>>> The IETF emergency service architecture realistically requires that > >>>>>> > >> the > >> > >>>>>> emergency calls are routed through the VSP in order to get identity > >>>>>> information attached to an emergency call. > >>>>>> > >>>>>> > >>>>>> > >>>>> NO!!!! > >>>>> > >>>>> That is NOT true. The PSAPs I work with will take calls that don't > >>>>> > >> come > >> > >>>>> >from a VSP over the internet. > >>>>> > >>>>> > >>>> I guess you need to describe in more detail what you have seen. > >>>> > >>>> > >>>> > >>>>> They may well have some suspicion on such > >>>>> calls due to the lack of a verifiable identity but they will take > the > >>>>> > >>>>> > >>>> call > >>>> > >>>> > >>>>> anyway. I've had numerous conversations with PSAP people who want > to > >>>>> > >>>>> > >>>> make > >>>> > >>>> > >>>>> sure I understand the "rules" they have (validated location for > >>>>> > >>>>> > >>>> examples). > >>>> > >>>> > >>>>> When I press them for what they want to do when something goes wrong > >>>>> > >> and > >> > >>>> it > >>>> > >>>> > >>>>> doesn't happen (like, validation fails, do they want unvalidated > >>>>> > >>>>> > >>>> location or > >>>> > >>>> > >>>>> no location), they ALWAYS want the call, and they want the data you > >>>>> > >>>>> > >>>> have. > >>>> > >>>> > >>>>> They may treat the call with suspiscion. They may go back later and > >>>>> > >> try > >> > >>>> to > >>>> > >>>> > >>>>> figure out why they didn't get what they wanted but they take the > call > >>>>> > >>>>> > >>>> and > >>>> > >>>> > >>>>> ask questions later. > >>>>> > >>>>> So please don't make that assumption. Ysa, we expect nearly all > calls > >>>>> > >>>>> > >>>> to go > >>>> > >>>> > >>>>> through a VSP, but the system works if Marc Linsner's proxy in his > >>>>> > >> house > >> > >>>>> sends the call to the PSAP. > >>>>> > >>>>> > >>>>> > >>>> That's fine. It is just the question what we write into the document. > >>>> What is the default behavior? > >>>> We sent the calls directly to the PSAP or via the VSP? > >>>> > >>>> This has impact for the phone BCP document. If you assume that calls > >>>> > >> are > >> > >>>> routed through the VSP then the protocol run by the end point does > not > >>>> matter too much. > >>>> If you assume that the end host MUST be able to route directly to the > >>>> PSAP as well then you have to mandate a certain functionality at the > >>>> > >> end > >> > >>>> point. > >>>> > >>>> So, what behavior do we want? > >>>> > >>>> > >>>> > >>>>>> Having said all that I believe that one important aspect, which is > >>>>>> > >> also > >> > >>>>>> different to architecturs investigated by other SDOs, is that the > >>>>>> > >> PSAP > >> > >>>>>> has to support a certain functionality. This functionality is > >>>>>> > >> described > >> > >>>>>> in the document but might not be too visible to the working group > or > >>>>>> > >> at > >> > >>>>>> least hasn't be advertised a lot. > >>>>>> > >>>>>> > >>>>>> > >>>>> Yes, this is true. We could make that more explicit. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> I believe we have to indicate quite close what the different > entities > >>>>>> have to support rather than meshing everything together. This > impacts > >>>>>> the document structure a bit. > >>>>>> > >>>>>> > >>>>>> > >>>>> Yes, we have thought about that a lot, and have had some suggestions > >>>>> > >> in > >> > >>>> that > >>>> > >>>> > >>>>> the direction, the goal being to have all the BCPs for phones in one > >>>>> > >>>>> > >>>> place, > >>>> > >>>> > >>>>> those for the access network in another place, etc. > >>>>> > >>>>> > >>>>> > >>>> It's OK to have the required functionality listed in one document > even > >>>> though they address all the involved parties in the architecture. > >>>> > >>>> > >>>> > >>>>>> Here is a suggested structure for the document: > >>>>>> > >>>>>> * Introduction > >>>>>> > >>>>>> Shorten the introduction > >>>>>> > >>>>>> It contains a lot of info that is already available in the > framework. > >>>>>> This document has to be read in the context of the architecture > >>>>>> > >> anyway. > >> > >>>>>> > >>>>> We will do that > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> Btw, the introduction must not use RFC 2119 language. > >>>>>> > >>>>>> > >>>>>> > >>>>> Yes > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> * Terminology > >>>>>> > >>>>>> Classical RFC boilerplate and pointers to the requirements > document. > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>>> * End Host Profile > >>>>>> > >>>>>> This section just describes what is absolutely necessary for an end > >>>>>> point to support the > >>>>>> > >>>>>> This is essentially the location part, the LoST part. > >>>>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. > >>>>>> The LoST stuff can be found in Section 6.3. > >>>>>> > >>>>>> * ISP Profile > >>>>>> > >>>>>> This is the location part. The server side of Section 4.2. > >>>>>> Optionally, LoST may be provided by the ISP. > >>>>>> > >>>>>> > >>>>>> > >>>>> You see where the problem is? You have the location part in both > End > >>>>> > >>>>> > >>>> Host > >>>> > >>>> > >>>>> and ISP. Same with LoST. > >>>>> > >>>>> This is the problem with this suggestion. It actually makes as much > >>>>> > >>>>> > >>>> sense > >>>> > >>>> > >>>>> to keep all the location information together as it does to keep all > >>>>> > >> the > >> > >>>> end > >>>> > >>>> > >>>>> host information together. > >>>>> > >>>>> My best idea to address this is to leave the structure as is, but to > >>>>> > >>>>> > >>>> make > >>>> > >>>> > >>>>> the BCP elements pulled out and labeled as to whom they apply > >>>>> > >> (endpoint, > >> > >>>>> VSP, ISP, PSAP). Then, after the functional sections, we can copy > the > >>>>> > >>>>> > >>>> BCP > >>>> > >>>> > >>>>> elements (only, not the other text) and sort them by who they apply > >>>>> > >> to. > >> > >>>>> > >>>>> > >>>> It's not a big problem to consider location aspects at the ISP and at > >>>> the end host since the demanded functionality is, to some extend, > >>>> different. > >>>> In this particular document we, for example, say that the ISP has to > >>>> implement one of the location protocols and the client implements all > >>>> > >> of > >> > >>>> them. > >>>> > >>>> > >>>> > >>>>>> * VSP Profile > >>>>>> > >>>>>> Some parts from Section 5 and Section 6 could go in here. Might > want > >>>>>> > >> to > >> > >>>>>> separate this into a separate sub-section to have a way to > reference > >>>>>> > >> it > >> > >>>>>> from the "End Host Profile" section to say something like > >>>>>> "When the end host implements SIP then the VSP might want to use > the > >>>>>> same functionality already at the client." > >>>>>> > >>>>>> The detailed considerations about SIP location conveyance are not > >>>>>> necessary since they can already be found in the SIP Location > >>>>>> > >>>>>> > >>>> Conveyance > >>>> > >>>> > >>>>>> document already. > >>>>>> > >>>>>> > >>>>>> > >>>>> Actually, I think a lot of this text has to stay as it describes how > >>>>> > >> you > >> > >>>> use > >>>> > >>>> > >>>>> the -conveyance mechanism. We'll take a sharp look at it for > >>>>> > >> deletions. > >> > >>>>> > >>>>> > >>>>>> Section 6.2 does not work with the general IETF emergency > >>>>>> > >> architecture, > >> > >>>>>> as described in the ECRIT framework document. For example, the > proxy > >>>>>> does not obtain location information since it cannot do so in the > >>>>>> generic case. > >>>>>> > >>>>>> > >>>>>> > >>>>> I don't want IETF to be in the position of not supporting proxy > >>>>> > >>>>> > >>>> insertion of > >>>> > >>>> > >>>>> location as, for example, 3GPP does. I think we explicitly allow it > >>>>> > >> but > >> > >>>>> explain the difficulties. > >>>>> > >>>>> > >>>>> > >>>> The problem is that it does not work together with the framework > >>>> > >> document. > >> > >>>> The framework document does not have a case for it. > >>>> > >>>> It's fine that the SIP Location Conveyance document has something in > >>>> there that could potentially be useful for the 3GPP. The interesting > >>>> case, however, is that the emergency services architecture of the > 3GPP > >>>> has the functionality of the P-CSCF and the E-CSCF in the local > network > >>>> and hence they don't standardize the interaction with the PSAP, > unlike > >>>> we do because the PSAP in the IETF emergency services architecture > >>>> > >> might > >> > >>>> get the call from an arbitrary entity rather than from the local > >>>> > >> network > >> > >>>> operator. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>>>> Section 8 is also relevant. > >>>>>> > >>>>>> > >>>>>> * PSAP Profile > >>>>>> > >>>>>> Section 6.5 is relevant but only to the extend where the PSAP > >>>>>> > >> operator > >> > >>>>>> network faces the outside world. I don't think it is too relevant > for > >>>>>> this document to talk about PSAP network interal operator, such as > >>>>>> transferring a call to another PSAP operator. > >>>>>> > >>>>>> > >>>>>> > >>>>> Probably right, but the endpoint requirements to support transfer > must > >>>>> > >>>>> > >>>> stay > >>>> > >>>> That's fine > >>>> > >>>> > >>>> > >>>>>> Section 8 is also relevant. > >>>>>> > >>>>>> > >>>>>> > >>>>>> * Security Considerations > >>>>>> > >>>>>> Don't go too much into the details since we talk about all the > stuff > >>>>>> > >> in > >> > >>>>>> other docs. > >>>>>> > >>>>>> > >>>>>> > >>>>> If you say so. I'm not sure we can get away with this. Can we ask > >>>>> > >> you > >> > >>>> to > >>>> > >>>> > >>>>> get a security reviewer assigned sooner rather than later and we can > >>>>> > >>>>> > >>>> work > >>>> > >>>> > >>>>> with him to see what we can accomplish with just references to other > >>>>> > >>>>> > >>>> docs? > >>>> > >>>> Good idea. We should do that. > >>>> > >>>> > >>>> > >>>>>> The testing section is fine. > >>>>>> > >>>>>> > >>>>>> > >>>>> Albeit it mixes endpoint and PSAP BCP statements. > >>>>> > >>>>> > >>>>> > >>>>>> -- I am not so sure about the location update section. > >>>>>> > >>>>>> > >>>>>> > >>>>> There is nothing to reference. It has to be somewhere else, and > >>>>> > >>>>> > >>>> referenced > >>>> > >>>> > >>>>> here, or here. This is a use of presence (and presumably HELD). > >>>>> > >>>>> > >>>>> > >>>>> > >>>> Hmm. I have to re-read that part. > >>>> > >>>> > >>>> > >>>>>> In any case: Try to make the document as short as possible. > >>>>>> > >>>>>> > >>>>>> > >>>>> Okay > >>>>> > >>>>> Thanks for the suggestions > >>>>> > >>>>> > >>>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:17:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4uP-0008J3-9n; Sun, 15 Jul 2007 10:17:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA4uN-0008Iw-P1 for ecrit@ietf.org; Sun, 15 Jul 2007 10:17:11 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA4u8-0002CI-Dq for ecrit@ietf.org; Sun, 15 Jul 2007 10:17:11 -0400 Received: from [63.243.41.34] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.66) (envelope-from ) id 1IA4ta-0002RN-Ur; Sun, 15 Jul 2007 09:16:23 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'Henning Schulzrinne'" References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D711.50103@gmx.net> <469A2949.50904@gmx.net> Subject: RE: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 10:16:30 -0400 Message-ID: <0f2001c7c6ea$be193b40$c6e6a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <469A2949.50904@gmx.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcfG6PlDTQfVpqEESLmI0d3hwlNI/gAATfxA X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'm going to jump the gun on Henning. We don't want emergency calls special cases in any way other than things that are absolutely necessary (recognizing, adding location and LoST route). In particular, the way it normally sends outbound calls is what we want. Henning did NOT say send direct, unless that is the way the phone normally handles outbound calls. If it has an outbound proxy configured, which most VSP-enabled phones would have, we want them sent there. Henning suggests not even discussing where to send them. I wanted to say that explicitly. He wants us to just say "emergency calls are handled exactly the same as any outbound calls except these very specific things". Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, July 15, 2007 10:04 AM > To: Henning Schulzrinne > Cc: Brian Rosen; ECRIT > Subject: Re: [Ecrit] Phone BCP Draft Comments > > Hi Henning, > > Henning Schulzrinne wrote: > > > > On Jul 15, 2007, at 4:13 AM, Hannes Tschofenig wrote: > > > >> Henning, do you think that the emergency call should go directly to > >> the PSAP without traveling through the VSP? > >> > > > > An emergency call should behave like any other SIP call from that end > > system. If the device uses a proxy to place calls to grandma, it > > should use that same proxy to reach 911. If it reaches destinations > > directly, it should do the same thing for emergency calls. This is far > > more likely to work than special-casing emergency calls. (I realize > > that the unauthenticated network access case is an unfortunate > > exception, but it should remain that.) > > > I agree; that's a nice property. > > But it is quite likely that systems that provide some level of > robustness also route calls through their VSP rather than sending them > directly to some entities. > > > > >> Btw, I noticed that we say nothing about NAT traversal in the Phone > >> BCP. That seems to be mandatory functionality, however. > >> > > > > We don't want to write a "How to deploy SIP" manual in ECRIT. I think > > you recently suggested trimming the document size; filling it with > > boilerplate and bromides just obscures the important parts. "Traverse > > NATs" is not testable behavior, given that there is no solution that > > can be guaranteed to work for all NATs under all circumstances. > Consider your previous statement: Emergency calls should be sent > directly to the PSAP without routing them through the VSP. Now, consider > a DSL network that typically has a NAT box in your home network. How > likely is it that this stuff works without any statement about > functionality that has to be available for the end point and the PSAP > with regard to NAT traversal? > > Ciao > Hannes > > > > > Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:23:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA50i-0005h8-Vv; Sun, 15 Jul 2007 10:23:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA50h-0005ds-40 for ecrit@ietf.org; Sun, 15 Jul 2007 10:23:43 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA50Q-0002Hl-Ef for ecrit@ietf.org; Sun, 15 Jul 2007 10:23:43 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FEMmtE006541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 10:22:49 -0400 (EDT) In-Reply-To: <469A2949.50904@gmx.net> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D711.50103@gmx.net> <469A2949.50904@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 10:22:44 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Consider your previous statement: Emergency calls should be sent > directly to the PSAP without routing them through the VSP. Now, > consider a DSL network that typically has a NAT box in your home > network. How likely is it that this stuff works without any > statement about functionality that has to be available for the end > point and the PSAP with regard to NAT traversal? These calls will work just as well as calls to any other SIP destination. In other words, if you screw up your SIP configuration so that calls to grandma don't work, it is extremely unlikely that the PSAP can fix that for you or that an ECRIT document will help. PSAPs have no special role in NAT traversal. Again, we don't want to write a manual about "how to build a SIP network". This is not within the charter of the working group and requires far more than a few vague statements about "beware of NATs". There is a danger of these documents becoming as useful as the typical investment disclosure form for stock offerings, consisting mainly of platitudes that read more like a lawyer trying to cover their liability than an engineering document. We want to write test capability into the spec so that people can figure out ahead of time when things don't work, for any number of reasons. > > Ciao > Hannes > >> >> Henning > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:35:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5Bj-00024Y-NW; Sun, 15 Jul 2007 10:35:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5Bh-00024Q-W1 for ecrit@ietf.org; Sun, 15 Jul 2007 10:35:05 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IA5Bc-0004Ws-R9 for ecrit@ietf.org; Sun, 15 Jul 2007 10:35:05 -0400 Received: (qmail invoked by alias); 15 Jul 2007 14:34:58 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp003) with SMTP; 15 Jul 2007 16:34:58 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/91PpVGbf9hEwUAerlm0LIrRjoJZY8GWxgSXq2V9 p6UEtKX9vsDTgD Message-ID: <469A308F.4080806@gmx.net> Date: Sun, 15 Jul 2007 16:34:55 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> <0f1f01c7c6ea$05ba2280$c6e6a8c0@cis.neustar.com> In-Reply-To: <0f1f01c7c6ea$05ba2280$c6e6a8c0@cis.neustar.com> 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: 9a0a5b57b7540919633bb8f7cd3cb4bd Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org But we cannot leave this aspect open. We need to specify actions that the different parties have todo. As part of this description, the framework document makes it very clear that the end host obtains location information (*). The 3GPP has a different architecture for emergency services and that's fine. We cannot just make such a vague statement that the VSP may add a reference to location information without explain the big picture. Ciao Hannes (*) In this discussion we ignoring the location hiding aspect for a moment. Brian Rosen wrote: > That is up to the VSP. In the 3GPP case, they send emergency calls to the > E-CSCF. Others may do it on the first hop outbound (what would be the > P-CSCF). I don't think we care, and I don't think we even discuss it. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Sunday, July 15, 2007 9:49 AM >> To: Brian Rosen >> Cc: 'ECRIT' >> Subject: Re: [Ecrit] Phone BCP Draft Comments >> >> Hi Brian, >> >> sure that's fine. But the problem is the following: What proxy should >> add location information other than a proxy in the access network. >> So far, such a proxy does not exist in our emergency services >> architecture. Right? >> >> Ciao >> Hannes >> >> Brian Rosen wrote: >> >>> Hannes >>> >>> I believe your opinion runs counter to consensus, and I'll bring this up >>> >> for >> >>> a hum at the meeting. I think most of us think endpoint insertion of >>> location is preferred, but proxy insertion, under the right >>> >> circumstances, >> >>> is acceptable. >>> >>> Brian >>> >>> >>> >>>> -----Original Message----- >>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>> Sent: Sunday, July 15, 2007 4:11 AM >>>> To: Brian Rosen >>>> Cc: 'ECRIT' >>>> Subject: Re: [Ecrit] Phone BCP Draft Comments >>>> >>>> Hi Brian, >>>> >>>> Brian Rosen wrote: >>>> >>>> >>>>> The text now says that the phone applies normal outbound processing. >>>>> >>>>> >>>> That >>>> >>>> >>>>> would mean it sends calls to the VSP. That's what we want. >>>>> >>>>> Marc's phone would normally send calls to his house proxy. That is >>>>> >> what >> >>>> we >>>> >>>> >>>>> want. >>>>> >>>>> >>>>> >>>> Typically, it would be the proxy of Marc's VoIP provider. >>>> >>>> >>>>> Let us try my way with the organization and see if it accomplishes >>>>> >> what >> >>>> you >>>> >>>> >>>>> want. If it's a mess, I'll look at doing it your way. >>>>> >>>>> I'll make sure we discuss proxy insertion of location in both - >>>>> >> framework >> >>>> and >>>> >>>> >>>>> -phonebcp. I think it is best to state it is acceptable if the >>>>> >>>>> >>>> limitations >>>> >>>> >>>>> implied (VSP has a relationship with ISP, has a good identifier that >>>>> >> ISP >> >>>> can >>>> >>>> >>>>> use) hold. >>>>> >>>>> >>>>> >>>> I don't think we have a place in our current architecture for the proxy >>>> insertion for location. >>>> We should first discuss that aspect from an architectural point of >>>> >> view. >> >>>> Ciao >>>> Hannes >>>> >>>> >>>> >>>> >>>>> Brian >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>> Sent: Saturday, July 14, 2007 5:38 PM >>>>>> To: Brian Rosen >>>>>> Cc: 'ECRIT' >>>>>> Subject: Re: [Ecrit] Phone BCP Draft Comments >>>>>> >>>>>> Hi Brian, >>>>>> >>>>>> thanks for the quick response. Please see my comments below: >>>>>> >>>>>> Brian Rosen wrote: >>>>>> >>>>>> >>>>>> >>>>>>> See in line >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>>> Sent: Friday, July 13, 2007 5:11 PM >>>>>>>> To: ECRIT >>>>>>>> Subject: [Ecrit] Phone BCP Draft Comments >>>>>>>> >>>>>>>> Hi Brian, >>>>>>>> Hi James, >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I like the document, as I expressed several times in the past. >>>>>>>> >>>>>>>> There are, however, a few issues with it. >>>>>>>> >>>>>>>> Henning and myself have recently written an ECRIT overview >>>>>>>> >> document. >> >>>>>>>> >>>>>> See >>>>>> >>>>>> >>>>>> >>>>>>>> http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- >>>>>>>> overview-00.txt >>>>>>>> >>>>>>>> One thing that was quite important for us to highlight was that the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> IETF >>>>>> >>>>>> >>>>>> >>>>>>>> emergency service architecture has a very nice property, namely the >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> fact >>>>>> >>>>>> >>>>>> >>>>>>>> that different VoIP protocols may be supported between the end host >>>>>>>> >>>>>>>> >>>> and >>>> >>>> >>>>>>>> the VoIP provider. There is no need to implement SIP only. >>>>>>>> >>>>>>>> Now, this document does not give me the impression that this aspect >>>>>>>> >>>>>>>> >>>> is >>>> >>>> >>>>>>>> given enough consideration. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> There are two things that came to mind when I read this. One is >>>>>>> >> that >> >>>>>>> >>>>>> you >>>>>> >>>>>> >>>>>> >>>>>>> are right, and we can be more clear that any protocol can be used >>>>>>> >>>>>>> >>>>>>> >>>>>> between >>>>>> >>>>>> >>>>>> >>>>>>> the endpoint and some kind of gateway that interworks to a protocol >>>>>>> >>>>>>> >>>> that >>>> >>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>> PSAP implements. >>>>>>> >>>>>>> The other is that SIP need not be the only protocol the PSAP >>>>>>> >>>>>>> >>>> implements. >>>> >>>> >>>>>> That's certainly true. We do, however, have to start somewhere. We >>>>>> cannot describe what Skype protocol features a PSAP has to implement >>>>>> >>>>>> >>>> for >>>> >>>> >>>>>> an emergency service scenario. >>>>>> >>>>>> Hence, we focus only on SIP. That's already enough for a PSAP to >>>>>> implement. >>>>>> We do, however, only mandate functionality that is absolutely >>>>>> >> necessary >> >>>>>> for interoperability. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> However. There are some requirements on what the protocol needs to >>>>>>> >> do. >> >>>>>>> >>>>>> We >>>>>> >>>>>> >>>>>> >>>>>>> should list them, and I think probably that discussion belongs in >>>>>>> -framework. LoST already can return multiple URIs with different >>>>>>> >>>>>>> >>>>>>> >>>>>> schemes >>>>>> >>>>>> >>>>>> >>>>>>> corresponding to what it implements. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> It might be a good idea to state what protocols have to support -- >>>>>> >>>>>> >>>> there >>>> >>>> >>>>>> aren't too many things anyway. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> The IETF emergency service architecture realistically requires that >>>>>>>> >>>>>>>> >>>> the >>>> >>>> >>>>>>>> emergency calls are routed through the VSP in order to get identity >>>>>>>> information attached to an emergency call. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> NO!!!! >>>>>>> >>>>>>> That is NOT true. The PSAPs I work with will take calls that don't >>>>>>> >>>>>>> >>>> come >>>> >>>> >>>>>>> >from a VSP over the internet. >>>>>>> >>>>>>> >>>>>>> >>>>>> I guess you need to describe in more detail what you have seen. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> They may well have some suspicion on such >>>>>>> calls due to the lack of a verifiable identity but they will take >>>>>>> >> the >> >>>>>>> >>>>>> call >>>>>> >>>>>> >>>>>> >>>>>>> anyway. I've had numerous conversations with PSAP people who want >>>>>>> >> to >> >>>>>>> >>>>>> make >>>>>> >>>>>> >>>>>> >>>>>>> sure I understand the "rules" they have (validated location for >>>>>>> >>>>>>> >>>>>>> >>>>>> examples). >>>>>> >>>>>> >>>>>> >>>>>>> When I press them for what they want to do when something goes wrong >>>>>>> >>>>>>> >>>> and >>>> >>>> >>>>>> it >>>>>> >>>>>> >>>>>> >>>>>>> doesn't happen (like, validation fails, do they want unvalidated >>>>>>> >>>>>>> >>>>>>> >>>>>> location or >>>>>> >>>>>> >>>>>> >>>>>>> no location), they ALWAYS want the call, and they want the data you >>>>>>> >>>>>>> >>>>>>> >>>>>> have. >>>>>> >>>>>> >>>>>> >>>>>>> They may treat the call with suspiscion. They may go back later and >>>>>>> >>>>>>> >>>> try >>>> >>>> >>>>>> to >>>>>> >>>>>> >>>>>> >>>>>>> figure out why they didn't get what they wanted but they take the >>>>>>> >> call >> >>>>>>> >>>>>> and >>>>>> >>>>>> >>>>>> >>>>>>> ask questions later. >>>>>>> >>>>>>> So please don't make that assumption. Ysa, we expect nearly all >>>>>>> >> calls >> >>>>>>> >>>>>> to go >>>>>> >>>>>> >>>>>> >>>>>>> through a VSP, but the system works if Marc Linsner's proxy in his >>>>>>> >>>>>>> >>>> house >>>> >>>> >>>>>>> sends the call to the PSAP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> That's fine. It is just the question what we write into the document. >>>>>> What is the default behavior? >>>>>> We sent the calls directly to the PSAP or via the VSP? >>>>>> >>>>>> This has impact for the phone BCP document. If you assume that calls >>>>>> >>>>>> >>>> are >>>> >>>> >>>>>> routed through the VSP then the protocol run by the end point does >>>>>> >> not >> >>>>>> matter too much. >>>>>> If you assume that the end host MUST be able to route directly to the >>>>>> PSAP as well then you have to mandate a certain functionality at the >>>>>> >>>>>> >>>> end >>>> >>>> >>>>>> point. >>>>>> >>>>>> So, what behavior do we want? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Having said all that I believe that one important aspect, which is >>>>>>>> >>>>>>>> >>>> also >>>> >>>> >>>>>>>> different to architecturs investigated by other SDOs, is that the >>>>>>>> >>>>>>>> >>>> PSAP >>>> >>>> >>>>>>>> has to support a certain functionality. This functionality is >>>>>>>> >>>>>>>> >>>> described >>>> >>>> >>>>>>>> in the document but might not be too visible to the working group >>>>>>>> >> or >> >>>> at >>>> >>>> >>>>>>>> least hasn't be advertised a lot. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes, this is true. We could make that more explicit. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I believe we have to indicate quite close what the different >>>>>>>> >> entities >> >>>>>>>> have to support rather than meshing everything together. This >>>>>>>> >> impacts >> >>>>>>>> the document structure a bit. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes, we have thought about that a lot, and have had some suggestions >>>>>>> >>>>>>> >>>> in >>>> >>>> >>>>>> that >>>>>> >>>>>> >>>>>> >>>>>>> the direction, the goal being to have all the BCPs for phones in one >>>>>>> >>>>>>> >>>>>>> >>>>>> place, >>>>>> >>>>>> >>>>>> >>>>>>> those for the access network in another place, etc. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> It's OK to have the required functionality listed in one document >>>>>> >> even >> >>>>>> though they address all the involved parties in the architecture. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Here is a suggested structure for the document: >>>>>>>> >>>>>>>> * Introduction >>>>>>>> >>>>>>>> Shorten the introduction >>>>>>>> >>>>>>>> It contains a lot of info that is already available in the >>>>>>>> >> framework. >> >>>>>>>> This document has to be read in the context of the architecture >>>>>>>> >>>>>>>> >>>> anyway. >>>> >>>> >>>>>>> We will do that >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Btw, the introduction must not use RFC 2119 language. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Yes >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> * Terminology >>>>>>>> >>>>>>>> Classical RFC boilerplate and pointers to the requirements >>>>>>>> >> document. >> >>>>>>>> >>>>>>>> >>>>>>>> * End Host Profile >>>>>>>> >>>>>>>> This section just describes what is absolutely necessary for an end >>>>>>>> point to support the >>>>>>>> >>>>>>>> This is essentially the location part, the LoST part. >>>>>>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. >>>>>>>> The LoST stuff can be found in Section 6.3. >>>>>>>> >>>>>>>> * ISP Profile >>>>>>>> >>>>>>>> This is the location part. The server side of Section 4.2. >>>>>>>> Optionally, LoST may be provided by the ISP. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> You see where the problem is? You have the location part in both >>>>>>> >> End >> >>>>>>> >>>>>> Host >>>>>> >>>>>> >>>>>> >>>>>>> and ISP. Same with LoST. >>>>>>> >>>>>>> This is the problem with this suggestion. It actually makes as much >>>>>>> >>>>>>> >>>>>>> >>>>>> sense >>>>>> >>>>>> >>>>>> >>>>>>> to keep all the location information together as it does to keep all >>>>>>> >>>>>>> >>>> the >>>> >>>> >>>>>> end >>>>>> >>>>>> >>>>>> >>>>>>> host information together. >>>>>>> >>>>>>> My best idea to address this is to leave the structure as is, but to >>>>>>> >>>>>>> >>>>>>> >>>>>> make >>>>>> >>>>>> >>>>>> >>>>>>> the BCP elements pulled out and labeled as to whom they apply >>>>>>> >>>>>>> >>>> (endpoint, >>>> >>>> >>>>>>> VSP, ISP, PSAP). Then, after the functional sections, we can copy >>>>>>> >> the >> >>>>>>> >>>>>> BCP >>>>>> >>>>>> >>>>>> >>>>>>> elements (only, not the other text) and sort them by who they apply >>>>>>> >>>>>>> >>>> to. >>>> >>>> >>>>>>> >>>>>> It's not a big problem to consider location aspects at the ISP and at >>>>>> the end host since the demanded functionality is, to some extend, >>>>>> different. >>>>>> In this particular document we, for example, say that the ISP has to >>>>>> implement one of the location protocols and the client implements all >>>>>> >>>>>> >>>> of >>>> >>>> >>>>>> them. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> * VSP Profile >>>>>>>> >>>>>>>> Some parts from Section 5 and Section 6 could go in here. Might >>>>>>>> >> want >> >>>> to >>>> >>>> >>>>>>>> separate this into a separate sub-section to have a way to >>>>>>>> >> reference >> >>>> it >>>> >>>> >>>>>>>> from the "End Host Profile" section to say something like >>>>>>>> "When the end host implements SIP then the VSP might want to use >>>>>>>> >> the >> >>>>>>>> same functionality already at the client." >>>>>>>> >>>>>>>> The detailed considerations about SIP location conveyance are not >>>>>>>> necessary since they can already be found in the SIP Location >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> Conveyance >>>>>> >>>>>> >>>>>> >>>>>>>> document already. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Actually, I think a lot of this text has to stay as it describes how >>>>>>> >>>>>>> >>>> you >>>> >>>> >>>>>> use >>>>>> >>>>>> >>>>>> >>>>>>> the -conveyance mechanism. We'll take a sharp look at it for >>>>>>> >>>>>>> >>>> deletions. >>>> >>>> >>>>>>> >>>>>>>> Section 6.2 does not work with the general IETF emergency >>>>>>>> >>>>>>>> >>>> architecture, >>>> >>>> >>>>>>>> as described in the ECRIT framework document. For example, the >>>>>>>> >> proxy >> >>>>>>>> does not obtain location information since it cannot do so in the >>>>>>>> generic case. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I don't want IETF to be in the position of not supporting proxy >>>>>>> >>>>>>> >>>>>>> >>>>>> insertion of >>>>>> >>>>>> >>>>>> >>>>>>> location as, for example, 3GPP does. I think we explicitly allow it >>>>>>> >>>>>>> >>>> but >>>> >>>> >>>>>>> explain the difficulties. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> The problem is that it does not work together with the framework >>>>>> >>>>>> >>>> document. >>>> >>>> >>>>>> The framework document does not have a case for it. >>>>>> >>>>>> It's fine that the SIP Location Conveyance document has something in >>>>>> there that could potentially be useful for the 3GPP. The interesting >>>>>> case, however, is that the emergency services architecture of the >>>>>> >> 3GPP >> >>>>>> has the functionality of the P-CSCF and the E-CSCF in the local >>>>>> >> network >> >>>>>> and hence they don't standardize the interaction with the PSAP, >>>>>> >> unlike >> >>>>>> we do because the PSAP in the IETF emergency services architecture >>>>>> >>>>>> >>>> might >>>> >>>> >>>>>> get the call from an arbitrary entity rather than from the local >>>>>> >>>>>> >>>> network >>>> >>>> >>>>>> operator. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Section 8 is also relevant. >>>>>>>> >>>>>>>> >>>>>>>> * PSAP Profile >>>>>>>> >>>>>>>> Section 6.5 is relevant but only to the extend where the PSAP >>>>>>>> >>>>>>>> >>>> operator >>>> >>>> >>>>>>>> network faces the outside world. I don't think it is too relevant >>>>>>>> >> for >> >>>>>>>> this document to talk about PSAP network interal operator, such as >>>>>>>> transferring a call to another PSAP operator. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Probably right, but the endpoint requirements to support transfer >>>>>>> >> must >> >>>>>>> >>>>>> stay >>>>>> >>>>>> That's fine >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> Section 8 is also relevant. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * Security Considerations >>>>>>>> >>>>>>>> Don't go too much into the details since we talk about all the >>>>>>>> >> stuff >> >>>> in >>>> >>>> >>>>>>>> other docs. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> If you say so. I'm not sure we can get away with this. Can we ask >>>>>>> >>>>>>> >>>> you >>>> >>>> >>>>>> to >>>>>> >>>>>> >>>>>> >>>>>>> get a security reviewer assigned sooner rather than later and we can >>>>>>> >>>>>>> >>>>>>> >>>>>> work >>>>>> >>>>>> >>>>>> >>>>>>> with him to see what we can accomplish with just references to other >>>>>>> >>>>>>> >>>>>>> >>>>>> docs? >>>>>> >>>>>> Good idea. We should do that. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> The testing section is fine. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Albeit it mixes endpoint and PSAP BCP statements. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -- I am not so sure about the location update section. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> There is nothing to reference. It has to be somewhere else, and >>>>>>> >>>>>>> >>>>>>> >>>>>> referenced >>>>>> >>>>>> >>>>>> >>>>>>> here, or here. This is a use of presence (and presumably HELD). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Hmm. I have to re-read that part. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>> In any case: Try to make the document as short as possible. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Okay >>>>>>> >>>>>>> Thanks for the suggestions >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> >>>>>> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:44:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5KU-0003AX-Ol; Sun, 15 Jul 2007 10:44:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5KT-00036e-HL for ecrit@ietf.org; Sun, 15 Jul 2007 10:44:09 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA5KT-0002cS-8S for ecrit@ietf.org; Sun, 15 Jul 2007 10:44:09 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FEi666008466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 10:44:07 -0400 (EDT) In-Reply-To: <469A308F.4080806@gmx.net> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> <0f1f01c7c6ea$05ba2280$c6e6a8c0@cis.neustar.com> <469A308F.4080806@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9AC60399-840F-43C8-9228-8A08EA00103B@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 10:44:01 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Since this is highly dependent on the specific network, I don't think we can say anything useful. The VSP will figure this out, based on local needs and capabilities. For example, a Vonage-like VSP may initially simply insert the user-provided location, i.e., the address customers typed into a web form. A combined VSP/ISP could use some proprietary mechanism that only works with its particular brand of equipment. The Hogwart's VSP would probably use Professor Trelaney's crystal ball. Unless there's an IETF protocol that we can tell somebody to implement, what useful information are we going to provide to the implementor and operator? Saying "only insert location information if you have it" isn't terribly helpful. But maybe you have a concrete proposal that the VSP should always use? Henning [trimming huge 10-deep quote] On Jul 15, 2007, at 10:34 AM, Hannes Tschofenig wrote: > But we cannot leave this aspect open. We need to specify actions > that the different parties have todo. > As part of this description, the framework document makes it very > clear that the end host obtains location information (*). > The 3GPP has a different architecture for emergency services and > that's fine. > > We cannot just make such a vague statement that the VSP may add a > reference to location information without explain the big picture. > > Ciao > Hannes > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 10:55:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5VJ-0007rN-4G; Sun, 15 Jul 2007 10:55:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5VI-0007rI-Qz for ecrit@ietf.org; Sun, 15 Jul 2007 10:55:20 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IA5VE-00050h-DW for ecrit@ietf.org; Sun, 15 Jul 2007 10:55:20 -0400 Received: (qmail invoked by alias); 15 Jul 2007 14:55:15 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp051) with SMTP; 15 Jul 2007 16:55:15 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+71qZRjs+7WqxSyXIe5jn9oMK0GmQF3NUUsMoyTW CcaFhyr/6v1VzD Message-ID: <469A3550.8030403@gmx.net> Date: Sun, 15 Jul 2007 16:55:12 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D711.50103@gmx.net> <469A2949.50904@gmx.net> 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: cab78e1e39c4b328567edb48482b6a69 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Not treating emergency calls special sounds good to me. Ciao Hannes Henning Schulzrinne wrote: > > >> Consider your previous statement: Emergency calls should be sent >> directly to the PSAP without routing them through the VSP. Now, >> consider a DSL network that typically has a NAT box in your home >> network. How likely is it that this stuff works without any statement >> about functionality that has to be available for the end point and >> the PSAP with regard to NAT traversal? > > > These calls will work just as well as calls to any other SIP > destination. In other words, if you screw up your SIP configuration so > that calls to grandma don't work, it is extremely unlikely that the > PSAP can fix that for you or that an ECRIT document will help. > > PSAPs have no special role in NAT traversal. > > Again, we don't want to write a manual about "how to build a SIP > network". This is not within the charter of the working group and > requires far more than a few vague statements about "beware of NATs". > There is a danger of these documents becoming as useful as the typical > investment disclosure form for stock offerings, consisting mainly of > platitudes that read more like a lawyer trying to cover their > liability than an engineering document. > > We want to write test capability into the spec so that people can > figure out ahead of time when things don't work, for any number of > reasons. > > >> >> Ciao >> Hannes >> >>> >>> Henning >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 11:01:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5bS-0005hS-5K; Sun, 15 Jul 2007 11:01:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5bQ-0005hI-Nt for ecrit@ietf.org; Sun, 15 Jul 2007 11:01:40 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IA5bM-000562-A7 for ecrit@ietf.org; Sun, 15 Jul 2007 11:01:40 -0400 Received: (qmail invoked by alias); 15 Jul 2007 15:01:34 -0000 Received: from p54985558.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.85.88] by mail.gmx.net (mp004) with SMTP; 15 Jul 2007 17:01:34 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/iwAFbhS/ilOKu5H92x0j0lui3k+Cqko+g+VvOY0 Ydts9RfbtW9cT3 Message-ID: <469A36CC.3090507@gmx.net> Date: Sun, 15 Jul 2007 17:01:32 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> <0f1f01c7c6ea$05ba2280$c6e6a8c0@cis.neustar.com> <469A308F.4080806@gmx.net> <9AC60399-840F-43C8-9228-8A08EA00103B@cs.columbia.edu> In-Reply-To: <9AC60399-840F-43C8-9228-8A08EA00103B@cs.columbia.edu> 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: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Currently the framework document does not say that the VSP should attach location information to an emergency call. Instead, the end host obtains it. That's why the document goes into a lot of details regarding the protocols that could be used for this purpose. Are we going to change this to a) If the VSP wants to add something in addition the information that is already inserted by the end host then it can do so. b) Change the architecture to something where the VSP adds location instead of the end point I am confused. Ciao Hannes Henning Schulzrinne wrote: > Since this is highly dependent on the specific network, I don't think > we can say anything useful. The VSP will figure this out, based on > local needs and capabilities. For example, a Vonage-like VSP may > initially simply insert the user-provided location, i.e., the address > customers typed into a web form. A combined VSP/ISP could use some > proprietary mechanism that only works with its particular brand of > equipment. The Hogwart's VSP would probably use Professor Trelaney's > crystal ball. > > Unless there's an IETF protocol that we can tell somebody to > implement, what useful information are we going to provide to the > implementor and operator? Saying "only insert location information if > you have it" isn't terribly helpful. But maybe you have a concrete > proposal that the VSP should always use? > > Henning > > [trimming huge 10-deep quote] > > On Jul 15, 2007, at 10:34 AM, Hannes Tschofenig wrote: > >> But we cannot leave this aspect open. We need to specify actions that >> the different parties have todo. >> As part of this description, the framework document makes it very >> clear that the end host obtains location information (*). >> The 3GPP has a different architecture for emergency services and >> that's fine. >> >> We cannot just make such a vague statement that the VSP may add a >> reference to location information without explain the big picture. >> >> Ciao >> Hannes >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 11:19:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5sj-0003AB-Az; Sun, 15 Jul 2007 11:19:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA5si-0003A6-61 for ecrit@ietf.org; Sun, 15 Jul 2007 11:19:32 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA5se-0005Ps-Th for ecrit@ietf.org; Sun, 15 Jul 2007 11:19:32 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FFJGi3011889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 11:19:17 -0400 (EDT) In-Reply-To: <469A36CC.3090507@gmx.net> References: <4697EA76.60606@gmx.net> <0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com> <46994251.5050201@gmx.net> <0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com> <4699D6AA.2040104@gmx.net> <0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> <0f1f01c7c6ea$05ba2280$c6e6a8c0@cis.neustar.com> <469A308F.4080806@gmx.net> <9AC60399-840F-43C8-9228-8A08EA00103B@cs.columbia.edu> <469A36CC.3090507@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <24251736-ED2B-4718-969E-3E6EED5E48BE@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Phone BCP Draft Comments Date: Sun, 15 Jul 2007 11:19:12 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There are two cases of interest: (1) The VSP receives a call without location information; I suspect we would agree that if the VSP has location information, it should insert it and route on it. There are no good alternatives. (2) The VSP receives a call with location information, but it (a) either cannot read it or (b) it can, but the VSP has different location information. (ISP claims that caller is at location X, VSP believes him to be at Y.) In the first case, I'd argue that having the VSP provide the location is probably a good thing, as long as it is labeled; see the SIP location conveyance discussion on that topic. I'm unsure about the second case, but would tend to favor inclusion for the same reason. Almost always, the ISP/end system will know better, but there may well be exceptions. (One exception you could imagine is that the ISP says "customer X is somewhere in the WiMax coverage area, which is Lincoln county". VSP says "by the way, the customer lives at 123 Main Street, Springfield, Lincoln County." Any such insertion should be marked by the appropriate source indication, i.e., billing address in the latter case.) I suspect we can also agree that having the VSP remove location information from a signaling message is a bad idea. The only interesting case for routing is case (2b). I don't know if we need to say anything about which location should be handed to LoST, although the right answer is usually likely to be the ISP/end- system provided location. Henning On Jul 15, 2007, at 11:01 AM, Hannes Tschofenig wrote: > Currently the framework document does not say that the VSP should > attach location information to an emergency call. Instead, the end > host obtains it. That's why the document goes into a lot of details > regarding the protocols that could be used for this purpose. > > Are we going to change this to > > a) If the VSP wants to add something in addition the information > that is already inserted by the end host then it can do so. > > b) Change the architecture to something where the VSP adds location > instead of the end point > > I am confused. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 15:39:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA9wZ-00047v-0k; Sun, 15 Jul 2007 15:39:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA9wX-00047q-8M for ecrit@ietf.org; Sun, 15 Jul 2007 15:39:45 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IA9wW-0000VV-DL for ecrit@ietf.org; Sun, 15 Jul 2007 15:39:45 -0400 X-SEF-Processed: 5_0_0_910__2007_07_15_14_48_00 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh1.andrew.com [10.86.20.24] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 15 Jul 2007 14:48:00 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Jul 2007 14:39:43 -0500 Content-class: urn:content-classes:message Subject: RE: [Ecrit] Phone BCP Draft Comments MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 15 Jul 2007 14:39:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: In-Reply-To: <469A25CF.5070302@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Phone BCP Draft Comments Thread-Index: AcfG5wK/oMyfQR0vQp6j84NkZDi8fwAL5t8Q References: <4697EA76.60606@gmx.net><0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com><46994251.5050201@gmx.net><0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com><4699D6AA.2040104@gmx.net><0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> From: "Dawson, Martin" To: "Hannes Tschofenig" , "Brian Rosen" X-OriginalArrivalTime: 15 Jul 2007 19:39:43.0771 (UTC) FILETIME=[E4A78EB0:01C7C717] X-Spam-Score: 1.8 (+) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes,=0D=0A=0D=0AWell... I can imagine a proxy in a residential LAN th= at knows how to=0D=0Atalk HELD to the access provider network when the clie= nt device (e.g.=0D=0Alegacy ATA) does not know how to. So the proxy does th= e request on=0D=0Abehalf of the ATA and does the insertion on the outbound.=0D= =0A=0D=0AI can imagine an Asterisk server in an enterprise that knows how t= o talk=0D=0Ato the enterprise LIS and requests and inserts location on beha= lf of the=0D=0Astandard phone form factor IP handsets that don't know how t= o do it=0D=0Athemselves.=0D=0A=0D=0AIn both cases, the option exists to rou= te the call directly to whatever=0D=0AURI the LoST service indicates is app= ropriate without any external VSP=0D=0Abeing involved.=0D=0A=0D=0AOr are yo= u saying that these proxies are the "VSP" in these scenarios=3F=0D=0AIt's j= ust a question of semantics=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A--= ---Original Message-----=0D=0AFrom: Hannes Tschofenig [mailto:Hannes.Tschof= enig@gmx.net]=20=0D=0ASent: Sunday, 15 July 2007 11:49 PM=0D=0ATo: Brian Ro= sen=0D=0ACc: 'ECRIT'=0D=0ASubject: Re: [Ecrit] Phone BCP Draft Comments=0D=0A=0D= =0AHi Brian,=0D=0A=0D=0Asure that's fine. But the problem is the following:= What proxy should=20=0D=0Aadd location information other than a proxy in t= he access network.=0D=0ASo far, such a proxy does not exist in our emergenc= y services=20=0D=0Aarchitecture. Right=3F=0D=0A=0D=0ACiao=0D=0AHannes=0D=0A=0D= =0ABrian Rosen wrote:=0D=0A> Hannes=0D=0A>=0D=0A> I believe your opinion ru= ns counter to consensus, and I'll bring this=0D=0Aup for=0D=0A> a hum at th= e meeting. I think most of us think endpoint insertion of=0D=0A> location = is preferred, but proxy insertion, under the right=0D=0Acircumstances,=0D=0A= > is acceptable.=0D=0A>=0D=0A> Brian=0D=0A>=0D=0A> =20=0D=0A>> -----Origin= al Message-----=0D=0A>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@g= mx.net]=0D=0A>> Sent: Sunday, July 15, 2007 4:11 AM=0D=0A>> To: Brian Rosen=0D= =0A>> Cc: 'ECRIT'=0D=0A>> Subject: Re: [Ecrit] Phone BCP Draft Comments=0D=0A= >>=0D=0A>> Hi Brian,=0D=0A>>=0D=0A>> Brian Rosen wrote:=0D=0A>> =20=0D=0A= >>> The text now says that the phone applies normal outbound processing.=0D= =0A>>> =20=0D=0A>> That=0D=0A>> =20=0D=0A>>> would mean it sends ca= lls to the VSP. That's what we want.=0D=0A>>>=0D=0A>>> Marc's phone would = normally send calls to his house proxy. That is=0D=0Awhat=0D=0A>>> =0D= =0A>> we=0D=0A>> =20=0D=0A>>> want.=0D=0A>>>=0D=0A>>> =20=0D=0A>> T= ypically, it would be the proxy of Marc's VoIP provider.=0D=0A>> =20=0D=0A= >>> Let us try my way with the organization and see if it accomplishes=0D=0A= what=0D=0A>>> =20=0D=0A>> you=0D=0A>> =20=0D=0A>>> want. If it's a= mess, I'll look at doing it your way.=0D=0A>>>=0D=0A>>> I'll make sure we = discuss proxy insertion of location in both=0D=0A-framework=0D=0A>>> =0D= =0A>> and=0D=0A>> =20=0D=0A>>> -phonebcp. I think it is best to state i= t is acceptable if the=0D=0A>>> =20=0D=0A>> limitations=0D=0A>> =0D= =0A>>> implied (VSP has a relationship with ISP, has a good identifier that=0D= =0AISP=0D=0A>>> =20=0D=0A>> can=0D=0A>> =20=0D=0A>>> use) hold.=0D=0A= >>>=0D=0A>>> =20=0D=0A>> I don't think we have a place in our current = architecture for the=0D=0Aproxy=0D=0A>> insertion for location.=0D=0A>> We = should first discuss that aspect from an architectural point of=0D=0Aview.=0D= =0A>>=0D=0A>> Ciao=0D=0A>> Hannes=0D=0A>>=0D=0A>>=0D=0A>> =20=0D=0A>>> B= rian=0D=0A>>>=0D=0A>>>=0D=0A>>> =20=0D=0A>>>> -----Original Message---= --=0D=0A>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A= >>>> Sent: Saturday, July 14, 2007 5:38 PM=0D=0A>>>> To: Brian Rosen=0D=0A>= >>> Cc: 'ECRIT'=0D=0A>>>> Subject: Re: [Ecrit] Phone BCP Draft Comments=0D=0A= >>>>=0D=0A>>>> Hi Brian,=0D=0A>>>>=0D=0A>>>> thanks for the quick response.= Please see my comments below:=0D=0A>>>>=0D=0A>>>> Brian Rosen wrote:=0D=0A= >>>>=0D=0A>>>> =20=0D=0A>>>>> See in line=0D=0A>>>>>=0D=0A>>>>>=0D=0A= >>>>>=0D=0A>>>>> =20=0D=0A>>>>>> -----Original Message-----=0D=0A>= >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A>>>>>= > Sent: Friday, July 13, 2007 5:11 PM=0D=0A>>>>>> To: ECRIT=0D=0A>>>>>> Sub= ject: [Ecrit] Phone BCP Draft Comments=0D=0A>>>>>>=0D=0A>>>>>> Hi Brian,=0D= =0A>>>>>> Hi James,=0D=0A>>>>>> Hi all,=0D=0A>>>>>>=0D=0A>>>>>> I like the = document, as I expressed several times in the past.=0D=0A>>>>>>=0D=0A>>>>>>= There are, however, a few issues with it.=0D=0A>>>>>>=0D=0A>>>>>> Henning = and myself have recently written an ECRIT overview=0D=0Adocument.=0D=0A>>>>= >>=0D=0A>>>>>> =20=0D=0A>>>> See=0D=0A>>>>=0D=0A>>>> =20=0D= =0A>>>>>>=0D=0Ahttp://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-archit= ecture-=0D=0A>>>>>> overview-00.txt=0D=0A>>>>>>=0D=0A>>>>>> One thing that = was quite important for us to highlight was that=0D=0Athe=0D=0A>>>>>>=0D=0A= >>>>>> =20=0D=0A>>>> IETF=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>= >>>> emergency service architecture has a very nice property, namely=0D=0At= he=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>> fact=0D=0A>>>>=0D=0A>>>= > =20=0D=0A>>>>>> that different VoIP protocols may be supported bet= ween the end=0D=0Ahost=0D=0A>>>>>> =20=0D=0A>> and=0D=0A>> =0D= =0A>>>>>> the VoIP provider. There is no need to implement SIP only.=0D=0A>= >>>>>=0D=0A>>>>>> Now, this document does not give me the impression that t= his=0D=0Aaspect=0D=0A>>>>>> =20=0D=0A>> is=0D=0A>> =20=0D=0A>= >>>>> given enough consideration.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> = =20=0D=0A>>>>> There are two things that came to mind when I read thi= s. One is=0D=0Athat=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> you=0D=0A= >>>>=0D=0A>>>> =20=0D=0A>>>>> are right, and we can be more clear th= at any protocol can be used=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> be= tween=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> the endpoint and some kind = of gateway that interworks to a=0D=0Aprotocol=0D=0A>>>>> =20=0D=0A= >> that=0D=0A>> =20=0D=0A>>>> the=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>= >>> PSAP implements.=0D=0A>>>>>=0D=0A>>>>> The other is that SIP need not b= e the only protocol the PSAP=0D=0A>>>>> =20=0D=0A>> implements.=0D= =0A>> =20=0D=0A>>>>> =20=0D=0A>>>> That's certainly true. We do= , however, have to start somewhere. We=0D=0A>>>> cannot describe what Skype= protocol features a PSAP has to=0D=0Aimplement=0D=0A>>>> =20=0D=0A>= > for=0D=0A>> =20=0D=0A>>>> an emergency service scenario.=0D=0A>>>>=0D=0A= >>>> Hence, we focus only on SIP. That's already enough for a PSAP to=0D=0A= >>>> implement.=0D=0A>>>> We do, however, only mandate functionality that i= s absolutely=0D=0Anecessary=0D=0A>>>> for interoperability.=0D=0A>>>>=0D=0A= >>>>=0D=0A>>>> =20=0D=0A>>>>> However. There are some requirements o= n what the protocol needs to=0D=0Ado.=0D=0A>>>>>=0D=0A>>>>> =20=0D= =0A>>>> We=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> should list them, and = I think probably that discussion belongs in=0D=0A>>>>> -framework. LoST al= ready can return multiple URIs with different=0D=0A>>>>>=0D=0A>>>>> = =20=0D=0A>>>> schemes=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> correspon= ding to what it implements.=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> = =20=0D=0A>>>> It might be a good idea to state what protocols have to= support --=0D=0A>>>> =20=0D=0A>> there=0D=0A>> =20=0D=0A>>>> are= n't too many things anyway.=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> =20=0D=0A>= >>>>> The IETF emergency service architecture realistically requires=0D=0At= hat=0D=0A>>>>>> =20=0D=0A>> the=0D=0A>> =20=0D=0A>>>>>> emerg= ency calls are routed through the VSP in order to get=0D=0Aidentity=0D=0A>>= >>>> information attached to an emergency call.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A= >>>>>> =20=0D=0A>>>>> NO!!!!=0D=0A>>>>>=0D=0A>>>>> That is NOT t= rue. The PSAPs I work with will take calls that=0D=0Adon't=0D=0A>>>>> = =20=0D=0A>> come=0D=0A>> =20=0D=0A>>>>> >from a VSP over the intern= et.=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> I guess you need to descri= be in more detail what you have seen.=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>> They may well have some suspicion on such=0D=0A>>>>> calls= due to the lack of a verifiable identity but they will take=0D=0Athe=0D=0A= >>>>>=0D=0A>>>>> =20=0D=0A>>>> call=0D=0A>>>>=0D=0A>>>> =0D= =0A>>>>> anyway. I've had numerous conversations with PSAP people who want=0D= =0Ato=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> make=0D=0A>>>>=0D=0A>>>>= =20=0D=0A>>>>> sure I understand the "rules" they have (validated l= ocation for=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> examples).=0D=0A>>= >>=0D=0A>>>> =20=0D=0A>>>>> When I press them for what they want to = do when something goes=0D=0Awrong=0D=0A>>>>> =20=0D=0A>> and=0D=0A= >> =20=0D=0A>>>> it=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> doesn't ha= ppen (like, validation fails, do they want unvalidated=0D=0A>>>>>=0D=0A>>>>= > =20=0D=0A>>>> location or=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>= >>> no location), they ALWAYS want the call, and they want the data=0D=0Ayo= u=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> have.=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>> They may treat the call with suspiscion. They may go b= ack later=0D=0Aand=0D=0A>>>>> =20=0D=0A>> try=0D=0A>> =20=0D=0A= >>>> to=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> figure out why they didn'= t get what they wanted but they take the=0D=0Acall=0D=0A>>>>>=0D=0A>>>>> = =20=0D=0A>>>> and=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> ask ques= tions later.=0D=0A>>>>>=0D=0A>>>>> So please don't make that assumption. Y= sa, we expect nearly all=0D=0Acalls=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A= >>>> to go=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> through a VSP, but the= system works if Marc Linsner's proxy in his=0D=0A>>>>> =20=0D=0A>= > house=0D=0A>> =20=0D=0A>>>>> sends the call to the PSAP.=0D=0A>>>>>=0D= =0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> That's fine. It is just the ques= tion what we write into the=0D=0Adocument.=0D=0A>>>> What is the default be= havior=3F=0D=0A>>>> We sent the calls directly to the PSAP or via the VSP=3F=0D= =0A>>>>=0D=0A>>>> This has impact for the phone BCP document. If you assume= that=0D=0Acalls=0D=0A>>>> =20=0D=0A>> are=0D=0A>> =20=0D=0A>>>> = routed through the VSP then the protocol run by the end point does=0D=0Anot=0D= =0A>>>> matter too much.=0D=0A>>>> If you assume that the end host MUST be = able to route directly to=0D=0Athe=0D=0A>>>> PSAP as well then you have to = mandate a certain functionality at=0D=0Athe=0D=0A>>>> =20=0D=0A>> en= d=0D=0A>> =20=0D=0A>>>> point.=0D=0A>>>>=0D=0A>>>> So, what behavior do = we want=3F=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>>> Having said= all that I believe that one important aspect, which=0D=0Ais=0D=0A>>>>>> = =20=0D=0A>> also=0D=0A>> =20=0D=0A>>>>>> different to architect= urs investigated by other SDOs, is that the=0D=0A>>>>>> =20=0D=0A= >> PSAP=0D=0A>> =20=0D=0A>>>>>> has to support a certain functionality. = This functionality is=0D=0A>>>>>> =20=0D=0A>> described=0D=0A>> = =20=0D=0A>>>>>> in the document but might not be too visible to the work= ing group=0D=0Aor=0D=0A>>>>>> =20=0D=0A>> at=0D=0A>> =20=0D=0A= >>>>>> least hasn't be advertised a lot.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>= > =20=0D=0A>>>>> Yes, this is true. We could make that more exp= licit.=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>>>= I believe we have to indicate quite close what the different=0D=0Aentities=0D= =0A>>>>>> have to support rather than meshing everything together. This=0D=0A= impacts=0D=0A>>>>>> the document structure a bit.=0D=0A>>>>>>=0D=0A>>>>>>=0D= =0A>>>>>> =20=0D=0A>>>>> Yes, we have thought about that a lot, = and have had some=0D=0Asuggestions=0D=0A>>>>> =20=0D=0A>> in=0D=0A= >> =20=0D=0A>>>> that=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> the dire= ction, the goal being to have all the BCPs for phones in=0D=0Aone=0D=0A>>>>= >=0D=0A>>>>> =20=0D=0A>>>> place,=0D=0A>>>>=0D=0A>>>> =20=0D= =0A>>>>> those for the access network in another place, etc.=0D=0A>>>>>=0D=0A= >>>>>=0D=0A>>>>> =20=0D=0A>>>> It's OK to have the required functi= onality listed in one document=0D=0Aeven=0D=0A>>>> though they address all = the involved parties in the architecture.=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>>> Here is a suggested structure for the document:=0D=0A>>= >>>>=0D=0A>>>>>> * Introduction=0D=0A>>>>>>=0D=0A>>>>>> Shorten the introdu= ction=0D=0A>>>>>>=0D=0A>>>>>> It contains a lot of info that is already ava= ilable in the=0D=0Aframework.=0D=0A>>>>>> This document has to be read in t= he context of the architecture=0D=0A>>>>>> =20=0D=0A>> anyway.=0D= =0A>> =20=0D=0A>>>>>> =20=0D=0A>>>>> We will do that=0D=0A>>>= >>=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>>> Btw, the intro= duction must not use RFC 2119 language.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>>= =20=0D=0A>>>>> Yes=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> = =20=0D=0A>>>>>> * Terminology=0D=0A>>>>>>=0D=0A>>>>>> Classical RF= C boilerplate and pointers to the requirements=0D=0Adocument.=0D=0A>>>>>>=0D= =0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>> =20=0D=0A>>>>>> * = End Host Profile=0D=0A>>>>>>=0D=0A>>>>>> This section just describes what i= s absolutely necessary for an=0D=0Aend=0D=0A>>>>>> point to support the=0D=0A= >>>>>>=0D=0A>>>>>> This is essentially the location part, the LoST part.=0D= =0A>>>>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5.=0D=0A>>= >>>> The LoST stuff can be found in Section 6.3.=0D=0A>>>>>>=0D=0A>>>>>> * = ISP Profile=0D=0A>>>>>>=0D=0A>>>>>> This is the location part. The server s= ide of Section 4.2.=0D=0A>>>>>> Optionally, LoST may be provided by the ISP= =2E=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>> You see w= here the problem is=3F You have the location part in both=0D=0AEnd=0D=0A>>= >>>=0D=0A>>>>> =20=0D=0A>>>> Host=0D=0A>>>>=0D=0A>>>> =20=0D= =0A>>>>> and ISP. Same with LoST.=0D=0A>>>>>=0D=0A>>>>> This is the proble= m with this suggestion. It actually makes as=0D=0Amuch=0D=0A>>>>>=0D=0A>>>= >> =20=0D=0A>>>> sense=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> t= o keep all the location information together as it does to keep=0D=0Aall=0D= =0A>>>>> =20=0D=0A>> the=0D=0A>> =20=0D=0A>>>> end=0D=0A>>>>=0D= =0A>>>> =20=0D=0A>>>>> host information together.=0D=0A>>>>>=0D=0A>>= >>> My best idea to address this is to leave the structure as is, but=0D=0A= to=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> make=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>> the BCP elements pulled out and labeled as to whom they= apply=0D=0A>>>>> =20=0D=0A>> (endpoint,=0D=0A>> =20=0D=0A>>>>>= VSP, ISP, PSAP). Then, after the functional sections, we can copy=0D=0Ath= e=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> BCP=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>> elements (only, not the other text) and sort them by who = they=0D=0Aapply=0D=0A>>>>> =20=0D=0A>> to.=0D=0A>> =20=0D=0A>>>= >>=0D=0A>>>>> =20=0D=0A>>>> It's not a big problem to consider loc= ation aspects at the ISP and=0D=0Aat=0D=0A>>>> the end host since the deman= ded functionality is, to some extend,=0D=0A>>>> different.=0D=0A>>>> In thi= s particular document we, for example, say that the ISP has=0D=0Ato=0D=0A>>= >> implement one of the location protocols and the client implements=0D=0Aa= ll=0D=0A>>>> =20=0D=0A>> of=0D=0A>> =20=0D=0A>>>> them.=0D=0A>>>>=0D= =0A>>>>=0D=0A>>>> =20=0D=0A>>>>>> * VSP Profile=0D=0A>>>>>>=0D=0A>>>= >>> Some parts from Section 5 and Section 6 could go in here. Might=0D=0Awa= nt=0D=0A>>>>>> =20=0D=0A>> to=0D=0A>> =20=0D=0A>>>>>> separat= e this into a separate sub-section to have a way to=0D=0Areference=0D=0A>>>= >>> =20=0D=0A>> it=0D=0A>> =20=0D=0A>>>>>> from the "End Host= Profile" section to say something like=0D=0A>>>>>> "When the end host impl= ements SIP then the VSP might want to use=0D=0Athe=0D=0A>>>>>> same functio= nality already at the client."=0D=0A>>>>>>=0D=0A>>>>>> The detailed conside= rations about SIP location conveyance are not=0D=0A>>>>>> necessary since t= hey can already be found in the SIP Location=0D=0A>>>>>>=0D=0A>>>>>> = =20=0D=0A>>>> Conveyance=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>>> do= cument already.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>= >> Actually, I think a lot of this text has to stay as it describes=0D=0Aho= w=0D=0A>>>>> =20=0D=0A>> you=0D=0A>> =20=0D=0A>>>> use=0D=0A>>>= >=0D=0A>>>> =20=0D=0A>>>>> the -conveyance mechanism. We'll take a = sharp look at it for=0D=0A>>>>> =20=0D=0A>> deletions.=0D=0A>> = =20=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>>> Section 6.2 does not wor= k with the general IETF emergency=0D=0A>>>>>> =20=0D=0A>> archit= ecture,=0D=0A>> =20=0D=0A>>>>>> as described in the ECRIT framework docu= ment. For example, the=0D=0Aproxy=0D=0A>>>>>> does not obtain location info= rmation since it cannot do so in the=0D=0A>>>>>> generic case.=0D=0A>>>>>>=0D= =0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>> I don't want IETF to be in = the position of not supporting proxy=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A= >>>> insertion of=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> location as, fo= r example, 3GPP does. I think we explicitly allow=0D=0Ait=0D=0A>>>>> = =20=0D=0A>> but=0D=0A>> =20=0D=0A>>>>> explain the difficulties.=0D=0A= >>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> The problem is that it d= oes not work together with the framework=0D=0A>>>> =20=0D=0A>> docum= ent.=0D=0A>> =20=0D=0A>>>> The framework document does not have a case f= or it.=0D=0A>>>>=0D=0A>>>> It's fine that the SIP Location Conveyance docum= ent has something=0D=0Ain=0D=0A>>>> there that could potentially be useful = for the 3GPP. The=0D=0Ainteresting=0D=0A>>>> case, however, is that the eme= rgency services architecture of the=0D=0A3GPP=0D=0A>>>> has the functionali= ty of the P-CSCF and the E-CSCF in the local=0D=0Anetwork=0D=0A>>>> and hen= ce they don't standardize the interaction with the PSAP,=0D=0Aunlike=0D=0A>= >>> we do because the PSAP in the IETF emergency services architecture=0D=0A= >>>> =20=0D=0A>> might=0D=0A>> =20=0D=0A>>>> get the call from an= arbitrary entity rather than from the local=0D=0A>>>> =20=0D=0A>> n= etwork=0D=0A>> =20=0D=0A>>>> operator.=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A= >>>>=0D=0A>>>> =20=0D=0A>>>>>> Section 8 is also relevant.=0D=0A>>>>= >>=0D=0A>>>>>>=0D=0A>>>>>> * PSAP Profile=0D=0A>>>>>>=0D=0A>>>>>> Section 6= =2E5 is relevant but only to the extend where the PSAP=0D=0A>>>>>> = =20=0D=0A>> operator=0D=0A>> =20=0D=0A>>>>>> network faces the outsid= e world. I don't think it is too relevant=0D=0Afor=0D=0A>>>>>> this documen= t to talk about PSAP network interal operator, such=0D=0Aas=0D=0A>>>>>> tra= nsferring a call to another PSAP operator.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>= >>> =20=0D=0A>>>>> Probably right, but the endpoint requirements= to support transfer=0D=0Amust=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>= stay=0D=0A>>>>=0D=0A>>>> That's fine=0D=0A>>>>=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>>> Section 8 is also relevant.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>= >>>>=0D=0A>>>>>> * Security Considerations=0D=0A>>>>>>=0D=0A>>>>>> Don't go= too much into the details since we talk about all the=0D=0Astuff=0D=0A>>>>= >> =20=0D=0A>> in=0D=0A>> =20=0D=0A>>>>>> other docs.=0D=0A>>= >>>>=0D=0A>>>>>>=0D=0A>>>>>> =20=0D=0A>>>>> If you say so. I'm = not sure we can get away with this. Can we=0D=0Aask=0D=0A>>>>> =0D= =0A>> you=0D=0A>> =20=0D=0A>>>> to=0D=0A>>>>=0D=0A>>>> =20=0D=0A>= >>>> get a security reviewer assigned sooner rather than later and we=0D=0A= can=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> work=0D=0A>>>>=0D=0A>>>> = =20=0D=0A>>>>> with him to see what we can accomplish with just refer= ences to=0D=0Aother=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> docs=3F=0D= =0A>>>>=0D=0A>>>> Good idea. We should do that.=0D=0A>>>>=0D=0A>>>>=0D=0A>>= >> =20=0D=0A>>>>>> The testing section is fine.=0D=0A>>>>>>=0D=0A>>>= >>>=0D=0A>>>>>> =20=0D=0A>>>>> Albeit it mixes endpoint and PSAP= BCP statements.=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>>>> = -- I am not so sure about the location update section.=0D=0A>>>>>>=0D=0A>>>= >>>=0D=0A>>>>>> =20=0D=0A>>>>> There is nothing to reference. I= t has to be somewhere else, and=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>= > referenced=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>> here, or here. This= is a use of presence (and presumably HELD).=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>= >>=0D=0A>>>>> =20=0D=0A>>>> Hmm. I have to re-read that part.=0D=0A= >>>>=0D=0A>>>>=0D=0A>>>> =20=0D=0A>>>>>> In any case: Try to make th= e document as short as possible.=0D=0A>>>>>>=0D=0A>>>>>>=0D=0A>>>>>> = =20=0D=0A>>>>> Okay=0D=0A>>>>>=0D=0A>>>>> Thanks for the suggestions=0D= =0A>>>>>=0D=0A>>>>>=0D=0A>>>>> =20=0D=0A>>>> Ciao=0D=0A>>>> Hannes=0D= =0A>>>>=0D=0A>>>> =20=0D=0A=0D=0A=0D=0A_____________________________= __________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps:/= /www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= This message is for the designated recipient only and may=0D=0Acontain priv= ileged, proprietary, or otherwise private information. =20=0D=0AIf you have= received it in error, please notify the sender=0D=0Aimmediately and delete= the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 17:49:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAByD-0007bb-0u; Sun, 15 Jul 2007 17:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAByB-0007bA-Gj; Sun, 15 Jul 2007 17:49:35 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IABy7-0006M8-5C; Sun, 15 Jul 2007 17:49:35 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6FLnQxo026648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 17:49:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sun, 15 Jul 2007 17:49:21 -0400 To: ECRIT X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: IESG Subject: [Ecrit] draft-ietf-ecrit-service-urn X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes pointed out that the service URN draft has been discussed in the IESG and I checked out the comments. I copied-and-pasted them below. I'll add some comments. > Has there been a urn-nid@apps.ietf.org review of this as > recommended by RFC 3406? > Yes, there was, many a moon ago (see http://www1.ietf.org/mail- archive/web/urn-nid/current/msg00410.html). > The registration should be owned by the IETF, to avoid the later > need for > an IESG action to change ownership in the event the ECRIT WG > completes. I'm not sure what this is referring to. Declared registrant of the namespace: Registering organization: IETF ECRIT Working Group Designated contact: Henning Schulzrinne Designated contact email: hgs@cs.columbia.edu ? I checked http://www.iana.org/assignments/urn-namespaces and all the examples seem to refer to non-IETF bodies. (Interestingly enough, the IETF name space itself is registered by a certain Ryan Moats.) > It strikes me as somewhat worrisome to standardize this URN before > standardizing the resolution method for the URN, but I understand > LOST is actively worked on. Should anything be said in this > document about what to do with the 'service' URN in cases of some > failure to resolve to a URL? LoST is somewhere beyond WG last call. I'm not sure that there is anything you can do if the resolution fails - I don't see a reasonable fall-back. > Agree with Russ on the title. Similarly, the abstract also doesn't > talk about ECRIT. Title will be modified in -07. > > > Section 3., paragraph 2: > > Declared registrant of the namespace: > > Registering organization: IETF ECRIT Working Group > > Can an ephemeral entity like a WG be a registrant? Should this be > "the > IETF" instead? (Question for the APP ADs.) For now, changed to IETF. Let me know if there's a better answer. > Commented by: > Lars Eggert > Comment: > Section 3., paragraph 4: > > service = top-level *("." sub-service) > > let-dig = ALPHA / DIGIT > > let-dig-hyp = let-dig / '-' > > sub-service = let-dig [ *let-dig-hyp let-dig ] > > top-level = let-dig [ *25let-dig-hyp let-dig ] > > DISCUSS: ABNF doesn't validate (3:26: error: Illegal character "'" - > skipping to end of line). Also, should cite RFC 4234 normatively for > ABNF. > Both fixed. > > I believe that the title of this document should be revised. The > current title does not include any indication that the document is > about ECRIT services. I recognize that the mechanism can be used > for non-emergency services (such as directory assistance). I > suggest: "A Uniform Resource Name (URN) for Emergency Services > and Other Well-Known Services" Changed to A Uniform Resource Name (URN) Namespace for Emergency and Other Well-Known Services Added sentence to abstract: Examples include emergency services, directory assistance and call-before-you-dig hot lines. I will submit -07 after the gates open again. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 20:07:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAE7R-0001VN-4n; Sun, 15 Jul 2007 20:07:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAE7Q-0001VI-Ew for ecrit@ietf.org; Sun, 15 Jul 2007 20:07:16 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAE7Q-0005kQ-6L for ecrit@ietf.org; Sun, 15 Jul 2007 20:07:16 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6G06dpf010107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 20:06:40 -0400 (EDT) In-Reply-To: <464254EB.1040205@ntt-at.com> References: <464254EB.1040205@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3D5A3ADC-0D50-46EF-B5EA-A34A2E24BE84@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Sun, 15 Jul 2007 20:06:37 -0400 To: shida@ntt-at.com X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ECRIT Subject: [Ecrit] Re: Review: draft-ietf-ecrit-mapping-arch-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Shida, thanks again for your comments, which I'm trying to integrate into -03. It will appear shortly at http://www.cs.columbia.edu/sip/draft/lost-arch/draft-ietf-ecrit- mapping-arch-03.html which I will update as this discussion unfolds. Please see inline below. On May 9, 2007, at 7:10 PM, Shida Schubert wrote: > Draft: draft-ietf-ecrit-mapping-arch-01 > Reviewer: Shida Schubert > Review Date: 2007.05.09 > > Summary: > ---------------------------------------- > - The draft looks really really good and solid and very > informative indeed. I think the draft is ready for WGLC if the > draft was a stand alone draft, but raises some questions on its > value when I view it as a draft providing overall picture for how > mapping works. > It may be simply because of my ignorance, but I had a really > hard time trying to map some of the logical entity to real world > deployment introduced in this draft such as forest guide. > It would be good to expand the text a bit to show for example > what entity would serve forest guide and what logical entity LoST > server generally serves etc. I've tried to add additional text to clarify that these are logical roles within the mapping architecture and that all of these are speaking LoST. Some, such as FGs, may also speak the sync extensions. > > > Technical Comments: > ---------------------------------------- > T1: Section 3, seeker. - Description of the seeker seems to > contradict what's mentioned in the section 5. In section 3, it is > clearly stated that skeeker may cache mapping result for its > own use and not provide any mapping service to others, yet > section 5 mentions about outbound proxy caching the mapping > result to provide its user.. How would the outbound > proxy provide the caching? I am assuming it is when it sees > LoST query from its user, wouldn't it be providing mapping > service once it's responding to a LoST query? > > I don't quite understand this comment. A SIP proxy is a (LoST) seeker in this architecture. The proxy issues queries and can cache the results locally. If it gets another SIP-carried location, it can thus consult its (seeker) cache and route the SIP request without issuing another LoST query to its resolver. Does that make sense? Henning > -- > Shida Sven Schubert shida@ntt-at.com PHONE: (604) 762-5606 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 15 20:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAEZs-0001iX-P0; Sun, 15 Jul 2007 20:36:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAEZr-0001iL-42 for ecrit@ietf.org; Sun, 15 Jul 2007 20:36:39 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAEZn-0001Lo-QP for ecrit@ietf.org; Sun, 15 Jul 2007 20:36:39 -0400 Received: from [192.168.0.41] (pool-70-21-209-10.nwrk.east.verizon.net [70.21.209.10]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l6G0aEKL007139 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 15 Jul 2007 20:36:18 -0400 (EDT) In-Reply-To: <4586DD67.70703@bbn.com> References: <4586DD67.70703@bbn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C7CA801-7DBB-42C0-A0C2-9FD1632A2CBB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Comments on draft-ietf-ecrit-mapping-arch-01 (definitions) Date: Sun, 15 Jul 2007 20:36:12 -0400 To: Matt Lepinski X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Matt, I'm finally, very belatedly, following up on some of your comments. You can see the intermediate results at http://www.cs.columbia.edu/sip/draft/lost-arch/draft-ietf-ecrit- mapping-arch-03.html Please see inline for comments; I will divide the response to avoid mile-long messages. I've elided parts that I've simply copied into the draft more or less verbatim. Henning On Dec 18, 2006, at 1:26 PM, Matt Lepinski wrote: > Henning, > > Here are some comments on draft-ietf-ecrit-mapping-arch-01. In > general, I like the current state of the document and therefore > many of my comments are just minor editorial suggestions. > > 3. Definitions > ----------------- > > - The term "region map" is defined but the term only appears in the > Security Considerations section. This may be acceptable, however, > consider deleting this definition and rewording the security > considerations section to use other terms. (Note: If the term > 'coverage region' were specifically defined, its definition could > include > Deleted. > - In Section 7.1 you state "The collection of all trees for one > service is known as a forest". For consistancy, you may want to > augment the definition of a Forest Guide as follows: "... the > coverage regions of all trees for a particular service". > Additionally, Section 7.1 indicates that (in a logical sense) each > tree provides mappings for a particular service. Therefore, you > might want to consider augmenting the definitoin of a tree in a > similar fashion: "... of authoritative mapping servers for a > particular service." Done. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 16 01:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAJaI-0003Zb-Qk; Mon, 16 Jul 2007 01:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAJaH-0003SE-IQ for ecrit@ietf.org; Mon, 16 Jul 2007 01:57:25 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAJaD-0007wH-68 for ecrit@ietf.org; Mon, 16 Jul 2007 01:57:25 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6G5vCRl028881; Sun, 15 Jul 2007 23:57:14 -0600 Message-ID: <469B08B6.8090401@ntt-at.com> Date: Sun, 15 Jul 2007 22:57:10 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Henning Schulzrinne References: <464254EB.1040205@ntt-at.com> <3D5A3ADC-0D50-46EF-B5EA-A34A2E24BE84@cs.columbia.edu> In-Reply-To: <3D5A3ADC-0D50-46EF-B5EA-A34A2E24BE84@cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: ECRIT Subject: [Ecrit] Re: Review: draft-ietf-ecrit-mapping-arch-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning; My comments inline.. >> Summary: >> ---------------------------------------- >> - The draft looks really really good and solid and very informative >> indeed. I think the draft is ready for WGLC if the draft was a >> stand alone draft, but raises some questions on its value when I >> view it as a draft providing overall picture for how mapping works. >> It may be simply because of my ignorance, but I had a really hard >> time trying to map some of the logical entity to real world >> deployment introduced in this draft such as forest guide. >> It would be good to expand the text a bit to show for example >> what entity would serve forest guide and what logical entity LoST >> server generally serves etc. > > I've tried to add additional text to clarify that these are logical > roles within the mapping architecture and that all of these are > speaking LoST. Some, such as FGs, may also speak the sync extensions. > The section 4 looks good with the added text.. Thanks. > >> >> >> Technical Comments: >> ---------------------------------------- >> T1: Section 3, seeker. - Description of the seeker seems to >> contradict what's mentioned in the section 5. In section 3, it is >> clearly stated that skeeker may cache mapping result for its own >> use and not provide any mapping service to others, yet section 5 >> mentions about outbound proxy caching the mapping result to provide >> its user.. How would the outbound >> proxy provide the caching? I am assuming it is when it sees LoST >> query from its user, wouldn't it be providing mapping service once >> it's responding to a LoST query? >> >> > > I don't quite understand this comment. A SIP proxy is a (LoST) seeker > in this architecture. The proxy issues queries and can cache the > results locally. If it gets another SIP-carried location, it can thus > consult its (seeker) cache and route the SIP request without issuing > another LoST query to its resolver. > Does that make sense? Yes it makes complete sense and it does not contradict the definition of section 3 at all. I am not sure what I was taking when I wrote this comment.. I can only assume what I had in mind, but I guess from the comment I wrote, I must have assumed that the SIP proxy would actually respond to LoST query sent from a UA and proxy the LoST query and cache the response from the resolver.. So after reading the text in section 3 once again, I see no problem with the text, the text looks good.. Thanks & Regards Shida > > Henning > > >> -- >> Shida Sven Schubert shida@ntt-at.com PHONE: (604) 762-5606 > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 16 04:26:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALuB-0006ZB-RA; Mon, 16 Jul 2007 04:26:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IALuA-0006Z6-7D for ecrit@ietf.org; Mon, 16 Jul 2007 04:26:06 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IALu8-00075w-Pe for ecrit@ietf.org; Mon, 16 Jul 2007 04:26:06 -0400 Received: (qmail invoked by alias); 16 Jul 2007 08:25:31 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp055) with SMTP; 16 Jul 2007 10:25:31 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+3+T031jm3QXhkmjLDka1qxjR0Amg1LPSrjUJA4P LJrQOL7RgnJhyb Message-ID: <469B2B7A.3070405@gmx.net> Date: Mon, 16 Jul 2007 10:25:30 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "Dawson, Martin" Subject: Re: [Ecrit] Phone BCP Draft Comments References: <4697EA76.60606@gmx.net><0dd401c7c657$b0db3980$c6e6a8c0@cis.neustar.com><46994251.5050201@gmx.net><0e6101c7c662$7e3f70d0$c6e6a8c0@cis.neustar.com><4699D6AA.2040104@gmx.net><0f1c01c7c6e2$97c95090$c6e6a8c0@cis.neustar.com> <469A25CF.5070302@gmx.net> 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: b081eb6a5bf2a87d9780cad244b3c5bd Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, Dawson, Martin wrote: > Hi Hannes, > > Well... I can imagine a proxy in a residential LAN that knows how to > talk HELD to the access provider network when the client device (e.g. > legacy ATA) does not know how to. So the proxy does the request on > behalf of the ATA and does the insertion on the outbound. > \ > I can imagine many scenarios as well The problem with all these things is that * we haven't described them clearly * there are a number of options * the client does not know in which environment it is in order get things to work. > I can imagine an Asterisk server in an enterprise that knows how to talk > to the enterprise LIS and requests and inserts location on behalf of the > standard phone form factor IP handsets that don't know how to do it > themselves. > I know that these things are possible and this would be very similar to the 3GPP emergency architecture where the user is actually at home. > In both cases, the option exists to route the call directly to whatever > URI the LoST service indicates is appropriate without any external VSP > being involved. > The VSP in this case would be the enterprise. > Or are you saying that these proxies are the "VSP" in these scenarios? > It's just a question of semantics? > > Ciao Hannes > Cheers, > Martin > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, 15 July 2007 11:49 PM > To: Brian Rosen > Cc: 'ECRIT' > Subject: Re: [Ecrit] Phone BCP Draft Comments > > Hi Brian, > > sure that's fine. But the problem is the following: What proxy should > add location information other than a proxy in the access network. > So far, such a proxy does not exist in our emergency services > architecture. Right? > > Ciao > Hannes > > Brian Rosen wrote: > >> Hannes >> >> I believe your opinion runs counter to consensus, and I'll bring this >> > up for > >> a hum at the meeting. I think most of us think endpoint insertion of >> location is preferred, but proxy insertion, under the right >> > circumstances, > >> is acceptable. >> >> Brian >> >> >> >>> -----Original Message----- >>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>> Sent: Sunday, July 15, 2007 4:11 AM >>> To: Brian Rosen >>> Cc: 'ECRIT' >>> Subject: Re: [Ecrit] Phone BCP Draft Comments >>> >>> Hi Brian, >>> >>> Brian Rosen wrote: >>> >>> >>>> The text now says that the phone applies normal outbound processing. >>>> >>>> >>> That >>> >>> >>>> would mean it sends calls to the VSP. That's what we want. >>>> >>>> Marc's phone would normally send calls to his house proxy. That is >>>> > what > >>>> >>>> >>> we >>> >>> >>>> want. >>>> >>>> >>>> >>> Typically, it would be the proxy of Marc's VoIP provider. >>> >>> >>>> Let us try my way with the organization and see if it accomplishes >>>> > what > >>>> >>>> >>> you >>> >>> >>>> want. If it's a mess, I'll look at doing it your way. >>>> >>>> I'll make sure we discuss proxy insertion of location in both >>>> > -framework > >>>> >>>> >>> and >>> >>> >>>> -phonebcp. I think it is best to state it is acceptable if the >>>> >>>> >>> limitations >>> >>> >>>> implied (VSP has a relationship with ISP, has a good identifier that >>>> > ISP > >>>> >>>> >>> can >>> >>> >>>> use) hold. >>>> >>>> >>>> >>> I don't think we have a place in our current architecture for the >>> > proxy > >>> insertion for location. >>> We should first discuss that aspect from an architectural point of >>> > view. > >>> Ciao >>> Hannes >>> >>> >>> >>> >>>> Brian >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>> Sent: Saturday, July 14, 2007 5:38 PM >>>>> To: Brian Rosen >>>>> Cc: 'ECRIT' >>>>> Subject: Re: [Ecrit] Phone BCP Draft Comments >>>>> >>>>> Hi Brian, >>>>> >>>>> thanks for the quick response. Please see my comments below: >>>>> >>>>> Brian Rosen wrote: >>>>> >>>>> >>>>> >>>>>> See in line >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>>>>>> Sent: Friday, July 13, 2007 5:11 PM >>>>>>> To: ECRIT >>>>>>> Subject: [Ecrit] Phone BCP Draft Comments >>>>>>> >>>>>>> Hi Brian, >>>>>>> Hi James, >>>>>>> Hi all, >>>>>>> >>>>>>> I like the document, as I expressed several times in the past. >>>>>>> >>>>>>> There are, however, a few issues with it. >>>>>>> >>>>>>> Henning and myself have recently written an ECRIT overview >>>>>>> > document. > >>>>>>> >>>>>>> >>>>> See >>>>> >>>>> >>>>> > http://tools.ietf.org/wg/ecrit/draft-tschofenig-ecrit-architecture- > >>>>>>> overview-00.txt >>>>>>> >>>>>>> One thing that was quite important for us to highlight was that >>>>>>> > the > >>>>>>> >>>>>>> >>>>> IETF >>>>> >>>>> >>>>> >>>>>>> emergency service architecture has a very nice property, namely >>>>>>> > the > >>>>>>> >>>>>>> >>>>> fact >>>>> >>>>> >>>>> >>>>>>> that different VoIP protocols may be supported between the end >>>>>>> > host > >>>>>>> >>>>>>> >>> and >>> >>> >>>>>>> the VoIP provider. There is no need to implement SIP only. >>>>>>> >>>>>>> Now, this document does not give me the impression that this >>>>>>> > aspect > >>>>>>> >>>>>>> >>> is >>> >>> >>>>>>> given enough consideration. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> There are two things that came to mind when I read this. One is >>>>>> > that > >>>>>> >>>>>> >>>>> you >>>>> >>>>> >>>>> >>>>>> are right, and we can be more clear that any protocol can be used >>>>>> >>>>>> >>>>>> >>>>> between >>>>> >>>>> >>>>> >>>>>> the endpoint and some kind of gateway that interworks to a >>>>>> > protocol > >>>>>> >>>>>> >>> that >>> >>> >>>>> the >>>>> >>>>> >>>>> >>>>>> PSAP implements. >>>>>> >>>>>> The other is that SIP need not be the only protocol the PSAP >>>>>> >>>>>> >>> implements. >>> >>> >>>>>> >>>>>> >>>>> That's certainly true. We do, however, have to start somewhere. We >>>>> cannot describe what Skype protocol features a PSAP has to >>>>> > implement > >>>>> >>>>> >>> for >>> >>> >>>>> an emergency service scenario. >>>>> >>>>> Hence, we focus only on SIP. That's already enough for a PSAP to >>>>> implement. >>>>> We do, however, only mandate functionality that is absolutely >>>>> > necessary > >>>>> for interoperability. >>>>> >>>>> >>>>> >>>>> >>>>>> However. There are some requirements on what the protocol needs to >>>>>> > do. > >>>>>> >>>>>> >>>>> We >>>>> >>>>> >>>>> >>>>>> should list them, and I think probably that discussion belongs in >>>>>> -framework. LoST already can return multiple URIs with different >>>>>> >>>>>> >>>>>> >>>>> schemes >>>>> >>>>> >>>>> >>>>>> corresponding to what it implements. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> It might be a good idea to state what protocols have to support -- >>>>> >>>>> >>> there >>> >>> >>>>> aren't too many things anyway. >>>>> >>>>> >>>>> >>>>> >>>>>>> The IETF emergency service architecture realistically requires >>>>>>> > that > >>>>>>> >>>>>>> >>> the >>> >>> >>>>>>> emergency calls are routed through the VSP in order to get >>>>>>> > identity > >>>>>>> information attached to an emergency call. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> NO!!!! >>>>>> >>>>>> That is NOT true. The PSAPs I work with will take calls that >>>>>> > don't > >>>>>> >>>>>> >>> come >>> >>> >>>>>> >from a VSP over the internet. >>>>>> >>>>>> >>>>>> >>>>> I guess you need to describe in more detail what you have seen. >>>>> >>>>> >>>>> >>>>> >>>>>> They may well have some suspicion on such >>>>>> calls due to the lack of a verifiable identity but they will take >>>>>> > the > >>>>>> >>>>>> >>>>> call >>>>> >>>>> >>>>> >>>>>> anyway. I've had numerous conversations with PSAP people who want >>>>>> > to > >>>>>> >>>>>> >>>>> make >>>>> >>>>> >>>>> >>>>>> sure I understand the "rules" they have (validated location for >>>>>> >>>>>> >>>>>> >>>>> examples). >>>>> >>>>> >>>>> >>>>>> When I press them for what they want to do when something goes >>>>>> > wrong > >>>>>> >>>>>> >>> and >>> >>> >>>>> it >>>>> >>>>> >>>>> >>>>>> doesn't happen (like, validation fails, do they want unvalidated >>>>>> >>>>>> >>>>>> >>>>> location or >>>>> >>>>> >>>>> >>>>>> no location), they ALWAYS want the call, and they want the data >>>>>> > you > >>>>>> >>>>>> >>>>> have. >>>>> >>>>> >>>>> >>>>>> They may treat the call with suspiscion. They may go back later >>>>>> > and > >>>>>> >>>>>> >>> try >>> >>> >>>>> to >>>>> >>>>> >>>>> >>>>>> figure out why they didn't get what they wanted but they take the >>>>>> > call > >>>>>> >>>>>> >>>>> and >>>>> >>>>> >>>>> >>>>>> ask questions later. >>>>>> >>>>>> So please don't make that assumption. Ysa, we expect nearly all >>>>>> > calls > >>>>>> >>>>>> >>>>> to go >>>>> >>>>> >>>>> >>>>>> through a VSP, but the system works if Marc Linsner's proxy in his >>>>>> >>>>>> >>> house >>> >>> >>>>>> sends the call to the PSAP. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> That's fine. It is just the question what we write into the >>>>> > document. > >>>>> What is the default behavior? >>>>> We sent the calls directly to the PSAP or via the VSP? >>>>> >>>>> This has impact for the phone BCP document. If you assume that >>>>> > calls > >>>>> >>>>> >>> are >>> >>> >>>>> routed through the VSP then the protocol run by the end point does >>>>> > not > >>>>> matter too much. >>>>> If you assume that the end host MUST be able to route directly to >>>>> > the > >>>>> PSAP as well then you have to mandate a certain functionality at >>>>> > the > >>>>> >>>>> >>> end >>> >>> >>>>> point. >>>>> >>>>> So, what behavior do we want? >>>>> >>>>> >>>>> >>>>> >>>>>>> Having said all that I believe that one important aspect, which >>>>>>> > is > >>>>>>> >>>>>>> >>> also >>> >>> >>>>>>> different to architecturs investigated by other SDOs, is that the >>>>>>> >>>>>>> >>> PSAP >>> >>> >>>>>>> has to support a certain functionality. This functionality is >>>>>>> >>>>>>> >>> described >>> >>> >>>>>>> in the document but might not be too visible to the working group >>>>>>> > or > >>>>>>> >>>>>>> >>> at >>> >>> >>>>>>> least hasn't be advertised a lot. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, this is true. We could make that more explicit. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I believe we have to indicate quite close what the different >>>>>>> > entities > >>>>>>> have to support rather than meshing everything together. This >>>>>>> > impacts > >>>>>>> the document structure a bit. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes, we have thought about that a lot, and have had some >>>>>> > suggestions > >>>>>> >>>>>> >>> in >>> >>> >>>>> that >>>>> >>>>> >>>>> >>>>>> the direction, the goal being to have all the BCPs for phones in >>>>>> > one > >>>>>> >>>>>> >>>>> place, >>>>> >>>>> >>>>> >>>>>> those for the access network in another place, etc. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> It's OK to have the required functionality listed in one document >>>>> > even > >>>>> though they address all the involved parties in the architecture. >>>>> >>>>> >>>>> >>>>> >>>>>>> Here is a suggested structure for the document: >>>>>>> >>>>>>> * Introduction >>>>>>> >>>>>>> Shorten the introduction >>>>>>> >>>>>>> It contains a lot of info that is already available in the >>>>>>> > framework. > >>>>>>> This document has to be read in the context of the architecture >>>>>>> >>>>>>> >>> anyway. >>> >>> >>>>>>> >>>>>>> >>>>>> We will do that >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Btw, the introduction must not use RFC 2119 language. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Yes >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> * Terminology >>>>>>> >>>>>>> Classical RFC boilerplate and pointers to the requirements >>>>>>> > document. > >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>>> * End Host Profile >>>>>>> >>>>>>> This section just describes what is absolutely necessary for an >>>>>>> > end > >>>>>>> point to support the >>>>>>> >>>>>>> This is essentially the location part, the LoST part. >>>>>>> This would essentially be Section 4.2, 4.3, 4.4, and 4.5. >>>>>>> The LoST stuff can be found in Section 6.3. >>>>>>> >>>>>>> * ISP Profile >>>>>>> >>>>>>> This is the location part. The server side of Section 4.2. >>>>>>> Optionally, LoST may be provided by the ISP. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> You see where the problem is? You have the location part in both >>>>>> > End > >>>>>> >>>>>> >>>>> Host >>>>> >>>>> >>>>> >>>>>> and ISP. Same with LoST. >>>>>> >>>>>> This is the problem with this suggestion. It actually makes as >>>>>> > much > >>>>>> >>>>>> >>>>> sense >>>>> >>>>> >>>>> >>>>>> to keep all the location information together as it does to keep >>>>>> > all > >>>>>> >>>>>> >>> the >>> >>> >>>>> end >>>>> >>>>> >>>>> >>>>>> host information together. >>>>>> >>>>>> My best idea to address this is to leave the structure as is, but >>>>>> > to > >>>>>> >>>>>> >>>>> make >>>>> >>>>> >>>>> >>>>>> the BCP elements pulled out and labeled as to whom they apply >>>>>> >>>>>> >>> (endpoint, >>> >>> >>>>>> VSP, ISP, PSAP). Then, after the functional sections, we can copy >>>>>> > the > >>>>>> >>>>>> >>>>> BCP >>>>> >>>>> >>>>> >>>>>> elements (only, not the other text) and sort them by who they >>>>>> > apply > >>>>>> >>>>>> >>> to. >>> >>> >>>>>> >>>>>> >>>>> It's not a big problem to consider location aspects at the ISP and >>>>> > at > >>>>> the end host since the demanded functionality is, to some extend, >>>>> different. >>>>> In this particular document we, for example, say that the ISP has >>>>> > to > >>>>> implement one of the location protocols and the client implements >>>>> > all > >>>>> >>>>> >>> of >>> >>> >>>>> them. >>>>> >>>>> >>>>> >>>>> >>>>>>> * VSP Profile >>>>>>> >>>>>>> Some parts from Section 5 and Section 6 could go in here. Might >>>>>>> > want > >>>>>>> >>>>>>> >>> to >>> >>> >>>>>>> separate this into a separate sub-section to have a way to >>>>>>> > reference > >>>>>>> >>>>>>> >>> it >>> >>> >>>>>>> from the "End Host Profile" section to say something like >>>>>>> "When the end host implements SIP then the VSP might want to use >>>>>>> > the > >>>>>>> same functionality already at the client." >>>>>>> >>>>>>> The detailed considerations about SIP location conveyance are not >>>>>>> necessary since they can already be found in the SIP Location >>>>>>> >>>>>>> >>>>>>> >>>>> Conveyance >>>>> >>>>> >>>>> >>>>>>> document already. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Actually, I think a lot of this text has to stay as it describes >>>>>> > how > >>>>>> >>>>>> >>> you >>> >>> >>>>> use >>>>> >>>>> >>>>> >>>>>> the -conveyance mechanism. We'll take a sharp look at it for >>>>>> >>>>>> >>> deletions. >>> >>> >>>>>> >>>>>> >>>>>>> Section 6.2 does not work with the general IETF emergency >>>>>>> >>>>>>> >>> architecture, >>> >>> >>>>>>> as described in the ECRIT framework document. For example, the >>>>>>> > proxy > >>>>>>> does not obtain location information since it cannot do so in the >>>>>>> generic case. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> I don't want IETF to be in the position of not supporting proxy >>>>>> >>>>>> >>>>>> >>>>> insertion of >>>>> >>>>> >>>>> >>>>>> location as, for example, 3GPP does. I think we explicitly allow >>>>>> > it > >>>>>> >>>>>> >>> but >>> >>> >>>>>> explain the difficulties. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> The problem is that it does not work together with the framework >>>>> >>>>> >>> document. >>> >>> >>>>> The framework document does not have a case for it. >>>>> >>>>> It's fine that the SIP Location Conveyance document has something >>>>> > in > >>>>> there that could potentially be useful for the 3GPP. The >>>>> > interesting > >>>>> case, however, is that the emergency services architecture of the >>>>> > 3GPP > >>>>> has the functionality of the P-CSCF and the E-CSCF in the local >>>>> > network > >>>>> and hence they don't standardize the interaction with the PSAP, >>>>> > unlike > >>>>> we do because the PSAP in the IETF emergency services architecture >>>>> >>>>> >>> might >>> >>> >>>>> get the call from an arbitrary entity rather than from the local >>>>> >>>>> >>> network >>> >>> >>>>> operator. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>> Section 8 is also relevant. >>>>>>> >>>>>>> >>>>>>> * PSAP Profile >>>>>>> >>>>>>> Section 6.5 is relevant but only to the extend where the PSAP >>>>>>> >>>>>>> >>> operator >>> >>> >>>>>>> network faces the outside world. I don't think it is too relevant >>>>>>> > for > >>>>>>> this document to talk about PSAP network interal operator, such >>>>>>> > as > >>>>>>> transferring a call to another PSAP operator. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Probably right, but the endpoint requirements to support transfer >>>>>> > must > >>>>>> >>>>>> >>>>> stay >>>>> >>>>> That's fine >>>>> >>>>> >>>>> >>>>> >>>>>>> Section 8 is also relevant. >>>>>>> >>>>>>> >>>>>>> >>>>>>> * Security Considerations >>>>>>> >>>>>>> Don't go too much into the details since we talk about all the >>>>>>> > stuff > >>>>>>> >>>>>>> >>> in >>> >>> >>>>>>> other docs. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> If you say so. I'm not sure we can get away with this. Can we >>>>>> > ask > >>>>>> >>>>>> >>> you >>> >>> >>>>> to >>>>> >>>>> >>>>> >>>>>> get a security reviewer assigned sooner rather than later and we >>>>>> > can > >>>>>> >>>>>> >>>>> work >>>>> >>>>> >>>>> >>>>>> with him to see what we can accomplish with just references to >>>>>> > other > >>>>>> >>>>>> >>>>> docs? >>>>> >>>>> Good idea. We should do that. >>>>> >>>>> >>>>> >>>>> >>>>>>> The testing section is fine. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Albeit it mixes endpoint and PSAP BCP statements. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -- I am not so sure about the location update section. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> There is nothing to reference. It has to be somewhere else, and >>>>>> >>>>>> >>>>>> >>>>> referenced >>>>> >>>>> >>>>> >>>>>> here, or here. This is a use of presence (and presumably HELD). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Hmm. I have to re-read that part. >>>>> >>>>> >>>>> >>>>> >>>>>>> In any case: Try to make the document as short as possible. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Okay >>>>>> >>>>>> Thanks for the suggestions >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> >>>>> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 16 17:16:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXw5-0008FM-2U; Mon, 16 Jul 2007 17:16:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAXw3-0008FD-LZ for ecrit@ietf.org; Mon, 16 Jul 2007 17:16:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IAXvz-0002bq-5h for ecrit@ietf.org; Mon, 16 Jul 2007 17:16:51 -0400 Received: (qmail invoked by alias); 16 Jul 2007 21:16:46 -0000 Received: from p549864A5.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.100.165] by mail.gmx.net (mp003) with SMTP; 16 Jul 2007 23:16:46 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18tsldKtTstilUOCipqXPDlu3vUPGKyFW8sKzSS+A FlGM6Gxf/zNgNc Message-ID: <469BE03A.50504@gmx.net> Date: Mon, 16 Jul 2007 23:16:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Ecrit] Preparation for the IETF ECRIT Meeting X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, there are a few items that should get resolved quickly and we will discuss them during the meeting: * LoST: Location Profiles We had a discussion about extending the location profiles in LoST. We need more feedback to either confirm or reject the suggestion. See http://www1.ietf.org/mail-archive/web/ecrit/current/msg04095.html * Phone BCP & Framework I recently suggested to restructure the phone BCP in order to get split the responsibilities a bit better. My proposal is here: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04100.html During this discussion a few issues surfaced or are still unresolved as part of previous discussions: - Proxy adding a location reference to an emergency call - Contact URI for resolving errors in database - Emergency Call marking http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace-00.txt - Usage of Identity information in an emergency call There are also two larger items that are still hanging around, namely - Unauthenticated emergency services - Location hiding It would be good to make some progress on the last two items as well. For the latter one we have spend already a considerable amount of discussion time and we have a document available: http://tools.ietf.org/wg/ecrit//draft-schulzrinne-ecrit-location-hiding-requirements-00.txt During the discussions about location hiding we also determined that there is a problem with calls that claim to be emergency calls but aren't. Richard wrote a document about it: http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt Are there other issues we need to keep an eye on? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 17 16:18:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtV9-0006D0-8x; Tue, 17 Jul 2007 16:18:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAtV7-0006By-0Y for ecrit@ietf.org; Tue, 17 Jul 2007 16:18:29 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IAtV4-0006Kw-AT for ecrit@ietf.org; Tue, 17 Jul 2007 16:18:28 -0400 Received: (qmail invoked by alias); 17 Jul 2007 20:18:24 -0000 Received: from p54984CE1.dip.t-dialin.net (EHLO [192.168.1.4]) [84.152.76.225] by mail.gmx.net (mp002) with SMTP; 17 Jul 2007 22:18:24 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19qhlBkL2dqlvie2evuLyRzvu9AApoIfsfX1mrwUx G/s5gEVPG16xhg Message-ID: <469D240B.80607@gmx.net> Date: Tue, 17 Jul 2007 22:18:19 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT , "ietf@ietf.org Discussion" 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: [Ecrit] Authority-to-Individuals Emergency Services Bar-BOF: Update X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, we plan to meet on MONDAY, July 23, 2007 during the lunch break (1130-1300) to speak about Authority-to-Individuals Emergency Services (Early Warning Systems). Updated information regarding the Bar-BOF can be found here: http://www.tschofenig.priv.at/twiki/bin/view/EmergencyServices/EarlyWarningBarBOF Please drop us a mail if you plan to attend (unless you did it already). Ciao Hannes & Steve _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 18 20:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBJgB-0002z5-PI; Wed, 18 Jul 2007 20:15:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBJft-0002Ao-Qm for ecrit@ietf.org; Wed, 18 Jul 2007 20:15:21 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBJfo-0004ea-U7 for ecrit@ietf.org; Wed, 18 Jul 2007 20:15:21 -0400 Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Jul 2007 01:15:12 +0100 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: [Ecrit] Preparation for the IETF ECRIT Meeting Date: Thu, 19 Jul 2007 01:15:04 +0100 Message-ID: <20B524BAC1567F48AE039F74BD294D19E748B3@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <469BE03A.50504@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Preparation for the IETF ECRIT Meeting Thread-Index: AcfH7qxRBrM4OLgXTaSZoJxCbH+GYgBqmwSw From: To: , X-OriginalArrivalTime: 19 Jul 2007 00:15:12.0108 (UTC) FILETIME=[DF8CE2C0:01C7C999] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes In the interest of moving the location profiles in LoST on I agree with both James and Henning as any thing that saves on complexity and promotes consistency is good with me.=20 Regards Steve Norreys -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: 16 July 2007 22:17 To: ECRIT Subject: [Ecrit] Preparation for the IETF ECRIT Meeting Hi all, there are a few items that should get resolved quickly and we will discuss them during the meeting: * LoST: Location Profiles We had a discussion about extending the location profiles in LoST. We need more feedback to either confirm or reject the suggestion. See http://www1.ietf.org/mail-archive/web/ecrit/current/msg04095.html * Phone BCP & Framework I recently suggested to restructure the phone BCP in order to get split the responsibilities a bit better. My proposal is here: http://www1.ietf.org/mail-archive/web/ecrit/current/msg04100.html During this discussion a few issues surfaced or are still unresolved as part of previous discussions: - Proxy adding a location reference to an emergency call - Contact URI for resolving errors in database - Emergency Call marking http://tools.ietf.org/id/draft-polk-ecrit-local-emergency-rph-namespace- 00.txt - Usage of Identity information in an emergency call There are also two larger items that are still hanging around, namely - Unauthenticated emergency services =20 - Location hiding It would be good to make some progress on the last two items as well.=20 For the latter one we have spend already a considerable amount of discussion time and we have a document available: http://tools.ietf.org/wg/ecrit//draft-schulzrinne-ecrit-location-hiding- requirements-00.txt During the discussions about location hiding we also determined that there is a problem with calls that claim to be emergency calls but aren't. Richard wrote a document about it: http://tools.ietf.org/wg/ecrit/draft-barnes-ecrit-auth-00.txt Are there other issues we need to keep an eye on? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 21 16:54:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLyX-0000LY-F1; Sat, 21 Jul 2007 16:54:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICLyW-0000LT-UN for ecrit@ietf.org; Sat, 21 Jul 2007 16:54:52 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1ICLyW-0003xS-3o for ecrit@ietf.org; Sat, 21 Jul 2007 16:54:52 -0400 Received: (qmail invoked by alias); 21 Jul 2007 20:54:50 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp019) with SMTP; 21 Jul 2007 22:54:50 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX186hRtzwUY62ZE4SBPqHsXWOF527bidBTohIRnBtX KiCNGBpN5wTO78 Message-ID: <46A27298.2000005@gmx.net> Date: Sat, 21 Jul 2007 22:54:48 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ECRIT 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: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Ecrit] Comments to draft-barnes-ecrit-auth-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, thanks for writing this document. I have a few comments: Section 2.1: Location and Service URN This is a very good summary of our currently assumed model. I am, however, not sure about the following statement: " An important restriction to the applicability of this solution is that it requires the asserter possess a location value that can serve as part of an authenticator. For instance, if the authenticator is to be carried an INVITE message, the UAC must have access to its own location (with some degree of precision). Since there are situations where UACs may not have access to their own location (in access networks prevent this), this solution must be embedded in SIP in such a way that it can be inserted by a UAC, a UAS, or a proxy. In addition, if the Geolocation header is used to convey the location used here, then the SIP embedding must take into account the usage restrictions in [location-conveyance]. " The UAC does not need to have access to precise location information. The considerations for "location hiding" apply here. I am not sure what you mean with the sentences in the later part of the paragraph Section 2.2: Asserter Identity This model assumes that the PSAP operators network asserts that it has received an emergency call. It furthermore assumes that the VSP is able to verify which identities are indeed PSAP operators. Hence, some white lists of PSAP operators need to made available. You want to use the Connected Identity for this purpose. Please let me know whether I correctly understood this solution. Section 2.3 Direct assertion From the description I got the impression that this is the plain SIP Identity. I cannot quite see how this prevents the attack. How does a VSP verify whether this is indeed an emergency call? Another solution would be to sign a LoST mapping response (with a service boundary). The SIP UA would then add the signed LoST mapping into the SIP message together with the location information it used for retrieving the mapping. The VSP would verify that a) the signature of the mapping is correct. b) compare the identity of the mapping server with a a whitelist of valid mapping servers c) verify whether the location information is contained in the service boundary. The problem is that this is again complex, i.e., by no means better than the current solution we use as a working assumption. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 08:30:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICx3q-0006nI-3T; Mon, 23 Jul 2007 08:30:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICx3p-0006n7-0W for ecrit@ietf.org; Mon, 23 Jul 2007 08:30:49 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICx3o-0004gk-II for ecrit@ietf.org; Mon, 23 Jul 2007 08:30:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 08:30:48 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ48pEZAZnmf/2dsb2JhbAA X-IronPort-AV: i="4.16,570,1175486400"; d="scan'208"; a="126744232:sNHT28971704" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NCUmne028605 for ; Mon, 23 Jul 2007 08:30:48 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NCUlWK024165 for ; Mon, 23 Jul 2007 12:30:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 08:30:29 -0400 Received: from [10.86.243.5] ([10.86.243.5]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 08:30:29 -0400 Message-ID: <46A49F6D.4050809@cisco.com> Date: Mon, 23 Jul 2007 08:30:37 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 12:30:29.0518 (UTC) FILETIME=[413A6AE0:01C7CD25] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1822; t=1185193848; x=1186057848; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20comments=20on=20draft-barnes-ecrit-auth-00 |Sender:=20 |To:=20ECRIT=20; bh=fA5NZd4Jmadp81ObhLgPYv141JnY04v8ILyFBRo+43g=; b=LCyS5moo1iYbCxhXimCMckU5Bse+4jbCb4CbQrFuHABVKQstrAU4gRQ2pchTbw6TNxQ8zxgE 6A+1wfCPf9Kjf9vmMumtd7jI+BGCi9A6h1nEo23Je1Vf6f7IKiWrt+dB; Authentication-Results: rtp-dkim-2; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ecrit] comments on draft-barnes-ecrit-auth-00 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org If my understanding is correct, the primary problem being addressed here is dealing with malicious callers that try and send emergency calls that are not really emergency calls. Is that correct? Furthermore, I think the fundamental assumption you are making is that a call is considered a valid emergency call if its routing will cause it to arrive at a PSAP. Consequently, the primary threat that is being addressed here are users that label calls as emergency calls, in order to get some kind of specialized treatment, but the calls don't go to a PSAP, but rather go to a friend or colleague. Is that correct? If so, you need to discuss this. The threat model here was very unclear. I'll note that this problem goes away if the VSP performs the location to PSAP mapping, not the UA. You might want to mention this as another solution. Section 2.2 - why does the identity of the caller, as asserted by the called party, indicate that this is an emergency call? I'd think you really want an assertion of role of the connected party - i.e., the 200 OK response to a call to a PSAP has a SAML document that attests that this 'user' is a PSAP. The draft talks about "authenticating" emergency services calls, but this term is not correct here. Authentication is establishment of identity of the originator of a message. That is not what we are doing here. I think this draft is about verification that a call is an emergency call. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 08:47:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxJj-0001eM-Ja; Mon, 23 Jul 2007 08:47:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxJj-0001eH-3v for ecrit@ietf.org; Mon, 23 Jul 2007 08:47:15 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICxJi-0003qi-OW for ecrit@ietf.org; Mon, 23 Jul 2007 08:47:15 -0400 X-SEF-Processed: 5_0_0_910__2007_07_23_07_55_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 23 Jul 2007 07:55:38 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jul 2007 07:47:12 -0500 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: [Ecrit] comments on draft-barnes-ecrit-auth-00 Date: Mon, 23 Jul 2007 07:47:09 -0500 Message-ID: In-Reply-To: <46A49F6D.4050809@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] comments on draft-barnes-ecrit-auth-00 Thread-Index: AcfNJU9CNXsUruCnRXiOImkR15QtsQAAaegg References: <46A49F6D.4050809@cisco.com> From: "Winterbottom, James" To: "Jonathan Rosenberg" , "ECRIT" X-OriginalArrivalTime: 23 Jul 2007 12:47:12.0296 (UTC) FILETIME=[96EE3280:01C7CD27] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org =0D=0A=0D=0A>=20=0D=0A> I'll note that this problem goes away if the VSP pe= rforms the location=0D=0A> to PSAP mapping, not the UA. You might want to m= ention this as another=0D=0A> solution.=0D=0A>=20=0D=0A=0D=0A[AJW] This is = only true if the end-point was given location in the first=0D=0Aplace and p= asses it on to the VSP. If the end-point is given a PSAP URI=0D=0Aand a loc= ation URI, for example, then the VSP is now no better off=0D=0Aunless it ha= s permission to dereference the URI. The notions of location=0D=0Ahiding th= at have been surfacing suggest that only the PSAP will have=0D=0Apermission= to dereference the location URI, so the VSP has no other=0D=0Aobvious way = of checking.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A----------------------------= --------------------------------------------------------------------=0D=0AT= his message is for the designated recipient only and may=0D=0Acontain privi= leged, proprietary, or otherwise private information. =20=0D=0AIf you have = received it in error, please notify the sender=0D=0Aimmediately and delete = the original. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A= ---------------------------------------------------------------------------= ---------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 10:45:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzAZ-0002qK-Pd; Mon, 23 Jul 2007 10:45:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzAY-0002ot-Qb for ecrit@ietf.org; Mon, 23 Jul 2007 10:45:54 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzAY-0008Ko-Fx for ecrit@ietf.org; Mon, 23 Jul 2007 10:45:54 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 10:45:54 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAH5cpEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,570,1175486400"; d="scan'208"; a="126766534:sNHT26930772" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NEjspO009315 for ; Mon, 23 Jul 2007 10:45:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6NEjdF7022026 for ; Mon, 23 Jul 2007 14:45:54 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 10:45:48 -0400 Received: from mlinsnerwxp ([10.21.120.147]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 10:45:47 -0400 From: "Marc Linsner" To: "'ECRIT'" Date: Mon, 23 Jul 2007 10:45:46 -0400 Message-ID: <005301c7cd38$280705c0$9378150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfNOCYn3VMFmimhQKWyl24gFyPcMg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 23 Jul 2007 14:45:47.0847 (UTC) FILETIME=[28211D70:01C7CD38] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=88; t=1185201954; x=1186065954; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20Reminder=20-=20Ad=20Hoc=20meeting=20today=20-=20Monday=2011=3 A30-1=3A00pm=20Salon=202=20-=203rd=20floor |Sender:=20 |To:=20=22'ECRIT'=22=20; bh=Gfx7Lb8dD9WsuqmIn7pjqMTHGDLYHxa7eMaMAhXTSFM=; b=Ld/1iAn+lNa9X4iQoBpc9RLz0P31kjuf5tW3oRpZN2FM5rTd9mwu7N2lb/U2nOQO+X21/eQE EHMnzavm8oJb4vwSzD8m/18AZGXAfrc5Fkq0LQtmsjqUqqkOTmdb5+9L; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [Ecrit] Reminder - Ad Hoc meeting today - Monday 11:30-1:00pm Salon 2 - 3rd floor X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is to discuss the 'authority to citizen' emergency communication Marc & Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 10:53:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzIC-0007ZY-8S; Mon, 23 Jul 2007 10:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzIA-0007Z3-T3 for ecrit@ietf.org; Mon, 23 Jul 2007 10:53:46 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzIA-0008Tc-7Y for ecrit@ietf.org; Mon, 23 Jul 2007 10:53:46 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2792582uge for ; Mon, 23 Jul 2007 07:53:45 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mJFcbE/00KreVs5FVV74FU0DOiAqsrW1vFN0bBLmqbYlIBTFGZ/qtTqxCBwjyFZNZtqkhcaRgXBr1pSG6LF4P+iorXJTDpCWKlJFginAzS51Q6mK/5OV6F8YPLJFTsrAzA8nCFS0lWjBDMKbBCHOUCudQQmGte0jkKLn1ma++yw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SC1zxEbLhBHfAhuvUSWs09w6psXwcdzC4YCulW2zhgaAsi0BwfIS3vYxY+HaJfr6G3xVcFY3Aep6uaA2k6DrfLEbftNzbQ4XewQSdJU+OymviLmFsdLM5WhjugJzAWiaLeeDKbXrfJMRxhmxS0/Y2QMB/vB/7xmU0KPZSslLMJ8= Received: by 10.67.88.17 with SMTP id q17mr4236556ugl.1185202425498; Mon, 23 Jul 2007 07:53:45 -0700 (PDT) Received: by 10.66.238.6 with HTTP; Mon, 23 Jul 2007 07:53:45 -0700 (PDT) Message-ID: <88ac5c710707230753jb3a0e12i4ade59b02b37a23@mail.gmail.com> Date: Mon, 23 Jul 2007 10:53:45 -0400 From: "Richard Barnes" To: ecrit@ietf.org Subject: Fwd: [Ecrit] comments on draft-barnes-ecrit-auth-00 In-Reply-To: <88ac5c710707230727ieb50b9fqa6a5b5bad8f49c2f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46A49F6D.4050809@cisco.com> <88ac5c710707230727ieb50b9fqa6a5b5bad8f49c2f@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ---------- Forwarded message ---------- From: Richard Barnes Date: Jul 23, 2007 10:27 AM Subject: Re: [Ecrit] comments on draft-barnes-ecrit-auth-00 To: Jonathan Rosenberg Jonathan, Thanks a lot for your comments. Some responses below: > If my understanding is correct, the primary problem being addressed here > is dealing with malicious callers that try and send emergency calls that > are not really emergency calls. Is that correct? Essentially, yes. I will add a better exposition of this problem in the next version. > Furthermore, I think > the fundamental assumption you are making is that a call is considered a > valid emergency call if its routing will cause it to arrive at a PSAP. > Consequently, the primary threat that is being addressed here are users > that label calls as emergency calls, in order to get some kind of > specialized treatment, but the calls don't go to a PSAP, but rather go > to a friend or colleague. Is that correct? I wouldn't characterize it quite that way. The basic assumption is that somebody (VSPs, ISPs, etc) will want to distinguish between emergency and non-emergency calls, based on some criterion. The distinguishing criterion could be the identity of either endpoint (To: or From:), or some explicit designation by a third-party authority. Presumably some action will be taken based on this distinction (e.g. changes in billing), that will make it attractive to have a call handled as an emergency call. So the threat is that the mechanism used for distinguishing emergency calls from non-emergency calls will be abused by non-emergency callers to obtain special treatment. > I'll note that this problem goes away if the VSP performs the location > to PSAP mapping, not the UA. You might want to mention this as another > solution. That solution only provides assurance to the VSP that does the mapping, not to any upstream or downstream entities. And in any case, a lot of the motivation for this document was the "location hiding" use case, where there's no location in the SIP message that the VSP can read (e.g., an access-controlled L-by-R). > Section 2.2 - why does the identity of the caller, as asserted by the > called party, indicate that this is an emergency call? I'd think you > really want an assertion of role of the connected party - i.e., the 200 > OK response to a call to a PSAP has a SAML document that attests that > this 'user' is a PSAP. First, note that the asserter is asserting its own identity; the called party asserts the identity of the callee, not the caller. The identity of the called party indicates that it is an emergency call because the identity presumably demonstrates that the called party is a PSAP. This is consistent with the definition of an emergency call used in the "location+URN" case (in which case the identity is the To AoR, and it is shown to be a PSAP via LoST). As far as direct assertions (like SAML), that's what I was trying to describe in section 2.3. > The draft talks about "authenticating" emergency services calls, but > this term is not correct here. Authentication is establishment of > identity of the originator of a message. That is not what we are doing > here. I think this draft is about verification that a call is an > emergency call. I was using the term in the sense the the mechanisms in the document "authenticate" the emergency status of the call (vs. the call itself), in that they demonstrate that the call is actually, authentically an emergency call. But it's just terminology, if people like verification better, we can change it to that. Thanks a lot, --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 11:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzWI-0001oo-1a; Mon, 23 Jul 2007 11:08:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzWG-0001oJ-Ly for ecrit@ietf.org; Mon, 23 Jul 2007 11:08:20 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICzWG-0007Vt-1O for ecrit@ietf.org; Mon, 23 Jul 2007 11:08:20 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ICzWE-0000Zi-4V; Mon, 23 Jul 2007 11:08:18 -0400 Message-ID: <46A4C45C.10904@bbn.com> Date: Mon, 23 Jul 2007 10:08:12 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Comments to draft-barnes-ecrit-auth-00.txt References: <46A27298.2000005@gmx.net> In-Reply-To: <46A27298.2000005@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes, Thanks for your comments. A few responses: > The UAC does not need to have access to precise location information. > The considerations for "location hiding" apply here. It doesn't need to have precise location, but it needs to have some location that's good enough for LoST. This may not be the case, e.g., if it just got the PSAP URIs through HELD. > I am not sure what you mean with the sentences in the later part of the > paragraph draft-ietf-sip-location-conveyance puts a few relevant restrictions on the use of the Geolocation header, including the specification of which request and response types can carry it. It also says that the value in the Geolocation header is always the location of the UAC. I was thinking that the UAS (the PSAP) might include ITS location in a Geolocation header, which would be a problem. > Section 2.2: Asserter Identity > > This model assumes that the PSAP operators network asserts that it has > received an emergency call. It furthermore assumes that the VSP is able > to verify which identities are indeed PSAP operators. Hence, some white > lists of PSAP operators need to made available. That's correct. I was imagining that you would have a dedicated authentication infrastructure for emergency services entities, so that if an entity were authenticated under this infrastructure, then you would know it's an emergency services entity. > You want to use the Connected Identity for this purpose. Yes, that's how a PSAP (as a UAS) could assert its identity. If you were thinking about authority-to-citizen, you use SIP Identity for the originating authority to authenticate its identity. > From the description I got the impression that this is the plain SIP > Identity. I cannot quite see how this prevents the attack. How does a > VSP verify whether this is indeed an emergency call? The idea behind 2.3 is something SAML-like: An asserter that has a credential that shows that it's authorized to assert emergency calls, like an emergency services gateway. The asserter inserts a marking (think SAML assertion) that asserts that the call is an emergency call. > Another solution would be to sign a LoST mapping response (with a > service boundary). The SIP UA would then add the signed LoST mapping > into the SIP message together with the location information it used for > retrieving the mapping. The VSP would verify that > a) the signature of the mapping is correct. > b) compare the identity of the mapping server with a a whitelist of > valid mapping servers > c) verify whether the location information is contained in the service > boundary. > > The problem is that this is again complex, i.e., by no means better than > the current solution we use as a working assumption. Using signed LoST responses could be a good option, one I'd like to discuss more. I'll split this off into a separate thread. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 11:17:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzfT-0004yV-Fs; Mon, 23 Jul 2007 11:17:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzfR-0004yO-SZ for ecrit@ietf.org; Mon, 23 Jul 2007 11:17:49 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICzfR-0007iR-Gy for ecrit@ietf.org; Mon, 23 Jul 2007 11:17:49 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ICzfR-0000iY-3Q; Mon, 23 Jul 2007 11:17:49 -0400 Message-ID: <46A4C698.8040106@bbn.com> Date: Mon, 23 Jul 2007 10:17:44 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Hannes Tschofenig References: <46A27298.2000005@gmx.net> In-Reply-To: <46A27298.2000005@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ECRIT Subject: [Ecrit] Signed LoST mappings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Another solution would be to sign a LoST mapping response (with a > service boundary). The SIP UA would then add the signed LoST mapping > into the SIP message together with the location information it used for > retrieving the mapping. The VSP would verify that > a) the signature of the mapping is correct. > b) compare the identity of the mapping server with a a whitelist of > valid mapping servers > c) verify whether the location information is contained in the service > boundary. I would make a couple of modifications: 1. Remove item (c) from the verification steps, since the location isn't really relevant (just that the destination is a PSAP). 2. Generalize item (b). It's not practical to maintain a global whitelist of mapping servers; what you'd want instead is some sort of "LoST PKI" that you would use to verify identities. You could have PKI hierarchies that correspond to tree hierarchies, with root tree nodes used as trust anchors, or you could use some FGs as trust anchors. I like this approach, because it only gives you one thing to credential, namely LoST servers. Chances are that the LoST infrastructure is going to require strong authentication anyway (to support peering and synchronization), so this is a good way to re-use that to support authentication of emergency calls. To summarize, then: Assertion: a) Include a signed LoST element in the SIP message Verification: a) Verify the signature on the element b) Verify that the signer is trusted c) Verify that the To: address for the dialog is contained in a Trust model: - Trust in LoST infrastructure and LoST credentialing authorities - Call is an emergency call if the To: address is a PSAP (as verified by a signed LoST mapping) Pros: - No location required - Very similar to the location+URN use case Cons: - Requires credentialing of LoST servers _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 11:54:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0F5-0004p1-Ku; Mon, 23 Jul 2007 11:54:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0F3-0004or-Qg for ecrit@ietf.org; Mon, 23 Jul 2007 11:54:37 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0F3-0000RI-Ca for ecrit@ietf.org; Mon, 23 Jul 2007 11:54:37 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 11:54:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMVrpEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,571,1175486400"; d="scan'208"; a="126773972:sNHT6448682410" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NFsS7Z010069; Mon, 23 Jul 2007 11:54:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NFrtWu009238; Mon, 23 Jul 2007 15:54:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 11:54:04 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.21.52]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 11:54:04 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jul 2007 10:54:00 -0500 To: Richard Barnes , Hannes Tschofenig From: "James M. Polk" Subject: Re: [Ecrit] Signed LoST mappings In-Reply-To: <46A4C698.8040106@bbn.com> References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2007 15:54:04.0279 (UTC) FILETIME=[B1CB0870:01C7CD41] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2223; t=1185206068; x=1186070068; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Signed=20LoST=20mappings=20 |Sender:=20 |To:=20Richard=20Barnes=20, =0A=20=20=20=20=20=20=20=20Ha nnes=20Tschofenig=20; bh=g4Lo76iW2ZVESGp8/jvf78Huz3D8HT8Rhp1MgBzeLhU=; b=ic0Sv2CCjALQ9u/0Mlvbx7aCgTFKnpMshJz4LW5yuScYaqGjgvx17REPiuQiG15uXluu3RmZ S6Tw6lIoqLkQPMx30SyUgIoVLrHYoc5PDupA+pnGuZIldnrbjJdh3SWx; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:17 AM 7/23/2007, Richard Barnes wrote: >>Another solution would be to sign a LoST mapping response (with a >>service boundary). The SIP UA would then add the signed LoST mapping >>into the SIP message together with the location information it used >>for retrieving the mapping. The VSP would verify that >>a) the signature of the mapping is correct. >>b) compare the identity of the mapping server with a a whitelist of >>valid mapping servers >>c) verify whether the location information is contained in the >>service boundary. > >I would make a couple of modifications: > >1. Remove item (c) from the verification steps, since the location >isn't really relevant (just that the destination is a PSAP). > >2. Generalize item (b). It's not practical to maintain a global >whitelist of mapping servers; what you'd want instead is some sort >of "LoST PKI" that you would use to verify identities. You could >have PKI hierarchies that correspond to tree hierarchies, with root >tree nodes used as trust anchors, or you could use some FGs as trust anchors. > >I like this approach, because it only gives you one thing to >credential, namely LoST servers. Chances are that the LoST >infrastructure is going to require strong authentication anyway (to >support peering and synchronization), so this is a good way to >re-use that to support authentication of emergency calls. > >To summarize, then: > >Assertion: >a) Include a signed LoST element in the SIP message exactly where is this in the SIP request? >Verification: >a) Verify the signature on the element >b) Verify that the signer is trusted >c) Verify that the To: address for the dialog is contained in a > >Trust model: >- Trust in LoST infrastructure and LoST credentialing authorities >- Call is an emergency call if the To: address is a PSAP (as >verified by a signed LoST mapping) > >Pros: >- No location required >- Very similar to the location+URN use case > >Cons: >- Requires credentialing of LoST servers > > > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 11:57:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0ID-0005oz-IC; Mon, 23 Jul 2007 11:57:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0IC-0005ou-SA for ecrit@ietf.org; Mon, 23 Jul 2007 11:57:52 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0IC-0000XC-Dy for ecrit@ietf.org; Mon, 23 Jul 2007 11:57:52 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1ID0IB-0001is-62; Mon, 23 Jul 2007 11:57:51 -0400 Message-ID: <46A4CFFB.2050301@bbn.com> Date: Mon, 23 Jul 2007 10:57:47 -0500 From: Richard Barnes User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: "James M. Polk" Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org James, In the spirit of separating authenticators from how they're carried in SIP, we haven't picked out a place in the SIP message for it. Seems most natural to me to include it as a body part. --Richard James M. Polk wrote: > At 10:17 AM 7/23/2007, Richard Barnes wrote: >>> Another solution would be to sign a LoST mapping response (with a >>> service boundary). The SIP UA would then add the signed LoST mapping >>> into the SIP message together with the location information it used >>> for retrieving the mapping. The VSP would verify that >>> a) the signature of the mapping is correct. >>> b) compare the identity of the mapping server with a a whitelist of >>> valid mapping servers >>> c) verify whether the location information is contained in the >>> service boundary. >> >> I would make a couple of modifications: >> >> 1. Remove item (c) from the verification steps, since the location >> isn't really relevant (just that the destination is a PSAP). >> >> 2. Generalize item (b). It's not practical to maintain a global >> whitelist of mapping servers; what you'd want instead is some sort of >> "LoST PKI" that you would use to verify identities. You could have >> PKI hierarchies that correspond to tree hierarchies, with root tree >> nodes used as trust anchors, or you could use some FGs as trust anchors. >> >> I like this approach, because it only gives you one thing to >> credential, namely LoST servers. Chances are that the LoST >> infrastructure is going to require strong authentication anyway (to >> support peering and synchronization), so this is a good way to re-use >> that to support authentication of emergency calls. >> >> To summarize, then: >> >> Assertion: >> a) Include a signed LoST element in the SIP message > > exactly where is this in the SIP request? > > >> Verification: >> a) Verify the signature on the element >> b) Verify that the signer is trusted >> c) Verify that the To: address for the dialog is contained in a >> >> Trust model: >> - Trust in LoST infrastructure and LoST credentialing authorities >> - Call is an emergency call if the To: address is a PSAP (as verified >> by a signed LoST mapping) >> >> Pros: >> - No location required >> - Very similar to the location+URN use case >> >> Cons: >> - Requires credentialing of LoST servers >> >> >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 12:27:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0kz-0006am-6e; Mon, 23 Jul 2007 12:27:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0kx-0006ah-RI for ecrit@ietf.org; Mon, 23 Jul 2007 12:27:35 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0kx-0001VO-AN for ecrit@ietf.org; Mon, 23 Jul 2007 12:27:35 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2007 12:27:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CALNzpEZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,571,1175486400"; d="scan'208"; a="126777909:sNHT65862124" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6NGRYBj027572; Mon, 23 Jul 2007 12:27:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6NGRYEj000694; Mon, 23 Jul 2007 16:27:34 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 12:27:20 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.21.52]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 12:27:20 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Jul 2007 11:27:15 -0500 To: Richard Barnes From: "James M. Polk" Subject: Re: [Ecrit] Signed LoST mappings In-Reply-To: <46A4CFFB.2050301@bbn.com> References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4CFFB.2050301@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 23 Jul 2007 16:27:20.0492 (UTC) FILETIME=[57A0F6C0:01C7CD46] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3455; t=1185208054; x=1186072054; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Signed=20LoST=20mappings |Sender:=20 |To:=20Richard=20Barnes=20; bh=r48Fy+spad/tuSEugGxLt8cTLRQ8Jx276cLxjm5FawQ=; b=V8bF0zQ/TEJFMn24fHBC2DRDn1l4y12rCRvXaYWe7TLtVmAsehkmH+dqx5qsMe+S7qJrZn8B ++sGjyXtiI52gAiuBLsWO358kaO7H373gDUbZQA4sdPCnI/jL9wos88n; Authentication-Results: rtp-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 10:57 AM 7/23/2007, Richard Barnes wrote: >James, > >In the spirit of separating authenticators from how they're carried >in SIP, we haven't picked out a place in the SIP message for >it. Seems most natural to me to include it as a body part. - this makes it only viable to the UAS (receiver), and not any servers - and I'm not sure you want that - you probably need a specific error (new or existing (with a new Warning or Reason code)) if it isn't processed correctly or is invalid - you might require a new option-tag to mandate support for this, because it can easily be ignored otherwise - this option-tag also allows you to mandate the recipient process this, otherwise the message fails (though this is usually reserved for SIP headers -- but I'm not sure where you are envisioning using this exactly) - will this be mandatory to process if present? - will SIP servers ever (need to) process this element? - I'm looking for why this new element is *not* a new PIDF element...? Especially if SIP doesn't use this. James >--Richard > > >James M. Polk wrote: >>At 10:17 AM 7/23/2007, Richard Barnes wrote: >>>>Another solution would be to sign a LoST mapping response (with a >>>>service boundary). The SIP UA would then add the signed LoST mapping >>>>into the SIP message together with the location information it >>>>used for retrieving the mapping. The VSP would verify that >>>>a) the signature of the mapping is correct. >>>>b) compare the identity of the mapping server with a a whitelist >>>>of valid mapping servers >>>>c) verify whether the location information is contained in the >>>>service boundary. >>> >>>I would make a couple of modifications: >>> >>>1. Remove item (c) from the verification steps, since the location >>>isn't really relevant (just that the destination is a PSAP). >>> >>>2. Generalize item (b). It's not practical to maintain a global >>>whitelist of mapping servers; what you'd want instead is some sort >>>of "LoST PKI" that you would use to verify identities. You could >>>have PKI hierarchies that correspond to tree hierarchies, with >>>root tree nodes used as trust anchors, or you could use some FGs >>>as trust anchors. >>> >>>I like this approach, because it only gives you one thing to >>>credential, namely LoST servers. Chances are that the LoST >>>infrastructure is going to require strong authentication anyway >>>(to support peering and synchronization), so this is a good way to >>>re-use that to support authentication of emergency calls. >>> >>>To summarize, then: >>> >>>Assertion: >>>a) Include a signed LoST element in the SIP message >>exactly where is this in the SIP request? >> >>>Verification: >>>a) Verify the signature on the element >>>b) Verify that the signer is trusted >>>c) Verify that the To: address for the dialog is contained in a >>> >>>Trust model: >>>- Trust in LoST infrastructure and LoST credentialing authorities >>>- Call is an emergency call if the To: address is a PSAP (as >>>verified by a signed LoST mapping) >>> >>>Pros: >>>- No location required >>>- Very similar to the location+URN use case >>> >>>Cons: >>>- Requires credentialing of LoST servers >>> >>> >>> >>> >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 12:36:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0tQ-0000TU-6g; Mon, 23 Jul 2007 12:36:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0tO-0000TO-SP for ecrit@ietf.org; Mon, 23 Jul 2007 12:36:18 -0400 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0tO-0001ji-8T for ecrit@ietf.org; Mon, 23 Jul 2007 12:36:18 -0400 Received: from [130.129.17.120] (dhcp-1178.ietf69.org [130.129.17.120]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6NGa0pa002451; Mon, 23 Jul 2007 10:36:00 -0600 Message-ID: <46A4D8E8.4050204@ntt-at.com> Date: Mon, 23 Jul 2007 09:35:52 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> In-Reply-To: <46A4C698.8040106@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, Comments inline.. Richard Barnes wrote: >> Another solution would be to sign a LoST mapping response (with a >> service boundary). The SIP UA would then add the signed LoST mapping >> into the SIP message together with the location information it used >> for retrieving the mapping. The VSP would verify that >> a) the signature of the mapping is correct. >> b) compare the identity of the mapping server with a a whitelist of >> valid mapping servers >> c) verify whether the location information is contained in the >> service boundary. > > I would make a couple of modifications: > > 1. Remove item (c) from the verification steps, since the location > isn't really relevant (just that the destination is a PSAP). > > 2. Generalize item (b). It's not practical to maintain a global > whitelist of mapping servers; what you'd want instead is some sort of > "LoST PKI" that you would use to verify identities. You could have > PKI hierarchies that correspond to tree hierarchies, with root tree > nodes used as trust anchors, or you could use some FGs as trust anchors. > > I like this approach, because it only gives you one thing to > credential, namely LoST servers. Chances are that the LoST > infrastructure is going to require strong authentication anyway (to > support peering and synchronization), so this is a good way to re-use > that to support authentication of emergency calls. > > To summarize, then: > > Assertion: > a) Include a signed LoST element in the SIP message The fact that you get LoST element indicates that UA has a location to query the LoST server to begin with. In which case, UA would naturally holds the location it used for mapping thus includes the location in the SIP request which can be utilized by VSP to verify the rigidness of emergency call by simply querying the LosT server itself. I thought you were trying to address a problem when location is not available neither for VSP nor UA while VSP wishes to verify that call indicated as an emergency call is really an emergency call. Use of connected-identity (C-ID) has some issues as well. AFAIK the C-ID requires calling party's device and called party's domain to support C-ID. It also uses UPDATE to send the C-ID and doesn't mandate when this UPDATE is sent. So the following issues may arise 1. I can call Hannes with indication that it's an emergency call, VSP forwards the call and I establish a call with Hannes and start talking to him as long as Hannes's device doesn't send UPDATE with connected-identity. 2. As far as I know C-ID although can be used by VSP to verify callee's identity, it is the UAC that actually set the option tag indicating the support for C-ID which is necessary information for UAS or callee's domain to trigger the C-ID process. So if UAC doesn't indicate that it supports C-ID (Although VSP supports it) using the defined option-tag, C-ID won't be sent from the callee. > > Verification: > a) Verify the signature on the element > b) Verify that the signer is trusted > c) Verify that the To: address for the dialog is contained in a > > Trust model: > - Trust in LoST infrastructure and LoST credentialing authorities > - Call is an emergency call if the To: address is a PSAP (as verified > by a signed LoST mapping) > > Pros: > - No location required > - Very similar to the location+URN use case > > Cons: > - Requires credentialing of LoST servers > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 12:56:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1D6-00026y-T9; Mon, 23 Jul 2007 12:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1D5-00026s-SX for ecrit@ietf.org; Mon, 23 Jul 2007 12:56:39 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID1D5-0003de-8m for ecrit@ietf.org; Mon, 23 Jul 2007 12:56:39 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2879938uge for ; Mon, 23 Jul 2007 09:56:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=R2E36JRxsLU/lLtkeOfukUHg26OnmnNxcO4M5rErmoKux6KVg7BiTNMys03J7PBWyEVCKT110u8pj4abztjSpTvrS0MPCAZ/WEXpunRB5shQVWAVvcA2iHzqnt31N5BYEmJVT5tj5BzEXVotbKg0R8PbM1luhRb2xM/zpUwZ2z4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bUFXlMPSEvONpbVphy4vM5gH2/zhK2t4K4sda6gklesJNm5oG0ywmyzJX0m9RK6nLuALF6lm2cmo0OO7xDWxFSh0y/RTNzjFvNCtIRm4YcURH+dHqHzvozwKDlG6rw0TBTKPQbmvDDlzefcZYvl4I6kOT0YN7BN90h13vKxFJ5Y= Received: by 10.67.26.7 with SMTP id d7mr4282581ugj.1185209798420; Mon, 23 Jul 2007 09:56:38 -0700 (PDT) Received: by 10.66.238.6 with HTTP; Mon, 23 Jul 2007 09:56:38 -0700 (PDT) Message-ID: <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> Date: Mon, 23 Jul 2007 11:56:38 -0500 From: "Richard Barnes" To: "Shida Schubert" Subject: Re: [Ecrit] Signed LoST mappings In-Reply-To: <46A4D8E8.4050204@ntt-at.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > The fact that you get LoST element indicates that UA has a > location to query the LoST server to begin with. Having a lost doesn't necessarily mean that the UA has the location -- it could be that someone else that has the location did the LoST lookup and passed the mapping to the UA. For instance, if the LCS (or other SIP configuration server) provided the . > Use of connected-identity (C-ID) has some issues as well. AFAIK the C-ID > requires calling party's device and called party's domain to support C-ID. > It also uses UPDATE to send the C-ID and doesn't mandate when this > UPDATE is sent. (I think you mean the "called party's device".) Since in the individual-to-authority case, all of these are PSAP/ESRP issues, I don't think theyr'e that big a deal. IP PSAPs will be new anyway, so they can be built to support C-ID, and they can be configured to send the UPDATE within a specified period. ISTM that this should be laid out in the phonebcp. > So the following issues may arise > 1. I can call Hannes with indication that it's an emergency call, VSP > forwards the > call and I establish a call with Hannes and start talking to him > as long as Hannes's > device doesn't send UPDATE with connected-identity. Yes, the idea would be to have a cut-off time specified in the phonebcp, after which the call would be considered unverified. > 2. As far as I know C-ID although can be used by VSP to verify > callee's identity, it is > the UAC that actually set the option tag indicating the support > for C-ID which is necessary > information for UAS or callee's domain to trigger the C-ID > process. So if UAC doesn't > indicate that it supports C-ID (Although VSP supports it) using > the defined option-tag, > C-ID won't be sent from the callee. I'm not intimately familiar with C-ID, so I'm not sure if this is a major issue or not. Couldn't a proxy that wants the authentication indicate it's support for C-ID? Thanks for your comments, --Richard > > > > Verification: > > a) Verify the signature on the element > > b) Verify that the signer is trusted > > c) Verify that the To: address for the dialog is contained in a > > > > Trust model: > > - Trust in LoST infrastructure and LoST credentialing authorities > > - Call is an emergency call if the To: address is a PSAP (as verified > > by a signed LoST mapping) > > > > Pros: > > - No location required > > - Very similar to the location+URN use case > > > > Cons: > > - Requires credentialing of LoST servers > > > > > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 12:57:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1Dh-0002Od-5R; Mon, 23 Jul 2007 12:57:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1Dg-0002OY-L7 for ecrit@ietf.org; Mon, 23 Jul 2007 12:57:16 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID1Df-0003eT-Uy for ecrit@ietf.org; Mon, 23 Jul 2007 12:57:16 -0400 Received: by ug-out-1314.google.com with SMTP id u2so2880387uge for ; Mon, 23 Jul 2007 09:57:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TyvW+o3lLUwCipUTAO3s0ZbgzfF6ng/yxxRxPg5seR1AzRFnhUiSHBucf+wTth8jqb5DYeJvNrGVDV3PuFFCeYpa1ESU9UKHKLdbCFLo9tGMK7InbZCAbiXUwGRtL5nhyayOXU1loDqZtA4bdLgqwsInQTpgrjoyyJRyXRTzmL0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IDhfB3u1y7NbfnbGLuZmH6I2AnugSQSQu6fSDrzbKGpisgea/wTcstASriFxg5T2bqIgtuTMT9Ft0mtD8a5ezwrWu2nGDJUqutO6NuviY3IAB6XHE/w9Qus6IsTYZxftITU+ab+Us6bDtSezi7JjBMnvzwHU+KWLvLsWOKVdF4E= Received: by 10.67.121.18 with SMTP id y18mr4297694ugm.1185209835331; Mon, 23 Jul 2007 09:57:15 -0700 (PDT) Received: by 10.66.238.6 with HTTP; Mon, 23 Jul 2007 09:57:15 -0700 (PDT) Message-ID: <88ac5c710707230957w1bfaa51es2d3cfbe9cdd58d51@mail.gmail.com> Date: Mon, 23 Jul 2007 11:57:15 -0500 From: "Richard Barnes" To: "James M. Polk" Subject: Re: [Ecrit] Signed LoST mappings In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4CFFB.2050301@bbn.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Ok, to be more specific, the concept would be analogous to the approach used by Geolocation -- you'd have a header pointing to a body part, and all the protocol machinery (warning codes, option tags, etc) would need to be defined. But I'd prefer not to get down into these details quite so soon. --Richard On 7/23/07, James M. Polk wrote: > At 10:57 AM 7/23/2007, Richard Barnes wrote: > >James, > > > >In the spirit of separating authenticators from how they're carried > >in SIP, we haven't picked out a place in the SIP message for > >it. Seems most natural to me to include it as a body part. > > - this makes it only viable to the UAS (receiver), and not any > servers - and I'm not sure you want that > - you probably need a specific error (new or existing (with a new > Warning or Reason code)) if it isn't processed correctly or is invalid > - you might require a new option-tag to mandate support for this, > because it can easily be ignored otherwise > - this option-tag also allows you to mandate the recipient process > this, otherwise the message fails (though this is usually reserved > for SIP headers -- but I'm not sure where you are envisioning using > this exactly) > - will this be mandatory to process if present? > - will SIP servers ever (need to) process this element? > > - I'm looking for why this new element is *not* a new PIDF > element...? Especially if SIP doesn't use this. > > James > > > > >--Richard > > > > > >James M. Polk wrote: > >>At 10:17 AM 7/23/2007, Richard Barnes wrote: > >>>>Another solution would be to sign a LoST mapping response (with a > >>>>service boundary). The SIP UA would then add the signed LoST mapping > >>>>into the SIP message together with the location information it > >>>>used for retrieving the mapping. The VSP would verify that > >>>>a) the signature of the mapping is correct. > >>>>b) compare the identity of the mapping server with a a whitelist > >>>>of valid mapping servers > >>>>c) verify whether the location information is contained in the > >>>>service boundary. > >>> > >>>I would make a couple of modifications: > >>> > >>>1. Remove item (c) from the verification steps, since the location > >>>isn't really relevant (just that the destination is a PSAP). > >>> > >>>2. Generalize item (b). It's not practical to maintain a global > >>>whitelist of mapping servers; what you'd want instead is some sort > >>>of "LoST PKI" that you would use to verify identities. You could > >>>have PKI hierarchies that correspond to tree hierarchies, with > >>>root tree nodes used as trust anchors, or you could use some FGs > >>>as trust anchors. > >>> > >>>I like this approach, because it only gives you one thing to > >>>credential, namely LoST servers. Chances are that the LoST > >>>infrastructure is going to require strong authentication anyway > >>>(to support peering and synchronization), so this is a good way to > >>>re-use that to support authentication of emergency calls. > >>> > >>>To summarize, then: > >>> > >>>Assertion: > >>>a) Include a signed LoST element in the SIP message > >>exactly where is this in the SIP request? > >> > >>>Verification: > >>>a) Verify the signature on the element > >>>b) Verify that the signer is trusted > >>>c) Verify that the To: address for the dialog is contained in a > >>> > >>>Trust model: > >>>- Trust in LoST infrastructure and LoST credentialing authorities > >>>- Call is an emergency call if the To: address is a PSAP (as > >>>verified by a signed LoST mapping) > >>> > >>>Pros: > >>>- No location required > >>>- Very similar to the location+URN use case > >>> > >>>Cons: > >>>- Requires credentialing of LoST servers > >>> > >>> > >>> > >>> > >>> > >>>_______________________________________________ > >>>Ecrit mailing list > >>>Ecrit@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 23 13:46:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1zV-00051w-2q; Mon, 23 Jul 2007 13:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1zT-0004yU-81 for ecrit@ietf.org; Mon, 23 Jul 2007 13:46:39 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID1zR-0005HI-Vr for ecrit@ietf.org; Mon, 23 Jul 2007 13:46:39 -0400 Received: from [130.129.17.120] (dhcp-1178.ietf69.org [130.129.17.120]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l6NHkOWx032431; Mon, 23 Jul 2007 11:46:25 -0600 Message-ID: <46A4E966.3080404@ntt-at.com> Date: Mon, 23 Jul 2007 10:46:14 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> In-Reply-To: <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Having a lost doesn't necessarily mean that the UA has the > location -- it could be that someone else that has the location did > the LoST lookup and passed the mapping to the UA. For instance, if > the LCS (or other SIP configuration server) provided the . > Okay. Obviously I overlooked that was to be provided by the LCS. > >> Use of connected-identity (C-ID) has some issues as well. AFAIK the C-ID >> requires calling party's device and called party's domain to support C-ID. >> It also uses UPDATE to send the C-ID and doesn't mandate when this >> UPDATE is sent. >> > > (I think you mean the "called party's device".) Since in the > individual-to-authority case, all of these are PSAP/ESRP issues, I > don't think theyr'e that big a deal. IP PSAPs will be new anyway, so > they can be built to support C-ID, and they can be configured to send > the UPDATE within a specified period. ISTM that this should be laid > out in the phonebcp. > Agree. Phone-BCP needs to cover this if we take this approach. > >> So the following issues may arise >> 1. I can call Hannes with indication that it's an emergency call, VSP >> forwards the >> call and I establish a call with Hannes and start talking to him >> as long as Hannes's >> device doesn't send UPDATE with connected-identity. >> > > Yes, the idea would be to have a cut-off time specified in the > phonebcp, after which the call would be considered unverified. > Agree. Same as above. > >> 2. As far as I know C-ID although can be used by VSP to verify >> callee's identity, it is >> the UAC that actually set the option tag indicating the support >> for C-ID which is necessary >> information for UAS or callee's domain to trigger the C-ID >> process. So if UAC doesn't >> indicate that it supports C-ID (Although VSP supports it) using >> the defined option-tag, >> C-ID won't be sent from the callee. >> > > I'm not intimately familiar with C-ID, so I'm not sure if this is a > major issue or not. Couldn't a proxy that wants the authentication > indicate it's support for C-ID? I agree what you suggest is possible, although I don't know what the spec says currently. It's also possible for PSAP to always add the C-ID, despite the lack of indication for the support of C-ID although it may be in conflict with the spec. Regards Shida > Thanks for your comments, > --Richard > > > > > > >>> Verification: >>> a) Verify the signature on the element >>> b) Verify that the signer is trusted >>> c) Verify that the To: address for the dialog is contained in a >>> >>> Trust model: >>> - Trust in LoST infrastructure and LoST credentialing authorities >>> - Call is an emergency call if the To: address is a PSAP (as verified >>> by a signed LoST mapping) >>> >>> Pros: >>> - No location required >>> - Very similar to the location+URN use case >>> >>> Cons: >>> - Requires credentialing of LoST servers >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >> >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 24 12:03:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMr5-000623-8a; Tue, 24 Jul 2007 12:03:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMr4-00061w-CR for ecrit@ietf.org; Tue, 24 Jul 2007 12:03:22 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMr3-0002lS-76 for ecrit@ietf.org; Tue, 24 Jul 2007 12:03:22 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l6OG31XX017245 for ; Tue, 24 Jul 2007 19:03:19 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 19:03:07 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 11:03:05 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jul 2007 11:03:04 -0500 Message-ID: In-Reply-To: <46A4E966.3080404@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ieee presentation in ecrit Thread-Index: AcfNUXQ7btcxxBDbRvaH8T0ytgicNgAtyb0A References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com><88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> <46A4E966.3080404@ntt-at.com> From: To: X-OriginalArrivalTime: 24 Jul 2007 16:03:05.0650 (UTC) FILETIME=[1EE37120:01C7CE0C] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Ecrit] ieee presentation in ecrit X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1316005339==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1316005339== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE0C.1EAE893E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE0C.1EAE893E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think some people missed this point during the discussion: 3gpp and other SDOs who adopted ieee .11 technology, started to work on the unauthenticated access by their own a while back. Thus, if ieee didn't address and provide a native solution for the unauthenticated case, then 3gpp/3gpp2, etc., would define their own solutions which would probably be different from each other, resulting in solutions tied to carriers. Would that be better? Requests like don't do it should be addressed to the carriers who may consider deploying it ... - gabor ------_=_NextPart_001_01C7CE0C.1EAE893E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ieee presentation in ecrit

I think some people missed this point = during the discussion:

3gpp and other SDOs who adopted ieee = .11 technology, started to work on the unauthenticated access by their = own a while back. Thus, if ieee didn't address and provide a native = solution for the unauthenticated case, then 3gpp/3gpp2, etc., would = define their own solutions which would probably be different from each = other, resulting in solutions tied to carriers. Would that be = better?

Requests like don't do it should be = addressed to the carriers who may consider deploying it …

 - gabor


------_=_NextPart_001_01C7CE0C.1EAE893E-- --===============1316005339== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1316005339==-- From ecrit-bounces@ietf.org Wed Jul 25 14:07:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlGs-0006wf-Hk; Wed, 25 Jul 2007 14:07:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDlGr-0006wD-MU for ecrit@ietf.org; Wed, 25 Jul 2007 14:07:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDlGq-0008K9-ES for ecrit@ietf.org; Wed, 25 Jul 2007 14:07:37 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2007 11:07:36 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAOYtp0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.16,581,1175497200"; d="scan'208"; a="188476529:sNHT31300425" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l6PI7Z9M020617 for ; Wed, 25 Jul 2007 11:07:35 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6PI7ET3024391 for ; Wed, 25 Jul 2007 18:07:35 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:07:32 -0400 Received: from jmpolk-wxp.cisco.com ([10.89.16.13]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 14:07:31 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 25 Jul 2007 13:07:31 -0500 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 25 Jul 2007 18:07:31.0992 (UTC) FILETIME=[AB969180:01C7CEE6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=944; t=1185386855; x=1186250855; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20draft-polk-ecrit-local-emergency-rph-namespace-01.txt=0A=20=2 0announcement |Sender:=20; bh=RAt9i6UeM1BVKOSF3959xK1icQHnREJqO5CYk2hTvDk=; b=kmBcU5dzD0aNiXE5iwwrQwxFbspaGiil0U+U2YDHx9QkneTckuabU+GhW88E9Vpnkpo+Erxp OMJfqWplSLczvtSahRRsbtsVgiMIsz6XZ0Eh+TE4z7PZsPK2l8xKWVPA; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] draft-polk-ecrit-local-emergency-rph-namespace-01.txt announcement X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org ECRIT This is the -01 version of the doc I was asked to present prior to anyone reading it (because I messed up submitted this one at the deadline) Comments are appreciated! >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > Title : IANA Registering a SIP Resource Priority > Header Namespace for Local Emergency Communications > Author(s) : J. Polk > Filename : > draft-polk-ecrit-local-emergency-rph-namespace-01.txt > Pages : 7 > Date : 2007-7-25 > >This document creates and IANA registers the new Session Initiation > Protocol (SIP) Resource Priority header (RPH) namespace "sos" for > local emergency usage to a public safety answering point (PSAP), > between PSAPs, and between a PSAP and first responders and their > organizations. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 25 18:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDovf-00016E-MI; Wed, 25 Jul 2007 18:01:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDove-00015z-BN for ecrit@ietf.org; Wed, 25 Jul 2007 18:01:58 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDove-0002Ua-2N for ecrit@ietf.org; Wed, 25 Jul 2007 18:01:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2007 18:01:57 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAIhcp0ZAZnmf/2dsb2JhbACDGQ X-IronPort-AV: i="4.16,581,1175486400"; d="scan'208"; a="127030647:sNHT22610134" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6PM1v61009001 for ; Wed, 25 Jul 2007 18:01:57 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6PM1vWI013979 for ; Wed, 25 Jul 2007 22:01:57 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 18:01:57 -0400 Received: from mlinsnerwxp ([10.82.211.117]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 18:01:57 -0400 From: "Marc Linsner" To: "'ECRIT'" Date: Wed, 25 Jul 2007 18:01:55 -0400 Message-ID: <009e01c7cf07$6b0cf340$2bf1520a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfPB1bs3wV9IquhRCGHP+Dd7ltiig== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-OriginalArrivalTime: 25 Jul 2007 22:01:57.0228 (UTC) FILETIME=[6B1F42C0:01C7CF07] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=89; t=1185400917; x=1186264917; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20ES=20Coordination=20Workshop |Sender:=20 |To:=20=22'ECRIT'=22=20; bh=OuVj+IMKfsHjxobuEQI1B+e8soHqAnZTqCDbzlCWY0o=; b=GAXUGcS7CBG9S5azkNDHD1L5q9HKikUeXdM5jVq0qitc1B/xEk0ALraQCQlPe8KejBN/vHtI RrVMGAzkhLfLj6TAIrvDLc9CIUyVTVIe1ICoHHp8NtLx8RuHxE/JHhzd; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ecrit] ES Coordination Workshop X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Fall 2007 http://www.emergency-services-coordination.info/2007Nov/ -Marc & Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 06:07:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSAC-0000gu-Lk; Mon, 30 Jul 2007 06:07:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSAB-0000gn-D3 for ecrit@ietf.org; Mon, 30 Jul 2007 06:07:43 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFSAB-0007Ka-3F for ecrit@ietf.org; Mon, 30 Jul 2007 06:07:43 -0400 Received: from [84.186.251.184] (p54BAFBB8.dip.t-dialin.net [84.186.251.184]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6UA7epQ013053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 06:07:41 -0400 (EDT) Message-ID: <46ADB86C.4080003@cs.columbia.edu> Date: Mon, 30 Jul 2007 12:07:40 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> In-Reply-To: <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > Yes, the idea would be to have a cut-off time specified in the > phonebcp, after which the call would be considered unverified. > You seem to be assuming some kind of call stateful model. SIP entities other than the end points or a B2BUA cannot terminate calls. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 06:12:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSEn-0001IE-Ks; Mon, 30 Jul 2007 06:12:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFSEn-0001I9-7b for ecrit@ietf.org; Mon, 30 Jul 2007 06:12:29 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFSEm-0008B6-Sf for ecrit@ietf.org; Mon, 30 Jul 2007 06:12:29 -0400 Received: from [84.186.251.184] (p54BAFBB8.dip.t-dialin.net [84.186.251.184]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6UACIHj006286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 06:12:24 -0400 (EDT) Message-ID: <46ADB983.6080907@cs.columbia.edu> Date: Mon, 30 Jul 2007 12:12:19 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> In-Reply-To: <46A4C698.8040106@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard Barnes wrote: > > I like this approach, because it only gives you one thing to credential, > namely LoST servers. Chances are that the LoST infrastructure is going > to require strong authentication anyway (to support peering and > synchronization), so this is a good way to re-use that to support > authentication of emergency calls. I don't think this follows. For LoST to work, you only need trust "up" the tree, i.e., a resolver needs to know that the forest guide it contacts is indeed the one it wants to talk to. It gets references to hosts, which it verifies in the same manner, without anything beyond verifying a binding between a domain name and a server certificate. All of this requires nothing more than a standard TLS host certificate that Verisign and others sell you today for your Apache server. This is a very different certification from "host foo.com is a legitimate LoST server" or even "foo.com is an authoritative LoST server for Jerusalem", whatever that may mean precisely. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 09:02:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUt5-0006SK-Ht; Mon, 30 Jul 2007 09:02:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFUt4-0006S3-Ea for ecrit@ietf.org; Mon, 30 Jul 2007 09:02:14 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFUt4-0004Yi-4f for ecrit@ietf.org; Mon, 30 Jul 2007 09:02:14 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFUt3-00054P-5b; Mon, 30 Jul 2007 09:02:13 -0400 Received: from col-dhcp33-244-154.bbn.com ([128.33.244.154] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IFUt3-0001XE-L8; Mon, 30 Jul 2007 09:02:13 -0400 Message-ID: <46ADE154.1070506@bbn.com> Date: Mon, 30 Jul 2007 09:02:12 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> <46ADB86C.4080003@cs.columbia.edu> In-Reply-To: <46ADB86C.4080003@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, >> Yes, the idea would be to have a cut-off time specified in the >> phonebcp, after which the call would be considered unverified. > > You seem to be assuming some kind of call stateful model. Any call status authentication model that uses any message other than the INVITE will likely require this sort of state. Otherwise, the verifying proxy has no way to know if the call never authenticates until after the call has finished. Note that this level of state (e.g., keeping track of all the messages in an INVITE transaction) is useful for things like accounting and billing as well, so VSPs may be doing it anyway. > SIP entities > other than the end points or a B2BUA cannot terminate calls. I didn't mean "cut-off time" in the sense of "time when the call is cut off," but rather in the sense of "time when a flag goes up that this call is not an emergency call." A VSP could use this signal to take whatever action it deems appropriate -- initiating billing, filing wire fraud charges, or (if it has a B2BUA in the path) terminating the call. --Richard _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 09:17:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFV7g-000625-4r; Mon, 30 Jul 2007 09:17:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFV7f-00061x-Hl for ecrit@ietf.org; Mon, 30 Jul 2007 09:17:19 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFV7f-0004ty-2Q for ecrit@ietf.org; Mon, 30 Jul 2007 09:17:19 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFV7e-0005P9-5L; Mon, 30 Jul 2007 09:17:18 -0400 Received: from col-dhcp33-244-154.bbn.com ([128.33.244.154] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IFV7e-0002Y3-G8; Mon, 30 Jul 2007 09:17:18 -0400 Message-ID: <46ADE4DD.5020000@bbn.com> Date: Mon, 30 Jul 2007 09:17:17 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> In-Reply-To: <46ADB983.6080907@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, ISTM that the assertions that LoST servers(and relying parties) are interested in would be something like "The holder of X public key is an authoritative LoST server for region Y" This is a parallel, but much different assertion than what the typical Verisign certificate says, i.e., "The holder of X public key is the holder of Y domain name." This statement has no relevance to LoST. Encoding such assertions in public-key certificates would result in an authentication infrastructure very much like the IP address / AS number PKI being developed in the SIDR WG: The multi-tree design and the existence of field guides in the mapping architecture complicates things a little, but the structure would be mostly the same within the trees. And the requirements for "resource holding" fields in the certificates are very similar. Three uses immediately come to mind: 1. LoST resolution security: Servers in the LoST heirarchy are assured of the identities of servers "up" the tree so that it knows that they're the ones it wants to talk to. 2. LoST provisioning security: Servers in the LoST heirarchy (and FGs) are assured of the identities of servers "down" the tree so that they know who's providing them information, e.g., coverage maps. Also applies to "lateral" peering among FGs. 3. Signed LoST mappings: When a third party gets a signed LoST mapping, he can verify that the signing party is the authoritative server for the given coverage area. This is what I had in mind in my earlier email. Hope this helps to clarify. --Richard Henning Schulzrinne wrote: > > > Richard Barnes wrote: > >> >> I like this approach, because it only gives you one thing to >> credential, namely LoST servers. Chances are that the LoST >> infrastructure is going to require strong authentication anyway (to >> support peering and synchronization), so this is a good way to re-use >> that to support authentication of emergency calls. > > I don't think this follows. For LoST to work, you only need trust "up" > the tree, i.e., a resolver needs to know that the forest guide it > contacts is indeed the one it wants to talk to. It gets references to > hosts, which it verifies in the same manner, without anything beyond > verifying a binding between a domain name and a server certificate. > > All of this requires nothing more than a standard TLS host certificate > that Verisign and others sell you today for your Apache server. This is > a very different certification from "host foo.com is a legitimate LoST > server" or even "foo.com is an authoritative LoST server for Jerusalem", > whatever that may mean precisely. > > Henning > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 12:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXfI-0007Fn-9i; Mon, 30 Jul 2007 12:00:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXfB-0007CF-Gn for ecrit@ietf.org; Mon, 30 Jul 2007 12:00:05 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFXfA-0001Jf-7o for ecrit@ietf.org; Mon, 30 Jul 2007 12:00:05 -0400 Received: from [84.186.251.184] (p54BAFBB8.dip.t-dialin.net [84.186.251.184]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6UFxneF019168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 11:59:55 -0400 (EDT) Message-ID: <46AE0AF6.1050705@cs.columbia.edu> Date: Mon, 30 Jul 2007 17:59:50 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> <46ADB86C.4080003@cs.columbia.edu> <46ADE154.1070506@bbn.com> In-Reply-To: <46ADE154.1070506@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard Barnes wrote: > Henning, > >>> Yes, the idea would be to have a cut-off time specified in the >>> phonebcp, after which the call would be considered unverified. >> >> You seem to be assuming some kind of call stateful model. > > Any call status authentication model that uses any message other than > the INVITE will likely require this sort of state. Otherwise, the > verifying proxy has no way to know if the call never authenticates until > after the call has finished. > > Note that this level of state (e.g., keeping track of all the messages > in an INVITE transaction) is useful for things like accounting and > billing as well, so VSPs may be doing it anyway. This is not the right forum for this discussions, but if a VSP relies on such capabilities, they are likely to be in (financial) trouble. One of the core assumptions for ECRIT is that we don't mess with SIP call flows or create emergency-specific call flows. > >> SIP entities other than the end points or a B2BUA cannot terminate calls. > > I didn't mean "cut-off time" in the sense of "time when the call is cut > off," but rather in the sense of "time when a flag goes up that this > call is not an emergency call." A VSP could use this signal to take > whatever action it deems appropriate -- initiating billing, filing wire > fraud charges, or (if it has a B2BUA in the path) terminating the call. See above. > > --Richard > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 12:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXlJ-00030E-UK; Mon, 30 Jul 2007 12:06:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFXlI-000305-9O for ecrit@ietf.org; Mon, 30 Jul 2007 12:06:24 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFXlH-0000U3-OQ for ecrit@ietf.org; Mon, 30 Jul 2007 12:06:24 -0400 Received: from [84.186.251.184] (p54BAFBB8.dip.t-dialin.net [84.186.251.184]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6UG685W018916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 12:06:14 -0400 (EDT) Message-ID: <46AE0C71.1090201@cs.columbia.edu> Date: Mon, 30 Jul 2007 18:06:09 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> In-Reply-To: <46ADE4DD.5020000@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Richard, That's what I assumed you meant. Unfortunately, this requires a world government or equivalent, which seems somewhat outside our scope to create or assume. Simply wishing that some global PKI comes into existence has a rather dismal track record of success. I don't know who is going to certify the authoritative LoST server for Taiwan or parts of the former Soviet Union, but I suspect that creating any kind of global PKI is going to be hard, particularly since the domain-level authenticity I described is likely to be sufficient for secure operation of the system. I'm curious as to whether there is any existing example, outside of emergency calling, of such a global role-based certification authority. Henning Richard Barnes wrote: > Henning, > > ISTM that the assertions that LoST servers(and relying parties) are > interested in would be something like > > "The holder of X public key is an authoritative LoST server for region Y" > > This is a parallel, but much different assertion than what the typical > Verisign certificate says, i.e., "The holder of X public key is the > holder of Y domain name." This statement has no relevance to LoST. > > Encoding such assertions in public-key certificates would result in an > authentication infrastructure very much like the IP address / AS number > PKI being developed in the SIDR WG: > > The multi-tree design and the existence of field guides in the mapping > architecture complicates things a little, but the structure would be > mostly the same within the trees. And the requirements for "resource > holding" fields in the certificates are very similar. > > Three uses immediately come to mind: > 1. LoST resolution security: Servers in the LoST heirarchy are assured > of the identities of servers "up" the tree so that it knows that they're > the ones it wants to talk to. > 2. LoST provisioning security: Servers in the LoST heirarchy (and FGs) > are assured of the identities of servers "down" the tree so that they > know who's providing them information, e.g., coverage maps. Also > applies to "lateral" peering among FGs. > 3. Signed LoST mappings: When a third party gets a signed LoST mapping, > he can verify that the signing party is the authoritative server for the > given coverage area. > > This is what I had in mind in my earlier email. Hope this helps to > clarify. > > --Richard > > > > > > > > Henning Schulzrinne wrote: >> >> >> Richard Barnes wrote: >> >>> >>> I like this approach, because it only gives you one thing to >>> credential, namely LoST servers. Chances are that the LoST >>> infrastructure is going to require strong authentication anyway (to >>> support peering and synchronization), so this is a good way to re-use >>> that to support authentication of emergency calls. >> >> I don't think this follows. For LoST to work, you only need trust "up" >> the tree, i.e., a resolver needs to know that the forest guide it >> contacts is indeed the one it wants to talk to. It gets references to >> hosts, which it verifies in the same manner, without anything beyond >> verifying a binding between a domain name and a server certificate. >> >> All of this requires nothing more than a standard TLS host certificate >> that Verisign and others sell you today for your Apache server. This >> is a very different certification from "host foo.com is a legitimate >> LoST server" or even "foo.com is an authoritative LoST server for >> Jerusalem", whatever that may mean precisely. >> >> Henning >> >> >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 12:53:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYVG-0001nm-8X; Mon, 30 Jul 2007 12:53:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYVF-0001nh-Hl for ecrit@ietf.org; Mon, 30 Jul 2007 12:53:53 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYVE-0001ZW-Qi for ecrit@ietf.org; Mon, 30 Jul 2007 12:53:53 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFYVE-0003dE-4j; Mon, 30 Jul 2007 12:53:52 -0400 Received: from col-dhcp33-244-154.bbn.com ([128.33.244.154] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IFYVE-0005Ru-AI; Mon, 30 Jul 2007 12:53:52 -0400 Message-ID: <46AE1796.8040102@bbn.com> Date: Mon, 30 Jul 2007 12:53:42 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> <46AE0C71.1090201@cs.columbia.edu> In-Reply-To: <46AE0C71.1090201@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, I encourage you to take a look at what the SIDR WG has been up to, namely defining a PKI that encodes assertions of the form "The holder of X public key is the holder of address space Y" "The holder of X public key is the holder of AS number Z" Administration of this PKI is globally distributed, and there will likely not be a single root, but rather a set of cross-certifications among the RIRs. This arrangement allows ISPs to validate certificates from the entire PKI based only on trust with their chosen RIR. This PKI is currently being implemented by the RIRs. To make the analogy with LoST, here's one way you could arrange things: 1. Each tree will have an autonomously administered, hierarchical PKI -- the LoST folks in Taiwan won't care about the LoST folks in the Ukraine, or Sierra Leone, or anywhere else. 2. FGs sign certificates for the roots of the trees with which they peer. I.e., they create certs that verify that "The holder of X public key is the root for region Y", given trust in the FG. 3. Seekers/resolvers use FG keys as trust anchors. If somebody gets something signed under this structure, he 1. Validates up to the root of the tree, then 2. Checks to see if any of his FGs vouch for that root. This model only requires local interactions, e.g.: 1. Each tree manages its own PKI. 2. Each FG only deals with the trees it already deals with. 3. Each seeker/resolver only deals with the FGs it already deals with. There's no global coordination needed here, only an augmentation of relationships already required by the mapping architecture. --Richard Henning Schulzrinne wrote: > Richard, > > That's what I assumed you meant. Unfortunately, this requires a world > government or equivalent, which seems somewhat outside our scope to > create or assume. Simply wishing that some global PKI comes into > existence has a rather dismal track record of success. I don't know who > is going to certify the authoritative LoST server for Taiwan or parts of > the former Soviet Union, but I suspect that creating any kind of global > PKI is going to be hard, particularly since the domain-level > authenticity I described is likely to be sufficient for secure operation > of the system. I'm curious as to whether there is any existing example, > outside of emergency calling, of such a global role-based certification > authority. > > Henning > > > Richard Barnes wrote: >> Henning, >> >> ISTM that the assertions that LoST servers(and relying parties) are >> interested in would be something like >> >> "The holder of X public key is an authoritative LoST server for region Y" >> >> This is a parallel, but much different assertion than what the typical >> Verisign certificate says, i.e., "The holder of X public key is the >> holder of Y domain name." This statement has no relevance to LoST. >> >> Encoding such assertions in public-key certificates would result in an >> authentication infrastructure very much like the IP address / AS >> number PKI being developed in the SIDR WG: >> >> The multi-tree design and the existence of field guides in the mapping >> architecture complicates things a little, but the structure would be >> mostly the same within the trees. And the requirements for "resource >> holding" fields in the certificates are very similar. >> >> Three uses immediately come to mind: >> 1. LoST resolution security: Servers in the LoST heirarchy are assured >> of the identities of servers "up" the tree so that it knows that >> they're the ones it wants to talk to. >> 2. LoST provisioning security: Servers in the LoST heirarchy (and FGs) >> are assured of the identities of servers "down" the tree so that they >> know who's providing them information, e.g., coverage maps. Also >> applies to "lateral" peering among FGs. >> 3. Signed LoST mappings: When a third party gets a signed LoST >> mapping, he can verify that the signing party is the authoritative >> server for the given coverage area. >> >> This is what I had in mind in my earlier email. Hope this helps to >> clarify. >> >> --Richard >> >> >> >> >> >> >> >> Henning Schulzrinne wrote: >>> >>> >>> Richard Barnes wrote: >>> >>>> >>>> I like this approach, because it only gives you one thing to >>>> credential, namely LoST servers. Chances are that the LoST >>>> infrastructure is going to require strong authentication anyway (to >>>> support peering and synchronization), so this is a good way to >>>> re-use that to support authentication of emergency calls. >>> >>> I don't think this follows. For LoST to work, you only need trust >>> "up" the tree, i.e., a resolver needs to know that the forest guide >>> it contacts is indeed the one it wants to talk to. It gets references >>> to hosts, which it verifies in the same manner, without anything >>> beyond verifying a binding between a domain name and a server >>> certificate. >>> >>> All of this requires nothing more than a standard TLS host >>> certificate that Verisign and others sell you today for your Apache >>> server. This is a very different certification from "host foo.com is >>> a legitimate LoST server" or even "foo.com is an authoritative LoST >>> server for Jerusalem", whatever that may mean precisely. >>> >>> Henning >>> >>> >>> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 13:23:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYxn-0008GP-3I; Mon, 30 Jul 2007 13:23:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYx3-0006j3-Sc for ecrit@ietf.org; Mon, 30 Jul 2007 13:22:37 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYsU-0002H2-Av for ecrit@ietf.org; Mon, 30 Jul 2007 13:17:58 -0400 Received: from [84.186.251.184] (p54BAFBB8.dip.t-dialin.net [84.186.251.184]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6UHHdfS006207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 13:17:45 -0400 (EDT) Message-ID: <46AE1D34.8080209@cs.columbia.edu> Date: Mon, 30 Jul 2007 19:17:40 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> <46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com> In-Reply-To: <46AE1796.8040102@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The problem is that the VSP in Sierra Leone will need to deal with their traveling customer visiting Taiwan (or the impostor pretending to visit Taiwan). These are in different trees, obviously. Richard Barnes wrote: > Henning, > > I encourage you to take a look at what the SIDR WG has been up to, > namely defining a PKI that encodes assertions of the form > > "The holder of X public key is the holder of address space Y" > "The holder of X public key is the holder of AS number Z" > > Administration of this PKI is globally distributed, and there will > likely not be a single root, but rather a set of cross-certifications > among the RIRs. This arrangement allows ISPs to validate certificates > from the entire PKI based only on trust with their chosen RIR. This PKI > is currently being implemented by the RIRs. > > To make the analogy with LoST, here's one way you could arrange things: > 1. Each tree will have an autonomously administered, hierarchical PKI -- > the LoST folks in Taiwan won't care about the LoST folks in the Ukraine, > or Sierra Leone, or anywhere else. > 2. FGs sign certificates for the roots of the trees with which they > peer. I.e., they create certs that verify that "The holder of X public > key is the root for region Y", given trust in the FG. > 3. Seekers/resolvers use FG keys as trust anchors. > > If somebody gets something signed under this structure, he > 1. Validates up to the root of the tree, then > 2. Checks to see if any of his FGs vouch for that root. > > This model only requires local interactions, e.g.: > 1. Each tree manages its own PKI. > 2. Each FG only deals with the trees it already deals with. > 3. Each seeker/resolver only deals with the FGs it already deals with. > > There's no global coordination needed here, only an augmentation of > relationships already required by the mapping architecture. > > --Richard > > > > Henning Schulzrinne wrote: >> Richard, >> >> That's what I assumed you meant. Unfortunately, this requires a world >> government or equivalent, which seems somewhat outside our scope to >> create or assume. Simply wishing that some global PKI comes into >> existence has a rather dismal track record of success. I don't know >> who is going to certify the authoritative LoST server for Taiwan or >> parts of the former Soviet Union, but I suspect that creating any kind >> of global PKI is going to be hard, particularly since the domain-level >> authenticity I described is likely to be sufficient for secure >> operation of the system. I'm curious as to whether there is any >> existing example, outside of emergency calling, of such a global >> role-based certification authority. >> >> Henning >> >> >> Richard Barnes wrote: >>> Henning, >>> >>> ISTM that the assertions that LoST servers(and relying parties) are >>> interested in would be something like >>> >>> "The holder of X public key is an authoritative LoST server for >>> region Y" >>> >>> This is a parallel, but much different assertion than what the >>> typical Verisign certificate says, i.e., "The holder of X public key >>> is the holder of Y domain name." This statement has no relevance to >>> LoST. >>> >>> Encoding such assertions in public-key certificates would result in >>> an authentication infrastructure very much like the IP address / AS >>> number PKI being developed in the SIDR WG: >>> >>> The multi-tree design and the existence of field guides in the >>> mapping architecture complicates things a little, but the structure >>> would be mostly the same within the trees. And the requirements for >>> "resource holding" fields in the certificates are very similar. >>> >>> Three uses immediately come to mind: >>> 1. LoST resolution security: Servers in the LoST heirarchy are >>> assured of the identities of servers "up" the tree so that it knows >>> that they're the ones it wants to talk to. >>> 2. LoST provisioning security: Servers in the LoST heirarchy (and >>> FGs) are assured of the identities of servers "down" the tree so that >>> they know who's providing them information, e.g., coverage maps. >>> Also applies to "lateral" peering among FGs. >>> 3. Signed LoST mappings: When a third party gets a signed LoST >>> mapping, he can verify that the signing party is the authoritative >>> server for the given coverage area. >>> >>> This is what I had in mind in my earlier email. Hope this helps to >>> clarify. >>> >>> --Richard >>> >>> >>> >>> >>> >>> >>> >>> Henning Schulzrinne wrote: >>>> >>>> >>>> Richard Barnes wrote: >>>> >>>>> >>>>> I like this approach, because it only gives you one thing to >>>>> credential, namely LoST servers. Chances are that the LoST >>>>> infrastructure is going to require strong authentication anyway (to >>>>> support peering and synchronization), so this is a good way to >>>>> re-use that to support authentication of emergency calls. >>>> >>>> I don't think this follows. For LoST to work, you only need trust >>>> "up" the tree, i.e., a resolver needs to know that the forest guide >>>> it contacts is indeed the one it wants to talk to. It gets >>>> references to hosts, which it verifies in the same manner, without >>>> anything beyond verifying a binding between a domain name and a >>>> server certificate. >>>> >>>> All of this requires nothing more than a standard TLS host >>>> certificate that Verisign and others sell you today for your Apache >>>> server. This is a very different certification from "host foo.com is >>>> a legitimate LoST server" or even "foo.com is an authoritative LoST >>>> server for Jerusalem", whatever that may mean precisely. >>>> >>>> Henning >>>> >>>> >>>> >>> >> >> > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 13:27:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ24-0001XE-6Z; Mon, 30 Jul 2007 13:27:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZ23-0001Wn-5E for ecrit@ietf.org; Mon, 30 Jul 2007 13:27:47 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFZ22-0003c6-32 for ecrit@ietf.org; Mon, 30 Jul 2007 13:27:47 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFZ21-00026P-5e; Mon, 30 Jul 2007 13:27:45 -0400 Received: from col-dhcp33-244-154.bbn.com ([128.33.244.154] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IFZ21-0000MV-HG; Mon, 30 Jul 2007 13:27:45 -0400 Message-ID: <46AE1F98.4050404@bbn.com> Date: Mon, 30 Jul 2007 13:27:52 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> <46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com> <46AE1D34.8080209@cs.columbia.edu> In-Reply-To: <46AE1D34.8080209@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Yes, whoever validates the signature an object signed by the Taiwanese LoST server will need to get certificates from Taiwanese tree. This is not a hard problem: There are existing mechanisms to do this using LDAP, FTP, and HTTP (RFC 2559 and 2589). The RIRs are just throwing everything in one big, distributed database that ISPs fetch using rsync. Also, remember that this validation doesn't necessarily have to be done in real time with the call. I think it was Barbara that said in an earlier discussion that it would be good enough to have a forensic capability. --RB Henning Schulzrinne wrote: > The problem is that the VSP in Sierra Leone will need to deal with their > traveling customer visiting Taiwan (or the impostor pretending to visit > Taiwan). These are in different trees, obviously. > > Richard Barnes wrote: >> Henning, >> >> I encourage you to take a look at what the SIDR WG has been up to, >> namely defining a PKI that encodes assertions of the form >> >> "The holder of X public key is the holder of address space Y" >> "The holder of X public key is the holder of AS number Z" >> >> Administration of this PKI is globally distributed, and there will >> likely not be a single root, but rather a set of cross-certifications >> among the RIRs. This arrangement allows ISPs to validate certificates >> from the entire PKI based only on trust with their chosen RIR. This >> PKI is currently being implemented by the RIRs. >> >> To make the analogy with LoST, here's one way you could arrange things: >> 1. Each tree will have an autonomously administered, hierarchical PKI >> -- the LoST folks in Taiwan won't care about the LoST folks in the >> Ukraine, or Sierra Leone, or anywhere else. >> 2. FGs sign certificates for the roots of the trees with which they >> peer. I.e., they create certs that verify that "The holder of X >> public key is the root for region Y", given trust in the FG. >> 3. Seekers/resolvers use FG keys as trust anchors. >> >> If somebody gets something signed under this structure, he >> 1. Validates up to the root of the tree, then >> 2. Checks to see if any of his FGs vouch for that root. >> >> This model only requires local interactions, e.g.: >> 1. Each tree manages its own PKI. >> 2. Each FG only deals with the trees it already deals with. >> 3. Each seeker/resolver only deals with the FGs it already deals with. >> >> There's no global coordination needed here, only an augmentation of >> relationships already required by the mapping architecture. >> >> --Richard >> >> >> >> Henning Schulzrinne wrote: >>> Richard, >>> >>> That's what I assumed you meant. Unfortunately, this requires a world >>> government or equivalent, which seems somewhat outside our scope to >>> create or assume. Simply wishing that some global PKI comes into >>> existence has a rather dismal track record of success. I don't know >>> who is going to certify the authoritative LoST server for Taiwan or >>> parts of the former Soviet Union, but I suspect that creating any >>> kind of global PKI is going to be hard, particularly since the >>> domain-level authenticity I described is likely to be sufficient for >>> secure operation of the system. I'm curious as to whether there is >>> any existing example, outside of emergency calling, of such a global >>> role-based certification authority. >>> >>> Henning >>> >>> >>> Richard Barnes wrote: >>>> Henning, >>>> >>>> ISTM that the assertions that LoST servers(and relying parties) are >>>> interested in would be something like >>>> >>>> "The holder of X public key is an authoritative LoST server for >>>> region Y" >>>> >>>> This is a parallel, but much different assertion than what the >>>> typical Verisign certificate says, i.e., "The holder of X public key >>>> is the holder of Y domain name." This statement has no relevance to >>>> LoST. >>>> >>>> Encoding such assertions in public-key certificates would result in >>>> an authentication infrastructure very much like the IP address / AS >>>> number PKI being developed in the SIDR WG: >>>> >>>> The multi-tree design and the existence of field guides in the >>>> mapping architecture complicates things a little, but the structure >>>> would be mostly the same within the trees. And the requirements for >>>> "resource holding" fields in the certificates are very similar. >>>> >>>> Three uses immediately come to mind: >>>> 1. LoST resolution security: Servers in the LoST heirarchy are >>>> assured of the identities of servers "up" the tree so that it knows >>>> that they're the ones it wants to talk to. >>>> 2. LoST provisioning security: Servers in the LoST heirarchy (and >>>> FGs) are assured of the identities of servers "down" the tree so >>>> that they know who's providing them information, e.g., coverage >>>> maps. Also applies to "lateral" peering among FGs. >>>> 3. Signed LoST mappings: When a third party gets a signed LoST >>>> mapping, he can verify that the signing party is the authoritative >>>> server for the given coverage area. >>>> >>>> This is what I had in mind in my earlier email. Hope this helps to >>>> clarify. >>>> >>>> --Richard >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Henning Schulzrinne wrote: >>>>> >>>>> >>>>> Richard Barnes wrote: >>>>> >>>>>> >>>>>> I like this approach, because it only gives you one thing to >>>>>> credential, namely LoST servers. Chances are that the LoST >>>>>> infrastructure is going to require strong authentication anyway >>>>>> (to support peering and synchronization), so this is a good way to >>>>>> re-use that to support authentication of emergency calls. >>>>> >>>>> I don't think this follows. For LoST to work, you only need trust >>>>> "up" the tree, i.e., a resolver needs to know that the forest guide >>>>> it contacts is indeed the one it wants to talk to. It gets >>>>> references to hosts, which it verifies in the same manner, without >>>>> anything beyond verifying a binding between a domain name and a >>>>> server certificate. >>>>> >>>>> All of this requires nothing more than a standard TLS host >>>>> certificate that Verisign and others sell you today for your Apache >>>>> server. This is a very different certification from "host foo.com >>>>> is a legitimate LoST server" or even "foo.com is an authoritative >>>>> LoST server for Jerusalem", whatever that may mean precisely. >>>>> >>>>> Henning >>>>> >>>>> >>>>> >>>> >>> >>> >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 13:38:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZCM-0000Cx-4l; Mon, 30 Jul 2007 13:38:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFZCL-0000Cl-F7 for ecrit@ietf.org; Mon, 30 Jul 2007 13:38:25 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFZCK-0004DR-4w for ecrit@ietf.org; Mon, 30 Jul 2007 13:38:25 -0400 Received: from mail.bbn.com ([128.33.1.19]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFZCJ-0004nF-5x; Mon, 30 Jul 2007 13:38:23 -0400 Received: from col-dhcp33-244-154.bbn.com ([128.33.244.154] helo=[127.0.0.1]) by mail.bbn.com with esmtp (Exim 4.67) (envelope-from ) id 1IFZCJ-0001OA-OI; Mon, 30 Jul 2007 13:38:23 -0400 Message-ID: <46AE2224.1000604@bbn.com> Date: Mon, 30 Jul 2007 13:38:44 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> <46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com> <46AE1D34.8080209@cs.columbia.edu> <46AE1F98.4050404@bbn.com> In-Reply-To: <46AE1F98.4050404@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > There are existing mechanisms to do this using LDAP, > FTP, and HTTP (RFC 2559 and 2589). Oops, that should be RFC 2585. --Richard > > > > Henning Schulzrinne wrote: >> The problem is that the VSP in Sierra Leone will need to deal with >> their traveling customer visiting Taiwan (or the impostor pretending >> to visit Taiwan). These are in different trees, obviously. >> >> Richard Barnes wrote: >>> Henning, >>> >>> I encourage you to take a look at what the SIDR WG has been up to, >>> namely defining a PKI that encodes assertions of the form >>> >>> "The holder of X public key is the holder of address space Y" >>> "The holder of X public key is the holder of AS number Z" >>> >>> Administration of this PKI is globally distributed, and there will >>> likely not be a single root, but rather a set of cross-certifications >>> among the RIRs. This arrangement allows ISPs to validate >>> certificates from the entire PKI based only on trust with their >>> chosen RIR. This PKI is currently being implemented by the RIRs. >>> >>> To make the analogy with LoST, here's one way you could arrange things: >>> 1. Each tree will have an autonomously administered, hierarchical PKI >>> -- the LoST folks in Taiwan won't care about the LoST folks in the >>> Ukraine, or Sierra Leone, or anywhere else. >>> 2. FGs sign certificates for the roots of the trees with which they >>> peer. I.e., they create certs that verify that "The holder of X >>> public key is the root for region Y", given trust in the FG. >>> 3. Seekers/resolvers use FG keys as trust anchors. >>> >>> If somebody gets something signed under this structure, he >>> 1. Validates up to the root of the tree, then >>> 2. Checks to see if any of his FGs vouch for that root. >>> >>> This model only requires local interactions, e.g.: >>> 1. Each tree manages its own PKI. >>> 2. Each FG only deals with the trees it already deals with. >>> 3. Each seeker/resolver only deals with the FGs it already deals with. >>> >>> There's no global coordination needed here, only an augmentation of >>> relationships already required by the mapping architecture. >>> >>> --Richard >>> >>> >>> >>> Henning Schulzrinne wrote: >>>> Richard, >>>> >>>> That's what I assumed you meant. Unfortunately, this requires a >>>> world government or equivalent, which seems somewhat outside our >>>> scope to create or assume. Simply wishing that some global PKI comes >>>> into existence has a rather dismal track record of success. I don't >>>> know who is going to certify the authoritative LoST server for >>>> Taiwan or parts of the former Soviet Union, but I suspect that >>>> creating any kind of global PKI is going to be hard, particularly >>>> since the domain-level authenticity I described is likely to be >>>> sufficient for secure operation of the system. I'm curious as to >>>> whether there is any existing example, outside of emergency calling, >>>> of such a global role-based certification authority. >>>> >>>> Henning >>>> >>>> >>>> Richard Barnes wrote: >>>>> Henning, >>>>> >>>>> ISTM that the assertions that LoST servers(and relying parties) are >>>>> interested in would be something like >>>>> >>>>> "The holder of X public key is an authoritative LoST server for >>>>> region Y" >>>>> >>>>> This is a parallel, but much different assertion than what the >>>>> typical Verisign certificate says, i.e., "The holder of X public >>>>> key is the holder of Y domain name." This statement has no >>>>> relevance to LoST. >>>>> >>>>> Encoding such assertions in public-key certificates would result in >>>>> an authentication infrastructure very much like the IP address / AS >>>>> number PKI being developed in the SIDR WG: >>>>> >>>>> The multi-tree design and the existence of field guides in the >>>>> mapping architecture complicates things a little, but the structure >>>>> would be mostly the same within the trees. And the requirements >>>>> for "resource holding" fields in the certificates are very similar. >>>>> >>>>> Three uses immediately come to mind: >>>>> 1. LoST resolution security: Servers in the LoST heirarchy are >>>>> assured of the identities of servers "up" the tree so that it knows >>>>> that they're the ones it wants to talk to. >>>>> 2. LoST provisioning security: Servers in the LoST heirarchy (and >>>>> FGs) are assured of the identities of servers "down" the tree so >>>>> that they know who's providing them information, e.g., coverage >>>>> maps. Also applies to "lateral" peering among FGs. >>>>> 3. Signed LoST mappings: When a third party gets a signed LoST >>>>> mapping, he can verify that the signing party is the authoritative >>>>> server for the given coverage area. >>>>> >>>>> This is what I had in mind in my earlier email. Hope this helps to >>>>> clarify. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Henning Schulzrinne wrote: >>>>>> >>>>>> >>>>>> Richard Barnes wrote: >>>>>> >>>>>>> >>>>>>> I like this approach, because it only gives you one thing to >>>>>>> credential, namely LoST servers. Chances are that the LoST >>>>>>> infrastructure is going to require strong authentication anyway >>>>>>> (to support peering and synchronization), so this is a good way >>>>>>> to re-use that to support authentication of emergency calls. >>>>>> >>>>>> I don't think this follows. For LoST to work, you only need trust >>>>>> "up" the tree, i.e., a resolver needs to know that the forest >>>>>> guide it contacts is indeed the one it wants to talk to. It gets >>>>>> references to hosts, which it verifies in the same manner, without >>>>>> anything beyond verifying a binding between a domain name and a >>>>>> server certificate. >>>>>> >>>>>> All of this requires nothing more than a standard TLS host >>>>>> certificate that Verisign and others sell you today for your >>>>>> Apache server. This is a very different certification from "host >>>>>> foo.com is a legitimate LoST server" or even "foo.com is an >>>>>> authoritative LoST server for Jerusalem", whatever that may mean >>>>>> precisely. >>>>>> >>>>>> Henning >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 14:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFaHG-0007c5-5e; Mon, 30 Jul 2007 14:47:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFaHE-0007aQ-Tt for ecrit@ietf.org; Mon, 30 Jul 2007 14:47:32 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFaHD-000621-MW for ecrit@ietf.org; Mon, 30 Jul 2007 14:47:32 -0400 Received: from [84.186.251.184] (p54BAFBB8.dip.t-dialin.net [84.186.251.184]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6UIlLTZ008376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Jul 2007 14:47:24 -0400 (EDT) Message-ID: <46AE323A.4000105@cs.columbia.edu> Date: Mon, 30 Jul 2007 20:47:22 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> <46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com> <46AE1D34.8080209@cs.columbia.edu> <46AE1F98.4050404@bbn.com> In-Reply-To: <46AE1F98.4050404@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org However, unless there is a global root, the VSP has no way to distinguish a valid Taiwanese cert from some randomly created one. Just being able to retrieve the cert makes no difference. The impostor can point to a cert by his best buddy and the VSP has no way to distinguish them. The only good way is to recognize, ssh-style, that the new certificate for Taiwan differs from the one the VSP saw last week, which means that the new one is probably dubious. This may well be sufficient in practice. I don't see how you avoid either cross-certification, which doesn't scale, or a global root certificate. ISPs have a far easier time with that, since AS "territories" are not in dispute, for example. Richard Barnes wrote: > Yes, whoever validates the signature an object signed by the Taiwanese > LoST server will need to get certificates from Taiwanese tree. This is > not a hard problem: There are existing mechanisms to do this using LDAP, > FTP, and HTTP (RFC 2559 and 2589). The RIRs are just throwing > everything in one big, distributed database that ISPs fetch using rsync. > > Also, remember that this validation doesn't necessarily have to be done > in real time with the call. I think it was Barbara that said in an > earlier discussion that it would be good enough to have a forensic > capability. > > --RB _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 20:07:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFfGq-0004Oh-1L; Mon, 30 Jul 2007 20:07:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFfGo-0004Ob-MG for ecrit@ietf.org; Mon, 30 Jul 2007 20:07:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFfGn-00074o-P7 for ecrit@ietf.org; Mon, 30 Jul 2007 20:07:26 -0400 X-SEF-Processed: 5_0_0_910__2007_07_30_19_15_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 30 Jul 2007 19:15:54 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jul 2007 19:07:20 -0500 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: [Ecrit] Signed LoST mappings Date: Mon, 30 Jul 2007 19:07:18 -0500 Message-ID: In-Reply-To: <46AE1F98.4050404@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Signed LoST mappings Thread-Index: AcfSzvQR1GYcbgaQQSyT50o/hoqKpAAN3dcw References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com><46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com><46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com><46AE1D34.8080209@cs.columbia.edu> <46AE1F98.4050404@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "Henning Schulzrinne" X-OriginalArrivalTime: 31 Jul 2007 00:07:20.0334 (UTC) FILETIME=[C34EE2E0:01C7D306] X-Spam-Score: 1.8 (+) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'd like to give Henning a chance here... I think Richard is making=0D=0Age= nuine practical proposals with respect to how trust is going to be=0D=0Ates= ted. Henning has spoken at a higher level about trust "going up the=0D=0Atr= ee" and ensuring that the forest guide is the one that you want and=0D=0Ath= at it provides the trustable host list.=0D=0A=0D=0ACan you elaborate, Henni= ng, on how you see a forest guide hosted in a=0D=0Aparticular jurisdiction = actually establishing the trusted host list=0D=0Abelonging to another juris= diction=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-= ----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn.com]=20=0D=0ASent: Tuesd= ay, 31 July 2007 3:28 AM=0D=0ATo: Henning Schulzrinne=0D=0ACc: ECRIT=0D=0AS= ubject: Re: [Ecrit] Signed LoST mappings=0D=0A=0D=0AYes, whoever validates = the signature an object signed by the Taiwanese=20=0D=0ALoST server will ne= ed to get certificates from Taiwanese tree. This is=20=0D=0Anot a hard pro= blem: There are existing mechanisms to do this using LDAP,=0D=0A=0D=0AFTP, = and HTTP (RFC 2559 and 2589). The RIRs are just throwing=20=0D=0Aeverythin= g in one big, distributed database that ISPs fetch using rsync.=0D=0A=0D=0A= Also, remember that this validation doesn't necessarily have to be done=20=0D= =0Ain real time with the call. I think it was Barbara that said in an=20=0D= =0Aearlier discussion that it would be good enough to have a forensic=20=0D= =0Acapability.=0D=0A=0D=0A--RB=0D=0A=0D=0A=0D=0A=0D=0AHenning Schulzrinne w= rote:=0D=0A> The problem is that the VSP in Sierra Leone will need to deal = with=0D=0Atheir=20=0D=0A> traveling customer visiting Taiwan (or the impos= tor pretending to=0D=0Avisit=20=0D=0A> Taiwan). These are in different tree= s, obviously.=0D=0A>=20=0D=0A> Richard Barnes wrote:=0D=0A>> Henning,=0D=0A= >>=0D=0A>> I encourage you to take a look at what the SIDR WG has been up t= o,=20=0D=0A>> namely defining a PKI that encodes assertions of the form=0D=0A= >>=0D=0A>> "The holder of X public key is the holder of address space Y"=0D= =0A>> "The holder of X public key is the holder of AS number Z"=0D=0A>>=0D=0A= >> Administration of this PKI is globally distributed, and there will=20=0D= =0A>> likely not be a single root, but rather a set of cross-certifications=0D= =0A=0D=0A>> among the RIRs. This arrangement allows ISPs to validate=0D=0A= certificates=20=0D=0A>> from the entire PKI based only on trust with their = chosen RIR. This=20=0D=0A>> PKI is currently being implemented by the RIRs= =2E=0D=0A>>=0D=0A>> To make the analogy with LoST, here's one way you could= arrange=0D=0Athings:=0D=0A>> 1. Each tree will have an autonomously admini= stered, hierarchical PKI=0D=0A=0D=0A>> -- the LoST folks in Taiwan won't ca= re about the LoST folks in the=20=0D=0A>> Ukraine, or Sierra Leone, or anyw= here else.=0D=0A>> 2. FGs sign certificates for the roots of the trees with= which they=20=0D=0A>> peer. I.e., they create certs that verify that "The= holder of X=20=0D=0A>> public key is the root for region Y", given trust i= n the FG.=0D=0A>> 3. Seekers/resolvers use FG keys as trust anchors.=0D=0A>= >=0D=0A>> If somebody gets something signed under this structure, he=0D=0A>= > 1. Validates up to the root of the tree, then=0D=0A>> 2. Checks to see if= any of his FGs vouch for that root.=0D=0A>>=0D=0A>> This model only requir= es local interactions, e.g.:=0D=0A>> 1. Each tree manages its own PKI.=0D=0A= >> 2. Each FG only deals with the trees it already deals with.=0D=0A>> 3. E= ach seeker/resolver only deals with the FGs it already deals=0D=0Awith.=0D=0A= >>=0D=0A>> There's no global coordination needed here, only an augmentation= of=20=0D=0A>> relationships already required by the mapping architecture.=0D= =0A>>=0D=0A>> --Richard=0D=0A>>=0D=0A>>=0D=0A>>=0D=0A>> Henning Schulzrinne= wrote:=0D=0A>>> Richard,=0D=0A>>>=0D=0A>>> That's what I assumed you meant= =2E Unfortunately, this requires a=0D=0Aworld=20=0D=0A>>> government or equ= ivalent, which seems somewhat outside our scope to=20=0D=0A>>> create or as= sume. Simply wishing that some global PKI comes into=20=0D=0A>>> existence = has a rather dismal track record of success. I don't know=20=0D=0A>>> who i= s going to certify the authoritative LoST server for Taiwan or=20=0D=0A>>> = parts of the former Soviet Union, but I suspect that creating any=20=0D=0A>= >> kind of global PKI is going to be hard, particularly since the=20=0D=0A>= >> domain-level authenticity I described is likely to be sufficient for=0D=0A=0D= =0A>>> secure operation of the system. I'm curious as to whether there is =0D= =0A>>> any existing example, outside of emergency calling, of such a global=0D= =0A=0D=0A>>> role-based certification authority.=0D=0A>>>=0D=0A>>> Henning=0D= =0A>>>=0D=0A>>>=0D=0A>>> Richard Barnes wrote:=0D=0A>>>> Henning,=0D=0A>>>>=0D= =0A>>>> ISTM that the assertions that LoST servers(and relying parties) are=0D= =0A=0D=0A>>>> interested in would be something like=0D=0A>>>>=0D=0A>>>> "Th= e holder of X public key is an authoritative LoST server for=20=0D=0A>>>> r= egion Y"=0D=0A>>>>=0D=0A>>>> This is a parallel, but much different asserti= on than what the=20=0D=0A>>>> typical Verisign certificate says, i.e., "The= holder of X public=0D=0Akey=20=0D=0A>>>> is the holder of Y domain name." = This statement has no relevance=0D=0Ato=20=0D=0A>>>> LoST.=0D=0A>>>>=0D=0A= >>>> Encoding such assertions in public-key certificates would result in=0D= =0A=0D=0A>>>> an authentication infrastructure very much like the IP addres= s / AS=0D=0A=0D=0A>>>> number PKI being developed in the SIDR WG:=0D=0A>>>>= =0D=0A>>>> The multi-t= ree design and the existence of field guides in the=20=0D=0A>>>> mapping ar= chitecture complicates things a little, but the structure=0D=0A=0D=0A>>>> w= ould be mostly the same within the trees. And the requirements=0D=0Afor =0D= =0A>>>> "resource holding" fields in the certificates are very similar.=0D=0A= >>>>=0D=0A>>>> Three uses immediately come to mind:=0D=0A>>>> 1. LoST resol= ution security: Servers in the LoST heirarchy are=20=0D=0A>>>> assured of t= he identities of servers "up" the tree so that it knows=0D=0A=0D=0A>>>> tha= t they're the ones it wants to talk to.=0D=0A>>>> 2. LoST provisioning secu= rity: Servers in the LoST heirarchy (and=20=0D=0A>>>> FGs) are assured of t= he identities of servers "down" the tree so=20=0D=0A>>>> that they know who= 's providing them information, e.g., coverage=20=0D=0A>>>> maps. Also appl= ies to "lateral" peering among FGs.=0D=0A>>>> 3. Signed LoST mappings: When= a third party gets a signed LoST=20=0D=0A>>>> mapping, he can verify that = the signing party is the authoritative=20=0D=0A>>>> server for the given co= verage area.=0D=0A>>>>=0D=0A>>>> This is what I had in mind in my earlier e= mail. Hope this helps to=0D=0A=0D=0A>>>> clarify.=0D=0A>>>>=0D=0A>>>> --Ri= chard=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D=0A>>>>=0D= =0A>>>> Henning Schulzrinne wrote:=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>> Richard= Barnes wrote:=0D=0A>>>>>=0D=0A>>>>>>=0D=0A>>>>>> I like this approach, bec= ause it only gives you one thing to=20=0D=0A>>>>>> credential, namely LoST = servers. Chances are that the LoST=20=0D=0A>>>>>> infrastructure is going = to require strong authentication anyway=20=0D=0A>>>>>> (to support peering = and synchronization), so this is a good way=0D=0Ato=20=0D=0A>>>>>> re-use t= hat to support authentication of emergency calls.=0D=0A>>>>>=0D=0A>>>>> I d= on't think this follows. For LoST to work, you only need trust=20=0D=0A>>>>= > "up" the tree, i.e., a resolver needs to know that the forest=0D=0Aguide =0D= =0A>>>>> it contacts is indeed the one it wants to talk to. It gets=20=0D=0A= >>>>> references to hosts, which it verifies in the same manner, without=0D= =0A=0D=0A>>>>> anything beyond verifying a binding between a domain name an= d a=20=0D=0A>>>>> server certificate.=0D=0A>>>>>=0D=0A>>>>> All of this req= uires nothing more than a standard TLS host=20=0D=0A>>>>> certificate that = Verisign and others sell you today for your=0D=0AApache=20=0D=0A>>>>> serve= r. This is a very different certification from "host foo.com=20=0D=0A>>>>> = is a legitimate LoST server" or even "foo.com is an authoritative=20=0D=0A>= >>>> LoST server for Jerusalem", whatever that may mean precisely.=0D=0A>>>= >>=0D=0A>>>>> Henning=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>>=0D=0A>>>>=0D=0A>>>=0D= =0A>>>=0D=0A>>=0D=0A>=20=0D=0A>=20=0D=0A=0D=0A=0D=0A_______________________= ________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ah= ttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0AThis message is for the designated recipient only and may=0D=0Aconta= in privileged, proprietary, or otherwise private information. =20=0D=0AIf y= ou have received it in error, please notify the sender=0D=0Aimmediately and= delete the original. Any unauthorized use of=0D=0Athis email is prohibite= d.=0D=0A-------------------------------------------------------------------= -----------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 30 21:08:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgDw-0004el-P2; Mon, 30 Jul 2007 21:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFgDv-0004d6-KC for ecrit@ietf.org; Mon, 30 Jul 2007 21:08:31 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFgDq-00089a-Va for ecrit@ietf.org; Mon, 30 Jul 2007 21:08:31 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFgDq-000424-40; Mon, 30 Jul 2007 21:08:26 -0400 Message-ID: <46AE8B84.2050101@bbn.com> Date: Mon, 30 Jul 2007 21:08:20 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Henning Schulzrinne , ECRIT Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com> <46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com> <46AE1D34.8080209@cs.columbia.edu> <46AE1F98.4050404@bbn.com> <46AE323A.4000105@cs.columbia.edu> In-Reply-To: <46AE323A.4000105@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FGs are already a locus of trust: By peering with tree roots, they effectively vouch for the validity of roots already. For each FG to provide a list of certificates for the roots with which it peers is conceptually no different than providing a list of DNS names for these roots, and offers lots of security benefits. (If there are bandwidth concerns, you could just as easily define a mechanism for querying for specific certs or domain names.) I'm not sure what the basis is for your argument that this type of cross-certification doesn't scale. Any given FG is only concerned with the roots from which it receives information, and for any given validation resolver/seeker is only concerned with certification of a root by its FGs. So the number of certs at each FG scales as O(#roots) and the number of certs for each resolver/seeker validation scales as O(#peeredFGs) in the worst case. Cert path length only grows as O(avgTreeDepth + 1), since a FG can create new certs for roots it learns about through its peers. --Richard Henning Schulzrinne wrote: > However, unless there is a global root, the VSP has no way to > distinguish a valid Taiwanese cert from some randomly created one. Just > being able to retrieve the cert makes no difference. The impostor can > point to a cert by his best buddy and the VSP has no way to distinguish > them. The only good way is to recognize, ssh-style, that the new > certificate for Taiwan differs from the one the VSP saw last week, which > means that the new one is probably dubious. This may well be sufficient > in practice. > > I don't see how you avoid either cross-certification, which doesn't > scale, or a global root certificate. ISPs have a far easier time with > that, since AS "territories" are not in dispute, for example. > > Richard Barnes wrote: >> Yes, whoever validates the signature an object signed by the Taiwanese >> LoST server will need to get certificates from Taiwanese tree. This >> is not a hard problem: There are existing mechanisms to do this using >> LDAP, FTP, and HTTP (RFC 2559 and 2589). The RIRs are just throwing >> everything in one big, distributed database that ISPs fetch using rsync. >> >> Also, remember that this validation doesn't necessarily have to be >> done in real time with the call. I think it was Barbara that said in >> an earlier discussion that it would be good enough to have a forensic >> capability. >> >> --RB > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 31 03:08:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlqB-0004Ht-LJ; Tue, 31 Jul 2007 03:08:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFlq9-0004Hn-Mr for ecrit@ietf.org; Tue, 31 Jul 2007 03:08:21 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFlq8-0003zR-NG for ecrit@ietf.org; Tue, 31 Jul 2007 03:08:21 -0400 Received: from [84.186.241.219] (p54BAF1DB.dip.t-dialin.net [84.186.241.219]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.13.6) with ESMTP id l6V78DjS015702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 31 Jul 2007 03:08:19 -0400 (EDT) Message-ID: <46AEDFDC.902@cs.columbia.edu> Date: Tue, 31 Jul 2007 09:08:12 +0200 From: Henning Schulzrinne User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 CC: ECRIT Subject: Re: [Ecrit] Signed LoST mappings References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com><46ADB983.6080907@cs.columbia.edu> <46ADE4DD.5020000@bbn.com><46AE0C71.1090201@cs.columbia.edu> <46AE1796.8040102@bbn.com><46AE1D34.8080209@cs.columbia.edu> <46AE1F98.4050404@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 1.6 (+) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org To make easier to talk about, I'm assuming that each country has a tree and that we have standard TLS host certs. The resolver is pre-configured with a host name of the FG. (I'm saying host name; in reality it's a NAPTR thing, but this doesn't seem to matter.) When the resolver connects to the FG, it uses the FG TLS cert to verify that it is indeed connected to the right FG. It needs to trust the FG to do the right thing. The FG in turn peers with other FGs, again based on pre-configured trust relationships and host certificates. The FG is configured with the top of the country tree(s), again with a domain name. The coverage maps contain domain names of the child nodes. For each step, the querier can verify that they are talking to the right host. The trust is by nature transitive, but we can't avoid that. There are two authenticity problems, which are largely orthogonal: (1) Assuring the resolver and host that their resolution traverses a legitimate chain of LoST servers. See above. (2) Proving to a third party that a LoST binding was indeed "authorized". This is harder. Henning Dawson, Martin wrote: > I'd like to give Henning a chance here... I think Richard is making > genuine practical proposals with respect to how trust is going to be > tested. Henning has spoken at a higher level about trust "going up the > tree" and ensuring that the forest guide is the one that you want and > that it provides the trustable host list. > > Can you elaborate, Henning, on how you see a forest guide hosted in a > particular jurisdiction actually establishing the trusted host list > belonging to another jurisdiction? > > Cheers, > Martin > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, 31 July 2007 3:28 AM > To: Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] Signed LoST mappings > > Yes, whoever validates the signature an object signed by the Taiwanese > LoST server will need to get certificates from Taiwanese tree. This is > not a hard problem: There are existing mechanisms to do this using LDAP, > > FTP, and HTTP (RFC 2559 and 2589). The RIRs are just throwing > everything in one big, distributed database that ISPs fetch using rsync. > > Also, remember that this validation doesn't necessarily have to be done > in real time with the call. I think it was Barbara that said in an > earlier discussion that it would be good enough to have a forensic > capability. > > --RB > > > > Henning Schulzrinne wrote: >> The problem is that the VSP in Sierra Leone will need to deal with > their >> traveling customer visiting Taiwan (or the impostor pretending to > visit >> Taiwan). These are in different trees, obviously. >> >> Richard Barnes wrote: >>> Henning, >>> >>> I encourage you to take a look at what the SIDR WG has been up to, >>> namely defining a PKI that encodes assertions of the form >>> >>> "The holder of X public key is the holder of address space Y" >>> "The holder of X public key is the holder of AS number Z" >>> >>> Administration of this PKI is globally distributed, and there will >>> likely not be a single root, but rather a set of cross-certifications > >>> among the RIRs. This arrangement allows ISPs to validate > certificates >>> from the entire PKI based only on trust with their chosen RIR. This >>> PKI is currently being implemented by the RIRs. >>> >>> To make the analogy with LoST, here's one way you could arrange > things: >>> 1. Each tree will have an autonomously administered, hierarchical PKI > >>> -- the LoST folks in Taiwan won't care about the LoST folks in the >>> Ukraine, or Sierra Leone, or anywhere else. >>> 2. FGs sign certificates for the roots of the trees with which they >>> peer. I.e., they create certs that verify that "The holder of X >>> public key is the root for region Y", given trust in the FG. >>> 3. Seekers/resolvers use FG keys as trust anchors. >>> >>> If somebody gets something signed under this structure, he >>> 1. Validates up to the root of the tree, then >>> 2. Checks to see if any of his FGs vouch for that root. >>> >>> This model only requires local interactions, e.g.: >>> 1. Each tree manages its own PKI. >>> 2. Each FG only deals with the trees it already deals with. >>> 3. Each seeker/resolver only deals with the FGs it already deals > with. >>> There's no global coordination needed here, only an augmentation of >>> relationships already required by the mapping architecture. >>> >>> --Richard >>> >>> >>> >>> Henning Schulzrinne wrote: >>>> Richard, >>>> >>>> That's what I assumed you meant. Unfortunately, this requires a > world >>>> government or equivalent, which seems somewhat outside our scope to >>>> create or assume. Simply wishing that some global PKI comes into >>>> existence has a rather dismal track record of success. I don't know >>>> who is going to certify the authoritative LoST server for Taiwan or >>>> parts of the former Soviet Union, but I suspect that creating any >>>> kind of global PKI is going to be hard, particularly since the >>>> domain-level authenticity I described is likely to be sufficient for > >>>> secure operation of the system. I'm curious as to whether there is >>>> any existing example, outside of emergency calling, of such a global > >>>> role-based certification authority. >>>> >>>> Henning >>>> >>>> >>>> Richard Barnes wrote: >>>>> Henning, >>>>> >>>>> ISTM that the assertions that LoST servers(and relying parties) are > >>>>> interested in would be something like >>>>> >>>>> "The holder of X public key is an authoritative LoST server for >>>>> region Y" >>>>> >>>>> This is a parallel, but much different assertion than what the >>>>> typical Verisign certificate says, i.e., "The holder of X public > key >>>>> is the holder of Y domain name." This statement has no relevance > to >>>>> LoST. >>>>> >>>>> Encoding such assertions in public-key certificates would result in > >>>>> an authentication infrastructure very much like the IP address / AS > >>>>> number PKI being developed in the SIDR WG: >>>>> >>>>> The multi-tree design and the existence of field guides in the >>>>> mapping architecture complicates things a little, but the structure > >>>>> would be mostly the same within the trees. And the requirements > for >>>>> "resource holding" fields in the certificates are very similar. >>>>> >>>>> Three uses immediately come to mind: >>>>> 1. LoST resolution security: Servers in the LoST heirarchy are >>>>> assured of the identities of servers "up" the tree so that it knows > >>>>> that they're the ones it wants to talk to. >>>>> 2. LoST provisioning security: Servers in the LoST heirarchy (and >>>>> FGs) are assured of the identities of servers "down" the tree so >>>>> that they know who's providing them information, e.g., coverage >>>>> maps. Also applies to "lateral" peering among FGs. >>>>> 3. Signed LoST mappings: When a third party gets a signed LoST >>>>> mapping, he can verify that the signing party is the authoritative >>>>> server for the given coverage area. >>>>> >>>>> This is what I had in mind in my earlier email. Hope this helps to > >>>>> clarify. >>>>> >>>>> --Richard >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Henning Schulzrinne wrote: >>>>>> >>>>>> Richard Barnes wrote: >>>>>> >>>>>>> I like this approach, because it only gives you one thing to >>>>>>> credential, namely LoST servers. Chances are that the LoST >>>>>>> infrastructure is going to require strong authentication anyway >>>>>>> (to support peering and synchronization), so this is a good way > to >>>>>>> re-use that to support authentication of emergency calls. >>>>>> I don't think this follows. For LoST to work, you only need trust >>>>>> "up" the tree, i.e., a resolver needs to know that the forest > guide >>>>>> it contacts is indeed the one it wants to talk to. It gets >>>>>> references to hosts, which it verifies in the same manner, without > >>>>>> anything beyond verifying a binding between a domain name and a >>>>>> server certificate. >>>>>> >>>>>> All of this requires nothing more than a standard TLS host >>>>>> certificate that Verisign and others sell you today for your > Apache >>>>>> server. This is a very different certification from "host foo.com >>>>>> is a legitimate LoST server" or even "foo.com is an authoritative >>>>>> LoST server for Jerusalem", whatever that may mean precisely. >>>>>> >>>>>> Henning >>>>>> >>>>>> >>>>>> >>>> >> > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 31 14:00:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFw1D-0006uV-7l; Tue, 31 Jul 2007 14:00:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFw1C-0006uP-5c for ecrit@ietf.org; Tue, 31 Jul 2007 14:00:26 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFw1B-0002XK-Qn for ecrit@ietf.org; Tue, 31 Jul 2007 14:00:26 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFw1B-00019C-44; Tue, 31 Jul 2007 14:00:25 -0400 Message-ID: <46AF78B7.2020109@bbn.com> Date: Tue, 31 Jul 2007 14:00:23 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Verifying that a call goes to a PSAP (Was Re: [Ecrit] Signed LoST mappings) References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> <46ADB86C.4080003@cs.columbia.edu> <46ADE154.1070506@bbn.com> <46AE0AF6.1050705@cs.columbia.edu> In-Reply-To: <46AE0AF6.1050705@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I'd like to step back (for a moment) from the discussion of whether there is a way for a third party to verify that a LoST mapping for a Taiwanese PSAP is authentic (or authoritative). At a high level Richard proposed that the problem of fruad prevention (verifying that a call is actually headed to a PSAP) can be solved more easily if we utilize not just the SIP INVITE but a response to the SIP INVITE. In particular, if we use Connected Identity (if PSAPs have appropriate credentials) or Signed LoST Mappings (if LoST servers have appropriate credentials) or something else (if someone else has appropriate credentials). Henning provided the following response: > [Richard Barnes:] Note that this level of state (e.g., keeping track > of all the messages in an INVITE transaction) is useful for things > like accounting and billing as well, so VSPs may be doing it anyway. > > [Henning Schulzrinne:] This is not the right forum for this > discussions, but if a VSP relies on such capabilities, they are likely > to be in (financial) trouble. One of the core assumptions for ECRIT is > that we don't mess with SIP call flows or create emergency-specific > call flows. > Henning seems to be saying that any mechanism for fraud prevention which relies on a message other than the SIP INVITE is not useful. Am I interpreting Henning's response correctly? Do others feel that using messages other than the SIP INVITE is not a useful approach to fraud prevention? - Matt Lepinski :-> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 31 14:24:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwOI-0006a4-1F; Tue, 31 Jul 2007 14:24:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwOG-0006Zz-U4 for ecrit@ietf.org; Tue, 31 Jul 2007 14:24:16 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFwOF-0001Lz-JS for ecrit@ietf.org; Tue, 31 Jul 2007 14:24:16 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2007 11:24:15 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGoar0arR7MV/2dsb2JhbAA X-IronPort-AV: i="4.19,204,1183359600"; d="scan'208"; a="191906262:sNHT77449923" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6VIOEDK009738; Tue, 31 Jul 2007 11:24:14 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6VIOA6M006555; Tue, 31 Jul 2007 18:24:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 11:24:07 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.90.33]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 11:24:06 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 31 Jul 2007 13:23:35 -0500 To: Matt Lepinski , Henning Schulzrinne From: "James M. Polk" Subject: Re: Verifying that a call goes to a PSAP (Was Re: [Ecrit] Signed LoST mappings) In-Reply-To: <46AF78B7.2020109@bbn.com> References: <46A27298.2000005@gmx.net> <46A4C698.8040106@bbn.com> <46A4D8E8.4050204@ntt-at.com> <88ac5c710707230956h5011276al142895018bbd78a4@mail.gmail.com> <46ADB86C.4080003@cs.columbia.edu> <46ADE154.1070506@bbn.com> <46AE0AF6.1050705@cs.columbia.edu> <46AF78B7.2020109@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 31 Jul 2007 18:24:06.0711 (UTC) FILETIME=[FAF72470:01C7D39F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2780; t=1185906254; x=1186770254; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Verifying=20that=20a=20call=20goes=20to=20a=20PSAP=20 (Was=20Re=3A=20[Ecrit]=0A=20=20Signed=20LoST=20mappings) |Sender:=20; bh=6pwCq6YK6B6GkTyrTokCVw8scAbbNH30zU5qoDEjuKo=; b=Sg+q/8dED4SqTAhf9IXhDEcaNOaTYufoMYIvNnhO56vlBX05IUHzAagCkS7QKqAwCnMc0EdB kl/wrGxbo5U5ExmbZ5xStWR6xKbveIcZvndgXsb0blmm9SPUGSevIvA/GDJTLNxvCTSMjglpkY Ix6aOba1oMNetTDhmpZKfC+SY=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Matt Looking at this example topology Alice--INVITE-->Proxy1-->Proxy2-->ESRP/ESInet-->EmSvcsProxy-->PSAP Alice<--Proxy1<--Proxy2<--ESRP/ESInet<--EmSvcsProxy<--200OK--PSAP Q#1 - Where is this 200 OK important in your context (for verifying intended destination)? Q#2 - Why is this important at this point in the topology? Q#3 - What do you expect the SIP element to do with any indication you are creating here? Little new can be between Alice and the ESRP, as we're attempting to create a solution with the LEAST amount of changes to SIP --> because the more changes there are, the more complicated the solution is, the less likely it will be implemented right --> which is the goal, right? The ESRP should be a B2BUA or SBC, so changes behind it towards the PSAP call taker's UA need to highlighted as only being in that part of the topology. We cannot expect COTS SIP products to do too much, yet I don't believe COTS SIP equipment will be used at the ESRP or between it and the PSAP. At 01:00 PM 7/31/2007, Matt Lepinski wrote: >I'd like to step back (for a moment) from the discussion of whether >there is a way for a third party to verify that a LoST mapping for a >Taiwanese PSAP is authentic (or authoritative). > >At a high level Richard proposed that the problem of fruad >prevention (verifying that a call is actually headed to a PSAP) can >be solved more easily if we utilize not just the SIP INVITE but a >response to the SIP INVITE. In particular, if we use Connected >Identity (if PSAPs have appropriate credentials) or Signed LoST >Mappings (if LoST servers have appropriate credentials) or something >else (if someone else has appropriate credentials). > >Henning provided the following response: > >>[Richard Barnes:] Note that this level of state (e.g., keeping >>track of all the messages in an INVITE transaction) is useful for >>things like accounting and billing as well, so VSPs may be doing it anyway. >> >>[Henning Schulzrinne:] This is not the right forum for this >>discussions, but if a VSP relies on such capabilities, they are >>likely to be in (financial) trouble. One of the core assumptions >>for ECRIT is that we don't mess with SIP call flows or create >>emergency-specific call flows. >Henning seems to be saying that any mechanism for fraud prevention >which relies on a message other than the SIP INVITE is not useful. > >Am I interpreting Henning's response correctly? > >Do others feel that using messages other than the SIP INVITE is not >a useful approach to fraud prevention? > >- Matt Lepinski :-> > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit