From ecrit-bounces@ietf.org Thu Mar 01 20:39: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 1HMwjz-000226-Fl; Thu, 01 Mar 2007 20:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMwjy-000221-En for ecrit@ietf.org; Thu, 01 Mar 2007 20:39:22 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMwjx-0001QR-4n for ecrit@ietf.org; Thu, 01 Mar 2007 20:39:22 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HMwjh-0003JW-Q4; Thu, 01 Mar 2007 19:39:05 -0600 From: "Brian Rosen" To: "'Shida Schubert'" Date: Thu, 1 Mar 2007 20:39:17 -0500 Message-ID: <0bef01c75c6b$98f3a970$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 In-Reply-To: <454E79E4.9070102@ntt-at.com> Thread-Index: AccBNebGYPuzCpWIRwi+4Fv3MsgDNxbNN0qQ 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: 'ECRIT' Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-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 I'm editing -framework and resolving comments. See in line for my responses > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Sunday, November 05, 2006 6:55 PM > To: ecrit@ietf.org > Cc: Henning Schulzrinne; br@brianrosen.net > Subject: Comments on draft-ietf-ecrit-framework-00 > > > Hi; > > Few comments on the draft. > > 1. What is the early URL? I can guess what this is but I think > it should be clarified somewhere as it I removed the "early". It's just a URI now. > > 2. Section 3, 4th paragraph explains how the proxy(ESRP) > would query the LoST server to resolve a Service URN but > this is based on the assumption that the URI in the route header > addressing the PSAP(assuming we are using the loose-route > Jonathan proposed.) is stale. But is it really? And how do we > know. There is no indication to show how fresh the psap-URI > is. So UA can literally have obtained a new psap-URI just before > it initiated an emergency call but according to the draft, ESRP or > proxy would still redo the mapping.. Worse yet, because there is > no indication that mapping has been accomplished, we may see > multiple proxies redoing the mapping as it can't tell if the mapping > has been executed already.. I don't know if there is any resolution > to this and I actually don't know if this is really a problem but I > figured > I should share my concern.. I'm in the midst of changing the example to be endpoint routed, rather than proxy routed. We want to promote the endpoint routed model anyway. This should eliminate the confusion in the text. I think we need an unambiguous indication that LoST mapping has been done. We should discuss this point. > > 3. Section 5.8 talks about location being validated prior to a device > placing > an actual emergency call. I don't understand what the text is trying > to say here. > How could the validation take place without the actual request?? I am > probably > being stupid here and not fully understanding the text here so > clarification would > be much appreciated. If you read on, you will see that the real validation is loading the value IN to the LIS. The endpoint can revalidate when it gets location (which is boot time and when it is reading location from the LIS), and any time thereafter. > > 4. Section 16.5. Call Signaling Integrity I think is better provided by > SIP-Identity, > which can provide over some headers and message body end-to-end over > TLS > which only provides integrity hop-by-hop. You already recommend the > use of > sip-identity to provide caller-authentication, it won't hurt to > recommend its use > to provide signaling integrity. Well, most of the text talks about maintaining the privacy of the location header, but I added text for the integrity protection Identity would get you. Thanks Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 01 22:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMy2D-0006iw-WD; Thu, 01 Mar 2007 22:02:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMy2C-0006im-Cp for ecrit@ietf.org; Thu, 01 Mar 2007 22:02:16 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMy2B-0002qa-0r for ecrit@ietf.org; Thu, 01 Mar 2007 22:02:16 -0500 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 l2231uXv017024; Thu, 1 Mar 2007 20:01:57 -0700 Message-ID: <45E793A6.2070100@ntt-at.com> Date: Thu, 01 Mar 2007 19:01:58 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Brian Rosen References: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> In-Reply-To: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: 'ECRIT' Subject: [Ecrit] Re: Comments on draft-ietf-ecrit-framework-00 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 in-line. Brian Rosen wrote: > I'm editing -framework and resolving comments. > > See in line for my responses > > >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] >> Sent: Sunday, November 05, 2006 6:55 PM >> To: ecrit@ietf.org >> Cc: Henning Schulzrinne; br@brianrosen.net >> Subject: Comments on draft-ietf-ecrit-framework-00 >> >> >> Hi; >> >> Few comments on the draft. >> >> 1. What is the early URL? I can guess what this is but I think >> it should be clarified somewhere as it >> > I removed the "early". It's just a URI now. > >> 2. Section 3, 4th paragraph explains how the proxy(ESRP) >> would query the LoST server to resolve a Service URN but >> this is based on the assumption that the URI in the route header >> addressing the PSAP(assuming we are using the loose-route >> Jonathan proposed.) is stale. But is it really? And how do we >> know. There is no indication to show how fresh the psap-URI >> is. So UA can literally have obtained a new psap-URI just before >> it initiated an emergency call but according to the draft, ESRP or >> proxy would still redo the mapping.. Worse yet, because there is >> no indication that mapping has been accomplished, we may see >> multiple proxies redoing the mapping as it can't tell if the mapping >> has been executed already.. I don't know if there is any resolution >> to this and I actually don't know if this is really a problem but I >> figured >> I should share my concern.. >> > I'm in the midst of changing the example to be endpoint routed, rather than > proxy routed. We want to promote the endpoint routed model anyway. This > should eliminate the confusion in the text. I think we need an unambiguous > indication that LoST mapping has been done. We should discuss this point. > I agree. I think the current direction of how to route and label the emergency call was to place Service URN in R-URI and PSAP URI in the Route header. Problem I see with this is that if there are more than one LoST querying proxy, the recursive LoST query may result in each of the LoST server resolving to the same URI placed in the Route header(time delay, failure at one server can mean call failure). As PSAP URI is expected to have no constant semantics indicating that it's a URI for PSAP, dip indicator may be needed to prevent this recursive LoST query at every LoST querying proxy along the signaling path. However, Henning did point out an interesting point (before or during the last IETF). I don't know if I interpreted his comment properly though... If not Henning please clarify what you meant.. As I understand Henning's idea was to use R-URI/Route header as an indicator to trigger the resolution. 1. If R-URI is urn:sos and Route header is not the proxy handling the message then the proxy is to assume the resolution is already done. 2. If R-URI is urn:sos and Route header is the proxy handling the message then the proxy is to conduct the resolution if capable. 3. If R-URI is urn:sos and Route header is empty obviously the resolution hasn't been completed thus the resolution is necessary if the proxy handling the message is capable to do so. I don't know how this would work with pre-configured route set and service-route etc. > > >> 3. Section 5.8 talks about location being validated prior to a device >> placing >> an actual emergency call. I don't understand what the text is trying >> to say here. >> How could the validation take place without the actual request?? I am >> probably >> being stupid here and not fully understanding the text here so >> clarification would >> be much appreciated. >> > If you read on, you will see that the real validation is loading the value > IN to the LIS. The endpoint can revalidate when it gets location (which is > boot time and when it is reading location from the LIS), and any time > thereafter. > > Okay. > >> 4. Section 16.5. Call Signaling Integrity I think is better provided by >> SIP-Identity, >> which can provide over some headers and message body end-to-end over >> TLS >> which only provides integrity hop-by-hop. You already recommend the >> use of >> sip-identity to provide caller-authentication, it won't hurt to >> recommend its use >> to provide signaling integrity. >> > Well, most of the text talks about maintaining the privacy of the location > header, but I added text for the integrity protection Identity would get > you. > Apologize for not reading it thorough enough. > Thanks > Brian > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 02 05:14: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 1HN4mc-0004c7-G3; Fri, 02 Mar 2007 05:14:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN4mb-0004a0-Fi for ecrit@ietf.org; Fri, 02 Mar 2007 05:14:37 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HN4ma-0000EM-23 for ecrit@ietf.org; Fri, 02 Mar 2007 05:14:37 -0500 Received: (qmail invoked by alias); 02 Mar 2007 10:14:34 -0000 X-Provags-ID: V01U2FsdGVkX1/MlCAW8ZPMCCzyIsQIx8qUwFMmrW97tckc3fR3WM lshxNaxAlZI/HU Message-ID: <45E7F907.70102@gmx.net> Date: Fri, 02 Mar 2007 11:14:31 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] WGLC for 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 Hi all, we would like to start a Working Group Last Call for the "Location-to-URL Mapping Architecture and Framework" draft: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-01.txt The WGLC starts today and will run until Friday 16th March. Please review the document! Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 02 06:06: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 1HN5af-0001UR-KF; Fri, 02 Mar 2007 06:06:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN5ae-0001UL-ET for ecrit@ietf.org; Fri, 02 Mar 2007 06:06:20 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN5ad-0000ro-62 for ecrit@ietf.org; Fri, 02 Mar 2007 06:06:20 -0500 Received: from [84.186.235.167] (p54BAEBA7.dip.t-dialin.net [84.186.235.167]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l22B5e7K006318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Mar 2007 06:05:47 -0500 (EST) Message-ID: <45E8050B.5070803@cs.columbia.edu> Date: Fri, 02 Mar 2007 12:05:47 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: shida@ntt-at.com References: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> <45E793A6.2070100@ntt-at.com> In-Reply-To: <45E793A6.2070100@ntt-at.com> Content-Type: text/plain; charset=UTF-8; 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: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'ECRIT' Subject: [Ecrit] Re: Comments on draft-ietf-ecrit-framework-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 > I think the current direction of how to route and label the emergency > call was to place Service URN > in R-URI and PSAP URI in the Route header. Problem I see with this is > that if there are more than > one LoST querying proxy, the recursive LoST query may result in each of > the LoST server resolving > to the same URI placed in the Route header(time delay, failure at one > server can mean call failure). They should never resolve to the same URI, as that would presumably cause looping. Let's say if the outbound proxy resolves to (PSAP) URL A. If A does the resolution and again produces A, you have a problem. No amount of identification is going to help with that problem. Please remember that SIP doesn't just randomly route messages. A proxy, except for the outbound proxy, will be named in the R-URL or the Route header. Otherwise, it's an error. You can't just expect to send a SIP message with a random URL to a proxy and say "please take care of it". (Otherwise, we'd have a problem very similar to the open relays in SMTP that caused a fair amount of email spam grief until running such an open relay would be a one-way ticket to a black list.) > > As PSAP URI is expected to have no constant semantics indicating that > it's a URI for PSAP, dip > indicator may be needed to prevent this recursive LoST query at every > LoST querying proxy along > the signaling path. See above; this doesn't work and is unnecessary. > As I understand Henning's idea was to use R-URI/Route header as an > indicator to trigger the > resolution. > > 1. If R-URI is urn:sos and Route header is not the proxy handling the > message then the proxy is to assume > the resolution is already done. As noted above, this can only occur if the proxy is an outbound proxy (P-CSCF in IMS terminology, I think). > 2. If R-URI is urn:sos and Route header is the proxy handling the > message then the proxy is to conduct > the resolution if capable. Right. > 3. If R-URI is urn:sos and Route header is empty obviously the > resolution hasn't been completed thus > the resolution is necessary if the proxy handling the message is > capable to do so. > > I don't know how this would work with pre-configured route set and > service-route etc. > Case 2 applies. Details probably require a bit of thought, as there are several possible answers, depending on whether that resolving proxy also "flushes" the remainder of the routes if it's in the middle of a route list or just adds the PSAP URI to the end of the list, which would be the normal behavior. I suspect that this depends a bit on the operational environment. Would an operator, for example, want the call to visit its service proxies before it heads to the PSAP? Given the proclivity of some architectures to tie, say, media authorization to SIP signaling, this may be necessary. In short, I'm opposed to an explicit marking since it would either be redundant or insufficient. The latter would occur if multiple mappings are done, as you'd have to keep track not just of whether "a" mapping has taken place, but which ones and where, essentially re-inventing Via or history (4244), depending on the details of how calls are bounced around. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 02 07:44:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN77E-0004EO-E1; Fri, 02 Mar 2007 07:44:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN77C-0004D7-Fr for ecrit@ietf.org; Fri, 02 Mar 2007 07:44:02 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN77B-00027e-31 for ecrit@ietf.org; Fri, 02 Mar 2007 07:44:02 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l22ChC518897; Fri, 2 Mar 2007 07:43:13 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007030207433602536 ; Fri, 02 Mar 2007 07:43:36 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 07:43:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Date: Fri, 2 Mar 2007 07:43:36 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Thread-Index: AccBNebGYPuzCpWIRwi+4Fv3MsgDNxbNN0qQABc6PhA= From: "Reese, Theresa E" To: "Brian Rosen" , "Shida Schubert" X-OriginalArrivalTime: 02 Mar 2007 12:43:36.0405 (UTC) FILETIME=[652D9850:01C75CC8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 - One comment in-line. Terry Reese -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, March 01, 2007 8:39 PM To: 'Shida Schubert' Cc: 'ECRIT' Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 I'm editing -framework and resolving comments. See in line for my responses > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Sunday, November 05, 2006 6:55 PM > To: ecrit@ietf.org > Cc: Henning Schulzrinne; br@brianrosen.net > Subject: Comments on draft-ietf-ecrit-framework-00 >=20 >=20 > Hi; >=20 > Few comments on the draft. >=20 > 1. What is the early URL? I can guess what this is but I think > it should be clarified somewhere as it I removed the "early". It's just a URI now. >=20 > 2. Section 3, 4th paragraph explains how the proxy(ESRP) > would query the LoST server to resolve a Service URN but > this is based on the assumption that the URI in the route header > addressing the PSAP(assuming we are using the loose-route > Jonathan proposed.) is stale. But is it really? And how do we > know. There is no indication to show how fresh the psap-URI > is. So UA can literally have obtained a new psap-URI just before > it initiated an emergency call but according to the draft, ESRP or > proxy would still redo the mapping.. Worse yet, because there is > no indication that mapping has been accomplished, we may see > multiple proxies redoing the mapping as it can't tell if the mapping > has been executed already.. I don't know if there is any resolution > to this and I actually don't know if this is really a problem but I > figured > I should share my concern.. I'm in the midst of changing the example to be endpoint routed, rather than proxy routed. We want to promote the endpoint routed model anyway. This should eliminate the confusion in the text. I think we need an unambiguous indication that LoST mapping has been done. We should discuss this point. [TER] It should be made clear that the presence of such an indication should in no way constrain a subsequent proxy from querying a LoST server. As we have discussed in the NENA Long Term Definition Working Group, it is very likely that emergency call routing will involve multiple queries being done by ESRPs of different levels (e.g., state, county, city), with the potential for each to result in different routing information. =20 >=20 > 3. Section 5.8 talks about location being validated prior to a device > placing > an actual emergency call. I don't understand what the text is trying > to say here. > How could the validation take place without the actual request?? I am > probably > being stupid here and not fully understanding the text here so > clarification would > be much appreciated. If you read on, you will see that the real validation is loading the value IN to the LIS. The endpoint can revalidate when it gets location (which is boot time and when it is reading location from the LIS), and any time thereafter. >=20 > 4. Section 16.5. Call Signaling Integrity I think is better provided by > SIP-Identity, > which can provide over some headers and message body end-to-end over > TLS > which only provides integrity hop-by-hop. You already recommend the > use of > sip-identity to provide caller-authentication, it won't hurt to > recommend its use > to provide signaling integrity. Well, most of the text talks about maintaining the privacy of the location header, but I added text for the integrity protection Identity would get you. Thanks 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 Fri Mar 02 08:15: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 1HN7bh-0005hZ-Hq; Fri, 02 Mar 2007 08:15:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN7bf-0005ZZ-PN for ecrit@ietf.org; Fri, 02 Mar 2007 08:15:31 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN7be-0007Ba-3s for ecrit@ietf.org; Fri, 02 Mar 2007 08:15:31 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HN7bM-0003mx-Vt; Fri, 02 Mar 2007 07:15:13 -0600 From: "Brian Rosen" To: "'Reese, Theresa E'" , "'Shida Schubert'" Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Date: Fri, 2 Mar 2007 08:15:16 -0500 Message-ID: <0ca601c75ccc$d388a520$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 In-Reply-To: Thread-Index: AccBNebGYPuzCpWIRwi+4Fv3MsgDNxbNN0qQABc6PhAAATcu4A== 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 Sure. We're just trying to make sure that proxies who try to be helpful don't screw up when a prior element already did the dip. The reliability of the information tends to go down the farther you get from the endpoint. Brian > -----Original Message----- > From: Reese, Theresa E [mailto:treese@telcordia.com] > Sent: Friday, March 02, 2007 7:44 AM > To: Brian Rosen; Shida Schubert > Cc: ECRIT > Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 > > Brian - > > One comment in-line. > > Terry Reese > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, March 01, 2007 8:39 PM > To: 'Shida Schubert' > Cc: 'ECRIT' > Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 > > I'm editing -framework and resolving comments. > > See in line for my responses > > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com] > > Sent: Sunday, November 05, 2006 6:55 PM > > To: ecrit@ietf.org > > Cc: Henning Schulzrinne; br@brianrosen.net > > Subject: Comments on draft-ietf-ecrit-framework-00 > > > > > > Hi; > > > > Few comments on the draft. > > > > 1. What is the early URL? I can guess what this is but I think > > it should be clarified somewhere as it > I removed the "early". It's just a URI now. > > > > 2. Section 3, 4th paragraph explains how the proxy(ESRP) > > would query the LoST server to resolve a Service URN but > > this is based on the assumption that the URI in the route header > > addressing the PSAP(assuming we are using the loose-route > > Jonathan proposed.) is stale. But is it really? And how do we > > know. There is no indication to show how fresh the psap-URI > > is. So UA can literally have obtained a new psap-URI just before > > it initiated an emergency call but according to the draft, ESRP or > > proxy would still redo the mapping.. Worse yet, because there is > > no indication that mapping has been accomplished, we may see > > multiple proxies redoing the mapping as it can't tell if the > mapping > > has been executed already.. I don't know if there is any resolution > > to this and I actually don't know if this is really a problem but I > > figured > > I should share my concern.. > I'm in the midst of changing the example to be endpoint routed, rather > than > proxy routed. We want to promote the endpoint routed model anyway. > This > should eliminate the confusion in the text. I think we need an > unambiguous > indication that LoST mapping has been done. We should discuss this > point. > > [TER] It should be made clear that the presence of such an indication > should in no way constrain a subsequent proxy from querying a LoST > server. As we have discussed in the NENA Long Term Definition Working > Group, it is very likely that emergency call routing will involve > multiple queries being done by ESRPs of different levels (e.g., state, > county, city), with the potential for each to result in different > routing information. > > > > > 3. Section 5.8 talks about location being validated prior to a device > > placing > > an actual emergency call. I don't understand what the text is > trying > > to say here. > > How could the validation take place without the actual request?? I > am > > probably > > being stupid here and not fully understanding the text here so > > clarification would > > be much appreciated. > If you read on, you will see that the real validation is loading the > value > IN to the LIS. The endpoint can revalidate when it gets location (which > is > boot time and when it is reading location from the LIS), and any time > thereafter. > > > > > > 4. Section 16.5. Call Signaling Integrity I think is better provided > by > > SIP-Identity, > > which can provide over some headers and message body end-to-end > over > > TLS > > which only provides integrity hop-by-hop. You already recommend the > > use of > > sip-identity to provide caller-authentication, it won't hurt to > > recommend its use > > to provide signaling integrity. > Well, most of the text talks about maintaining the privacy of the > location > header, but I added text for the integrity protection Identity would get > you. > > Thanks > 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 Fri Mar 02 08:21: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 1HN7h9-0005zL-Ed; Fri, 02 Mar 2007 08:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN7h5-0005vK-VN for ecrit@ietf.org; Fri, 02 Mar 2007 08:21:08 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN7eM-0007hl-0A for ecrit@ietf.org; Fri, 02 Mar 2007 08:18:19 -0500 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l22DI5525993; Fri, 2 Mar 2007 08:18:05 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007030208182809685 ; Fri, 02 Mar 2007 08:18:28 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Mar 2007 08:18:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Date: Fri, 2 Mar 2007 08:18:28 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Thread-Index: AccBNebGYPuzCpWIRwi+4Fv3MsgDNxbNN0qQABc6PhAAATcu4AAAIwaQ From: "Reese, Theresa E" To: "Brian Rosen" , "Shida Schubert" X-OriginalArrivalTime: 02 Mar 2007 13:18:28.0748 (UTC) FILETIME=[444FCCC0:01C75CCD] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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 - In the context of a multi-level ESRP model, I don't agree that "reliability of the information tends to go down the farther you get from the endpoint." Terry -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Friday, March 02, 2007 8:15 AM To: Reese, Theresa E; 'Shida Schubert' Cc: 'ECRIT' Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Sure. We're just trying to make sure that proxies who try to be helpful don't screw up when a prior element already did the dip. The reliability of the information tends to go down the farther you get from the endpoint. Brian > -----Original Message----- > From: Reese, Theresa E [mailto:treese@telcordia.com] > Sent: Friday, March 02, 2007 7:44 AM > To: Brian Rosen; Shida Schubert > Cc: ECRIT > Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 >=20 > Brian - >=20 > One comment in-line. >=20 > Terry Reese >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, March 01, 2007 8:39 PM > To: 'Shida Schubert' > Cc: 'ECRIT' > Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 >=20 > I'm editing -framework and resolving comments. >=20 > See in line for my responses >=20 > > -----Original Message----- > > From: Shida Schubert [mailto:shida@ntt-at.com] > > Sent: Sunday, November 05, 2006 6:55 PM > > To: ecrit@ietf.org > > Cc: Henning Schulzrinne; br@brianrosen.net > > Subject: Comments on draft-ietf-ecrit-framework-00 > > > > > > Hi; > > > > Few comments on the draft. > > > > 1. What is the early URL? I can guess what this is but I think > > it should be clarified somewhere as it > I removed the "early". It's just a URI now. > > > > 2. Section 3, 4th paragraph explains how the proxy(ESRP) > > would query the LoST server to resolve a Service URN but > > this is based on the assumption that the URI in the route header > > addressing the PSAP(assuming we are using the loose-route > > Jonathan proposed.) is stale. But is it really? And how do we > > know. There is no indication to show how fresh the psap-URI > > is. So UA can literally have obtained a new psap-URI just before > > it initiated an emergency call but according to the draft, ESRP or > > proxy would still redo the mapping.. Worse yet, because there is > > no indication that mapping has been accomplished, we may see > > multiple proxies redoing the mapping as it can't tell if the > mapping > > has been executed already.. I don't know if there is any resolution > > to this and I actually don't know if this is really a problem but I > > figured > > I should share my concern.. > I'm in the midst of changing the example to be endpoint routed, rather > than > proxy routed. We want to promote the endpoint routed model anyway. > This > should eliminate the confusion in the text. I think we need an > unambiguous > indication that LoST mapping has been done. We should discuss this > point. >=20 > [TER] It should be made clear that the presence of such an indication > should in no way constrain a subsequent proxy from querying a LoST > server. As we have discussed in the NENA Long Term Definition Working > Group, it is very likely that emergency call routing will involve > multiple queries being done by ESRPs of different levels (e.g., state, > county, city), with the potential for each to result in different > routing information. >=20 > > > > 3. Section 5.8 talks about location being validated prior to a device > > placing > > an actual emergency call. I don't understand what the text is > trying > > to say here. > > How could the validation take place without the actual request?? I > am > > probably > > being stupid here and not fully understanding the text here so > > clarification would > > be much appreciated. > If you read on, you will see that the real validation is loading the > value > IN to the LIS. The endpoint can revalidate when it gets location (which > is > boot time and when it is reading location from the LIS), and any time > thereafter. >=20 >=20 > > > > 4. Section 16.5. Call Signaling Integrity I think is better provided > by > > SIP-Identity, > > which can provide over some headers and message body end-to-end > over > > TLS > > which only provides integrity hop-by-hop. You already recommend the > > use of > > sip-identity to provide caller-authentication, it won't hurt to > > recommend its use > > to provide signaling integrity. > Well, most of the text talks about maintaining the privacy of the > location > header, but I added text for the integrity protection Identity would get > you. >=20 > Thanks > Brian >=20 >=20 > _______________________________________________ > 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 Mar 02 08:38: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 1HN7xm-0000Fi-9q; Fri, 02 Mar 2007 08:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HN7xk-0000FE-OF for ecrit@ietf.org; Fri, 02 Mar 2007 08:38:20 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HN7xj-000316-8q for ecrit@ietf.org; Fri, 02 Mar 2007 08:38:20 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HN7xb-0008GL-S9; Fri, 02 Mar 2007 07:38:12 -0600 From: "Brian Rosen" To: "'Reese, Theresa E'" , "'Shida Schubert'" Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 Date: Fri, 2 Mar 2007 08:38:15 -0500 Message-ID: <0cbb01c75cd0$098ce4d0$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 In-Reply-To: Thread-Index: AccBNebGYPuzCpWIRwi+4Fv3MsgDNxbNN0qQABc6PhAAATcu4AAAIwaQAACqC0A= 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-Source: X-Source-Args: X-Source-Dir: 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 Ah, we're talking past each other. I'm referring to proxies in the origination network, not in the emergency services network. Agree that within the emergency services networks, you may well do multiple levels of location based routing. State level ESRPs to PSAPs, PSAP ESRP to call takers. Brian > -----Original Message----- > From: Reese, Theresa E [mailto:treese@telcordia.com] > Sent: Friday, March 02, 2007 8:18 AM > To: Brian Rosen; Shida Schubert > Cc: ECRIT > Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 > > Brian - > > In the context of a multi-level ESRP model, I don't agree that > "reliability of the information tends to go down the farther you get > from the endpoint." > > Terry > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, March 02, 2007 8:15 AM > To: Reese, Theresa E; 'Shida Schubert' > Cc: 'ECRIT' > Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 > > Sure. We're just trying to make sure that proxies who try to be helpful > don't screw up when a prior element already did the dip. The > reliability of > the information tends to go down the farther you get from the endpoint. > > > Brian > > > -----Original Message----- > > From: Reese, Theresa E [mailto:treese@telcordia.com] > > Sent: Friday, March 02, 2007 7:44 AM > > To: Brian Rosen; Shida Schubert > > Cc: ECRIT > > Subject: RE: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 > > > > Brian - > > > > One comment in-line. > > > > Terry Reese > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, March 01, 2007 8:39 PM > > To: 'Shida Schubert' > > Cc: 'ECRIT' > > Subject: [Ecrit] RE: Comments on draft-ietf-ecrit-framework-00 > > > > I'm editing -framework and resolving comments. > > > > See in line for my responses > > > > > -----Original Message----- > > > From: Shida Schubert [mailto:shida@ntt-at.com] > > > Sent: Sunday, November 05, 2006 6:55 PM > > > To: ecrit@ietf.org > > > Cc: Henning Schulzrinne; br@brianrosen.net > > > Subject: Comments on draft-ietf-ecrit-framework-00 > > > > > > > > > Hi; > > > > > > Few comments on the draft. > > > > > > 1. What is the early URL? I can guess what this is but I think > > > it should be clarified somewhere as it > > I removed the "early". It's just a URI now. > > > > > > 2. Section 3, 4th paragraph explains how the proxy(ESRP) > > > would query the LoST server to resolve a Service URN but > > > this is based on the assumption that the URI in the route header > > > addressing the PSAP(assuming we are using the loose-route > > > Jonathan proposed.) is stale. But is it really? And how do we > > > know. There is no indication to show how fresh the psap-URI > > > is. So UA can literally have obtained a new psap-URI just before > > > it initiated an emergency call but according to the draft, ESRP > or > > > proxy would still redo the mapping.. Worse yet, because there is > > > no indication that mapping has been accomplished, we may see > > > multiple proxies redoing the mapping as it can't tell if the > > mapping > > > has been executed already.. I don't know if there is any > resolution > > > to this and I actually don't know if this is really a problem but > I > > > figured > > > I should share my concern.. > > I'm in the midst of changing the example to be endpoint routed, rather > > than > > proxy routed. We want to promote the endpoint routed model anyway. > > This > > should eliminate the confusion in the text. I think we need an > > unambiguous > > indication that LoST mapping has been done. We should discuss this > > point. > > > > [TER] It should be made clear that the presence of such an indication > > should in no way constrain a subsequent proxy from querying a LoST > > server. As we have discussed in the NENA Long Term Definition Working > > Group, it is very likely that emergency call routing will involve > > multiple queries being done by ESRPs of different levels (e.g., state, > > county, city), with the potential for each to result in different > > routing information. > > > > > > > > 3. Section 5.8 talks about location being validated prior to a > device > > > placing > > > an actual emergency call. I don't understand what the text is > > trying > > > to say here. > > > How could the validation take place without the actual request?? > I > > am > > > probably > > > being stupid here and not fully understanding the text here so > > > clarification would > > > be much appreciated. > > If you read on, you will see that the real validation is loading the > > value > > IN to the LIS. The endpoint can revalidate when it gets location > (which > > is > > boot time and when it is reading location from the LIS), and any time > > thereafter. > > > > > > > > > > 4. Section 16.5. Call Signaling Integrity I think is better > provided > > by > > > SIP-Identity, > > > which can provide over some headers and message body end-to-end > > over > > > TLS > > > which only provides integrity hop-by-hop. You already recommend > the > > > use of > > > sip-identity to provide caller-authentication, it won't hurt to > > > recommend its use > > > to provide signaling integrity. > > Well, most of the text talks about maintaining the privacy of the > > location > > header, but I added text for the integrity protection Identity would > get > > you. > > > > Thanks > > 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 Fri Mar 02 21:23: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 1HNJuA-0002Ph-Sc; Fri, 02 Mar 2007 21:23:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNJtt-00020L-GX for ecrit@ietf.org; Fri, 02 Mar 2007 21:23:09 -0500 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNJts-00083N-Su for ecrit@ietf.org; Fri, 02 Mar 2007 21:23:09 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.5) with ESMTP id ; Fri, 2 Mar 2007 18:23:08 -0800 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: [Ecrit] draft-ietf-ecrit-requirements-13 as a result of AD comments Date: Fri, 2 Mar 2007 18:23:01 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657506E9FC19@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-requirements-13 as a result of AD comments Thread-Index: AcdR1NCn1zXH10ejQqeO0XfrwUsHigLZUuwg References: From: "Roger Marshall" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd Cc: Marc Linsner 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've updated the requirements draft, which has been submitted, and will get posted as draft-ietf-ecrit-requirements-13 soon. =20 RE: Change log to document changes from: draft-ietf-ecrit-requirements-12 to upcoming version -13. Date: 3/02/07 By: R. Marshall C1. Delete following requirement Ma18, since it is not clear how it is different than Ma15. Ma18. Alternate mapping sources: The mapping protocol MUST implement a mechanism that allows for the retrieval of mapping information from different sources. Motivation: This provides the possibility of having available alternative sources of mapping information when the normal source is unavailable or unreachable. C2. Renumber Ma19 to Ma18 per above. C3. Change last paragraph to section 1, based on Jon's comment: I expected the last paragraph in Section 1 to have an additional=20 >> sentence saying something to the effect that the latter use=20 >> (displaying location information at the PSAP) is orthogonal to the=20 >> mapping protocol problem and the scope of this document. Change from: Location is required for two separate purposes, first, to support the routing of the emergency call to the appropriate PSAP and second, to display the caller's location to the call taker to help in dispatching emergency assistance to the appropriate location. Change to: (appended paragraph) Location is required for two separate purposes, first, to support the routing of the emergency call to the appropriate PSAP and second, to display the caller's location to the call taker to help in dispatching emergency assistance to the appropriate location. This latter use, the display of location information to the PSAP, is orthogonal to the mapping protocol, and is outside the scope of this document. C4. Change term "Internet Attachment Provider", based on comment below: >> 3.2 - The term "Internet Attachment Provider" is not a common one,=20 >> and doesn't seem to be distinguished from the more common concept of=20 >> an access network. I would suggest that "access network" at least be=20 >> provided as a synonym in the definition. > > My suggestion would be to switch to "Internet Access Provider", as=20 > that seems closer to common usage. Plus, 'attachment' is probably not=20 > a good fit for, say, 'unattached' network connections, such as wireless.. Change from: "Internet Attachment Provider" to: "Internet Access Provider"=20 (throughout, including diagram). C5. Change definition of ESRP from a B2BUA, to something more general, per the folowing AD review comment. >> 3.4 - I'm not sure what the need is to suggest that the ESRP function >> might be performed by a B2BUA. At a high level, I suppose I see the=20 >> mapping client function as one that could be performed by a number of >> entities, including entities that instantiate the SIP proxy role and=20 >> the SIP user agent client role. I think language to that effect would >> be preferable to suggesting that there is some motivation for pairing >> the mapping client function with a B2BUA. Change from: Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call routing support entity that invokes the location-to-PSAP URI mapping, to return either the URI for the appropriate PSAP, or the URI for another ESRP. (In a SIP system, the ESRP would typically be a SIP proxy, but may also be a back-to-back user agent (B2BUA)). Change to: Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call routing support entity that invokes the location-to-PSAP URI mapping function, to return an appropriate PSAP URI, or the URI for another ESRP. Client mapping requests could also be=20 performed by a number of entities, including entities that=20 instantiate the SIP proxy role and the SIP user agent client role. C6. Fix broken sentence, (per comment below): >> (Emergency) service URL: The service URL is a protocol-specific=20 >> (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the address >> of the PSAP or other emergency service. >> >> after the im: citation, you probably want the words: "identifier=20 >> which" >> Yes, "identifier which" must be added. Change from: (Emergency) service URL: The service URL is a protocol-specific (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the address of the PSAP or other emergency service. It depends on the specific signaling or data transport protocol used to reach the emergency service. Change to: (Emergency) service URL: The service URL is a protocol-specific (e.g., SIP) or protocol-agnostic (e.g., im: [5]) identifier which contains the address of the PSAP or other emergency service. It depends on the specific signaling or data transport protocol used to reach the emergency service. C7. Change Lo5 Heading (per comment below): >> In Section 6, why is Lo5 called "Validation resolution"? The=20 >> description of the requirement doesn't seem to relate to validation=20 >> or resolution, as far as I can tell. "Additional Information" or=20 >> something might be a better name for this requirement. > > I agree that the heading is not helpful. I'd suggest calling it > > Information about location data used for mapping > > I agree that changing the heading would help to make it clearer. Change Lo5 heading from: "Validation resolution"=20 Change Lo5 heading to: "Information about location data used for mapping" C8.=20 >> In Section 8, Ma11 uses the seemingly innocuous name "URI properties" >> to provide requirements that seem to contradict Ma8. If the mapping=20 >> protocol is going to return multiple PSAP URIs as described in Ma11,=20 >> there should be a story stronger than "local policy" to meet the=20 >> requirement of Ma8. You might want to find a better name for Ma11=20 >> than "URI properties", too. [RM comment - Whereas Ma8 is a SHOULD, i.e., that it is optimal for only one URI be returned, yet it allows for cases where more than one may be returned, Ma11 is a MUST, i.e., must be able to return extra info to help pick one URI over the other - in the case where there are multiple URIs returned. I see no contradiction between the two reqs.] No change made to either Ma8 or Ma11. C9. Change to Ma15 Heading, change from, "Resilience to failure" to, "Resilience to mapping server failure" (per the comments below). [above comment con't] >> >> Also in 8, how is Ma15 different from Ma18? > > I'm not sure I'm interpreting your question correctly, but Ma15 talks=20 > about reliability of the mapping protocol, while Ma8 talks about=20 > returning mappings to achieve reliability. To make this clearer, the=20 > title in Ma15 should be changed to > > Resilience to mapping server failure > I also believe that the problem would be fixed by changing the heading of Ma15 to "Resilience to mapping server failure". C10. Delete requirement Ma9 (per Henning's/Hannes' comments below): > By the way, we've decided to not do Ma9, based on additional=20 > discussion, so I'd suggest dropping it. Not that anybody is going to=20 > do a point-by-point comparison of LoST to the requirements document... > I would also suggest to delete Ma9. Requirement Ma9 deleted. Requirements Ma10-Ma18 now renamed to Ma9-Ma17. /end. Roger Marshall =20 >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >Sent: Friday, March 02, 2007 6:12 AM >To: Peterson, Jon >Cc: Henning Schulzrinne; hgs+ecrit@cs.columbia.edu; Roger Marshall;=20 >Marc Linsner >Subject: Re: AD review of draft-ietf-ecrit-requirements-12.txt > >Hi Jon, > >Ma15 vs. Ma18: Let's delete Ma18. I cannot figure out what the=20 >difference is to Ma15. > >Ciao >Hannes > > >Peterson, Jon wrote: >>>>> Also in 8, how is Ma15 different from Ma18? >>>>> =20 >>>> I'm not sure I'm interpreting your question correctly, but >>>> =20 >>> Ma15 talks >>> =20 >>>> about reliability of the mapping protocol, while Ma8 talks about=20 >>>> returning mappings to achieve reliability. To make this >>>> =20 >>> clearer, the >>> =20 >>>> title in Ma15 should be changed to >>>> >>>> Resilience to mapping server failure >>>> >>>> =20 >>> I also believe that the problem would be fixed by changing the=20 >>> heading of Ma15 to "Resilience to mapping server failure". >>> >>> Ma8 is fine as it is and fits perfectly what we did in the protocol=20 >>> design. >>> =20 >> >> For the record, I was asking how Ma15 is different from >-Ma18-, not -Ma8-. >> >> - J >> =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 Mar 02 22: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 1HNL5Y-0008H0-V0; Fri, 02 Mar 2007 22:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNL5X-0008Ew-1Q for ecrit@ietf.org; Fri, 02 Mar 2007 22:39:15 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNL5V-0007My-KP for ecrit@ietf.org; Fri, 02 Mar 2007 22:39:15 -0500 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 l233cw40013814; Fri, 2 Mar 2007 20:38:59 -0700 Message-ID: <45E8EDD5.8010506@ntt-at.com> Date: Fri, 02 Mar 2007 19:39:01 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Henning Schulzrinne References: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> <45E793A6.2070100@ntt-at.com> <45E8050B.5070803@cs.columbia.edu> In-Reply-To: <45E8050B.5070803@cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: 'ECRIT' Subject: [Ecrit] Re: Comments on draft-ietf-ecrit-framework-00 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 Henning, >> I think the current direction of how to route and label the emergency >> call was to place Service URN >> in R-URI and PSAP URI in the Route header. Problem I see with this is >> that if there are more than >> one LoST querying proxy, the recursive LoST query may result in each >> of the LoST server resolving >> to the same URI placed in the Route header(time delay, failure at one >> server can mean call failure). > > They should never resolve to the same URI, as that would presumably > cause looping. Let's say if the outbound proxy resolves to (PSAP) URL > A. If A does the resolution and again produces A, you have a problem. > No amount of identification is going to help with that problem. > > Please remember that SIP doesn't just randomly route messages. A > proxy, except for the outbound proxy, will be named in the R-URL or > the Route header. Otherwise, it's an error. You can't just expect to > send a SIP message with a random URL to a proxy and say "please take > care of it". (Otherwise, we'd have a problem very similar to the open > relays in SMTP that caused a fair amount of email spam grief until > running such an open relay would be a one-way ticket to a black list.) The source of resolution is location, so I am assuming every time you conduct the resolution, the resolution in fact should resolve to the same URL. So your statement about resolution pointing to a different PSAP URI puzzles me and concerns me a bit. If you are calling the fact that resolution for same location-info always resolve to the same URI is a loop, and is a problem then I think we have problem in hand. 1. Assuming user was roaming from a hotel. 2. User ends up with record-set for outbound proxy of the hotel and home proxy. 3. UA does the LoST resolution and forwards the request to outbound proxy. 4. Outbound proxy does the LoST resolution and forwards the request to the next route(home proxy). 5. Home proxy does the LoST resolution and forwards the request to the next route(hopefully PSAP). I think what's illustrated above can easily happen. I may be misunderstanding something very fundamental and if so, I do appreciate it if you can aid me so I have the right understanding. As I was thinking about this, another question I had was if there are more than one LoST querying proxy on the signaling path what happens when each LoST querying proxy uses different location information contained in the request. Assuming I was in Prague, connecting to my home proxy via VPN and my UA obtained location from 1. GPS (geo-location[Prague]) 2. DHCP (civic-location[Czech]) and home proxy inserted location reference (may be civic-location[North America]) Each of the location may be different enough that resolution for each of the location may resolve to a different PSAP URI. And if the behavior of proxy for the resolved URI is to push it into the route-set, the request may end up with 3 Route entry each destined for different PSAPs. Probably not a problem, as I understand PSAP operator always ask for the physical location to the caller.. Regards Shida > >> >> As PSAP URI is expected to have no constant semantics indicating that >> it's a URI for PSAP, dip >> indicator may be needed to prevent this recursive LoST query at every >> LoST querying proxy along >> the signaling path. > > See above; this doesn't work and is unnecessary. > > >> As I understand Henning's idea was to use R-URI/Route header as an >> indicator to trigger the >> resolution. >> >> 1. If R-URI is urn:sos and Route header is not the proxy handling the >> message then the proxy is to assume >> the resolution is already done. > > As noted above, this can only occur if the proxy is an outbound proxy > (P-CSCF in IMS terminology, I think). > > >> 2. If R-URI is urn:sos and Route header is the proxy handling the >> message then the proxy is to conduct >> the resolution if capable. > > Right. > >> 3. If R-URI is urn:sos and Route header is empty obviously the >> resolution hasn't been completed thus >> the resolution is necessary if the proxy handling the message is >> capable to do so. >> >> I don't know how this would work with pre-configured route set and >> service-route etc. >> > > Case 2 applies. Details probably require a bit of thought, as there > are several possible answers, depending on whether that resolving > proxy also "flushes" the remainder of the routes if it's in the > middle of a route list or just adds the PSAP URI to the end of the > list, which would be the normal behavior. I suspect that this depends > a bit on the operational environment. Would an operator, for example, > want the call to visit its service proxies before it heads to the > PSAP? Given the proclivity of some architectures to tie, say, media > authorization to SIP signaling, this may be necessary. > > In short, I'm opposed to an explicit marking since it would either be > redundant or insufficient. The latter would occur if multiple mappings > are done, as you'd have to keep track not just of whether "a" mapping > has taken place, but which ones and where, essentially re-inventing > Via or history (4244), depending on the details of how calls are > bounced around. > > Henning > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 03 04:01: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 1HNQ6e-0005om-Fm; Sat, 03 Mar 2007 04:00:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNQ6b-0005Ve-VK for ecrit@ietf.org; Sat, 03 Mar 2007 04:00:41 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNQ6a-0001t3-OS for ecrit@ietf.org; Sat, 03 Mar 2007 04:00:41 -0500 Received: from [84.186.210.69] (p54BAD245.dip.t-dialin.net [84.186.210.69]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2390P7i013265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Mar 2007 04:00:27 -0500 (EST) Message-ID: <45E93929.5000506@cs.columbia.edu> Date: Sat, 03 Mar 2007 10:00:25 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: shida@ntt-at.com References: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> <45E793A6.2070100@ntt-at.com> <45E8050B.5070803@cs.columbia.edu> <45E8EDD5.8010506@ntt-at.com> In-Reply-To: <45E8EDD5.8010506@ntt-at.com> Content-Type: text/plain; charset=UTF-8; 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'ECRIT' Subject: [Ecrit] Re: Comments on draft-ietf-ecrit-framework-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 > The source of resolution is location, so I am assuming every time you > conduct the resolution, > the resolution in fact should resolve to the same URL. So your statement Not necessarily. The idea, discussed on this list, would be that you do incremental resolution: location -> national ESRP uses location to derive -> state ESRP, which uses location to arrive at actual PSAP Thus, you might have the URLs esrp@fema.gov emergency@nj.state.us 911@leonianj.gov along the way. > > Each of the location may be different enough that resolution for each of > the location may resolve to a different > PSAP URI. And if the behavior of proxy for the resolved URI is to push > it into the route-set, the request may end > up with 3 Route entry each destined for different PSAPs. Probably not a > problem, as I understand PSAP operator > always ask for the physical location to the caller.. Note that the route will only be pushed once the call actually reaches that destination, unless each intermediary decides to do resolution from scratch. Even in that case, there will be somewhat rational behavior in that the call will arrive at the PSAP that has been identified first, with some additional Route's left over. > > Regards > Shida > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 03 15:26: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 1HNao2-0004dJ-4z; Sat, 03 Mar 2007 15:26:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNao1-0004dA-A4 for ecrit@ietf.org; Sat, 03 Mar 2007 15:26:13 -0500 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNanv-0001tD-AR for ecrit@ietf.org; Sat, 03 Mar 2007 15:26:13 -0500 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 l23KPtfH031340; Sat, 3 Mar 2007 13:25:56 -0700 Message-ID: <45E9D9D7.7050005@ntt-at.com> Date: Sat, 03 Mar 2007 12:25:59 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Henning Schulzrinne References: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> <45E793A6.2070100@ntt-at.com> <45E8050B.5070803@cs.columbia.edu> <45E8EDD5.8010506@ntt-at.com> <45E93929.5000506@cs.columbia.edu> In-Reply-To: <45E93929.5000506@cs.columbia.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 'ECRIT' Subject: [Ecrit] Re: Comments on draft-ietf-ecrit-framework-00 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 Hmm.. Interesting.. I understand how this would work once it gets into the ESRP domain(or network or whatever you want to call it), to find a finer grained resolution. What I want to know is if I am understanding correctly whether UA, hotel proxy and home proxy when conducting a LoST query on say, civic location obtained through DHCP, that it would resolve to a same URI(PSAP or ESRP..)? If not I am totally LoST.. Regards Shida Henning Schulzrinne wrote: >> The source of resolution is location, so I am assuming every time you >> conduct the resolution, >> the resolution in fact should resolve to the same URL. So your statement > > Not necessarily. The idea, discussed on this list, would be that you > do incremental resolution: > > location -> national ESRP uses location to derive -> state ESRP, which > uses location to arrive at actual PSAP > > Thus, you might have the URLs > > esrp@fema.gov > emergency@nj.state.us > 911@leonianj.gov > > along the way. > >> >> Each of the location may be different enough that resolution for each >> of the location may resolve to a different >> PSAP URI. And if the behavior of proxy for the resolved URI is to >> push it into the route-set, the request may end >> up with 3 Route entry each destined for different PSAPs. Probably >> not a problem, as I understand PSAP operator >> always ask for the physical location to the caller.. > > Note that the route will only be pushed once the call actually reaches > that destination, unless each intermediary decides to do resolution > from scratch. Even in that case, there will be somewhat rational > behavior in that the call will arrive at the PSAP that has been > identified first, with some additional Route's left over. > > >> >> Regards >> Shida >> > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Mar 03 15:40: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 1HNb1q-0000cS-Lr; Sat, 03 Mar 2007 15:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNb1p-0000b2-Jk for ecrit@ietf.org; Sat, 03 Mar 2007 15:40:29 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNb1o-0003sS-Dd for ecrit@ietf.org; Sat, 03 Mar 2007 15:40:29 -0500 Received: from [84.186.210.69] (p54BAD245.dip.t-dialin.net [84.186.210.69]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l23Ke40U019477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Mar 2007 15:40:06 -0500 (EST) Message-ID: <45E9DD25.9010509@cs.columbia.edu> Date: Sat, 03 Mar 2007 21:40:05 +0100 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: shida@ntt-at.com References: <0bef01c75c6b$98f3a970$640fa8c0@cis.neustar.com> <45E793A6.2070100@ntt-at.com> <45E8050B.5070803@cs.columbia.edu> <45E8EDD5.8010506@ntt-at.com> <45E93929.5000506@cs.columbia.edu> <45E9D9D7.7050005@ntt-at.com> In-Reply-To: <45E9D9D7.7050005@ntt-at.com> Content-Type: text/plain; charset=UTF-8; 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: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'ECRIT' Subject: [Ecrit] Re: Comments on draft-ietf-ecrit-framework-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 Shida Schubert wrote: > What I want to know is if I am understanding correctly whether UA, > hotel proxy and home proxy when conducting a LoST query on say, civic > location > obtained through DHCP, that it would resolve to a same URI(PSAP or ESRP..)? Yes, like you said - it would be rather odd (and some kind of fault) if they didn't. There are various disclaimers about caching behavior, roundtrip delays while databases are being updated, etc, but I don't think you were worried about that... > > If not I am totally LoST.. > > Regards > Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 04 16:32: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 1HNyJU-0003ej-0B; Sun, 04 Mar 2007 16:32:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNyJT-0003ee-20 for ecrit@ietf.org; Sun, 04 Mar 2007 16:32:15 -0500 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNyJR-0000db-N5 for ecrit@ietf.org; Sun, 04 Mar 2007 16:32:15 -0500 Received: from GunnarH (217.208.188.8) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 45D47D3D00463E2A for ecrit@ietf.org; Sun, 4 Mar 2007 22:32:06 +0100 Message-ID: <45D47D3D00463E2A@pne-smtpout2-sn1.fre.skanova.net> (added by postmaster@pne.skanova.net) From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Ecrit@Ietf. Org" Date: Sun, 4 Mar 2007 22:32:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcdepHDwfykCbDblRxqkM0SFuT1q6Q== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Ecrit] Modification proposals for media support in draft-ietf-ecrit-phonebcp 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 want to propose a few small modifications to=20 draft-ietf-ecrit-phonebcp-00.txt 1. Editorial and explanation. ---------------------------------- The last lines in section 2 reads: =93o The proxy recognizes the call as an emergency call and routes = the call using normal SIP routing mechanisms [RFC4504] details Best Current Practice for SIP user agents. This memo can be considered an addition to it for endpoints.=94 A full stop is missing after mechanisms, and it is unusual to start a sentence with a reference. I also suggest to include a hint on what is = found in RFC 4504 I suggest a slight change to: " o The proxy recognizes the call as an emergency call, routes the call using normal SIP routing mechanisms. Best Current Practice for SIP user agents including handling of audio = and real-time text [RFC 4103] media detailed in [RFC4504] SHOULD be applied. This memo can be considered an addition to it for endpoints." 2. Add a bullet point in the list in section 2. ------------------------------------------------ I also suggest that the sequence of steps should end with media establishment rather than just routing Insert as a new bullet point last in the list in section 2: o The call is established and common media streams opened. 3. More real-time text improvements --------------------------------------- Section 3 starts: " Although present PSAPs have only support for voice calls" That is not true. A reasonable part of the population has also support = for real-time text calls. So, the support for real-time text expected from = IP is to maintain and extend support rather than fulfilling new expectations. I suggest rewording to: " Support for voice calls and real-time text calls placed through PSTN facilities or systems connected to the PSTN is found in = present PSAPs. Future PSAPs will however support Internet connectivity and a = wider range of media types and provide higher functionality." 4. Handle unused references. ---------------------------- In the current version, I have observed two unused references. [RFC 4103] and [draft-ietf-sipping-toip], both related to the real-time = text medium.=20 Revival of reference [rfc 4103] is proposed in 3) above. In order to revive the use of [sipping-toip], I suggest adding this line between the two paragraphs of section 3: "The expectations for emergency service support for the real-time text medium, described in [draft-ietf-sipping-toip], section 7.1 SHOULD be fulfilled." ( draft-ietf-sipping-toip-07 is in publication requested state ) With these small changes I think the phonebcp draft will be a good = guidance for design of user terminals. Thanks Gunnar ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 04 19:44: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 1HO1Ir-0006oe-A4; Sun, 04 Mar 2007 19:43:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO1Iq-0006no-1b for ecrit@ietf.org; Sun, 04 Mar 2007 19:43:48 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO1Il-0006gl-Pf for ecrit@ietf.org; Sun, 04 Mar 2007 19:43:48 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HO1IV-0001v8-1j; Sun, 04 Mar 2007 18:43:28 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" Subject: RE: [Ecrit] Review of the ECRIT Framework Draft Date: Sun, 4 Mar 2007 19:43:36 -0500 Message-ID: <000001c75ebf$52adb9f0$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: <45A4EF4C.6000409@gmx.net> Thread-Index: Acc0vm9arufquMdqTzeb3jRnedvbSQp43gTA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "'Nennker, Axel'" 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 did not make many of the suggested additions in this review. The subject of signing location is active, and when it concludes, I will add text accordingly. A number of other suggestions, I did not agree with, and will raise at another time after I get this version out. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, January 10, 2007 8:51 AM > To: ECRIT > Cc: Nennker, Axel > Subject: [Ecrit] Review of the ECRIT Framework Draft > > Hi all, > > Axel Nennker has done a review of draft-ietf-ecrit-framework-00.txt and > he also suggests text! > > Here is his review: > http://www.ietf-ecrit.org/TEMP/draft-ietf-ecrit-framework-00-nennker.doc > > Thank you Axel for your work. > > Ciao > Hannes > > > _______________________________________________ > 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 Mar 04 19:44: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 1HO1Ip-0006nj-TW; Sun, 04 Mar 2007 19:43:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO1Io-0006nZ-P0 for ecrit@ietf.org; Sun, 04 Mar 2007 19:43:46 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO1In-0006hA-MH for ecrit@ietf.org; Sun, 04 Mar 2007 19:43:46 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HO1IX-0001v8-Co; Sun, 04 Mar 2007 18:43:31 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'ECRIT'" Subject: RE: [Ecrit] Comments on [draft-ietf-ecrit-framework-00.txt] Date: Sun, 4 Mar 2007 19:43:37 -0500 Message-ID: <000101c75ebf$541957e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA2B535F@crexc41p> Thread-Index: Acc1mWegHbAYW4oZR5CanKpFGjpNIwm0jj9Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7b4956e5f2f9c5fe16a8fbd4ddb538bc 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: , Content-Type: multipart/mixed; boundary="===============0091560300==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0091560300== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C75E95.6B434FE0" This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C75E95.6B434FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm finally editing -framework. See my responses inline _____ From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Sent: Thursday, January 11, 2007 10:58 AM To: ECRIT Subject: [Ecrit] Comments on [draft-ietf-ecrit-framework-00.txt] I reviewed this document from the perspective of an employee of a major service provider. Nonetheless, these opinions are mine, as an individual. I think the overall framework here is reasonable and do-able, and I support this effort. I also understand that this document is incomplete and not ready for publication, and it will continue to be improved upon. As a general comment, I had to review phonebcp in conjunction with this framework, because there are so many references to it. I realize phonebcp isn't an ecrit document, but I would recommend it be included on the service provider review page. It's highly integral to understanding the overall architecture.
I agree. -framework (which is informative and big picture) refers to -phonebcp (which is "normative" in the sense that a BCP specifies behavior) and -phonebcp tries to mechanize what -framework says. I don't see any request to change text in either document here, but if you have suggestions, they would be welcome Specific comments: ------------------------------ The definition of ESRP in ecrit requirements seems different than the definition of ESRP in the NENA i3 Functional and Interface Standards. The ecrit requirements and the usage of the term in "framework" seem to suggest that the ESRP could be in the VSP (voice provider) network, since proxies in the VSP network may also do LoST queries. It's not clear that the ESRP expects to get a different LoST response than the endpoint. The NENA doc says that the ESRP is an entry point to a group of PSAPs, and implies that it is the thing that gets routed to by the uri returned by the SIP device's LoST query. Is there something we can do so ESRP means the same thing in both places? I think the NENA usage is what's intended, and the query for routing info done by the ESRP returns different and more detailed routing info than the one done by the SIP end device. The SIP device LoST query leads to the ESRP, and the ESRP query leads to the PSAP. It's also possible for the VSP proxy to do LoST queries, but that doesn't make it an ESRP. A VSP proxy's LoST query would return the same uri as the SIP device's query.
I have modified the text to make it more clear that an "ESRP" is something in the emergency services domain. I just call a proxy that may provide some emergency call services a "sip proxy server". In the IMS world, that would be an "E-CSCF", but if I had my druthers, it would be the endpoing doing the work, with the regular outbound proxy (the first proxy that gets a call) doing backstop for the endpoint not doing it. We're not going to get into the NENA i3 work in this document. ecrit requirements: Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call routing support entity that invokes the location-to-PSAP URI mapping, to return either the URI for the appropriate PSAP, or the URI for another ESRP. (In a SIP system, the ESRP would typically be a SIP proxy, but may also be a back-to-back user agent (B2BUA)). NENA: Emergency Services Routing Proxy (ESRP) - This ESRP is a routing proxy that acts on behalf of a group of PSAPs, to provide intermediate or final routing to the PSAP, based on the caller's location. This function is not identified explicitly in the i3 functional architecture, but has been discussed in industry presentations and the concept is included in Framework for Emergency Calling in Internet Multimedia [3]. The ESRP function is included in the example physical architecture. Section 2, 3rd full paragraph on Page 6 The term "master-slave" is considered politically incorrect by many governmental bodies in the US. I recommend using other terms to describe these protocols.
fixed Section 3, Figure 1 Needs descriptive text. What do the numbers mean? Boxes also need definition, although they're defined in the Figure 2 description. This is all just editorial, though.
the numbers are defined in the text as the message numbers. I have significantly reworked this part. Would you look at it again and tell me if you think I've dealt with this problems? Bullet 2 (of Figure 2 description) What is meant by "local domain"? I usually consider my "local domain" to be the domain of my home router, or the domain of my ISP (if my router has no domain). But SIP registration uses a SIP domain, which I don't see as overly "local", since the registration server could be 1000 miles away, or more. Could this maybe be worded something like "...for Alice's UA to register with. Most SIP UAs will register with a server, so it will be a common scenario for UAs that make emergency calls to be registered with a server."
fixed Bullet 3 [editorial]: change "initiated" to "initiates"
I reworded text here, and "initiated is gone Paragraph after the bullets "...UA ... has location configured within her UA when her UA boots..." Is this meant to describe the case where the UA gets location configuration as part of its boot process, such as DHCP or L7 CP? Or does it imply a statically stored location which the UA finds and uses during its boot process? This wasn't clear to me. In general, I think there are 3 basic ways the UA could be configured: (1) a saved manually entered location, (2) location manually entered after it boots, (3) receives a location from the network. The location from the network could be a measured location, or it could be based on knowing the physical locations of network termination points. This sentence doesn't convey that to me.
the text has been edited heavily. Is it more clear now? Next paragraph, that starts with "Some time..." [Editorial]: change "initiated" to "initiates"
fixed Section 6.3 2nd paragraph: "XRef" should probably be [phonebcp]? If it is, then the 3rd to last sentence and the last sentence would be redundant. Note that these guidelines for dealing with multiple locations are not in phonebcp at this time. I'll make this comment against phonebcp.
-pidf-lo-profile discusses the various ways you get multiple location things and what they should be used for. Conveyance adds yet another dimension to that. -phonebcp needs text to advise. I fixed the reference here to -pidf-lo-profile, and added "additional" to "guidance". 3rd paragraph [editorial] end of the paragraph "...and ask the caller with." doesn't make sense.
fixed Section 5.4 [editorial] 2 instances where "can" needs to be "can be"
fixed Section 5.8 I recommend changing "...to ensure that phone billing records correspond to valid..." to "...to ensure that the service addresses in phone billing records correspond to valid..." Section 5.9 What is CMTS? Naturally, "(how?)" needs to be resolved.
defined as Cable Modem Termination system. We need a discussion on how to mark default locations. Section 6 Paragraph at the end of page 20. I had questions here as to whether this VSP proxy would be an ESRP, based on the ecrit requirements definition and the usage of that term in this document. I'm hoping it would not be an ESRP.
It's not, and the adjusted text above should make that clear Section 7 I'm not sure how practical persistent TLS connection are for large VSPs, given that they may have to connect to thousands of PSAPs.
I don't think that is a problem. In practical terms in the U.S. the VSP will connect to 50 state level ESRPs, which will be next hop for them. Section 9 Recommend several references to phonebcp in this section, since phonebcp specifically discusses where these IDs are placed in the SIP message.
done Section 11 I would slightly expand this section to also mention the disabling of calling features. For example, change the header and add a sentence like "The disabling of other call features, such as call waiting, is also discussed in phonebcp.
done Barbara Stark BellSouth Science & Technology (a recently acquired part of AT&T) ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA624 ------=_NextPart_000_0002_01C75E95.6B434FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on [draft-ietf-ecrit-framework-00.txt]

I’m finally editing –framework.   See my responses = inline

 

From: = Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]
Sent: Thursday, January = 11, 2007 10:58 AM
To: ECRIT
Subject: [Ecrit] Comments = on [draft-ietf-ecrit-framework-00.txt]

 

I reviewed this document from the perspective of an employee of a major = service provider. Nonetheless, these opinions are mine, as an = individual.

I think the overall framework here is reasonable and do-able, and I = support this effort. I also understand that this document is incomplete and not ready = for publication, and it will continue to be improved = upon.

As a general comment, I had to review phonebcp in conjunction with this = framework, because there are so many references to it. I realize phonebcp isn't an = ecrit document, but I would recommend it be included on the service provider = review page. It's highly integral to understanding the overall = architecture.

<br>I agree.  –framework (which is informative and big picture) refers to –phonebcp (which is “normative” in the sense that a BCP specifies behavior) and –phonebcp tries to mechanize what –framework says.  I don’t see any request to change text in either document here, but = if you have suggestions, they would be welcome

Specific comments:
----------------------------= --
The definition of ESRP in ecrit requirements seems different than the = definition of ESRP in the NENA i3 Functional and Interface Standards. The ecrit = requirements and the usage of the term in "framework" seem to suggest that = the ESRP could be in the VSP (voice provider) network, since proxies in the = VSP network may also do LoST queries. It's not clear that the ESRP expects = to get a different LoST response than the endpoint. The NENA doc says that the = ESRP is an entry point to a group of PSAPs, and implies that it is the thing = that gets routed to by the uri returned by the SIP device's LoST query. Is there something we can do so ESRP means the same thing in both places? I think = the NENA usage is what's intended, and the query for routing info done by = the ESRP returns different and more detailed routing info than the one done by = the SIP end device. The SIP device LoST query leads to the ESRP, and the ESRP = query leads to the PSAP. It's also possible for the VSP proxy to do LoST = queries, but that doesn't make it an ESRP. A VSP proxy's LoST query would return the = same uri as the SIP device's query.

<br>I have modified the text to make it more = clear that an “ESRP” is something in the emergency services = domain.  I just call a proxy that may provide some emergency call services a = “sip proxy server”.  In the IMS world, that would be an “E-CSCF”, but if I had my druthers, it would be the endpoing = doing the work, with the regular outbound proxy (the first proxy that gets a = call) doing backstop for the endpoint not doing it.  We’re not = going to get into the NENA i3 work in this document.

ecrit requirements:
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call = routing support entity that invokes the location-to-PSAP URI mapping, to return = either the URI for the appropriate PSAP, or the URI for another ESRP. (In a SIP system, the ESRP would typically be a SIP proxy, but may also be a = back-to-back user agent (B2BUA)).

NENA:
Emergency Services Routing Proxy (ESRP) - This ESRP is a routing proxy = that acts on behalf of a group of PSAPs, to provide intermediate or final = routing to the PSAP, based on the caller’s location. This function is not = identified explicitly in the i3 functional architecture, but has been discussed in industry presentations and the concept is included in Framework for Emergency Calling in Internet = Multimedia <http://www.ietf.org/internet-drafts/draft-rosen-ecrit-framework-00= .txt> [3]. The ESRP function is included in the example physical = architecture.

Section 2, 3rd full paragraph on Page 6
The term "master-slave" is considered politically incorrect by = many governmental bodies in the US. I recommend using other terms to describe these = protocols.

<br> fixed

Section 3, Figure 1
Needs descriptive text. What do the numbers mean? Boxes also need = definition, although they're defined in the Figure 2 description. This is all just editorial, though.

<br>the numbers are defined in the text as the message numbers.  I have significantly reworked this part.  Would you look at it again and = tell me if you think I’ve dealt with this = problems?

Bullet 2 (of Figure 2 description)
What is meant by "local domain"? I usually consider my = "local domain" to be the domain of my home router, or the domain of my ISP = (if my router has no domain). But SIP registration uses a SIP domain, which I = don't see as overly "local", since the registration server could be = 1000 miles away, or more. Could this maybe be worded something like  "...for Alice's UA to register with. Most SIP UAs will register with a server, so it = will be a common scenario for UAs that make emergency calls to be registered with = a server."

<br> fixed

Bullet 3 [editorial]: change "initiated" to "initiates" =

<br>I reworded text here, and “initiated is = gone

Paragraph after the bullets
"...UA ... has location configured within her UA when her UA boots..." Is this meant to describe the case where the UA gets = location configuration as part of its boot process, such as DHCP or L7 CP? Or = does it imply a statically stored location which the UA finds and uses during = its boot process? This wasn't clear to me. In general, I think there are 3 basic = ways the UA could be configured: (1) a saved manually entered location, (2) = location manually entered after it boots, (3) receives a location from the = network. The location from the network could be a measured location, or it could be = based on knowing the physical locations of network termination points. This = sentence doesn't convey that to me.

<br>the text has been edited heavily.  Is it more clear = now?

Next paragraph, that starts with "Some time..."
[Editorial]: change "initiated" to "initiates" =

<br>fixed

Section 6.3
2nd paragraph: "XRef" should probably be [phonebcp]? If it is, = then the 3rd to last sentence and the last sentence would be redundant. Note = that these guidelines for dealing with multiple locations are not in phonebcp = at this time. I'll make this comment against = phonebcp.

<br> -pidf-lo-profile discusses the various ways you get multiple location = things and what they should be used for.  Conveyance adds yet another = dimension to that.  –phonebcp needs text to advise.  I fixed the reference here to –pidf-lo-profile, and added = “additional” to “guidance”.

3rd paragraph
[editorial] end of the paragraph "...and ask the caller with." doesn't make sense.

<br>fixed

Section 5.4
[editorial] 2 instances where "can" needs to be "can = be"

<br> fixed

Section 5.8
I recommend changing "...to ensure that phone billing records = correspond to valid..." to
"...to ensure that the service addresses in phone billing records correspond to valid..."

Section 5.9
What is CMTS?
Naturally, "(how?)" needs to be resolved. =

<br>defined as Cable Modem Termination system.  We need a discussion on how to = mark default locations.

Section 6
Paragraph at the end of page 20.
I had questions here as to whether this VSP proxy would be an ESRP, = based on the ecrit requirements definition and the usage of that term in this = document. I'm hoping it would not be an ESRP.

<br>It’s not, and the adjusted text above should make that = clear

Section 7
I'm not sure how practical persistent TLS connection are for large VSPs, = given that they may have to connect to thousands of = PSAPs.

<br>I don’t think that is a problem.  In practical terms in the = U.S. = the VSP will connect to 50 state level ESRPs, which will be next hop for = them.

Section 9
Recommend several references to phonebcp in this section, since phonebcp specifically discusses where these IDs are placed in the SIP = message.

<br>done

Section 11
I would slightly expand this section to also mention the disabling of = calling features. For example, change the header and add a sentence like = "The disabling of other call features, such as call waiting, is also = discussed in phonebcp.

<br>done

Barbara Stark
BellSouth Science & Technology (a recently acquired part of = AT&T)

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. GA624

 ------=_NextPart_000_0002_01C75E95.6B434FE0-- --===============0091560300== 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 --===============0091560300==-- From ecrit-bounces@ietf.org Sun Mar 04 21:37: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 1HO34l-0005GX-U1; Sun, 04 Mar 2007 21:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO34k-0005GK-M5 for ecrit@ietf.org; Sun, 04 Mar 2007 21:37:22 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO34j-0000oC-9q for ecrit@ietf.org; Sun, 04 Mar 2007 21:37:22 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HO34T-0002uV-3g; Sun, 04 Mar 2007 20:37:05 -0600 From: "Brian Rosen" To: =?iso-8859-1?Q?'Gunnar_Hellstr=F6m'?= , "'Ecrit@Ietf. Org'" Subject: RE: [Ecrit] Modification proposals for media support indraft-ietf-ecrit-phonebcp Date: Sun, 4 Mar 2007 21:37:17 -0500 Message-ID: <007a01c75ecf$327ea3f0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45D47D3D00463E2A@pne-smtpout2-sn1.fre.skanova.net> (added bypostmaster@pne.skanova.net) Thread-Index: AcdepHDwfykCbDblRxqkM0SFuT1q6QAKpFCw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 -phonebcp-01 will be released before the deadline. I have made all of = these changes, although I created a new "media" section where some of the suggested text has been placed. When the draft is announced, please = have a look and see if these changes meet your approval. Brian > -----Original Message----- > From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se] > Sent: Sunday, March 04, 2007 4:32 PM > To: Ecrit@Ietf. Org > Subject: [Ecrit] Modification proposals for media support = indraft-ietf- > ecrit-phonebcp >=20 > I want to propose a few small modifications to > draft-ietf-ecrit-phonebcp-00.txt >=20 >=20 > 1. Editorial and explanation. > ---------------------------------- > The last lines in section 2 reads: >=20 > =93o The proxy recognizes the call as an emergency call and routes = the > call using normal SIP routing mechanisms > [RFC4504] details Best Current Practice for SIP user agents. This > memo can be considered an addition to it for endpoints.=94 >=20 > A full stop is missing after mechanisms, and it is unusual to start a > sentence with a reference. I also suggest to include a hint on what is > found > in RFC 4504 >=20 > I suggest a slight change to: >=20 > " o The proxy recognizes the call as an emergency call, routes the > call using normal SIP routing mechanisms. >=20 > Best Current Practice for SIP user agents including handling of audio = and > real-time text [RFC 4103] media detailed in [RFC4504] SHOULD be = applied. > This memo can be considered an addition to it for endpoints." >=20 > 2. Add a bullet point in the list in section 2. > ------------------------------------------------ > I also suggest that the sequence of steps should end with media > establishment rather than just routing >=20 > Insert as a new bullet point last in the list in section 2: >=20 > o The call is established and common media streams opened. >=20 >=20 > 3. More real-time text improvements > --------------------------------------- > Section 3 starts: > " Although present PSAPs have only support for voice calls" >=20 > That is not true. A reasonable part of the population has also support = for > real-time text calls. So, the support for real-time text expected from = IP > is > to maintain and extend support rather than fulfilling new = expectations. >=20 > I suggest rewording to: >=20 > " Support for voice calls and real-time text calls placed > through PSTN facilities or systems connected to the PSTN is found in > present > PSAPs. Future PSAPs will however support Internet connectivity and a = wider > range of media types and provide higher functionality." >=20 > 4. Handle unused references. > ---------------------------- > In the current version, I have observed two unused references. > [RFC 4103] and [draft-ietf-sipping-toip], both related to the = real-time > text > medium. >=20 > Revival of reference [rfc 4103] is proposed in 3) above. >=20 > In order to revive the use of [sipping-toip], I suggest adding this = line > between the two paragraphs of section 3: >=20 > "The expectations for emergency service support for the real-time text > medium, described in [draft-ietf-sipping-toip], section 7.1 SHOULD be > fulfilled." >=20 > ( draft-ietf-sipping-toip-07 is in publication requested state ) >=20 >=20 >=20 > With these small changes I think the phonebcp draft will be a good > guidance > for design of user terminals. >=20 >=20 >=20 > Thanks >=20 > Gunnar >=20 > ------------------------------------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se >=20 >=20 >=20 > _______________________________________________ > 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 Mar 04 22:53: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 1HO4Fu-0007La-Q1; Sun, 04 Mar 2007 22:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO4Ft-0007KK-O3 for ecrit@ietf.org; Sun, 04 Mar 2007 22:52:57 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO4Fr-0005Ot-4I for ecrit@ietf.org; Sun, 04 Mar 2007 22:52:57 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HO4Fo-0007KP-9n; Sun, 04 Mar 2007 21:52:53 -0600 From: "Brian Rosen" To: , "'ECRIT list'" Subject: RE: Comments on Phone BCP (Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt) Date: Sun, 4 Mar 2007 22:52:49 -0500 Message-ID: <009701c75ed9$c0340fa0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acb4msDN9J981PLVT4KcTNlvHjieNBmPSk7g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 24a7cf5a8ecd726b219a9ca617c8090e 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: , Content-Type: multipart/mixed; boundary="===============0894941890==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0894941890== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01C75EAF.D75E07A0" This is a multi-part message in MIME format. ------=_NextPart_000_0098_01C75EAF.D75E07A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I did most of these. Look at the new text and see whether we need more "applicability" stuff in the LCP section I took a half hearted attempt to rework the text on relayed location. Maybe it's okay, but I'm expecting you still won't like it. I'm not sure what we have agreed to for learning home dialstring. It's not DHCP (that is visited). It's some form of configuration. I think we have been moving down the line that if you have a mobile client, you can do a point in polygon to figure out if you moved beyond the provided service boundary. We will offer advise that this boundary should be simple (by using approximations when not near an edge, and using a small edge section when near an edge) I don't want to have another parameter for a declared dead call. 5 min is a pretty long SWAG. Got another suggestion? Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Wednesday, October 25, 2006 9:05 PM To: ECRIT list Cc: Brian Rosen; James Polk Subject: Comments on Phone BCP (Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt) Hi all, I've given the new Phone BCP rev a good read, and have a bunch of comments / questions. None negative, just looking to further improve the spec. I have also collected a pile of editorial type nits that I don't want to torture the whole list with, but would be happy to compile and fwd to the authors if they like (Brian, James just let me know). First though, I'm really glad to see LLDP-MED specifically a MUST location method. I certainly believe this is a very good thing, especially in managed enterprise environments. Also think it has a lot of future extension potential. Comments: o Pg 3, Introduction. The "Phone BCP" also covers aspects of network infrastructure and the overall Emergency Call Service itself, as required to support the end device. I think this needs to be more carefully stated in the Intro material, to scope the spec. If the scope cannot be easily limited, then it might be better to either break up into multiple specs (one for end device, one for access network, one for proxy ...), or intentionally pile in all requirements on all elements in the path. Personally, I hope not to need to go to either option; think the content is well targeted, however it is real important to get the right implementation people to take it seriously. A specific Scope section might help. I could try some words if you like. o Pg 3, under "As a quick overview...", 2nd bullet point, also add LLDP-MED. (DHCP and L7 mentioned only) o Sec 4 general. This reads as one big mouthful, and as such makes it hard to follow and determine what applies to what. Suggest some subsectioning would be a very helpful (albeit editorial) change. Suggest: Location Determination Methods, Location Determination Timeliness, Mapping of Location Information. o Sec 4, pg 5, 1st paragraph "Such a method MUST be specified, and every device MUST support it.", I think it would be good to strengthen this, by adding words to the effect of: "It is RECOMMENDED that at least one of the location methods specified here be used, in order to promote improved interoperability." o Sec 4, pg 5, 2nd paragraph, I think it would be helpful to tighten words: "For all other devices, the device MUST support all of: DHCP [ref], L7 [ref], and LLDP-MED [ref]." Also break off part of this paragraph about DHCP to separate paragraph (see next). o Sec 4, pg 5, after above, I think all 3 methods should have some statement of applicability and their general nature. Notably, paragraph on LLDP-MED should not characterize it as "an alternative to DHCP" -- it is not really, though it shares common data format for Civic and Geo LCI. I can try some words if others agree that applicability would be a good thing. o Sec 4, pg 5, 5th paragraph, "For devices that operate in ...". This one is unclear to me. (Thought I got it on first read ... now not so sure.) I *think* it is intended to be about deployments such as ethernet or wireless boxes behind (say) cable / DSL modem, for example residential or small office / home office. (?!?!?) I think this needs to be clarified, and state more clearly which end is receiving location from the network operator, how, and how it is relayed to the actual endpoint through one of the 3 mechanisms. o Sec 4, pg 5, 7th paragraph. Is "Self Reported" meant to mean end-user configured, or something else? It is capitalized as a Formal Term, yet not defined. Needs to be clarified. (actually, a Definitions section might help overall.) o Sec 5, pg 7, 8th paragraph, "Systems that support roaming ...". I think it would be helpful to point out "guest use" of the end device as another important scenario (eg. Alice, visiting Germany; Dieter has an issue and grabs Alice's phone, dials ... what exactly). This is orthogonal to visited network vs home, but has many of the same requirements in terms of knowing the local emergency dial string. o Sec 5, pg 8, 2nd paragraph. This does not mention the proposed DHCP method for supplying local dialstring. I seem to have lost (or is that LoST ;-) track of where this went, if anywhere. What's the state of the proposal to supply dialstring by DHCP? If it is alive, it would be worth mention here. o Sec 6.2, pg 9, item 13, re compressed codecs. Also seem to have lost track on this one. Personally, I believe compressed codecs should be in the SDP list, but as last choice. SHOULD NOT seems too strong, would personally prefer "MUST be lowest priority". At any rate, it should say non-compressed audio codec MUST be supplied, and should name one (likely G.711). Yeah, this is probably still contentious... o Sec 6.2, pg 9, paragraph after item 13, re silence suppression. I think this deserves to be a numbered item, not merely a note. Silence sup non-use is the right thing (ie MUST NOT), normative, so not a side-note. o Sec 6.2, pg 10, 1st paragraph, " ... mapping is performed whenever the UA acquires new location information that is outside the bounds of the current PSAP coverage region ...". Perhaps I'm missing something obvious here, but, HOW can the UA determine this? I would be VERY resistant to burden the end device (which must be simple and very cost-sensitive) with complex and possibly open-ended calculations to figure out PSAP bounds. I think the trigger to get new LoST PSAP URI info should be much simpler, either time based, or at every time the underlying location data changes. o Sec 6.4, pg 11, 4th paragraph, " ... 5 minutes elapses ... call may be declared dead ...". Hmmmm.... Is the 5 minutes an arbitrary SWAG (Scientific Wild-Ass Guess)? Would this requirement potentially differ depending on jurisdiction? Agree there needs to be some time limit, but this just seems arbitrary. o References, both LLDP and LLDP-MED needs corrections: [LLDP] IEEE 802.1AB-2005, Station and Media Access Control Connectivity Discovery (aka Link Layer Discovery Protocol - LLDP), May 2005. <-- Note date, capitalization "AB" and (tm) ... IEEE folks are fussy about these things. [LLDP-MED] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices (aka LLDP-MED), Apr 2006. ---- Hope that helps. Peter Blatherwick . Internet-Drafts@ietf.org 18.10.06 15:50 To: i-d-announce@ietf.org cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt 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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-00.txt Pages : 16 Date : 2006-10-18 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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. ftp://anonymous@ftp.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.tx t_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0098_01C75EAF.D75E07A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I did most of = these.

 

Look at the new text and see = whether we need more “applicability” stuff in the LCP = section

 

I took a half hearted attempt to = rework the text on relayed location.  Maybe it’s okay, but I’m expecting you still won’t like it.

 

I’m not sure what we have = agreed to for learning home dialstring.  It’s not DHCP (that is visited).  It’s some form of = configuration.

 

I think we have been moving down = the line that if you have a mobile client, you can do a point in polygon to = figure out if you moved beyond the provided service boundary.  We will offer = advise that this boundary should be simple (by using approximations when not = near an edge, and using a small edge section when near an = edge)

 

I don’t want to have another parameter for a declared dead call.  5 min is a pretty long = SWAG.  Got another suggestion?

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, October = 25, 2006 9:05 PM
To: ECRIT list
Cc: Brian Rosen; James = Polk
Subject: Comments on = Phone BCP (Re: [Ecrit] I-D = ACTION:draft-ietf-ecrit-phonebcp-00.txt)

 


Hi all,

I've given the new Phone BCP rev a good read, and have a bunch of comments / questions.  None negative, just looking to further improve the = spec.  I have also collected a pile of editorial type nits that I don't want to = torture the whole list with, but would be happy to compile and fwd to the = authors if they like (Brian, James just let me know).  

First though, I'm really glad to see LLDP-MED specifically a MUST location = method.  I certainly believe this is a very good thing, especially in managed = enterprise environments.  Also think it has a lot of future extension = potential.  

Comments:

o Pg 3, Introduction.  The "Phone BCP" also covers aspects = of network infrastructure and the overall Emergency Call Service itself, as required to support the end device.  I think this needs to be more carefully stated in the Intro material, to scope the spec.  If the = scope cannot be easily limited, then it might be better to either break up = into multiple specs (one for end device, one for access network, one for = proxy ...), or intentionally pile in all requirements on all elements in the path. =  Personally, I hope not to need to go to either option; think the content is well = targeted, however it is real important to get the right implementation people to = take it seriously.  A specific Scope section might help.  I could try = some words if you like.  

o Pg 3, under "As a quick overview...", 2nd bullet point, also = add  LLDP-MED.  (DHCP and L7 mentioned only)

o Sec 4 general.  This reads as one big mouthful, and as such makes = it hard to follow and determine what applies to what.  Suggest some = subsectioning would be a very helpful (albeit editorial) change. Suggest: Location Determination Methods, Location Determination Timeliness, Mapping of = Location Information.  

o Sec 4, pg 5, 1st paragraph "Such a method MUST be specified, and = every device MUST support it.", I think it would be good to strengthen = this, by adding words to the effect of: "It is RECOMMENDED that at least one = of the location methods specified here be used, in order to promote improved interoperability."

o Sec 4, pg 5, 2nd paragraph, I think it would be helpful to tighten = words: "For all other devices, the device MUST support all of: DHCP [ref], = L7 [ref], and LLDP-MED [ref]."  Also break off part of this = paragraph about DHCP to separate paragraph (see next).

o Sec 4, pg 5, after above, I think all 3 methods should have some = statement of applicability and their general nature.  Notably, paragraph on = LLDP-MED should not characterize it as "an alternative to DHCP" -- =  it is not really, though it shares common data format for Civic and Geo LCI. =  I can try some words if others agree that applicability would be a good = thing.    

o Sec 4, pg 5, 5th paragraph, "For devices that operate in ...". =  This one is unclear to me.  (Thought I got it on first read ... now not = so sure.)   I *think* it is intended to be about deployments such as = ethernet or wireless boxes behind (say) cable / DSL modem, for example = residential or small office / home office.  (?!?!?)  I think this needs to be clarified, and state more clearly which end is receiving location from = the network operator, how, and how it is relayed to the actual endpoint = through one of the 3 mechanisms.  

o Sec 4, pg 5, 7th paragraph.  Is "Self Reported" meant to = mean end-user configured, or something else?  It is capitalized as a = Formal Term, yet not defined.  Needs to be clarified.  (actually, a Definitions section might help overall.)

o Sec 5, pg 7, 8th paragraph, "Systems that support roaming = ...".  I think it would be helpful to point out "guest use" of the end = device as another important scenario (eg. Alice, visiting Germany; = Dieter has an issue and grabs Alice's phone, dials ... what exactly).  This is orthogonal to visited = network vs home, but  has many of the same requirements in terms of knowing = the local emergency dial string.  

o Sec 5, pg 8, 2nd paragraph.  This does not mention the proposed = DHCP method for supplying local dialstring.  I seem to have lost (or is = that LoST ;-) track of where this went, if anywhere.  What's the state = of the proposal to supply dialstring by DHCP?  If it is alive, it would be = worth mention here.  

o Sec 6.2, pg 9, item 13, re compressed codecs.  Also seem to have = lost track on this one.  Personally, I believe compressed codecs should = be in the SDP list, but as last choice.  SHOULD NOT seems too strong, = would personally prefer "MUST be lowest priority".  At any = rate, it should say non-compressed audio codec MUST be supplied, and should name = one (likely G.711).  Yeah, this is probably still contentious... =

o Sec 6.2, pg 9, paragraph after item 13, re silence suppression.  I = think this deserves to be a numbered item, not merely a note.  Silence = sup non-use is the right thing (ie MUST NOT), normative, so not a side-note. =  
o Sec 6.2, pg 10, 1st paragraph, " ... mapping is performed whenever = the UA acquires new location information that is outside the bounds of the = current PSAP coverage region ...".  Perhaps I'm missing something = obvious here, but, HOW can the UA determine this?  I would be VERY = resistant to burden the end device (which must be simple and very cost-sensitive) = with complex and possibly open-ended calculations to figure out PSAP bounds. =  I think the trigger to get new LoST PSAP URI info should be much simpler, = either time based, or at every time the underlying location data changes. =  

o Sec 6.4, pg 11, 4th paragraph, " ... 5 minutes elapses ... call may = be declared dead ...".   Hmmmm....   Is the 5 minutes an = arbitrary SWAG (Scientific Wild-Ass Guess)?  Would this requirement = potentially differ depending on jurisdiction?  Agree there needs to be some = time limit, but this just seems arbitrary.  

o References, both LLDP and LLDP-MED needs corrections: =  
[LLDP] IEEE = 802.1AB-2005, Station and Media Access Control Connectivity Discovery (aka Link Layer Discovery Protocol - LLDP), May 2005.   <-- Note date, capitalization "AB" and (tm) ... IEEE folks are = fussy about these things.  
[LLDP-MED] ANSI/TIA-1057, Link Layer Discovery Protocol for Media Endpoint Devices  (aka = LLDP-MED), Apr 2006.  

----

Hope that helps.  

Peter Blatherwick


.  

 

Internet-Drafts@ietf.org

18.10.06 15:50

       
        To:       =  i-d-announce@ietf.org
        cc:       =  ecrit@ietf.org
        Subject:        [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-00.txt




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   =                       =          : Best Current Practice for Communications = Services in support of Emergency Calling
                Author(s)   =               : B. Rosen, J. Polk
                Filename   =               : = draft-ietf-ecrit-phonebcp-00.txt
                Pages   =                       =          : 16
                Date   =                       =          : 2006-10-18
               

  Requesting help in an emergency using a communications device = such as
  a telephone or mobile is an accepted practice in most of the = world.
  As communications devices increasingly utilize the Internet = to
  interconnect and communicate, users will continue to expect to = use
  such devices to request help, regardless of whether or not = they
  communicate using IP.  The emergency response community will = have to
  upgrade their facilities to support the wider range of = communications
  services, but cannot be expected to handle wide variation in = device
  and service capability.  The IETF has several efforts = targeted at
  standardizing various aspects of placing emergency calls. =  This memo
  describes best current practice on how devices and services = should
  use such standards to reliably make emergency calls


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.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-phonebcp-00.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-phonebcp-00.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.
ftp://anonymous@ftp.ietf.org/internet-drafts/draf= t-ietf-ecrit-phonebcp-00.txt_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------=_NextPart_000_0098_01C75EAF.D75E07A0-- --===============0894941890== 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 --===============0894941890==-- From ecrit-bounces@ietf.org Mon Mar 05 08:16: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 1HOD2j-0006kr-Uo; Mon, 05 Mar 2007 08:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOD2i-0006kZ-5o for ecrit@ietf.org; Mon, 05 Mar 2007 08:15:56 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOD2g-0004YN-VJ for ecrit@ietf.org; Mon, 05 Mar 2007 08:15:56 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HOD2Z-00033c-VJ for ecrit@ietf.org; Mon, 05 Mar 2007 07:15:48 -0600 From: "Brian Rosen" To: "'ECRIT list'" Date: Mon, 5 Mar 2007 08:15:51 -0500 Message-ID: <014701c75f28$6781d140$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 Thread-Index: AcdfKGWfnoiHTWR9T/mlt+5KgyMIHA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] draft-ietf-ecrit-framework-01 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 submitted an update to -framework. Until it appears in the archives, you can obtain a copy at: http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-framework-01.txt http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-framework-01.html http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-framework-01.xml _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 05 08:20: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 1HOD6e-0008DN-1C; Mon, 05 Mar 2007 08:20:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOD6c-0008Cw-3j for ecrit@ietf.org; Mon, 05 Mar 2007 08:19:58 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOD6Y-0005CE-Sf for ecrit@ietf.org; Mon, 05 Mar 2007 08:19:58 -0500 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id CAC7D2ACB2 for ; Mon, 5 Mar 2007 13:19:24 +0000 (GMT) Received: from stntexch12.cis.neustar.com ([10.31.13.31]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 08:19:24 -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: Mon, 5 Mar 2007 08:19:23 -0500 Message-ID: <886DD03D15173C43BCE98EA662A0101A015FB02F@stntexch12.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ecrit-phonebcp Thread-Index: AcdfKOQ8zEkF7ZN6QWmRfZzprWNRQA== From: "Rosen, Brian" To: "ECRIT list" X-OriginalArrivalTime: 05 Mar 2007 13:19:24.0662 (UTC) FILETIME=[E4E0D960:01C75F28] X-Spam-Score: -2.8 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ecrit] draft-ietf-ecrit-phonebcp 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 submitted an update to -phonebcp. Until it appears in the archives, you can obtain a copy at: http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-phonebcp -01.txt http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-phonebcp -01.html http://www.brianrosen.net/internet-drafts/draft-ietf-ecrit-phonebcp -01.xml We have resolved comments received. We added text covering parameters on the Geolocation header. We added text explicitly covering text applicable to proxy servers and B2BUAs. Additional security considerations text was added. Additional references to required behavior were added.=20 Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 05 15:52: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 1HOKAJ-000310-Ff; Mon, 05 Mar 2007 15:52:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9I-0001X6-4D; Mon, 05 Mar 2007 15:51:12 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOK8s-0000Qd-82; Mon, 05 Mar 2007 15:51:12 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 7C61826ECA; Mon, 5 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8B-0005fh-6U; Mon, 05 Mar 2007 15:50:03 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 05 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-13.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 : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-13.txt Pages : 32 Date : 2007-3-5 This document defines terminology and enumerates requirements for the context resolution of emergency calls placed by the public using voice-over-IP (VoIP) and general Internet multimedia systems, where Internet protocols are used end-to-end. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-13.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-requirements-13.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-requirements-13.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-3-5123919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5123919.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 Mar 06 15:52: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 1HOgdk-0007j7-L9; Tue, 06 Mar 2007 15:52:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOgcD-00043G-9J; Tue, 06 Mar 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HOgcC-0000X1-Sx; Tue, 06 Mar 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AA9DD17813; Tue, 6 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOgbi-00064d-E2; Tue, 06 Mar 2007 15:50:02 -0500 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, 06 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-service-urn-06.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 Uniform Resource Name (URN) for Services Author(s) : H. Schulzrinne Filename : draft-ietf-ecrit-service-urn-06.txt Pages : 15 Date : 2007-3-6 The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows to identify context-dependent services that can be resolved in a distributed manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-06.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-service-urn-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-service-urn-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-6120200.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-service-urn-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-service-urn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-6120200.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 Mar 07 10:14: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 1HOxqX-00075W-Lz; Wed, 07 Mar 2007 10:14:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOxqV-000757-PZ for ecrit@ietf.org; Wed, 07 Mar 2007 10:14:27 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOxqV-0008Am-3F for ecrit@ietf.org; Wed, 07 Mar 2007 10:14:27 -0500 Received: (qmail invoked by alias); 07 Mar 2007 15:14:25 -0000 Received: from p54986A0E.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.106.14] by mail.gmx.net (mp017) with SMTP; 07 Mar 2007 16:14:25 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+wNrkspIWw4keUR6AIjm5LUBqV8piTBxLVc38hUc 70joW+wQJAaTOQ Message-ID: <45EED6DB.8030003@gmx.net> Date: Wed, 07 Mar 2007 17:14:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Roger Marshall Subject: Re: [Ecrit] draft-ietf-ecrit-requirements-13 as a result of AD comments References: <8C837214C95C864C9F34F3635C2A657506E9FC19@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A657506E9FC19@SEA-EXCHVS-2.telecomsys.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: c0aa019322dfce838bd8604f5a841b57 Cc: Marc Linsner , 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 Let me also add that the changes were made based on a review by Jon. Thanks Jon for the review comments and for the quick interaction to resolve them. Ciao Hannes Roger Marshall wrote: > I've updated the requirements draft, which has been submitted, and will > get posted as draft-ietf-ecrit-requirements-13 soon. > > RE: Change log to document changes from: > draft-ietf-ecrit-requirements-12 to upcoming version -13. > Date: 3/02/07 > By: R. Marshall > > > C1. Delete following requirement Ma18, since it is not clear how it is > different than Ma15. > > Ma18. Alternate mapping sources: The mapping protocol MUST implement a > mechanism that allows for the retrieval of mapping information from > different sources. > > Motivation: This provides the possibility of having available > alternative sources of mapping information when the normal source is > unavailable or unreachable. > > > C2. Renumber Ma19 to Ma18 per above. > > > C3. Change last paragraph to section 1, based on Jon's comment: > I expected the last paragraph in Section 1 to have an additional > >>> sentence saying something to the effect that the latter use >>> (displaying location information at the PSAP) is orthogonal to the >>> mapping protocol problem and the scope of this document. >>> > > Change from: > > Location is required for two separate purposes, first, to support the > routing of the emergency call to the appropriate PSAP and second, to > display the caller's location to the call taker to help in dispatching > emergency assistance to the appropriate location. > > Change to: (appended paragraph) > > Location is required for two separate purposes, first, to support the > routing of the emergency call to the appropriate PSAP and second, to > display the caller's location to the call taker to help in dispatching > emergency assistance to the appropriate location. > > This latter use, the display of location information to the PSAP, is > orthogonal to the mapping protocol, and is outside the scope of this > document. > > > C4. Change term "Internet Attachment Provider", based on comment below: > > >>> 3.2 - The term "Internet Attachment Provider" is not a common one, >>> and doesn't seem to be distinguished from the more common concept of >>> an access network. I would suggest that "access network" at least be >>> provided as a synonym in the definition. >>> >> My suggestion would be to switch to "Internet Access Provider", as >> that seems closer to common usage. Plus, 'attachment' is probably not >> a good fit for, say, 'unattached' network connections, such as >> > wireless.. > > Change from: "Internet Attachment Provider" to: "Internet Access > Provider" > (throughout, including diagram). > > > C5. Change definition of ESRP from a B2BUA, to something more general, > per the folowing AD review comment. > > >>> 3.4 - I'm not sure what the need is to suggest that the ESRP function >>> > > >>> might be performed by a B2BUA. At a high level, I suppose I see the >>> mapping client function as one that could be performed by a number of >>> > > >>> entities, including entities that instantiate the SIP proxy role and >>> the SIP user agent client role. I think language to that effect would >>> > > >>> be preferable to suggesting that there is some motivation for pairing >>> > > >>> the mapping client function with a B2BUA. >>> > > Change from: > > Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call > routing support entity that invokes the location-to-PSAP URI > mapping, to return either the URI for the appropriate PSAP, or the > URI for another ESRP. (In a SIP system, the ESRP would typically > be a SIP proxy, but may also be a back-to-back user agent > (B2BUA)). > > Change to: > > Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call > routing support entity that invokes the location-to-PSAP URI > mapping function, to return an appropriate PSAP URI, or the > URI for another ESRP. Client mapping requests could also be > performed by a number of entities, including entities that > instantiate the SIP proxy role and the SIP user agent client role. > > > C6. Fix broken sentence, (per comment below): > > >>> (Emergency) service URL: The service URL is a protocol-specific >>> (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the address >>> > > >>> of the PSAP or other emergency service. >>> >>> after the im: citation, you probably want the words: "identifier >>> which" >>> >>> > Yes, "identifier which" must be added. > > Change from: > > (Emergency) service URL: The service URL is a protocol-specific > (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the > address of the PSAP or other emergency service. It depends on the > specific signaling or data transport protocol used to reach the > emergency service. > > Change to: > > (Emergency) service URL: The service URL is a protocol-specific > (e.g., SIP) or protocol-agnostic (e.g., im: [5]) identifier which > contains the > address of the PSAP or other emergency service. It depends on the > specific signaling or data transport protocol used to reach the > emergency service. > > > C7. Change Lo5 Heading (per comment below): > > >>> In Section 6, why is Lo5 called "Validation resolution"? The >>> description of the requirement doesn't seem to relate to validation >>> or resolution, as far as I can tell. "Additional Information" or >>> something might be a better name for this requirement. >>> >> I agree that the heading is not helpful. I'd suggest calling it >> >> Information about location data used for mapping >> >> >> > I agree that changing the heading would help to make it clearer. > > Change Lo5 heading from: "Validation resolution" > > Change Lo5 heading to: "Information about location data used for > mapping" > > > C8. > > >>> In Section 8, Ma11 uses the seemingly innocuous name "URI properties" >>> to provide requirements that seem to contradict Ma8. If the mapping >>> protocol is going to return multiple PSAP URIs as described in Ma11, >>> there should be a story stronger than "local policy" to meet the >>> requirement of Ma8. You might want to find a better name for Ma11 >>> than "URI properties", too. >>> > > [RM comment - Whereas Ma8 is a SHOULD, i.e., that it is optimal for only > one URI be returned, yet it allows for cases where more than one may be > returned, Ma11 is a MUST, i.e., must be able to return extra info to > help pick one URI over the other - in the case where there are multiple > URIs returned. I see no contradiction between the two reqs.] > > No change made to either Ma8 or Ma11. > > > C9. Change to Ma15 Heading, change from, "Resilience to failure" to, > "Resilience to mapping server failure" (per the comments below). > > [above comment con't] > >>> Also in 8, how is Ma15 different from Ma18? >>> >> I'm not sure I'm interpreting your question correctly, but Ma15 talks >> about reliability of the mapping protocol, while Ma8 talks about >> returning mappings to achieve reliability. To make this clearer, the >> title in Ma15 should be changed to >> >> Resilience to mapping server failure >> >> > I also believe that the problem would be fixed by changing the heading > of Ma15 to "Resilience to mapping server failure". > > > C10. Delete requirement Ma9 (per Henning's/Hannes' comments below): > > >> By the way, we've decided to not do Ma9, based on additional >> discussion, so I'd suggest dropping it. Not that anybody is going to >> do a point-by-point comparison of LoST to the requirements document... >> >> > I would also suggest to delete Ma9. > > Requirement Ma9 deleted. > Requirements Ma10-Ma18 now renamed to Ma9-Ma17. > > /end. > > Roger Marshall > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Friday, March 02, 2007 6:12 AM >> To: Peterson, Jon >> Cc: Henning Schulzrinne; hgs+ecrit@cs.columbia.edu; Roger Marshall; >> Marc Linsner >> Subject: Re: AD review of draft-ietf-ecrit-requirements-12.txt >> >> Hi Jon, >> >> Ma15 vs. Ma18: Let's delete Ma18. I cannot figure out what the >> difference is to Ma15. >> >> Ciao >> Hannes >> >> >> Peterson, Jon wrote: >> >>>>>> Also in 8, how is Ma15 different from Ma18? >>>>>> >>>>>> >>>>> I'm not sure I'm interpreting your question correctly, but >>>>> >>>>> >>>> Ma15 talks >>>> >>>> >>>>> about reliability of the mapping protocol, while Ma8 talks about >>>>> returning mappings to achieve reliability. To make this >>>>> >>>>> >>>> clearer, the >>>> >>>> >>>>> title in Ma15 should be changed to >>>>> >>>>> Resilience to mapping server failure >>>>> >>>>> >>>>> >>>> I also believe that the problem would be fixed by changing the >>>> heading of Ma15 to "Resilience to mapping server failure". >>>> >>>> Ma8 is fine as it is and fits perfectly what we did in the protocol >>>> design. >>>> >>>> >>> For the record, I was asking how Ma15 is different from >>> >> -Ma18-, not -Ma8-. >> >>> - J >>> >>> >> > > > 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 Wed Mar 07 17:45: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 1HP4t4-0001l0-0z; Wed, 07 Mar 2007 17:45:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36F-0002VR-PH; Wed, 07 Mar 2007 15:51:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HP36F-0007Pn-7L; Wed, 07 Mar 2007 15:51:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id BFACB177FC; Wed, 7 Mar 2007 20:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HP35H-000327-Gv; Wed, 07 Mar 2007 15:50:03 -0500 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, 07 Mar 2007 15:50:03 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-lost-05.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 : LoST: A Location-to-Service Translation Protocol Author(s) : T. Hardie, et al. Filename : draft-ietf-ecrit-lost-05.txt Pages : 71 Date : 2007-3-7 This document describes an XML-based protocol for mapping service identifiers and geodetic or civic location information to service contact URIs. In particular, it can be used to determine the location-appropriate PSAP for emergency services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-05.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-lost-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-lost-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-3-7142203.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-lost-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-lost-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-7142203.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 Thu Mar 08 10:50: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 1HPKsY-0007n9-9I; Thu, 08 Mar 2007 10:50:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPKsU-0007iO-RU; Thu, 08 Mar 2007 10:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPKsU-0000WU-En; Thu, 08 Mar 2007 10:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 49D5926F19; Thu, 8 Mar 2007 15:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPKsU-0004CD-0d; Thu, 08 Mar 2007 10:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 10:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-framework-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 --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 in Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-01.txt Pages : 32 Date : 2007-3-8 Summoning emergency help by the public is a core feature of telephone networks. This document describes a framework of 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. This document explains how location mapping, call identification and end system behavior are combined to allow multimedia emergency calls. 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-01.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-01.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-01.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-3-8093808.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-framework-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8093808.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 Fri Mar 09 04:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPb15-0000Mt-TA; Fri, 09 Mar 2007 04:03:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPPZJ-00079E-In; Thu, 08 Mar 2007 15:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HPPZI-000259-W1; Thu, 08 Mar 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id E03C82ACFA; Thu, 8 Mar 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HPPYo-0007FI-Lc; Thu, 08 Mar 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Mar 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-phonebcp-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 --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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-01.txt Pages : 21 Date : 2007-3-8 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-01.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-phonebcp-01.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-phonebcp-01.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-3-8112037.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-phonebcp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-8112037.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 Fri Mar 09 14:28: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 1HPkkw-00041Y-42; Fri, 09 Mar 2007 14:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPkkv-0003yf-Cq for ecrit@ietf.org; Fri, 09 Mar 2007 14:27:57 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPkkt-0003Gz-E0 for ecrit@ietf.org; Fri, 09 Mar 2007 14:27:57 -0500 Received: (qmail invoked by alias); 09 Mar 2007 19:27:53 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp018) with SMTP; 09 Mar 2007 20:27:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/UVHwDLCXUmBlHD4nrsDVIYZCpOuhiHhAP8tUrfd g/RoTX6weoj6oz Message-ID: <45F1B536.80600@gmx.net> Date: Fri, 09 Mar 2007 21:27:50 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] ECRIT Meeting Scheduling 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, here is the current (and hopefully) final status of the ECRIT meeting scheduling: * Official ECRIT WG Meeting THURSDAY, March 22, 2007 1510-1610 Afternoon Session II Congress I * 2nd Part of the SIPPING slot on FRIDAY, Congress II, March 23, 2007, namely 1030-1130, will be used for ECRIT as well * ECRIT / IEEE Information Sharing Workshop Monday, 19th March, 11:30 - 13:00 Room: TBD You need to register for this meeting since we will organize food for you. I will post a separate mail. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 09 17:13: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 1HPnLJ-0005Sv-JY; Fri, 09 Mar 2007 17:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPnLG-0005Ry-N2 for ecrit@ietf.org; Fri, 09 Mar 2007 17:13:38 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPnL8-0000lK-0N for ecrit@ietf.org; Fri, 09 Mar 2007 17:13:38 -0500 Received: (qmail invoked by alias); 09 Mar 2007 22:13:28 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp042) with SMTP; 09 Mar 2007 23:13:28 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+C8F1zh5mCKK31nkzk/E3NvurXPIq8p3OYk93OzY 6joCn44DCgpq72 Message-ID: <45F1DC03.9030609@gmx.net> Date: Sat, 10 Mar 2007 00:13:23 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT , GEOPRIV , sip@ietf.org, es-coordination@cs.columbia.edu, iab@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [Ecrit] SDO Emergency Services Workshop 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, we would like to inform you about the progress of the preparation of the 2nd SDO Emergency Services Workshop hosted by the U.S. Department of Transportation (DOT). The workshop will be held April 10, 11 & 12, 2007, from 8:30 am – 6:00 pm., in the Jefferson Building of the Library of Congress, located at 101 Independence Avenue SE in Washington, D.C. Please find updated information at this webpage: http://www.emergency-services-coordination.info/2007/ Best regards, Jenny Hansen Marc Linsner Stephen McCann Christian Militeau Atle Monrad Henning Schulzrinne Hannes Tschofenig Harry Worstell _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 11 16:23: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 1HQUZQ-0008Nj-2Y; Sun, 11 Mar 2007 16:23:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQUZP-0008Nd-Kh for ecrit@ietf.org; Sun, 11 Mar 2007 16:23:07 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQUZN-0004v7-TP for ecrit@ietf.org; Sun, 11 Mar 2007 16:23:07 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2BKN4Qu029677 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 11 Mar 2007 16:23:05 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Sun, 11 Mar 2007 16:23:01 -0400 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: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ecrit] LoST 05 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 LoST 05 is now in the archives, with the following changes based on ECRIT list discussion: * Added the terms 'Mapping', 'LoST Client and Server', 'Service Boundary', and 'Validation' to the terminology section * Extended the description in Section 3 "Overview of Protocol Usage". * Fixed a bug in the example of Section 4 "LoST servers and Their Resolution" * Removed the 'version' attribute of Section 5.1, from the Relax NG schema and from the examples. * Modified the schema to prevent empty elements. * Updated text in Section 5.5. "Defining the Service Region with the Element", "5.6. Service Boundaries by Reference: the Element", "7.3.4. Service Boundary", and "7.4.2. Civic Address Validation: the Element" * Fixed a bug in the examples with respect to the srsName * Updated Section 12. "Errors, Warnings, and Redirects" * Changed the default value for the recursion attribute from 'true' to 'false". * Added Jonathan's intro paragraph. * Took out the optional for responses. * Added NO-CACHE and NO-EXPIRATION for expires attribute with corresponding text in Section 5.2. * Modified the description in Section 6 "Path of a Request" * Modified the description in Section 7.3.3. "Recursion and Iteration" * Update to location profiles in Section 11.1. "Location Profile Usage" and in Section 11.2. "Two Dimensional Geodetic Profile" There is still a need for a bit of clean-up in the examples, which didn't quite get done in the rush to meet the I-D deadline. We'll also add an error for an invalid/unknown SRS. Otherwise, we believe this to reflect list comments, so it would be particularly useful if those that have provided comments take a look at their main concerns and make sure that these have been addressed. Henning (on behalf of the LoST author team) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 11 17:21: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 1HQVTj-0004hx-40; Sun, 11 Mar 2007 17:21:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQVTh-0004hp-ML for ecrit@ietf.org; Sun, 11 Mar 2007 17:21:17 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQVTZ-0004fq-Ub for ecrit@ietf.org; Sun, 11 Mar 2007 17:21:17 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 11 Mar 2007 14:21:09 -0700 X-IronPort-AV: i="4.14,271,1170662400"; d="scan'208"; a="120021119:sNHT38187846" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2BLL96Z029162 for ; Sun, 11 Mar 2007 14:21:09 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id l2BLL81U008524 for ; Sun, 11 Mar 2007 21:21:09 GMT 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: Cullen Jennings Date: Sun, 11 Mar 2007 14:20:45 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=406; t=1173648069; x=1174512069; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20question=20related=20to=20lost=20GML=20reference |Sender:=20; bh=ljTk/1IO9Waf5aBrT+nOGIRQLX3ZvYicbmpq0RaJLbU=; b=YKG5Czv+a+txIsso9MpbvXuMEQSGk7tFYosYtQyPsguIKY2C/hV8DNTq8w85XJmyz9GNX7Bf 5JtZleouDJqom/RxS1ilWsm21xkO+uIlab3Hl09CLAwSNQu948KVFeNE; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] question related to lost GML reference 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 doc has a normative reference to [13] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)", Candidate OpenGIS Implementation Specification , December 2006. Can anyone give a bit of an update of how that is preceding and at what point we might be expect it to be an OpenGIS specification? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 11 18:35: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 1HQWdC-00078b-RJ; Sun, 11 Mar 2007 18:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWdB-00078V-B7 for ecrit@ietf.org; Sun, 11 Mar 2007 18:35:09 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQWdA-0001IU-1q for ecrit@ietf.org; Sun, 11 Mar 2007 18:35:09 -0400 X-SEF-Processed: 5_0_0_910__2007_03_11_17_41_03 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, 11 Mar 2007 17:41:03 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Mar 2007 17:35:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] question related to lost GML reference Date: Sun, 11 Mar 2007 17:35:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] question related to lost GML reference Thread-Index: AcdkI2yv3tGkPkcpSOOH296lt9fRUgACdobg From: "Thomson, Martin" To: "Cullen Jennings" , "ECRIT" X-OriginalArrivalTime: 11 Mar 2007 22:35:07.0684 (UTC) FILETIME=[8558BE40:01C7642D] 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: , Content-Type: multipart/mixed; boundary="===============0659202452==" Errors-To: ecrit-bounces@ietf.org --===============0659202452== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ3VsbGVuLA0KDQpodHRwOi8vd3d3Lm9wZW5nZW9zcGF0aWFsLm9yZy9zdGFuZGFyZHMvYnAN Cg0KSG93ZXZlciwgd2UgYXJlIHdvcmtpbmcgb24gYSByZXZpc2lvbiB0byB0aGF0IGRvY3VtZW50 LiAgVGhlIHJlZmVyZW5jZSBjYW4gY2hhbmdlIHRvICJCZXN0IFByYWN0aWNlLCAwNi0xNDIiIHRo b3VnaC4NCg0KQ2hlZXJzLA0KTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQ3VsbGVuIEplbm5pbmdzIFttYWlsdG86Zmx1ZmZ5QGNpc2NvLmNvbV0NCj4gU2Vu dDogTW9uZGF5LCAxMiBNYXJjaCAyMDA3IDg6MjEgQU0NCj4gVG86IEVDUklUDQo+IFN1YmplY3Q6 IFtFY3JpdF0gcXVlc3Rpb24gcmVsYXRlZCB0byBsb3N0IEdNTCByZWZlcmVuY2UNCj4gDQo+IA0K PiBUaGlzIGRvYyBoYXMgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvDQo+IA0KPiAgICAgWzEzXSAg UmVlZCwgQy4gYW5kIE0uIFRob21zb24sICJHTUwgMy4xLjEgUElERi1MTyBTaGFwZSBBcHBsaWNh dGlvbg0KPiAgICAgICAgICAgU2NoZW1hIGZvciB1c2UgYnkgdGhlIEludGVybmV0IEVuZ2luZWVy aW5nIFRhc2sgRm9yY2UgKElFVEYpIiwNCj4gICAgICAgICAgIENhbmRpZGF0ZSBPcGVuR0lTIElt cGxlbWVudGF0aW9uIFNwZWNpZmljYXRpb24gLCBEZWNlbWJlcg0KPiAyMDA2Lg0KPiANCj4gQ2Fu IGFueW9uZSBnaXZlIGEgYml0IG9mIGFuIHVwZGF0ZSBvZiBob3cgdGhhdCBpcyBwcmVjZWRpbmcg YW5kIGF0DQo+IHdoYXQgcG9pbnQgd2UgbWlnaHQgYmUgZXhwZWN0IGl0IHRvIGJlIGFuIE9wZW5H SVMgc3BlY2lmaWNhdGlvbj8NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IEVjcml0IG1haWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0K PiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhl IGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBw cm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBo YXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVk aWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YN CnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KW21mMl0NCg== --===============0659202452== 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 --===============0659202452==-- From ecrit-bounces@ietf.org Sun Mar 11 18: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 1HQWoy-0001SV-S8; Sun, 11 Mar 2007 18:47:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQWoy-0001SQ-Hq for ecrit@ietf.org; Sun, 11 Mar 2007 18:47:20 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQWox-0003Rp-8r for ecrit@ietf.org; Sun, 11 Mar 2007 18:47:20 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 11 Mar 2007 15:47:18 -0700 X-IronPort-AV: i="4.14,271,1170662400"; d="scan'208"; a="365043897:sNHT47918444" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l2BMlIFh023663 for ; Sun, 11 Mar 2007 15:47:18 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id l2BMlHdw023116 for ; Sun, 11 Mar 2007 22:47:17 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9A5C6A0D-4A99-4A51-B1B4-81198C56B358@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Cullen Jennings Date: Sun, 11 Mar 2007 15:46:53 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1020; t=1173653238; x=1174517238; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-ietf-ecrit-phonebcp-01 |Sender:=20; bh=jGWIzCN4glw/r/rcuGKhLZfcMyYHvf6K/WQaQ2SXVNg=; b=BAnQtFrxBIaSy+IDZd+U5ClXt4IeyadPF4lSm03JbfXEHXdqe2PEqxGoDOCv+3DCJi096f2N Y/IXcCM9EML9nWGf8ZKr8Gs4StPMi/uKaKIoRmnWxodj6e5Je933Pqpe; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-01 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 Few small comments .. If a phone makes an anonymous call to the police emergency number, is that handled about the same as any other anonymous call? One small thing - I note that it says the UA should insert an 3325 P- Asserted-Identity. I really doubt this would ever be of much use and don't think it should be recommended unless it has value. I do see the value of the service provider putting one in and passing to PSAP but that is different. I think you should require all the PSAP equipment to support multipart. In the support for IM stuff, it's pretty clear to me how SIP pager mode fits in, but it is really unclear to me how a phone doing xmpp would end up connected with the PSAP such that they were speaking to same operator as voice call. I'm sure it could be done but seem like a lot more specification is needed that what is here. I guess the obvious approach would be using SIP to set up an XMPP media session using something like the comedia stuff in SIP. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 12 07:51: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 1HQj3S-0007Tk-AT; Mon, 12 Mar 2007 07:51:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQj3R-0007Td-CN for ecrit@ietf.org; Mon, 12 Mar 2007 07:51:05 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQj3P-0006AF-0I for ecrit@ietf.org; Mon, 12 Mar 2007 07:51:05 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HQj3N-0008AV-IN; Mon, 12 Mar 2007 06:51:01 -0500 From: "Brian Rosen" To: "'Cullen Jennings'" , "'ECRIT'" Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-01 Date: Mon, 12 Mar 2007 07:50:59 -0400 Message-ID: <02e901c7649c$b53f2a80$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 In-Reply-To: <9A5C6A0D-4A99-4A51-B1B4-81198C56B358@cisco.com> Thread-Index: AcdkLzd0W7S6XRXWSfmfn1FwH9D1awAbJmqw 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) 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 See below > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Sunday, March 11, 2007 6:47 PM > To: ECRIT > Subject: [Ecrit] draft-ietf-ecrit-phonebcp-01 > > > Few small comments .. > > If a phone makes an anonymous call to the police emergency number, is > that handled about the same as any other anonymous call? In most jurisdictions, it is a legal requirement for the carrier to provide location and telephone number, so the answer is no. We need some text I think. > > One small thing - I note that it says the UA should insert an 3325 P- > Asserted-Identity. I really doubt this would ever be of much use and > don't think it should be recommended unless it has value. I do see > the value of the service provider putting one in and passing to PSAP > but that is different. Right, it's the carrier that should do this. I'll change the text > > I think you should require all the PSAP equipment to support multipart. Yes, it must > > In the support for IM stuff, it's pretty clear to me how SIP pager > mode fits in, but it is really unclear to me how a phone doing xmpp > would end up connected with the PSAP such that they were speaking to > same operator as voice call. I'm sure it could be done but seem like > a lot more specification is needed that what is here. I guess the > obvious approach would be using SIP to set up an XMPP media session > using something like the comedia stuff in SIP. Yeah, but I don't want to invent something like that. I don't think it's a practical problem, because I think if the "call" is multimedia (more than one media) it will be signaled with SIP, and XMPP would only be used in an IM-only circumstance. I'll clarify the text. If someone comes along and defines SIP establishment of XMPP, and we see some deployment for multimedia calls, then maybe we can revisit. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 12 13:30: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 1HQoLp-00035d-Ql; Mon, 12 Mar 2007 13:30:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQoLo-00035V-Q4 for ecrit@ietf.org; Mon, 12 Mar 2007 13:30:24 -0400 Received: from dnsmx1pya.telcordia.com ([128.96.20.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HQoL5-0006rw-1Z for ecrit@ietf.org; Mon, 12 Mar 2007 13:30:24 -0400 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx1pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l2CHTUi21309; Mon, 12 Mar 2007 13:29:30 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007031213295709837 ; Mon, 12 Mar 2007 13:29:57 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Mar 2007 13:29:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] LoST 05 Date: Mon, 12 Mar 2007 13:29:57 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST 05 Thread-Index: AcdkG1kq4Z0nhGgmSdWkCgyZ6iMb7QAr4Qwg References: From: "Reese, Theresa E" To: "Henning Schulzrinne" , "ECRIT" X-OriginalArrivalTime: 12 Mar 2007 17:29:57.0717 (UTC) FILETIME=[0E2B4050:01C764CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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 LoST Author Team: I want to take this opportunity to thank you for all your hard work on the LoST Internet Draft. I have reviewed lost-05 in detail and find it to be quite complete. I just have a few additional minor comments for your consideration. 1. Editorial comments: =20 Section 3, first paragraph under and Change the first sentence to read: "This message pattern allows for the retrieval of contact URIs based on location information together with a service identifier." Section 3, first paragraph under and Change the first sentence to read: "This message pattern supports a query for a service boundary. The details can be found in Section 8." Section 5.6, last paragraph, last line: remove the extra "the". Section 11.1, item 3, first sentence: Change "profiles of derived" to "profiles if derived". Section 13, second paragraph: Add a period at the end of the sentence. 2. Section 6, third paragraph states, "If a query is answered iteratively, the querier includes all servers." The only "querier" in an iterative example is the original client. The authoritative (responding) server will only identify itself in this scenario, so the element should contain only the corresponding to the responding server. Perhaps this could be clarified in the text. 3. Section 7.3.3, second paragraph states, "In iterative mode, the server contacted returns a redirection response indicating the next server to be queried." Must a redirection response always be provided? Wouldn't that only be necessary if the first server could not respond to the request? 4. Figure 7, Figure 9, Figure 17 Based on Section 5.1, hasn't the "version" attribute been removed from the Data Source information in messages? =20 5. Section 12, first paragraph states, "This document does not define warnings." =20 This sentence seems to conflict with the last sentence in the same paragraph which states, "Unless otherwise noted, all elements below can be either an error or a warning, depending on whether a default response, such as a mapping, is included." What is intent of the statement that says that this document does not define warnings? Is the idea that warnings are not explicitly defined AT THIS TIME (i.e., that they will be addressed in the future), or that warnings should not be used at all. I think warnings could be very useful. The last sentence of Section 12.2 seems to imply the former. (I noticed that there was no pattern provided in the Relax NG Schema in Section 14 for "Warning".) Thank you again for all your hard work and your patience in addressing my comments and those of the others on the ECRIT list. Terry Reese -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Sunday, March 11, 2007 4:23 PM To: ECRIT Subject: [Ecrit] LoST 05 LoST 05 is now in the archives, with the following changes based on =20 ECRIT list discussion: * Added the terms 'Mapping', 'LoST Client and Server', 'Service =20 Boundary', and 'Validation' to the terminology section * Extended the description in Section 3 "Overview of Protocol Usage". * Fixed a bug in the example of Section 4 "LoST servers and Their =20 Resolution" * Removed the 'version' attribute of Section 5.1, from the Relax NG =20 schema and from the examples. * Modified the schema to prevent empty elements. * Updated text in Section 5.5. "Defining the Service Region with the =20 Element", "5.6. Service Boundaries by Reference: the =20 Element", "7.3.4. Service Boundary", and "7.4.2. Civic Address Validation: the Element" * Fixed a bug in the examples with respect to the srsName * Updated Section 12. "Errors, Warnings, and Redirects" * Changed the default value for the recursion attribute from 'true' =20 to 'false". * Added Jonathan's intro paragraph. * Took out the optional for responses. * Added NO-CACHE and NO-EXPIRATION for expires attribute with =20 corresponding text in Section 5.2. * Modified the description in Section 6 "Path of a Request" * Modified the description in Section 7.3.3. "Recursion and Iteration" * Update to location profiles in Section 11.1. "Location Profile =20 Usage" and in Section 11.2. "Two Dimensional Geodetic Profile" There is still a need for a bit of clean-up in the examples, which =20 didn't quite get done in the rush to meet the I-D deadline. We'll =20 also add an error for an invalid/unknown SRS. Otherwise, we believe =20 this to reflect list comments, so it would be particularly useful if =20 those that have provided comments take a look at their main concerns =20 and make sure that these have been addressed. Henning (on behalf of the LoST author team) _______________________________________________ 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 Mar 12 20:31: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 1HQuuu-0002c5-TQ; Mon, 12 Mar 2007 20:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQuuX-0002Q1-Gp for ecrit@ietf.org; Mon, 12 Mar 2007 20:30:41 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQure-0007xE-2I for ecrit@ietf.org; Mon, 12 Mar 2007 20:27:43 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2D0REth027595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Mar 2007 20:27:27 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A4559BE-F4A6-4B08-9986-729236FEF3F6@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST 05 #1 Date: Mon, 12 Mar 2007 20:27:12 -0400 To: "Reese, Theresa E" 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: 9ed51c9d1356100bce94f1ae4ec616a9 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 Theresa, thanks again for your careful review. I will be editing -06 based on these comments; please see inline. On Mar 12, 2007, at 1:29 PM, Reese, Theresa E wrote: > > > 1. Editorial comments: > > Section 3, first paragraph under and > > > Change the first sentence to read: "This message pattern allows > for the > retrieval of contact URIs based on location information together > with a > service identifier." Reworded. > > Section 3, first paragraph under and > > > Change the first sentence to read: "This message pattern supports a > query for a service boundary. The details can be found in Section 8." Fixed. > > Section 5.6, last paragraph, last line: remove the extra "the". > > Section 11.1, item 3, first sentence: Change "profiles of derived" to > "profiles if derived". > > Section 13, second paragraph: Add a period at the end of the > sentence. Fixed. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 12 20:36: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 1HQv0D-0007xf-TM; Mon, 12 Mar 2007 20:36:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQv0D-0007wV-03 for ecrit@ietf.org; Mon, 12 Mar 2007 20:36:33 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQv0A-0002Mb-N0 for ecrit@ietf.org; Mon, 12 Mar 2007 20:36:32 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2D0aARP022795 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Mar 2007 20:36:15 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2341DD7E-F887-4EA8-8B48-FB76AFB7FDF2@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST 05 #2 (iterative/recursive) Date: Mon, 12 Mar 2007 20:36:08 -0400 To: "Reese, Theresa E" 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: 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 > > 2. Section 6, third paragraph states, "If a query is answered > iteratively, the querier includes all servers." > > The only "querier" in an iterative example is the original client. > The > authoritative (responding) server will only identify itself in this > scenario, so the element should contain only the > corresponding to the responding server. Perhaps this could be > clarified > in the text. The idea was that the query would contain all the servers the client has contacted so far. This allows a mixture of iterative and recursive resolution, if desired, without losing the loop protection mechanism. For example, if client C has contact X and Y so far, where X has redirected C to Y and Y to Z, C would send a message to Z: X Y I don't know if this is helpful or necessary, but it seems at least harmless. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 12 20:45: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 1HQv8u-0004bd-O0; Mon, 12 Mar 2007 20:45:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQv8s-0004bC-NP for ecrit@ietf.org; Mon, 12 Mar 2007 20:45:31 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQv8q-0004rk-GZ for ecrit@ietf.org; Mon, 12 Mar 2007 20:45:30 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2D0jKlN029239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Mar 2007 20:45:20 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8DD8CF5B-2664-44D7-8CD7-561C7BD479AB@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST 05 #3 Date: Mon, 12 Mar 2007 20:45:18 -0400 To: "Reese, Theresa E" 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: 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 On Mar 12, 2007, at 1:29 PM, Reese, Theresa E wrote: > > 3. Section 7.3.3, second paragraph states, "In iterative mode, the > server contacted returns a redirection response indicating the next > server to be queried." > > Must a redirection response always be provided? Wouldn't that only be > necessary if the first server could not respond to the request? > Indeed. Added if the server contacted connot provide an answer itself _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 12 20:56: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 1HQvJ4-0002B6-Bi; Mon, 12 Mar 2007 20:56:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQvJ2-0001y1-O8 for ecrit@ietf.org; Mon, 12 Mar 2007 20:56:00 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQvJ1-0000Ps-H7 for ecrit@ietf.org; Mon, 12 Mar 2007 20:56:00 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2D0twsJ001416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Mar 2007 20:55:59 -0400 (EDT) In-Reply-To: References: 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 05 #4, #5 Date: Mon, 12 Mar 2007 20:55:56 -0400 To: "Reese, Theresa E" 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: 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 > > 4. Figure 7, Figure 9, Figure 17 > > Based on Section 5.1, hasn't the "version" attribute been removed from > the Data Source information in messages? This is a bug; fixed. > > 5. Section 12, first paragraph states, "This document does not define > warnings." > > This sentence seems to conflict with the last sentence in the same > paragraph which states, "Unless otherwise noted, all elements below > can > be either an error or a warning, depending on whether a default > response, such as a mapping, is included." What is intent of the > statement that says that this document does not define warnings? > Is the > idea that warnings are not explicitly defined AT THIS TIME (i.e., that > they will be addressed in the future), or that warnings should not be > used at all. I think warnings could be very useful. The last > sentence > of Section 12.2 seems to imply the former. (I noticed that there > was no > pattern provided in the Relax NG Schema in Section 14 for "Warning".) > This is an incomplete discussion. We had started to discuss the idea you quote, namely that the same condition can lead to both an error or a warning, depending on the circumstances. However, this does not appear to be the case for any of the errors defined in the document, i.e., for none of the errors listed would it be possible to return a (partial) answer, as far as I can tell. Maybe my co-authors have a different perspective. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 12 23:15: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 1HQxTN-0008Tm-Kq; Mon, 12 Mar 2007 23:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQxTL-0008Rq-OV for ecrit@ietf.org; Mon, 12 Mar 2007 23:14:47 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQxTI-0004hk-FB for ecrit@ietf.org; Mon, 12 Mar 2007 23:14:47 -0400 Received: from [10.0.1.109] ([::ffff:72.196.237.170]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 12 Mar 2007 23:11:47 -0400 id 0158841B.45F61673.00000250 In-Reply-To: References: 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: Andrew Newton Subject: Re: [Ecrit] LoST 05 #4, #5 Date: Mon, 12 Mar 2007 23:14:27 -0400 To: Henning Schulzrinne , "Reese, Theresa E" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) 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 On Mar 12, 2007, at 8:55 PM, Henning Schulzrinne wrote: >> 5. Section 12, first paragraph states, "This document does not define >> warnings." >> >> This sentence seems to conflict with the last sentence in the same >> paragraph which states, "Unless otherwise noted, all elements >> below can >> be either an error or a warning, depending on whether a default >> response, such as a mapping, is included." What is intent of the >> statement that says that this document does not define warnings? >> Is the >> idea that warnings are not explicitly defined AT THIS TIME (i.e., >> that >> they will be addressed in the future), or that warnings should not be >> used at all. I think warnings could be very useful. The last >> sentence >> of Section 12.2 seems to imply the former. (I noticed that there >> was no >> pattern provided in the Relax NG Schema in Section 14 for "Warning".) >> > > This is an incomplete discussion. We had started to discuss the > idea you quote, namely that the same condition can lead to both an > error or a warning, depending on the circumstances. However, this > does not appear to be the case for any of the errors defined in the > document, i.e., for none of the errors listed would it be possible > to return a (partial) answer, as far as I can tell. > > Maybe my co-authors have a different perspective. Apparently we seem to be circling on this issue. I think the case could be made that a server that for some reason could not get to its RDBMS data store might want to return a default configured answer and an warning, because the policy of the server is to respond on a best effort basis. Similarly, a server operator may want to issue a warning and return some sort of default answer for queries that just cannot be parsed -- again as part of a best effort basis. Some server operators may not want to do that. I'm not saying either way is right or wrong. It's a matter policy, and it's one I'd feel more comfortable putting in the hands of the operators and not making in a protocol. The important thing from a protocol perspective is that a client acts upon an answer with warnings in the same exact way that it would act upon the answer if no warnings were given. Warnings are strictly for postmortem analysis. Incidentally, is defined in the Relax NG, page 43 of the draft. It is part of the commonResponsePattern. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 00:11: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 1HQyLa-0002eT-Ol; Tue, 13 Mar 2007 00:10:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HQyLZ-0002eG-7x for ecrit@ietf.org; Tue, 13 Mar 2007 00:10:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HQyLX-0000IH-S9 for ecrit@ietf.org; Tue, 13 Mar 2007 00:10:49 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2D4AYtj000929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 12 Mar 2007 21:10:35 -0700 Received: from [71.204.158.100] (vpn-10-50-0-140.qualcomm.com [10.50.0.140]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2D4AWJa030493; Mon, 12 Mar 2007 21:10:33 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 12 Mar 2007 21:10:31 -0700 To: Andrew Newton , Henning Schulzrinne , "Reese, Theresa E" From: Ted Hardie Subject: Re: [Ecrit] LoST 05 #4, #5 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 11:14 PM -0400 3/12/07, Andrew Newton wrote: >Apparently we seem to be circling on this issue. I think the case could be made that a server that for some reason could not get to its RDBMS data store might want to return a default configured answer and an warning, because the policy of the server is to respond on a best effort basis. Similarly, a server operator may want to issue a warning and return some sort of default answer for queries that just cannot be parsed -- again as part of a best effort basis. Some server operators may not want to do that. >I'm not saying either way is right or wrong. It's a matter policy, and it's one I'd feel more comfortable putting in the hands of the operators and not making in a protocol. The important thing from a protocol perspective is that a client acts upon an answer with warnings in the same exact way that it would act upon the answer if no warnings were given. Warnings are strictly for postmortem analysis. > >Incidentally, is defined in the Relax NG, page 43 of the draft. It is part of the commonResponsePattern. I think this remains a tension we identified a long time ago; for most protocols, a clear error when the server cannot process a request is a useful thing. If your life depends on it, *some* answer, however derived, is better than nothing. You don't care if the answer is old, the backup's backup, or what--it gives you a better chance of reaching a call taker than nothing. In the ECRIT version of LoST, in other words, we throw out protocol purity in order to allow the server to be as robust as possible in the general aim. The warnings Andy identified would be there to tag the requests as somehow sub-optimal, without refusing to provide some answer. With a bit more experience, we're likely to have a better shot at identifying what warnings will be useful. In the meantime, I would personally suggest returning the answer you have, without identifying its shortcomings explicitly at the moment (possibly manipulating the expiry if it is a transient error). Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 10:00: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 1HR7Xh-0007Pf-VG; Tue, 13 Mar 2007 09:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR7Ua-0005h2-8Q for ecrit@ietf.org; Tue, 13 Mar 2007 09:56:44 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR7Qd-0008Uz-DV for ecrit@ietf.org; Tue, 13 Mar 2007 09:53:08 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 13 Mar 2007 09:49:43 -0400 id 01588429.45F6ABF7.0000372D In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 09:52:28 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) 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 On Mar 13, 2007, at 12:10 AM, Ted Hardie wrote: > In the ECRIT version of LoST, in other words, we throw out protocol > purity in order to allow the server to be as robust as possible in > the general > aim. The warnings Andy identified would be there to tag the > requests as somehow > sub-optimal, without refusing to provide some answer. With a bit > more experience, > we're likely to have a better shot at identifying what warnings > will be useful. > In the meantime, I would personally suggest returning the answer > you have, > without identifying its shortcomings explicitly at the moment > (possibly > manipulating the expiry if it is a transient error). Are you suggesting we get rid of the warnings? Just trying to understand your last sentence. We might want to put something in the draft, perhaps in an appendix, about best-effort answers. Using the value NO-CACHE in the expiry attribute is the proper way of manipulating the expiry in this case, I believe. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 10:43: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 1HR8DH-00069d-EL; Tue, 13 Mar 2007 10:42:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8DG-00069T-N3 for ecrit@ietf.org; Tue, 13 Mar 2007 10:42:54 -0400 Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8DF-0002cf-E1 for ecrit@ietf.org; Tue, 13 Mar 2007 10:42:54 -0400 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l2DEgWi19740; Tue, 13 Mar 2007 10:42:32 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007031310425925575 ; Tue, 13 Mar 2007 10:42:59 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 10:42:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 10:42:58 -0400 Message-ID: In-Reply-To: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST 05 #4, #5 Thread-Index: AcdldvEi9ZrjeuZgSSi94V6AX3Jw4QABedKg References: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> From: "Reese, Theresa E" To: "Andrew Newton" , "Ted Hardie" X-OriginalArrivalTime: 13 Mar 2007 14:42:58.0982 (UTC) FILETIME=[E4F35C60:01C7657D] 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 LoST Authors: I believe warnings will be useful in situations where, for example, a client sends an iterative query that includes a request for location validation, and the server, while capable of returning routing information, does not itself do location validation. In this instance, only the routing information would be included in the response, but is would be useful to indicate via a warning that validation information is not available. This may trigger the client to either send future queries requesting recursive service (with the idea being that the server will have an arrangement with another server that performs location validation), or to omit requests for validation from future queries sent to the "routing only" server. =20 I would like to see some additional work done to include warnings in a future update to LoST. Terry Reese -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, March 13, 2007 9:52 AM To: Ted Hardie Cc: Henning Schulzrinne; Reese, Theresa E; ECRIT Subject: Re: [Ecrit] LoST 05 #4, #5 On Mar 13, 2007, at 12:10 AM, Ted Hardie wrote: > In the ECRIT version of LoST, in other words, we throw out protocol > purity in order to allow the server to be as robust as possible in =20 > the general > aim. The warnings Andy identified would be there to tag the =20 > requests as somehow > sub-optimal, without refusing to provide some answer. With a bit =20 > more experience, > we're likely to have a better shot at identifying what warnings =20 > will be useful. > In the meantime, I would personally suggest returning the answer =20 > you have, > without identifying its shortcomings explicitly at the moment =20 > (possibly > manipulating the expiry if it is a transient error). Are you suggesting we get rid of the warnings? Just trying to =20 understand your last sentence. We might want to put something in the draft, perhaps in an appendix, =20 about best-effort answers. Using the value NO-CACHE in the expiry =20 attribute is the proper way of manipulating the expiry in this case, =20 I believe. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 11:00: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 1HR8U7-0003nJ-5J; Tue, 13 Mar 2007 11:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8U6-0003nE-3i for ecrit@ietf.org; Tue, 13 Mar 2007 11:00:18 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR8U0-0005tU-1W for ecrit@ietf.org; Tue, 13 Mar 2007 11:00:18 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 13 Mar 2007 10:57:09 -0400 id 01588115.45F6BBC5.000049AD In-Reply-To: References: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 10:59:55 -0400 To: "Reese, Theresa E" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============0092505223==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0092505223== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-18866-1173797844-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-18866-1173797844-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 13, 2007, at 10:42 AM, Reese, Theresa E wrote: > I believe warnings will be useful in situations where, for example, a > client sends an iterative query that includes a request > for location validation, and the server, while capable of returning > routing information, does not itself do location validation. In this > instance, only the routing information would be included in the > response, but is would be useful to indicate via a warning that > validation information is not available. This may trigger the > client to > either send future queries requesting recursive service (with the idea > being that the server will have an arrangement with another server > that > performs location validation), or to omit requests for validation from > future queries sent to the "routing only" server. Theresa, the behavior you have specified seems to violate the rule that I called out. Specifically, that warnings DO NOT change the behavior of clients. Or were you suggesting that a human was the one observing the warning and changing recursive flag? > I would like to see some additional work done to include warnings in a > future update to LoST. The schema does allow the addition of warning from other XML namespaces without the need for specifically revising the LoST protocol to accommodate them. -andy --=_zeke.ecotroph.net-18866-1173797844-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 13, 2007, at 10:= 42 AM, Reese, Theresa E wrote:

I b= elieve warnings will be useful in situations where, for example, a=

client sends an iterative &= lt;findService> query that includes a request

for location validation, and the server, whil= e capable of returning

=A0 In this

instance, only the routing information would be = included in the

<= FONT face=3D"Helvetica" size=3D"3" style=3D"font: 12.0px Helvetica">respo= nse, but is would be useful to indicate via a warning that

validation information is not availa= ble.=A0 This may trigger the = client to

either send = future queries requesting recursive service (with the idea

being that the server will have an a= rrangement with another server that

performs location validation), or to omit requests for val= idation from

future q= ueries sent to the "routing only" server. =A0


Theresa, the behavior you have specified seems to = violate the rule that I called out.=A0 Specifically, that warnings DO NOT = change the behavior of clients.=A0 Or were you suggesting that a human wa= s the one observing the warning and changing recursive flag?

I would li= ke to see some additional work done to include warnings in a

<= P style=3D"margin: 0.0px 0.0px 0.0px 0.0px">future update to LoST.

=

The schema does allow the addition of warning = from other XML namespaces without the need for specifically revising the = LoST protocol to=A0accommodate them.

-andy
--=_zeke.ecotroph.net-18866-1173797844-0001-2-- --===============0092505223== 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 --===============0092505223==-- From ecrit-bounces@ietf.org Tue Mar 13 11:29: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 1HR8vV-0003rj-FN; Tue, 13 Mar 2007 11:28:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR8vT-0003qu-SH for ecrit@ietf.org; Tue, 13 Mar 2007 11:28:35 -0400 Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HR8vC-0001Ft-OT for ecrit@ietf.org; Tue, 13 Mar 2007 11:28:35 -0400 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l2DFSBi01058; Tue, 13 Mar 2007 11:28:11 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007031311283728269 ; Tue, 13 Mar 2007 11:28:37 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Mar 2007 11:28:37 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 11:28:37 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST 05 #4, #5 Thread-Index: AcdlgFckx5/XF4WQT0St2QTW4wV5bwAAjbug References: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> From: "Reese, Theresa E" To: "Andrew Newton" X-OriginalArrivalTime: 13 Mar 2007 15:28:37.0622 (UTC) FILETIME=[454EA960:01C76584] X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e 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="===============0767321138==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0767321138== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C76584.451A03A3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C76584.451A03A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy - =20 I was thinking that the return of the warning could be logged (like the return of an error indication), and that this could result in a human potentially modifying some settings. Even if the modification didn't take place, I was envisioning that the logging would. It seems odd to me that if a client makes an explicit request (e.g., for location validation), and the server cannot accommodate it and so does not return the requested information (even though it can and does return routing information), that this would not be flagged as some kind of abnormal situation. =20 While the schema may allow for warnings from other XML namespaces, the text in the document is currently ambiguous about whether they are supported or not. =20 Terry =20 ________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Tuesday, March 13, 2007 11:00 AM To: Reese, Theresa E Cc: Ted Hardie; Henning Schulzrinne; ECRIT Subject: Re: [Ecrit] LoST 05 #4, #5 =20 =20 On Mar 13, 2007, at 10:42 AM, Reese, Theresa E wrote: I believe warnings will be useful in situations where, for example, a client sends an iterative query that includes a request for location validation, and the server, while capable of returning routing information, does not itself do location validation. In this instance, only the routing information would be included in the response, but is would be useful to indicate via a warning that validation information is not available. This may trigger the client to either send future queries requesting recursive service (with the idea being that the server will have an arrangement with another server that performs location validation), or to omit requests for validation from future queries sent to the "routing only" server. =20 =20 Theresa, the behavior you have specified seems to violate the rule that I called out. Specifically, that warnings DO NOT change the behavior of clients. Or were you suggesting that a human was the one observing the warning and changing recursive flag? I would like to see some additional work done to include warnings in a future update to LoST. =20 The schema does allow the addition of warning from other XML namespaces without the need for specifically revising the LoST protocol to accommodate them. =20 -andy ------_=_NextPart_001_01C76584.451A03A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy = –

 

I was thinking that the return of = the warning could be logged (like the return of an error indication), and = that this could result in a human potentially

modifying some settings.  Even = if the modification didn’t take place, I was envisioning that the logging = would.  It seems odd to me that if a client makes an explicit request (e.g., for = location validation), and the server cannot accommodate it and so does not return = the requested information (even though it can and does return routing = information), that this would not be flagged as some kind of abnormal = situation.

 

While the schema may allow for = warnings from other XML namespaces, the text in the document is currently = ambiguous about whether they are supported or not.

 

Terry

 

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Tuesday, March 13, = 2007 11:00 AM
To: Reese, Theresa E
Cc: Ted Hardie; Henning Schulzrinne; ECRIT
Subject: Re: [Ecrit] LoST = 05 #4, #5

 

 

On Mar 13, 2007, at 10:42 AM, Reese, Theresa E = wrote:



I believe warnings will = be useful in situations where, for example, a

client sends an = iterative <findService> query that includes a = request

for location validation, = and the server, while capable of returning

routing information, = does not itself do location validation.  = In this

instance, only the = routing information would be included in the

response, but is would = be useful to indicate via a warning that

validation information = is not available.  This may = trigger the client to

either send future = queries requesting recursive service (with the idea

being that the server = will have an arrangement with another server that

performs location = validation), or to omit requests for validation from

future queries sent to = the "routing only" server.  

 

Theresa, the behavior you have specified seems to violate the = rule that I called out.  Specifically, that warnings DO NOT change the = behavior of clients.  Or were you suggesting that a human was the one observing = the warning and changing recursive flag?



I would like to see some additional work done to include warnings in = a

future update to = LoST.

 

The schema does allow the addition of warning from other XML = namespaces without the need for specifically revising the LoST protocol to accommodate them.

 

-andy

------_=_NextPart_001_01C76584.451A03A3-- --===============0767321138== 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 --===============0767321138==-- From ecrit-bounces@ietf.org Tue Mar 13 11:47: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 1HR9DA-0000jm-EZ; Tue, 13 Mar 2007 11:46:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HR9D9-0000jX-1w for ecrit@ietf.org; Tue, 13 Mar 2007 11:46:51 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HR9D7-0008WL-Rn for ecrit@ietf.org; Tue, 13 Mar 2007 11:46:51 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Tue, 13 Mar 2007 11:44:01 -0400 id 0158838A.45F6C6C1.0000575B In-Reply-To: References: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: From: Andrew Newton Subject: Re: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 11:46:47 -0400 To: "Reese, Theresa E" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) 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 On Mar 13, 2007, at 11:28 AM, Reese, Theresa E wrote: > Andy =96 > > > > I was thinking that the return of the warning could be logged (like =20= > the return of an error indication), and that this could result in a =20= > human potentially > > modifying some settings. Even if the modification didn=92t take =20 > place, I was envisioning that the logging would. It seems odd to =20 > me that if a client makes an explicit request (e.g., for location =20 > validation), and the server cannot accommodate it and so does not =20 > return the requested information (even though it can and does =20 > return routing information), that this would not be flagged as some =20= > kind of abnormal situation. Ok. So you were thinking along the same lines as I was. I believe Henning has stated in the past that such logging could take =20= place because the validation information would not be present and =20 therefore no explicit warning is needed. However, an explicit =20 warning does provide a place to put appropriate descriptive text if =20 that is desirable. I see no harm in adding an =20 element as a compromise to this issue. =20 Henning? Anybody else? > While the schema may allow for warnings from other XML namespaces, =20= > the text in the document is currently ambiguous about whether they =20 > are supported or not. Agreed. Once we come to resolution, the text needs to be better =20 about what is going on here. -andy= _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 13:31: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 1HRAqC-00084N-PS; Tue, 13 Mar 2007 13:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRAqB-00080P-Pt for ecrit@ietf.org; Tue, 13 Mar 2007 13:31:15 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRAqA-0005y2-3J for ecrit@ietf.org; Tue, 13 Mar 2007 13:31:15 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l2DHUrLb005119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Mar 2007 10:30:53 -0700 Received: from [71.204.158.100] (vpn-10-50-16-113.qualcomm.com [10.50.16.113]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l2DHUqwl028257; Tue, 13 Mar 2007 10:30:52 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> References: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> Date: Tue, 13 Mar 2007 10:30:50 -0700 To: Andrew Newton From: Ted Hardie Subject: Re: [Ecrit] LoST 05 #4, #5 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 9:52 AM -0400 3/13/07, Andrew Newton wrote: >On Mar 13, 2007, at 12:10 AM, Ted Hardie wrote: >>In the ECRIT version of LoST, in other words, we throw out protocol >>purity in order to allow the server to be as robust as possible in the general >>aim. The warnings Andy identified would be there to tag the requests as somehow >>sub-optimal, without refusing to provide some answer. With a bit more experience, >>we're likely to have a better shot at identifying what warnings will be useful. >>In the meantime, I would personally suggest returning the answer you have, >>without identifying its shortcomings explicitly at the moment (possibly >>manipulating the expiry if it is a transient error). > >Are you suggesting we get rid of the warnings? Just trying to understand your last sentence. Sorry, it was late and my cold medicine was kicking in. I do not want to get rid of the warnings. I was trying to say that someone deploying now can just return the answer it has, without worrying about providing a warning, if they are not sure what warning to provide. They might, as you suggest below, use NO-CACHE to make sure that the answer is expired promptly. ted >We might want to put something in the draft, perhaps in an appendix, about best-effort answers. Using the value NO-CACHE in the expiry attribute is the proper way of manipulating the expiry in this case, I believe. > >-andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 13: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 1HRB0h-0004bf-Qs; Tue, 13 Mar 2007 13:42:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRB0h-0004ba-8R for ecrit@ietf.org; Tue, 13 Mar 2007 13:42:07 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRB0g-0000P1-1f for ecrit@ietf.org; Tue, 13 Mar 2007 13:42:07 -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 l2DHftdx025307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2007 13:41:55 -0400 (EDT) In-Reply-To: References: <0B86BD33-00D3-44E5-AF51-AE1B2066D981@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 13:42:35 -0400 To: Andrew Newton 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: 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 have no objection to providing additional diagnostic information, =20 as long as it is optional for this particular case (no validation). =20 In other words, a client should be able to ignore the warning and =20 still function just fine. On Mar 13, 2007, at 11:46 AM, Andrew Newton wrote: > > On Mar 13, 2007, at 11:28 AM, Reese, Theresa E wrote: > >> Andy =96 >> >> >> >> I was thinking that the return of the warning could be logged =20 >> (like the return of an error indication), and that this could =20 >> result in a human potentially >> >> modifying some settings. Even if the modification didn=92t take =20 >> place, I was envisioning that the logging would. It seems odd to =20 >> me that if a client makes an explicit request (e.g., for location =20 >> validation), and the server cannot accommodate it and so does not =20 >> return the requested information (even though it can and does =20 >> return routing information), that this would not be flagged as =20 >> some kind of abnormal situation. > > Ok. So you were thinking along the same lines as I was. > > I believe Henning has stated in the past that such logging could =20 > take place because the validation information would not be present =20 > and therefore no explicit warning is needed. However, an explicit =20 > warning does provide a place to put appropriate descriptive text if =20= > that is desirable. I see no harm in adding an =20 > element as a compromise to this issue. =20 > Henning? Anybody else? > >> While the schema may allow for warnings from other XML =20 >> namespaces, the text in the document is currently ambiguous about =20 >> whether they are supported or not. > Agreed. Once we come to resolution, the text needs to be better =20 > about what is going on here. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 13 13:46: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 1HRB4Q-0007S8-N5; Tue, 13 Mar 2007 13:45:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRB4O-0007PQ-Uw for ecrit@ietf.org; Tue, 13 Mar 2007 13:45:56 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRB4N-0001Su-My for ecrit@ietf.org; Tue, 13 Mar 2007 13:45:56 -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 l2DHjq1D026137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Mar 2007 13:45:53 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9B58E393-DD0B-4120-A7BF-044499654F02@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST 05 #4, #5 Date: Tue, 13 Mar 2007 13:46:35 -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.5 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 I generally agree with the objective, but will point out practical limitations. It is not clear to me what useful answer can be returned by a local resolver, say, unless you return some global emergency calling center. In some cases, such as authoritative servers that are responsible only for a state, such a default answer is reasonable, since they wouldn't have been contacted unless somebody else believed the location to be in that state, say. In any event, making the Warning optional and indicating its purpose for logging, while explaining the behavior should allow sufficient implementation flexibility for server writers without burdening clients with numerous additional code paths and special cases. On Mar 13, 2007, at 12:10 AM, Ted Hardie wrote: > At 11:14 PM -0400 3/12/07, Andrew Newton wrote: >> Apparently we seem to be circling on this issue. I think the case >> could be made that a server that for some reason could not get to >> its RDBMS data store might want to return a default configured >> answer and an warning, because the policy of the >> server is to respond on a best effort basis. Similarly, a server >> operator may want to issue a warning and return some >> sort of default answer for queries that just cannot be parsed -- >> again as part of a best effort basis. Some server operators may >> not want to do that. >> I'm not saying either way is right or wrong. It's a matter >> policy, and it's one I'd feel more comfortable putting in the >> hands of the operators and not making in a protocol. The >> important thing from a protocol perspective is that a client acts >> upon an answer with warnings in the same exact way that it would >> act upon the answer if no warnings were given. Warnings are >> strictly for postmortem analysis. >> >> Incidentally, is defined in the Relax NG, page 43 of >> the draft. It is part of the commonResponsePattern. > > I think this remains a tension we identified a long time ago; for > most protocols, > a clear error when the server cannot process a request is a useful > thing. If > your life depends on it, *some* answer, however derived, is better > than > nothing. You don't care if the answer is old, the backup's backup, > or what--it > gives you a better chance of reaching a call taker than nothing. > > In the ECRIT version of LoST, in other words, we throw out protocol > purity in order to allow the server to be as robust as possible in > the general > aim. The warnings Andy identified would be there to tag the > requests as somehow > sub-optimal, without refusing to provide some answer. With a bit > more experience, > we're likely to have a better shot at identifying what warnings > will be useful. > In the meantime, I would personally suggest returning the answer > you have, > without identifying its shortcomings explicitly at the moment > (possibly > manipulating the expiry if it is a transient error). > > Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 14 02: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 1HRMv7-0003Kr-6D; Wed, 14 Mar 2007 02:25:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRMv5-0003JY-Cv; Wed, 14 Mar 2007 02:25:07 -0400 Received: from [2001:858:745:a0e4:20b:dbff:fe95:d83a] (helo=sil1.mah.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRMuy-0003AJ-NQ; Wed, 14 Mar 2007 02:25:07 -0400 Received: from [81.223.16.197] (helo=[192.168.1.47]) by sil1.mah.priv.at with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1HRMuk-0006p2-5U; Wed, 14 Mar 2007 07:24:46 +0100 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0776CCB1-730D-438D-A89D-E92B8B31A917@mah.priv.at> Content-Transfer-Encoding: 7bit From: Haberler Michael Date: Wed, 14 Mar 2007 07:24:40 +0100 To: "Dawson, Martin" X-Mailer: Apple Mail (2.752.3) X-SA-Exim-Connect-IP: 81.223.16.197 X-SA-Exim-Mail-From: ml1234@mah.priv.at X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on sil1.mah.priv.at X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb X-SA-Exim-Version: 4.2.1 (built Wed, 07 Mar 2007 15:40:54 +0000) X-SA-Exim-Scanned: Yes (on sil1.mah.priv.at) X-Spam-Score: 0.5 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: GEOPRIV WG , ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal 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 Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > > Secondly, one of the things that emergency services don't concern > themselves with in responding to callers is whether you really are the > individual they claim to be. Anonymous emergency calling via public > payphones, SIMless mobiles, and any other point a caller can lay their > hands on a device is an accepted feature of the service. just noting SIMless 911 seems to be not universally accepted - Switzerland explicitely denies SIMless emergency calls in Austria recommended procedure for mountaineers is to remove the SIM before the hike to get better coverage for 140 (mountain rescue) downside of this is - Vienna police gets a surge of SIMless 112 calls every saturday as stolen mobiles are tested for functionality on the flea markets by calling 112 more relevant (possibly to ECRIT towards PSAP contact publishing requirements) is - Switzerland publishes *routing numbers* as PSAP destinations which are meaningful only in a national interconnect scenario -Michael _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 14 04:43: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 1HRP4o-0004zR-Ax; Wed, 14 Mar 2007 04:43:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRP4m-0004y3-Oq; Wed, 14 Mar 2007 04:43:17 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRP4h-0004Jn-4X; Wed, 14 Mar 2007 04:43:16 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 3587820467; Wed, 14 Mar 2007 09:42:54 +0100 (CET) X-AuditID: c1b4fb3e-af9eebb0000061ca-e6-45f7b58edd40 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 16582203C2; Wed, 14 Mar 2007 09:42:54 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 09:42:53 +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] Re: [Geopriv] RE: Strawman Proposal Date: Wed, 14 Mar 2007 09:44:52 +0100 Message-ID: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> In-Reply-To: <0776CCB1-730D-438D-A89D-E92B8B31A917@mah.priv.at> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Thread-Index: AcdmAbrVKswpGhPET36uGRpMxiVTdQAEdaPw From: "Raymond Forbes \(CV/ETL\)" To: "Dawson, Martin" X-OriginalArrivalTime: 14 Mar 2007 08:42:53.0436 (UTC) FILETIME=[C1746BC0:01C76614] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: GEOPRIV WG , ecrit@ietf.org 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 =20 We have had similar discussion in ETSI many Times, I can confirm that Currently, Two Countries mandate by law that SIM-less Emergency Calls Shall be allowed. In Germany these calls are still traceable though the Mobile may not be uniquely identifiable, as a dummy CLI is allocated to the call, the actual Mobile Equipment may also be traced as the IMEI may be sent over the air. In Austria I am not aware of the solution. In the UK, Eire, Switzerland, and increasingly in other EU countries; SIM-Less Emergency Calls are forbidden as the Mobile traceability is mandated by law. In a number of countries like France and Portugal that did allow SIM-less Emergency calls though not by mandate the laws and systems now (or soon will) forbid them. The reason for this change is that the Emergency services were flooded with Anonymous calls from second hand traders of Mobile handsets.=20 Regards, Ray Forbes Ericsson Limited BU Networks (CV/ETL/BBC/D) Telephone: +44 (0) 24 7656 3106 Mobile: +44 (0) 771 851 1361 Email: Raymond.Forbes@Ericsson.com Registered Office: Unit 4, Midleton Gate, Guildford Business Park, Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: 942215 This communication is confidential and intended solely for the addressee(s). Any unauthorised review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.=20 Ericsson Limited does not enter into contracts or contractual obligations via electronic mail, unless otherwise agreed in writing between the parties concerned. E-mail including attachments is susceptible to data corruption, interruption, unauthorised amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.=20 -----Original Message----- From: Haberler Michael [mailto:ml1234@mah.priv.at]=20 Sent: 14 March 2007 06:25 To: Dawson, Martin Cc: GEOPRIV WG; ecrit@ietf.org Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > > Secondly, one of the things that emergency services don't concern=20 > themselves with in responding to callers is whether you really are the > individual they claim to be. Anonymous emergency calling via public=20 > payphones, SIMless mobiles, and any other point a caller can lay their > hands on a device is an accepted feature of the service. just noting SIMless 911 seems to be not universally accepted - Switzerland explicitely denies SIMless emergency calls in Austria recommended procedure for mountaineers is to remove the SIM before the hike to get better coverage for 140 (mountain rescue) downside of this is - Vienna police gets a surge of SIMless 112 calls every saturday as stolen mobiles are tested for functionality on the flea markets by calling 112 more relevant (possibly to ECRIT towards PSAP contact publishing requirements) is - Switzerland publishes *routing numbers* as PSAP destinations which are meaningful only in a national interconnect scenario -Michael _______________________________________________ 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 Mar 14 04:55: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 1HRPGI-0004BG-Ft; Wed, 14 Mar 2007 04:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRPGH-0004B0-8M for ecrit@ietf.org; Wed, 14 Mar 2007 04:55:09 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRPGF-0000hD-Je for ecrit@ietf.org; Wed, 14 Mar 2007 04:55:09 -0400 Received: (qmail invoked by alias); 14 Mar 2007 08:55:06 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp044) with SMTP; 14 Mar 2007 09:55:06 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19Z6mkK0WJZFiq1kgdThwIuOecUkEJ4EXdxObObOz CfdNMHeoYgtkdT Message-ID: <45F7B867.4040603@gmx.net> Date: Wed, 14 Mar 2007 09:55:03 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Raymond Forbes (CV/ETL)" Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal References: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> In-Reply-To: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> 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: 6ffdee8af20de249c24731d8414917d3 Cc: GEOPRIV WG , "Dawson, Martin" , ecrit@ietf.org 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 Raymond, one issue that is quite important to me is whether regulators will demand * "unauthenticated network access" for emergency calls This means that an emergency caller can attach to a network even though it does not have credentials for this network. For example, someone might just use Ericsson enterprise network (or my private WLAN DSL home network) for an emergency call. * authenticated (but unauthorized) emergency calls where some form of authentication of the emergency caller needs to take place. None of these two aspect directly correspond the concept of SIMless emergency calls since the credentials for the two mechanisms are typically different. So, it remains open what it means to have SIM-less emergency calls on the Internet, from a technical and from a regulatory side. It might well be that the trend for a more restrictive user identification makes the entire subject irrelevant. Ciao Hannes Raymond Forbes (CV/ETL) wrote: > > We have had similar discussion in ETSI many Times, I can confirm that > Currently, Two Countries mandate by law that SIM-less Emergency Calls > Shall be allowed. In Germany these calls are still traceable though the > Mobile may not be uniquely identifiable, as a dummy CLI is allocated to > the call, the actual Mobile Equipment may also be traced as the IMEI may > be sent over the air. In Austria I am not aware of the solution. > > In the UK, Eire, Switzerland, and increasingly in other EU countries; > SIM-Less Emergency Calls are forbidden as the Mobile traceability is > mandated by law. In a number of countries like France and Portugal that > did allow SIM-less Emergency calls though not by mandate the laws and > systems now (or soon will) forbid them. The reason for this change is > that the Emergency services were flooded with Anonymous calls from > second hand traders of Mobile handsets. > > Regards, > > Ray Forbes > Ericsson Limited > BU Networks (CV/ETL/BBC/D) > Telephone: +44 (0) 24 7656 3106 > Mobile: +44 (0) 771 851 1361 > Email: Raymond.Forbes@Ericsson.com > > Registered Office: Unit 4, Midleton Gate, Guildford Business Park, > Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: > 942215 > > This communication is confidential and intended solely for the > addressee(s). Any unauthorised review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you. > > Ericsson Limited does not enter into contracts or contractual > obligations via electronic mail, unless otherwise agreed in writing > between the parties concerned. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorised amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof. > > -----Original Message----- > From: Haberler Michael [mailto:ml1234@mah.priv.at] > Sent: 14 March 2007 06:25 > To: Dawson, Martin > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal > > > Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > >> Secondly, one of the things that emergency services don't concern >> themselves with in responding to callers is whether you really are the >> > > >> individual they claim to be. Anonymous emergency calling via public >> payphones, SIMless mobiles, and any other point a caller can lay their >> > > >> hands on a device is an accepted feature of the service. >> > > just noting SIMless 911 seems to be not universally accepted - > > Switzerland explicitely denies SIMless emergency calls > > in Austria recommended procedure for mountaineers is to remove the SIM > before the hike to get better coverage for 140 (mountain rescue) > > downside of this is - Vienna police gets a surge of SIMless 112 calls > every saturday as stolen mobiles are tested for functionality on the > flea markets by calling 112 > > more relevant (possibly to ECRIT towards PSAP contact publishing > requirements) is - Switzerland publishes *routing numbers* as PSAP > destinations which are meaningful only in a national interconnect > scenario > > -Michael > > > > > > _______________________________________________ > 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 Wed Mar 14 05:19: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 1HRPdw-00034l-DO; Wed, 14 Mar 2007 05:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRPdv-00034d-1O; Wed, 14 Mar 2007 05:19:35 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRPdp-0002Bf-6T; Wed, 14 Mar 2007 05:19:35 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9B3C5214AF; Wed, 14 Mar 2007 10:19:24 +0100 (CET) X-AuditID: c1b4fb3e-ad9eabb0000061ca-1b-45f7be1c2c4c Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 81181211EF; Wed, 14 Mar 2007 10:19:24 +0100 (CET) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 10:19:18 +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] Re: [Geopriv] RE: Strawman Proposal Date: Wed, 14 Mar 2007 10:21:17 +0100 Message-ID: <0074F19FF6F8534E8F74C56BB84397BBB0C685@esealmw118.eemea.ericsson.se> In-Reply-To: <45F7B867.4040603@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Thread-Index: AcdmFnf/CJIratAFRwGotgpeuuwAaAAAKSGA From: "Raymond Forbes \(CV/ETL\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 14 Mar 2007 09:19:18.0710 (UTC) FILETIME=[D7FAC560:01C76619] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: GEOPRIV WG , ecrit@ietf.org 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 =20 Hannes, Currently By analogy with the GSM Regulation, The German and Austrian Regulators Demand Unauthenticated access on Publicly Licensed networks. The Private Corporate Networks (CSP IP access; in the IP context) are not subject to this regulation.=20 This will be confusing to the IETF as they do not differentiate between CSP networks and ISP networks. In their relationship with 3GPP the IETF considered 3GPP network as Private Enterprise networks. Some Private Enterprise Networks are nationally Licensed to Sell services to the Public (T-Mobil-D1 or Vodafone-D2), and subject to regulation [they must provide unauthenticated access, but authorise its use with IMEIs and Dummy CLIs; analogous to P_Asserted_Identies in Validated in Proxies], others Only provide corporate access (Siemens or Ericsson) and have a closed community and less or no regulation in this context). Germany and Austria are the only countries that mandate Unauthenticated Access you may be closer to what their governments are thinking about IP access In Other Countries the regulation may be exactly the Opposite un UK, Eire, Private Enterprise Networks are nationally Licensed to Sell services to the Public (T-Mobile-UK or Vodafone-UK), and subject to regulation they must forbid unauthenticated access. You do not need to consider the case of Corporate CSP access, But Publicly Incensed Enterprise Networks. In All cases calls have to be authorised calls to allow traceability. I am not sure that this helps except to say the technology need to provide all cases, except unauthorised. Currently the only Authentication Provide on VoIP Emergency calls is to the ISP/CSP access using Radius or IPSec. Regards, Ray Forbes Ericsson Limited BU Networks (CV/ETL/BBC/D) Telephone: +44 (0) 24 7656 3106 Mobile: +44 (0) 771 851 1361 Email: Raymond.Forbes@Ericsson.com Registered Office: Unit 4, Midleton Gate, Guildford Business Park, Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: 942215 This communication is confidential and intended solely for the addressee(s). Any unauthorised review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.=20 Ericsson Limited does not enter into contracts or contractual obligations via electronic mail, unless otherwise agreed in writing between the parties concerned. E-mail including attachments is susceptible to data corruption, interruption, unauthorised amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: 14 March 2007 08:55 To: Raymond Forbes (CV/ETL) Cc: Dawson, Martin; GEOPRIV WG; ecrit@ietf.org Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Hi Raymond, one issue that is quite important to me is whether regulators will demand * "unauthenticated network access" for emergency calls This means that an emergency caller can attach to a network even though it does not have credentials for this network. For example, someone might just use Ericsson enterprise network (or my private WLAN DSL home network) for an emergency call. * authenticated (but unauthorized) emergency calls where some form of authentication of the emergency caller needs to take place. None of these two aspect directly correspond the concept of SIMless emergency calls since the credentials for the two mechanisms are typically different. So, it remains open what it means to have SIM-less emergency calls on the Internet, from a technical and from a regulatory side. It might well be that the trend for a more restrictive user identification makes the entire subject irrelevant. Ciao Hannes Raymond Forbes (CV/ETL) wrote: > =20 > We have had similar discussion in ETSI many Times, I can confirm that > Currently, Two Countries mandate by law that SIM-less Emergency Calls > Shall be allowed. In Germany these calls are still traceable though the > Mobile may not be uniquely identifiable, as a dummy CLI is allocated to > the call, the actual Mobile Equipment may also be traced as the IMEI may > be sent over the air. In Austria I am not aware of the solution. > > In the UK, Eire, Switzerland, and increasingly in other EU countries; > SIM-Less Emergency Calls are forbidden as the Mobile traceability is > mandated by law. In a number of countries like France and Portugal that > did allow SIM-less Emergency calls though not by mandate the laws and > systems now (or soon will) forbid them. The reason for this change is > that the Emergency services were flooded with Anonymous calls from > second hand traders of Mobile handsets.=20 > > Regards, > > Ray Forbes > Ericsson Limited > BU Networks (CV/ETL/BBC/D) > Telephone: +44 (0) 24 7656 3106 > Mobile: +44 (0) 771 851 1361 > Email: Raymond.Forbes@Ericsson.com > > Registered Office: Unit 4, Midleton Gate, Guildford Business Park, > Guildford, Surrey, GU2 8SG. Registered Number in England and Wales: > 942215 > > This communication is confidential and intended solely for the > addressee(s). Any unauthorised review, use, disclosure or distribution > is prohibited. If you believe this message has been sent to you in > error, please notify the sender by replying to this transmission and > delete the message without disclosing it. Thank you.=20 > > Ericsson Limited does not enter into contracts or contractual > obligations via electronic mail, unless otherwise agreed in writing > between the parties concerned. > > E-mail including attachments is susceptible to data corruption, > interruption, unauthorised amendment, tampering and viruses, and we only > send and receive e-mails on the basis that we are not liable for any > such corruption, interception, amendment, tampering or viruses or any > consequences thereof.=20 > > -----Original Message----- > From: Haberler Michael [mailto:ml1234@mah.priv.at]=20 > Sent: 14 March 2007 06:25 > To: Dawson, Martin > Cc: GEOPRIV WG; ecrit@ietf.org > Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal > > > Am 14.03.2007 um 00:29 schrieb Dawson, Martin: > =20 >> Secondly, one of the things that emergency services don't concern=20 >> themselves with in responding to callers is whether you really are the >> =20 > > =20 >> individual they claim to be. Anonymous emergency calling via public=20 >> payphones, SIMless mobiles, and any other point a caller can lay their >> =20 > > =20 >> hands on a device is an accepted feature of the service. >> =20 > > just noting SIMless 911 seems to be not universally accepted - > > Switzerland explicitely denies SIMless emergency calls > > in Austria recommended procedure for mountaineers is to remove the SIM > before the hike to get better coverage for 140 (mountain rescue) > > downside of this is - Vienna police gets a surge of SIMless 112 calls > every saturday as stolen mobiles are tested for functionality on the > flea markets by calling 112 > > more relevant (possibly to ECRIT towards PSAP contact publishing > requirements) is - Switzerland publishes *routing numbers* as PSAP > destinations which are meaningful only in a national interconnect > scenario > > -Michael > > > > > > _______________________________________________ > 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 > =20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 14 08:29: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 1HRSbF-000540-GQ; Wed, 14 Mar 2007 08:29:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSbE-00053j-AD; Wed, 14 Mar 2007 08:29:00 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRSbB-00074o-1E; Wed, 14 Mar 2007 08:29:00 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2ECSj5E015498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Mar 2007 08:28:45 -0400 (EDT) In-Reply-To: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> References: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3533255A-60C4-43F6-9423-84B9100BA8C1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Date: Wed, 14 Mar 2007 08:28:42 -0400 To: Raymond Forbes ((CV/ETL)) 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: GEOPRIV WG , "Dawson, Martin" , ecrit@ietf.org 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 the UK, Eire, Switzerland, and increasingly in other EU countries; > SIM-Less Emergency Calls are forbidden as the Mobile traceability is > mandated by law. In a number of countries like France and Portugal > that > did allow SIM-less Emergency calls though not by mandate the laws and > systems now (or soon will) forbid them. The reason for this change is > that the Emergency services were flooded with Anonymous calls from > second hand traders of Mobile handsets. I don't know what kind of location conveyance is used there (the equivalent of Phase II wireless seems less common in Europe), but it is pretty clear that reliable location delivery would help very little. It would be interesting to see where most of today's crank calls are coming from; if they are from pay phones on strip malls, location reporting isn't exactly going to help with that problem, as the location information for these is not in doubt. I agree with Hannes that we need an overall threat model, not just a threat model for conveying location. After all, I suspect that NENA and PSAP don't really care whether bogus calls are prevented by some fancy crypto math or some truth inducer in handsets that makes it impossible for callers to lie when dialing 911. Like I said before, I'm not opposed to investigating the role of signing location information, but I believe that it is being oversold. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 14 08:45: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 1HRSqL-00088Y-Ec; Wed, 14 Mar 2007 08:44:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRSqJ-00087k-UN; Wed, 14 Mar 2007 08:44:35 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRSqI-00025G-Mn; Wed, 14 Mar 2007 08:44:35 -0400 Received: from [192.168.0.41] (pool-141-153-174-50.mad.east.verizon.net [141.153.174.50]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2ECiTPW018321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Mar 2007 08:44:34 -0400 (EDT) In-Reply-To: References: 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: Wed, 14 Mar 2007 08:44:28 -0400 To: GEOPRIV 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT Subject: [Ecrit] Re: [Geopriv] RE: Strawman Proposal 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 point, however, is that the actual identity of the caller isn't the > gating factor. Indeed, the question of whether you're using your phone > or someone else's doesn't come up. The whole point of disallowing SIMless emergency calls is that - it makes it impossible to find and fine the nuisance caller - the caller knows that and acts accordingly I believe that traceable identity largely addresses the individual nuisance call problem. (Unlike for SIMless phones, where the SIM is tied to having a contract and paying, it is much easier to imagine no- fee, verified SIP accounts that only do emergency calling.) Just like location signing, this does not have to be perfect to be useful. Most everyone seems to agree that not all calls will have signed locations, so, with any assurance scheme, PSAPs will have to deal with unauthenticated and unsigned calls, using the prioritization mechanisms Brian keeps talking about. The advantage of verified identity is that it works today, without a new infrastructure or a new national CA. Thus, I see it as an important part of the tool kit that will lower the deployment hurdles and will allow us to avoid having to build a perfect location signing system. Thus, I can imagine four levels of calls: (1) assured identity and assured fine-grained location (2) assured identity and unsigned location -> unlikely to be spoofed; equivalent to a large fraction of today's wireless calls (3) no traceable identity and signed location -> equivalent to a payphone or SIMless wireless call today, i.e., treat with caution (4) no identity assurance, no location signing -> suspicious, handle with care and drop during overload Here, identity can be either a L2/L3 identity or a VSP identity; it really doesn't much matter, although VSP identity is the one that's currently available without extra mechanism. The "bot net" out of area attack vector is a different issue and should be discussed separately. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 05:42: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 1HRmTn-00054A-C5; Thu, 15 Mar 2007 05:42:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRmTm-00053l-4q for ecrit@ietf.org; Thu, 15 Mar 2007 05:42:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRmSK-00086J-7J for ecrit@ietf.org; Thu, 15 Mar 2007 05:41:10 -0400 Received: (qmail invoked by alias); 15 Mar 2007 09:41:07 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp031) with SMTP; 15 Mar 2007 10:41:07 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+6/uJMbj66ptup/aPVK5YH5YYdB9XJ+kAejECeHf E9HdNa15KHHCuG Message-ID: <45F914AE.2060405@gmx.net> Date: Thu, 15 Mar 2007 10:41:02 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: GEOPRIV , 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [Ecrit] NENA 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, I would like to better understand the work done by NENA. Which SDOs are going to make use (or is already used) of the work done by NENA? Consider the following SDOs, as an example - 3GPP - 3GPP2 - Wimax - Wifi Alliance - DSL Forum - ETSI TISPAN - CableLabs Since there is often a mismatch between the standards being developed in these SDOs I would like to also understand how the NENA work going to be used on the Internet? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 06:28: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 1HRnBs-00026M-Ql; Thu, 15 Mar 2007 06:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnBq-00025z-Mc; Thu, 15 Mar 2007 06:28:10 -0400 Received: from mail120.messagelabs.com ([216.82.250.83]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRnBp-0003hs-9W; Thu, 15 Mar 2007 06:28:10 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-8.tower-120.messagelabs.com!1173954484!12364495!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 6363 invoked from network); 15 Mar 2007 10:28:05 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-8.tower-120.messagelabs.com with SMTP; 15 Mar 2007 10:28:05 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FAIs7G019862; Thu, 15 Mar 2007 06:18:54 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FAIqfp019856; Thu, 15 Mar 2007 06:18:52 -0400 (EDT) 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 Date: Thu, 15 Mar 2007 05:28:02 -0500 Message-ID: <28F05913385EAC43AF019413F674A017101B7790@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <45F914AE.2060405@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEw References: <45F914AE.2060405@gmx.net> From: "DOLLY, MARTIN C, ATTLABS" To: "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 ATIS=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, March 15, 2007 5:41 AM To: GEOPRIV; ECRIT Subject: [Ecrit] NENA Hi all, I would like to better understand the work done by NENA. Which SDOs are going to make use (or is already used) of the work done=20 by NENA? Consider the following SDOs, as an example - 3GPP - 3GPP2 - Wimax - Wifi Alliance - DSL Forum - ETSI TISPAN - CableLabs Since there is often a mismatch between the standards being developed in these SDOs I would like to also understand how the NENA work going to be used on the Internet? Ciao Hannes _______________________________________________ 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 Mar 15 06:36: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 1HRnJt-0000aa-AU; Thu, 15 Mar 2007 06:36:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRnIj-000858-GE; Thu, 15 Mar 2007 06:35:17 -0400 Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRnEX-00045U-0V; Thu, 15 Mar 2007 06:30:58 -0400 Received: from mail3.siemens.de (localhost [127.0.0.1]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id l2FAUsSh023507; Thu, 15 Mar 2007 11:30:54 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l2FAUqZ9028726; Thu, 15 Mar 2007 11:30:54 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:30:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 11:30:50 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> In-Reply-To: <28F05913385EAC43AF019413F674A017101B7790@OCCLUST04EVS1.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hA= From: "Tschofenig, Hannes" To: "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 10:30:53.0068 (UTC) FILETIME=[02078CC0:01C766ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 Martin,=20 what do you mean by "ATIS"? You mean that ATIS is using the NENA architecture or I should have = included ATIS in the list of SDOs?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > An: Hannes Tschofenig; GEOPRIV; ECRIT > Betreff: [Geopriv] RE: [Ecrit] NENA >=20 > ATIS=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, March 15, 2007 5:41 AM > To: GEOPRIV; ECRIT > Subject: [Ecrit] NENA >=20 > Hi all, >=20 > I would like to better understand the work done by NENA. >=20 > Which SDOs are going to make use (or is already used) of the=20 > work done=20 > by NENA? >=20 > Consider the following SDOs, as an example > - 3GPP > - 3GPP2 > - Wimax > - Wifi Alliance > - DSL Forum > - ETSI TISPAN > - CableLabs >=20 > Since there is often a mismatch between the standards being=20 > developed in >=20 > these SDOs I would like to also understand how the NENA work=20 > going to be >=20 > used on the Internet? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 07:53: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 1HRoVz-0000WM-R2; Thu, 15 Mar 2007 07:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoVy-0000SW-SQ; Thu, 15 Mar 2007 07:53:02 -0400 Received: from mail121.messagelabs.com ([216.82.241.195]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRoVw-0005ru-JB; Thu, 15 Mar 2007 07:53:02 -0400 X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-3.tower-121.messagelabs.com!1173959579!21901340!1 X-StarScan-Version: 5.5.10.7.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 1941 invoked from network); 15 Mar 2007 11:52:59 -0000 Received: from unknown (HELO attrh9i.attrh.att.com) (134.24.146.4) by server-3.tower-121.messagelabs.com with SMTP; 15 Mar 2007 11:52:59 -0000 Received: from attrh.att.com (localhost [127.0.0.1]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FBhneu013237; Thu, 15 Mar 2007 07:43:49 -0400 (EDT) Received: from OCCLUST04EVS1.ugd.att.com (ocst08.ugd.att.com [135.38.164.13]) by attrh9i.attrh.att.com (8.13.8/8.13.8) with ESMTP id l2FBhivJ013217; Thu, 15 Mar 2007 07:43:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 06:52:54 -0500 Message-ID: <28F05913385EAC43AF019413F674A017101B7791@OCCLUST04EVS1.ugd.att.com> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAuYscA== References: <28F05913385EAC43AF019413F674A017101B7790@OCCLUST04EVS1.ugd.att.com> <8F6CBC7005099442AECDB784C9E9D7E701903BB6@MCHP7R6A.ww002.siemens.net> From: "DOLLY, MARTIN C, ATTLABS" To: "Tschofenig, Hannes" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Yes=20 -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Thursday, March 15, 2007 6:31 AM To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT Subject: AW: [Geopriv] RE: [Ecrit] NENA Hi Martin,=20 what do you mean by "ATIS"? You mean that ATIS is using the NENA architecture or I should have = included ATIS in the list of SDOs?=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > An: Hannes Tschofenig; GEOPRIV; ECRIT > Betreff: [Geopriv] RE: [Ecrit] NENA >=20 > ATIS=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, March 15, 2007 5:41 AM > To: GEOPRIV; ECRIT > Subject: [Ecrit] NENA >=20 > Hi all, >=20 > I would like to better understand the work done by NENA. >=20 > Which SDOs are going to make use (or is already used) of the=20 > work done=20 > by NENA? >=20 > Consider the following SDOs, as an example > - 3GPP > - 3GPP2 > - Wimax > - Wifi Alliance > - DSL Forum > - ETSI TISPAN > - CableLabs >=20 > Since there is often a mismatch between the standards being=20 > developed in >=20 > these SDOs I would like to also understand how the NENA work=20 > going to be >=20 > used on the Internet? >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 07:57: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 1HRoaX-0001l1-5N; Thu, 15 Mar 2007 07:57:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoaW-0001kK-79; Thu, 15 Mar 2007 07:57:44 -0400 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRoaU-0006W6-IQ; Thu, 15 Mar 2007 07:57:44 -0400 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l2FBvcQ3012618; Thu, 15 Mar 2007 12:57:38 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l2FBvcAD010836; Thu, 15 Mar 2007 12:57:38 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 12:57:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 12:57:36 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAAArn0Q From: "Tschofenig, Hannes" To: "Dawson, Martin" , "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 11:57:38.0068 (UTC) FILETIME=[20738540:01C766F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 Martin,=20 Thanks for the quick response.=20 I am trying to figure out what the impact to the Internet is if many = SDOs develop their own specifications for emergency services without = considering the NENA work and I am particularly referring to the SDOs = that potentially impact real networks.=20 More comments below:=20 > -----Urspr=FCngliche Nachricht----- > Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Gesendet: Donnerstag, 15. M=E4rz 2007 12:47 > An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes=20 > Tschofenig; GEOPRIV; ECRIT > Betreff: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS=20 > works with NENA specifications. NENA is not an accredited SDO=20 > - in the same sense, for example, that ATIS is accredited and=20 > able to publish American National Standards. Of course, that=20 > doesn't prevent NENA from publishing referencable documents.=20 > The E2 interface specification used for wireless E-9-1-1 is a=20 > NENA document and, as ever, the i2 architecture specification=20 > is a NENA document. >=20 > I don't think there's anything prescriptive about how the=20 > work of NENA interacts with other SDOs. I think it's best=20 > understood in terms of the general role of NENA - which is to=20 > provide a national consensus view on how the elements of the=20 > emergency service fit together. This ends up covering=20 > everything from devices through access and core networks, and=20 > into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the=20 > US which is extremely devolved with multiple independent=20 > parties operating at every level and every function. Without=20 > a body like NENA it would all deteriorate into chaos -=20 > despite how it seems to some, that's not what it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA=20 > J-STD-036 specification for phase 2 wireless which=20 > subsequently formed the deployment model for how the FCC=20 > mandate for wireless E-9-1-1 should be satisfied. This=20 > consequently had an impact on 3GPP/2. >From the last SDO workshop I got the impression that the 3GPP2 actually = had nothing expect for a few high-level requirements. Since a lot of the = 3GPP2 work is taken from 3GPP it might well be possible that they also = recycle the emergency services work.=20 Maybe they have developed a solution already. Maybe you can point to the = relevant documents.=20 There are even=20 > parameters in the 3GPP MAP specification called NA-ESRK and=20 > NA-ESRD (the NA part stands for North American) - though they=20 > do actually have generic utility. But the NENA work is more than just these parameters.=20 >=20 > A typical chain of influence would go along the lines that US=20 > carriers need to meet some regulatory requirement for which=20 > definitions originating or influenced by NENA form the model=20 > for deployment. The carriers need their vendors to support=20 > the functionality associated with the model. Both the vendors=20 > and the carriers participate in the SDOs governing the=20 > specifications for the network elements involved and=20 > subsequently influence what those specifications look like.=20 > To a large extent, artefacts turn up in SDO specifications as=20 > an extended phenotype of the significance and influence of=20 > the US market and the role of NENA in that market. But it is not really good if the NENA work does not appear in the = standardization work of other SDOs.=20 >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. It makes sense but to me it looks like the recipe for a non-working = global emergency service solution since there are too many players = involved that want to develop their own story.=20 Ciao Hannes > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin,=20 >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should=20 > have included ATIS in the list of SDOs?=20 >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS=20 > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of the=20 > > work done=20 > > by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being=20 > > developed in > >=20 > > these SDOs I would like to also understand how the NENA work=20 > > going to be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > 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] >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 08:14:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoq5-0004m8-EL; Thu, 15 Mar 2007 08:13:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRoq3-0004lj-Lx; Thu, 15 Mar 2007 08:13:47 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRopx-0001vL-VS; Thu, 15 Mar 2007 08:13:47 -0400 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.173138017; Thu, 15 Mar 2007 08:13:13 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 08:13:13 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Mar 2007 08:13:13 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 08:13:11 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA031B2B60@crexc41p> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Importance: normal Priority: normal Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAAArn0QAADinsA= References: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> From: "Stark, Barbara" To: "Tschofenig, Hannes" , "Dawson, Martin" , "Dolly, Martin C \(Attlabs\)" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 12:13:13.0211 (UTC) FILETIME=[4DD704B0:01C766FB] X-Spam-Score: 0.1 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 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 DSL Forum is also using the NENA documents to determine requirements for = network elements and CPE. Barbara=20 -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Thursday, March 15, 2007 7:58 AM To: Dawson, Martin; Dolly, Martin C (Attlabs); Hannes Tschofenig; = GEOPRIV; ECRIT Subject: AW: [Geopriv] RE: [Ecrit] NENA Hi Martin,=20 Thanks for the quick response.=20 I am trying to figure out what the impact to the Internet is if many = SDOs develop their own specifications for emergency services without = considering the NENA work and I am particularly referring to the SDOs = that potentially impact real networks.=20 More comments below:=20 > -----Urspr=FCngliche Nachricht----- > Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Gesendet: Donnerstag, 15. M=E4rz 2007 12:47 > An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;=20 > GEOPRIV; ECRIT > Betreff: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS works with=20 > NENA specifications. NENA is not an accredited SDO > - in the same sense, for example, that ATIS is accredited and able to=20 > publish American National Standards. Of course, that doesn't prevent=20 > NENA from publishing referencable documents. > The E2 interface specification used for wireless E-9-1-1 is a NENA=20 > document and, as ever, the i2 architecture specification is a NENA=20 > document. >=20 > I don't think there's anything prescriptive about how the work of NENA = > interacts with other SDOs. I think it's best understood in terms of=20 > the general role of NENA - which is to provide a national consensus=20 > view on how the elements of the emergency service fit together. This=20 > ends up covering everything from devices through access and core=20 > networks, and into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the US which=20 > is extremely devolved with multiple independent parties operating at=20 > every level and every function. Without a body like NENA it would all=20 > deteriorate into chaos - despite how it seems to some, that's not what = > it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA > J-STD-036 specification for phase 2 wireless which subsequently formed = > the deployment model for how the FCC mandate for wireless E-9-1-1=20 > should be satisfied. This consequently had an impact on 3GPP/2. >From the last SDO workshop I got the impression that the 3GPP2 actually = had nothing expect for a few high-level requirements. Since a lot of the = 3GPP2 work is taken from 3GPP it might well be possible that they also = recycle the emergency services work.=20 Maybe they have developed a solution already. Maybe you can point to the = relevant documents.=20 There are even=20 > parameters in the 3GPP MAP specification called NA-ESRK and NA-ESRD=20 > (the NA part stands for North American) - though they do actually have = > generic utility. But the NENA work is more than just these parameters.=20 >=20 > A typical chain of influence would go along the lines that US carriers = > need to meet some regulatory requirement for which definitions=20 > originating or influenced by NENA form the model for deployment. The=20 > carriers need their vendors to support the functionality associated=20 > with the model. Both the vendors and the carriers participate in the=20 > SDOs governing the specifications for the network elements involved=20 > and subsequently influence what those specifications look like. > To a large extent, artefacts turn up in SDO specifications as an=20 > extended phenotype of the significance and influence of the US market=20 > and the role of NENA in that market. But it is not really good if the NENA work does not appear in the = standardization work of other SDOs.=20 >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. It makes sense but to me it looks like the recipe for a non-working = global emergency service solution since there are too many players = involved that want to develop their own story.=20 Ciao Hannes > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin, >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should have=20 > included ATIS in the list of SDOs? >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of the work=20 > > done by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being=20 > > developed in > >=20 > > these SDOs I would like to also understand how the NENA work going=20 > > to be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may contain=20 > 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=20 > prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 09:43: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 1HRqEx-00030g-Nc; Thu, 15 Mar 2007 09:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqEw-00030T-29; Thu, 15 Mar 2007 09:43:34 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqEs-0001nH-EI; Thu, 15 Mar 2007 09:43:34 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2007 09:43:31 -0400 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 l2FDhURt008768; Thu, 15 Mar 2007 09:43:30 -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 l2FDhOlG002393; Thu, 15 Mar 2007 13:43:24 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, 15 Mar 2007 09:43:11 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:43:11 -0400 From: "Marc Linsner" To: "'Dawson, Martin'" Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:43:10 -0400 Message-ID: <007001c76707$df4ac600$230d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Mar 2007 13:43:11.0231 (UTC) FILETIME=[DF4F80F0:01C76707] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8090; t=1173966210; x=1174830210; 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[Geopriv]=20RE=3A=20[Ecrit]=20NENA |Sender:=20 |To:=20=22'Dawson,=20Martin'=22=20; bh=2otwv8B+3mnT7vO6L7kIaiiy2myPFaGFpLU/dpg+EqY=; b=j0BefUX9Jwn0Elju1mdpz7rrgeNDfk9b95P7RDFsdBIlaKpas3d6nYqWNnqQwJh3NAWGft3y ECdyRHeza1iJh9MzSch6cfQ2AGD9ocNtK4XQJBO+m5yvSHZ8MFi58JHn; 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: ff0adf256e4dd459cc25215cfa732ac1 Cc: 'GEOPRIV' , '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 Martin D., As I have expressed in many NENA venues and will reiterate here, NENA = goes way past their boundary of expertise. I've pleaded many times, for many years (starting at the 2000 TDC), at many a microphone in NENA venues to please provide the requirements they need to perform their function. = IMO, no other organization can do that as well as NENA for North America. If/when NENA does such, the IP/VoIP/Internet industry/SDO community would/will provide the best solution possible to meet those = requirements. My statement didn't change over time: 'Please draw a line in the sand, = on one side is the world and the other side is NENA constituents, state the requirements when crossing the line.' Instead, many people have promoted to NENA members that they can not = only take NENA requirements to the SDO community, but that NENA can somehow dictate the solution. NENA's current review of location acquisition mechanisms is an example = of NENA crossing the line. Those documents which have now filtered to ATIS then liaised to a wide variety of SDOs 'on behalf of NENA' are fraught = with technical errors and misguided assumptions. But, when the responses to = the liaise attempt to point out those issues, it's passed off as a derelict response. Further discussion of the ATIS process wrt this isn't = warranted in this venue. But my point is that it seems to be common thread with = what we're experiencing in the IETF. But, there is good in the world! In my obviously biased opinion, I believe an example of what has worked = is the relationship between NENA and ECRIT. I believe that LoST/related = drafts have met almost all, if not all of the goals/requirements of the NENA = LTD wg. I did get a little testy when I (possibly mistakenly) sensed a late change in requirements, but I sense that has resolved itself. I've also witnessed a willingness by the LoST team to make adjustments to the = solution as we/NENA gain implementation experience. If that isn't an example of = how things should work, then all hope has vanished. So, I ask that you compare the difference between the NENA-ECRIT relationship and the NENA-GeoPriv relationship, what is your opinion of = what worked/didn't work/isn't working/and why? Yes, NENA does count! Threats of regulation do not count! -Marc- > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=20 > Sent: Thursday, March 15, 2007 7:47 AM > To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes=20 > Tschofenig; GEOPRIV; ECRIT > Subject: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS=20 > works with NENA specifications. NENA is not an accredited SDO=20 > - in the same sense, for example, that ATIS is accredited and=20 > able to publish American National Standards. Of course, that=20 > doesn't prevent NENA from publishing referencable documents.=20 > The E2 interface specification used for wireless E-9-1-1 is a=20 > NENA document and, as ever, the i2 architecture specification=20 > is a NENA document. >=20 > I don't think there's anything prescriptive about how the=20 > work of NENA interacts with other SDOs. I think it's best=20 > understood in terms of the general role of NENA - which is to=20 > provide a national consensus view on how the elements of the=20 > emergency service fit together. This ends up covering=20 > everything from devices through access and core networks, and=20 > into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the=20 > US which is extremely devolved with multiple independent=20 > parties operating at every level and every function. Without=20 > a body like NENA it would all deteriorate into chaos -=20 > despite how it seems to some, that's not what it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA=20 > J-STD-036 specification for phase 2 wireless which=20 > subsequently formed the deployment model for how the FCC=20 > mandate for wireless E-9-1-1 should be satisfied. This=20 > consequently had an impact on 3GPP/2. There are even=20 > parameters in the 3GPP MAP specification called NA-ESRK and=20 > NA-ESRD (the NA part stands for North American) - though they=20 > do actually have generic utility. >=20 > A typical chain of influence would go along the lines that US=20 > carriers need to meet some regulatory requirement for which=20 > definitions originating or influenced by NENA form the model=20 > for deployment. The carriers need their vendors to support=20 > the functionality associated with the model. Both the vendors=20 > and the carriers participate in the SDOs governing the=20 > specifications for the network elements involved and=20 > subsequently influence what those specifications look like.=20 > To a large extent, artefacts turn up in SDO specifications as=20 > an extended phenotype of the significance and influence of=20 > the US market and the role of NENA in that market. >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin,=20 >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should=20 > have included ATIS in the list of SDOs?=20 >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of=20 > the work done=20 > > by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being=20 > developed=20 > > in > >=20 > > these SDOs I would like to also understand how the NENA=20 > work going to=20 > > be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may=20 > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender=20 > immediately and delete the original. Any unauthorized use of=20 > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 10:50: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 1HRrGd-0006AV-Mw; Thu, 15 Mar 2007 10:49:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrGd-0006AN-3P; Thu, 15 Mar 2007 10:49:23 -0400 Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrGb-0003Ld-Fq; Thu, 15 Mar 2007 10:49:23 -0400 Received: from rrc-dte-ieg01.cc.telcordia.com (rrc-dte-ieg01.cc.telcordia.com [128.96.20.22]) by dnsmx2pya.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id l2FEn8O24854; Thu, 15 Mar 2007 10:49:08 -0400 (EDT) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by rrc-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2007031510493608821 ; Thu, 15 Mar 2007 10:49:36 -0400 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 10:49:35 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 10:49:30 -0400 Message-ID: In-Reply-To: <007001c76707$df4ac600$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmgAAKWrQA= From: "Abbott, Nadine B" To: "Marc Linsner" X-OriginalArrivalTime: 15 Mar 2007 14:49:35.0888 (UTC) FILETIME=[2659E900:01C76711] X-Spam-Score: 0.0 (/) X-Scan-Signature: e178fd6cb61ffb6940cd878e7fea8606 Cc: GEOPRIV , 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 Marc, I think that you misrepresent the NENA WG work on location acquisition. The NENA WG worked to provide requirements and to feed these = requirements into the IETF Geopriv process, and it seems to me that many = IETF Geopriv members have exerted considerable effort to consider how to = include those requirements. Many of those requirements were in fact, quite aligned with the related = Long-Term Definition requirements provided to ECRIT.=20 Further, the NENA WG then has tried to stay aware of what is going on in = many industry forums in the expectation of identifying and recommending = standard solutions that would meet those requirements, and in the hope = of promoting widespread implementation of location-related capabilities. = This is an ongoing work effort. In the liaisons that were sent out to many SDOs last summer, the NENA WG = encouraged these SDOs to work in cooperation with IETF toward common = solutions. NENA has a keen interest in seeing common location solutions = become widely available. In addition to this encouragement, the liaisons = that were sent out included a summary of the above-mentioned = requirements, as well as examples of proposed solution(s) that the NENA = WG found to meet many of these requirements, to stimulate dialog. =20 To my knowledge, the NENA WG has never "passed off as a derelict = response" the responses that have been received from several SDOs to = these liaisons. =20 As you point out, IETF has the deepest understanding of the Internet, = but it has always seemed to me that in the area of location = capabilities, the community of mobile and IP service and solution = providers have valuable insights to offer. Members of the NENA WG have = tried to advocate within IETF (and industry SDOs) for solutions that = would meet practical needs of the emergency services community, and also = have a better chance of being implemented in existing infrastructures = beyond enterprise environments. I am encouraged by Ted Hardie's comments and the hope that the Geopriv = WG will be able to make some progress in the Prague meeting. =20 Regards, Nadine Abbott =20 -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Thursday, March 15, 2007 9:43 AM To: 'Dawson, Martin' Cc: 'GEOPRIV'; 'ECRIT' Subject: RE: [Geopriv] RE: [Ecrit] NENA Martin D., As I have expressed in many NENA venues and will reiterate here, NENA = goes way past their boundary of expertise. I've pleaded many times, for = many years (starting at the 2000 TDC), at many a microphone in NENA = venues to please provide the requirements they need to perform their = function. IMO, no other organization can do that as well as NENA for = North America. If/when NENA does such, the IP/VoIP/Internet industry/SDO community = would/will provide the best solution possible to meet those = requirements. My statement didn't change over time: 'Please draw a line in the sand, = on one side is the world and the other side is NENA constituents, state = the requirements when crossing the line.' Instead, many people have promoted to NENA members that they can not = only take NENA requirements to the SDO community, but that NENA can = somehow dictate the solution. NENA's current review of location acquisition mechanisms is an example = of NENA crossing the line. Those documents which have now filtered to = ATIS then liaised to a wide variety of SDOs 'on behalf of NENA' are = fraught with technical errors and misguided assumptions. But, when the = responses to the liaise attempt to point out those issues, it's passed = off as a derelict response. Further discussion of the ATIS process wrt = this isn't warranted in this venue. But my point is that it seems to be = common thread with what we're experiencing in the IETF. But, there is good in the world! In my obviously biased opinion, I believe an example of what has worked = is the relationship between NENA and ECRIT. I believe that LoST/related = drafts have met almost all, if not all of the goals/requirements of the = NENA LTD wg. I did get a little testy when I (possibly mistakenly) = sensed a late change in requirements, but I sense that has resolved = itself. I've also witnessed a willingness by the LoST team to make = adjustments to the solution as we/NENA gain implementation experience. = If that isn't an example of how things should work, then all hope has = vanished. So, I ask that you compare the difference between the NENA-ECRIT = relationship and the NENA-GeoPriv relationship, what is your opinion of = what worked/didn't work/isn't working/and why? Yes, NENA does count! Threats of regulation do not count! -Marc- > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, March 15, 2007 7:47 AM > To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;=20 > GEOPRIV; ECRIT > Subject: RE: [Geopriv] RE: [Ecrit] NENA >=20 > I think Martin (the other Martin, not me) meant that ATIS works with=20 > NENA specifications. NENA is not an accredited SDO > - in the same sense, for example, that ATIS is accredited and able to=20 > publish American National Standards. Of course, that doesn't prevent=20 > NENA from publishing referencable documents. > The E2 interface specification used for wireless E-9-1-1 is a NENA=20 > document and, as ever, the i2 architecture specification is a NENA=20 > document. >=20 > I don't think there's anything prescriptive about how the work of NENA = > interacts with other SDOs. I think it's best understood in terms of=20 > the general role of NENA - which is to provide a national consensus=20 > view on how the elements of the emergency service fit together. This=20 > ends up covering everything from devices through access and core=20 > networks, and into the emergency network elements - the routers, call=20 > centers, and ALI and ANI databases. >=20 > This is particularly important in an environment such as the US which=20 > is extremely devolved with multiple independent parties operating at=20 > every level and every function. Without a body like NENA it would all=20 > deteriorate into chaos - despite how it seems to some, that's not what = > it is now. :) >=20 > It's good to look at a case study. >=20 > NENA had a lot of influence on, for example, the TIA > J-STD-036 specification for phase 2 wireless which subsequently formed = > the deployment model for how the FCC mandate for wireless E-9-1-1=20 > should be satisfied. This consequently had an impact on 3GPP/2. There=20 > are even parameters in the 3GPP MAP specification called NA-ESRK and=20 > NA-ESRD (the NA part stands for North American) - though they do=20 > actually have generic utility. >=20 > A typical chain of influence would go along the lines that US carriers = > need to meet some regulatory requirement for which definitions=20 > originating or influenced by NENA form the model for deployment. The=20 > carriers need their vendors to support the functionality associated=20 > with the model. Both the vendors and the carriers participate in the=20 > SDOs governing the specifications for the network elements involved=20 > and subsequently influence what those specifications look like. > To a large extent, artefacts turn up in SDO specifications as an=20 > extended phenotype of the significance and influence of the US market=20 > and the role of NENA in that market. >=20 > Does that make sense? I'm not aware that there are any strict=20 > definitions for the relationship between NENA and other SDOs. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, 15 March 2007 9:31 PM > To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT > Subject: AW: [Geopriv] RE: [Ecrit] NENA >=20 > Hi Martin, >=20 > what do you mean by "ATIS"? >=20 > You mean that ATIS is using the NENA architecture or I should have=20 > included ATIS in the list of SDOs? >=20 > Ciao > Hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] > > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 > > An: Hannes Tschofenig; GEOPRIV; ECRIT > > Betreff: [Geopriv] RE: [Ecrit] NENA > >=20 > > ATIS > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Thursday, March 15, 2007 5:41 AM > > To: GEOPRIV; ECRIT > > Subject: [Ecrit] NENA > >=20 > > Hi all, > >=20 > > I would like to better understand the work done by NENA. > >=20 > > Which SDOs are going to make use (or is already used) of > the work done > > by NENA? > >=20 > > Consider the following SDOs, as an example > > - 3GPP > > - 3GPP2 > > - Wimax > > - Wifi Alliance > > - DSL Forum > > - ETSI TISPAN > > - CableLabs > >=20 > > Since there is often a mismatch between the standards being > developed > > in > >=20 > > these SDOs I would like to also understand how the NENA > work going to > > be > >=20 > > used on the Internet? > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may contain=20 > 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=20 > prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 >=20 > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Geopriv mailing list Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 11:22: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 1HRrm2-00021O-0J; Thu, 15 Mar 2007 11:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRrm0-0001xc-CC; Thu, 15 Mar 2007 11:21:48 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRrlw-0008FH-Ky; Thu, 15 Mar 2007 11:21:48 -0400 Received: from [172.28.172.102] ([::ffff:12.172.52.10]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 15 Mar 2007 11:18:34 -0400 id 01588433.45F963CB.00005B83 In-Reply-To: References: Mime-Version: 1.0 Message-Id: From: Andrew Newton Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 11:21:22 -0400 To: "Abbott, Nadine B" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: GEOPRIV WG , iab@ietf.org, 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="===============1123231210==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============1123231210== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-23436-1173971917-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-23436-1173971917-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 15, 2007, at 10:49 AM, Abbott, Nadine B wrote: > The NENA WG worked to provide requirements and to feed these > requirements into the IETF Geopriv process, and it seems to me that > many IETF Geopriv members have exerted considerable effort to > consider how to include those requirements. > Many of those requirements were in fact, quite aligned with the > related Long-Term Definition requirements provided to ECRIT. > > Further, the NENA WG then has tried to stay aware of what is going > on in many industry forums in the expectation of identifying and > recommending standard solutions that would meet those requirements, > and in the hope of promoting widespread implementation of location- > related capabilities. This is an ongoing work effort. I'm currently sitting in a NENA NG Partner Program meeting in Arlington, VA. One of the presentations was a list of the SDOs that NENA has reached out to, with the IETF left off the list. When questioned about that, the response was (summarizing) "Working with the IETF is a given. We work with them every day." I think some of the frustration around the requirements has been that, from the perspective of many IETF'ers, the requirements from NENA have been thrown over the wall, they are done as far as NENA is concerned, and that the IETF has no right to question them. I do not believe that was the intent, because I know many NENA active participants have been active in GEOPRIV and ECRIT. From the other perspective, I'm sure NENA participants see the IETF reacting badly. In the future, both organizations should strive to work together during the requirements development. I personally I have casually pursued getting the IETF to have an official liaison to NENA, but the IAB has not exactly been receptive of the idea. I think it is time that the ECRIT and GEOPRIV co-chairs push harder on the IAB to establish an official relationship if NENA is willing to allow it. -andy --=_zeke.ecotroph.net-23436-1173971917-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 15, 2007, at 10:= 49 AM, Abbott, Nadine B wrote:

The = NENA WG worked to provide requirements and to feed these requirements int= o the IETF Geopriv process, and it seems to me that many IETF Geopriv mem= bers have exerted considerable effort to consider how to include those re= quirements.

Many of th= ose requirements were in fact, quite aligned with the related Long-Term D= efinition requirements provided to ECRIT.=A0


Further, the NENA WG then has tried to stay aware of = what is going on in many industry forums in the expectation of=A0 identifying and recommending standa= rd solutions that would meet those requirements, and in the hope of promo= ting widespread implementation of location-related capabilities.=A0 This is an ongoing work effort.


I'm currently sitting in a NENA NG = Partner Program meeting in Arlington, VA.=A0 One of the presentations was = a list of the SDOs that NENA has reached out to, with the IETF left off t= he list.=A0 When questioned about that, the response was (summarizing) "W= orking with the IETF is a given.=A0 We work with them every day."

I think some of the f= rustration around the requirements has been that, from the perspective of = many IETF'ers, the requirements from NENA have been thrown over the wall, = they are done as far as NENA is concerned, and that the IETF has no right = to question them.=A0 I do not believe that was the intent, because I know = many NENA active participants have been active in GEOPRIV and ECRIT.=A0 F= rom the other perspective, I'm sure NENA participants see the IETF reacti= ng badly.

In t= he future, both organizations should strive to work together during the r= equirements development.=A0 I personally I have casually pursued getting = the IETF to have an official liaison to NENA, but the IAB has not exactly = been receptive of the idea.=A0 I think it is time that the ECRIT and GEOP= RIV co-chairs push harder on the IAB to establish an official relationshi= p if NENA is willing to allow it.

-andy
--=_zeke.ecotroph.net-23436-1173971917-0001-2-- --===============1123231210== 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 --===============1123231210==-- From ecrit-bounces@ietf.org Thu Mar 15 11:46: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 1HRs9T-0008WU-4j; Thu, 15 Mar 2007 11:46:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRs9S-0008WM-PS; Thu, 15 Mar 2007 11:46:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRs9Q-0002z1-E0; Thu, 15 Mar 2007 11:46:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 15 Mar 2007 08:46:00 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2FFjx5n022152; Thu, 15 Mar 2007 08:45:59 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l2FFjcAY022040; Thu, 15 Mar 2007 15:45:59 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, 15 Mar 2007 11:45:56 -0400 Received: from mlinsnerwxp ([10.82.170.66]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 11:45:55 -0400 From: "Marc Linsner" To: "'Abbott, Nadine B'" Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 11:45:55 -0400 Message-ID: <00a801c76719$04ecf570$230d0d0a@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: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmgAAKWrQAAAzfwgA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 15 Mar 2007 15:45:55.0979 (UTC) FILETIME=[050ADDB0:01C76719] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3210; t=1173973559; x=1174837559; c=relaxed/simple; s=sjdkim5002; 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[Geopriv]=20RE=3A=20[Ecrit]=20NENA |Sender:=20; bh=L0YSdN7W7shDUggk+AtJwg3AiSS4b6NWNn1A9+q8KC4=; b=RoKkyfCMvqTvFfck4ERMw3slO7oyQDknh2/oupmTqSSyfiKouCzbp4tjzDmgqVXD+PvWOGRZ 2QXV81RPaOWnRmfz0LaJrCCXhcGMFZ3w1sRKWfD3nlLwUGnsj0JkE+8Q; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'GEOPRIV' , '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 Nadine, > Further, the NENA WG then has tried to stay aware of what is > going on in many industry forums in the expectation of > identifying and recommending standard solutions that would > meet those requirements, and in the hope of promoting > widespread implementation of location-related capabilities. > This is an ongoing work effort. It is the act of NENA 'recommending standard solutions' that I am referring to. IMO, that is outside of NENA's expertise. > > In the liaisons that were sent out to many SDOs last summer, > the NENA WG encouraged these SDOs to work in cooperation with > IETF toward common solutions. NENA has a keen interest in > seeing common location solutions become widely available. In > addition to this encouragement, the liaisons that were sent > out included a summary of the above-mentioned requirements, > as well as examples of proposed solution(s) that the NENA WG > found to meet many of these requirements, to stimulate dialog. I wasn't specifically referring to the liaisons from NENA last summer, sorry that wasn't clear, but I was focused on NENA's new found agent, ESIF/NGES. It's very interesting on how Martin is characterizing these latest liaisons from NGES as an ESIF effort, but yet in that very venue when I questioned why normal ANSI engineering practices were not being exercised, I was told to go back to NENA if I questioned the requirements. So either that effort is an ESIF project requiring due ANSI proscribed engineering, or ESIF/NGES is an agent for NENA as was explained to me in that venue. Martin is changing the characterization of this project to fit his needs in the current conversation. > > To my knowledge, the NENA WG has never "passed off as a > derelict response" the responses that have been received from > several SDOs to these liaisons. Again, this is my opinion of how NGES is handling responses to their liaison, sorry for the confusion. > > As you point out, IETF has the deepest understanding of the > Internet, but it has always seemed to me that in the area of > location capabilities, the community of mobile and IP service > and solution providers have valuable insights to offer. > Members of the NENA WG have tried to advocate within IETF > (and industry SDOs) for solutions that would meet practical > needs of the emergency services community, and also have a > better chance of being implemented in existing > infrastructures beyond enterprise environments. So, come one and all with requirements. When consensus on requirements is achieved, come one and all with solution proposals. I've tried to demonstrate with the ECRIT example how that process works and at the same I believe we've witnessed how it doesn't work by bringing the requirements along with a proposed solution in what appears to be a mixed up sequence. > > I am encouraged by Ted Hardie's comments and the hope that > the Geopriv WG will be able to make some progress in the > Prague meeting. I have great hope for this effort. I hope Ted can provide the spark to get things moving forward. I know I'm tired of trying. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 12:47: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 1HRt6I-0004Xr-Qc; Thu, 15 Mar 2007 12:46:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRt6H-0004Xi-RE; Thu, 15 Mar 2007 12:46:49 -0400 Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRt6G-0001bO-IM; Thu, 15 Mar 2007 12:46:49 -0400 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 51D1C4CFE4; Thu, 15 Mar 2007 17:46:35 +0100 (CET) Date: Thu, 15 Mar 2007 17:46:35 +0100 From: Otmar Lendl To: "Raymond Forbes (CV/ETL)" Subject: Re: [Ecrit] Re: [Geopriv] RE: Strawman Proposal Message-ID: <20070315164634.GB19647@nic.at> Mail-Followup-To: Otmar Lendl , "Raymond Forbes (CV/ETL)" , "Dawson, Martin" , GEOPRIV WG , ecrit@ietf.org References: <0776CCB1-730D-438D-A89D-E92B8B31A917@mah.priv.at> <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0074F19FF6F8534E8F74C56BB84397BBB0C61D@esealmw118.eemea.ericsson.se> User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: GEOPRIV WG , "Dawson, Martin" , ecrit@ietf.org 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 [Unrelated to ecrit/geopriv, but I'm curious.] On 2007/03/14 09:03, "Raymond Forbes (CV/ETL)" wrote: > > In the UK, Eire, Switzerland, and increasingly in other EU countries; > SIM-Less Emergency Calls are forbidden as the Mobile traceability is > mandated by law. In a number of countries like France and Portugal that > did allow SIM-less Emergency calls though not by mandate the laws and > systems now (or soon will) forbid them. The reason for this change is > that the Emergency services were flooded with Anonymous calls from > second hand traders of Mobile handsets. If these anonymous test calls are reason for disabling a possible life-saving feature (emergency calls from SIM-less phones), why didn't the regulator instead force carriers to implement a simple test-number which could be used by those second hand traders without bothering PSAPs? It's not like these traders _want_ to harrass the PSAPs. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 13:34: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 1HRtpp-0003Cv-OO; Thu, 15 Mar 2007 13:33:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRtpo-0003Cn-RS; Thu, 15 Mar 2007 13:33:52 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRtpX-0002Fk-PP; Thu, 15 Mar 2007 13:33:52 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HRtpM-0007kP-MJ; Thu, 15 Mar 2007 12:33:25 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'GEOPRIV'" , "'ECRIT'" Subject: RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 13:33:29 -0400 Message-ID: <002201c76728$0ebb09c0$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 In-Reply-To: <45F914AE.2060405@gmx.net> Thread-Index: Acdm5knMQsrGGshPT0Oq3ygUQ/zZrgAPXrCQ 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 the chair of the Long Term Definition Working Group in NENA. We are developing a specification currently entitled "Functional and Interface Requirements for Next Generation 9-1-1 (i3)". The central concept to i3 is the Emergency Services IP Network, which is a managed IP network to which all public safety agencies will be connected. The ESInet, which WILL be connected to the Internet, is the entry point for emergency calls, but it is also used among public safety agencies to exchange calls and data. The above referenced document has a defined scope. That scope is the interface for calls and asynchronous events from access networks (including the Internet), and the 9-1-1 system, coming into the ESInet and things within the ESInet itself. After a transition period, ALL calls and events will enter the ESInet through an i3 defined interface. A succinct definition of that interface is "SIP, with location and call back, routed by LoST". We may support other interfaces (e.g. XMPP). There will be an asynchronous event interface. The scope does not include what happens inside a PSAP, but does include the external interfaces it exposes and uses. The working group is intimately familiar with, and attempts to work with ecrit to make sure that the interface it defines aligns with the work of ecrit. The interface for multimedia calls will be SIP, and should conform to the -framework and -phonebcp documents. The scope of i3 is slightly bigger than the edge of the ESInet, because it includes the "Emergency Call Routing Function" (ECRF) which is the database callers use to route calls to an Emergency Services Routing Proxy (ESRP) which sits at the edge of the ESInet. The ECRF will have a LoST interface. Any carrier who delivers calls via IP to a PSAP in North America, will be required to use the NENA interface, since that is the only interface that will be supported. During transition, other interfaces may be supported, and of course, existing interfaces will be supported for some time during transition. PSAPs presently define their interfaces, and carriers are required to conform to them. That will not change. Carriers don't get to make up their own interface and demand the PSAP conform to that. On the other hand, PSAPs, and NENA, don't get to tell carriers how to build their networks. We only define the interface, and, in this case, supply databases for routing and validation. A draft of the document was liaisoned to a number of SDOs for comments. We are reluctant to put the document on a public website, since it is just a draft, and NENA policies to not permit drafts of its standards to be publicly available. I would have to get the group and NENA's concurrence, but if there are members of ecrit who cannot get the document by another path, I can probably arrange to email it to you. LTD has, on a number of occasions, sent requirements to ecrit. This has been done in the usual informal way, as an email or an Internet Draft submitted by an individual. We discuss ecrit drafts in our meeting, achieve consensus on what we would like to see happen, and delegate individuals to pursue the changes we want. Theresa Reese has recently been fulfilling that role with respect to the LoST drafts. In the NENA division of labor, location for NG9-1-1 is the province of a different working group (the "VoIP Location Working Group"), which has different leadership, but similar style. They mainly deal with geopriv. While a formal liaison relationship with NENA is possible, I don't feel we need one. NENA, like IETF, can do formal liaisons, but the organization is not an SDO, and doesn't really have a great process for liaisons. It would be nice to have a better way to get document drafts to IETF folks. I hope this is a sufficient explanation of NENAs work on IP based interfaces to emergency calls, the scope of its current work in that area, the way it thinks it interacts with IETF, and how it expects its work product to be used. If you have any questions, I would be please to answer them. Brian Rosen Chair Long Term Definition Working Group VoIP/Packet Technical Committee NENA Note: This email is my personal opinion and does not represent any discussions in NENA > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 15, 2007 5:41 AM > To: GEOPRIV; ECRIT > Subject: [Ecrit] NENA > > Hi all, > > I would like to better understand the work done by NENA. > > Which SDOs are going to make use (or is already used) of the work done > by NENA? > > Consider the following SDOs, as an example > - 3GPP > - 3GPP2 > - Wimax > - Wifi Alliance > - DSL Forum > - ETSI TISPAN > - CableLabs > > Since there is often a mismatch between the standards being developed in > these SDOs I would like to also understand how the NENA work going to be > used on the Internet? > > Ciao > Hannes > > > _______________________________________________ > 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 Mar 15 15:33: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 1HRvhA-0007YV-JW; Thu, 15 Mar 2007 15:33:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvh8-0007Xj-LD; Thu, 15 Mar 2007 15:33:02 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRvgh-0006Xt-3p; Thu, 15 Mar 2007 15:33:02 -0400 Received: from [172.28.172.102] ([::ffff:12.172.52.10]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Thu, 15 Mar 2007 15:29:10 -0400 id 01588370.45F99E87.00001B39 In-Reply-To: <002201c76728$0ebb09c0$640fa8c0@cis.neustar.com> References: <002201c76728$0ebb09c0$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Message-Id: <0B003BCE-0BA4-485D-8F9A-D397698BC516@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 15:30:59 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: 'GEOPRIV' , '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="===============0798512936==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0798512936== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-6975-1173986965-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-6975-1173986965-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 15, 2007, at 1:33 PM, Brian Rosen wrote: > While a formal liaison relationship with NENA is possible, I don't > feel we > need one. NENA, like IETF, can do formal liaisons, but the > organization is > not an SDO, and doesn't really have a great process for liaisons. > It would > be nice to have a better way to get document drafts to IETF folks. Brian, The IETF has liaison relationships with organizations that are not typically classified as SDOs. ICANN is a big example. I would also disagree about NENA not being an SDO, as they appear to be publishing standards in the context of these conversations. The standards may not be typical technical wire protocol specifications, but requirements can also be standards. I just had a conversation with Roger Hixson about the possibility of a formal liaison, and he believes it to be appropriate. -andy --=_zeke.ecotroph.net-6975-1173986965-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.54.2
On Mar 15, 2007, at 1:3= 3 PM, Brian Rosen wrote:

While a fo= rmal liaison relationship with NENA is possible, I don't feel we

need one.=A0 NENA, like IETF, can do formal liaisons, but = the organization is

n= ot an SDO, and doesn't really have a great process for liaisons.=A0 It would

be nice to have a better way to get document = drafts to IETF folks.


Brian,
=

The IETF has liaiso= n relationships with organizations that are not typically classified as S= DOs.=A0 ICANN is a big example.=A0 I would also disagree about NENA not b= eing an SDO, as they appear to be publishing standards in the context of = these conversations.=A0 The standards may not be typical technical wire p= rotocol specifications, but requirements can also be standards.=A0 I just = had a conversation with Roger Hixson about the possibility of a formal li= aison, and he believes it to be appropriate.

-andy
--=_zeke.ecotroph.net-6975-1173986965-0001-2-- --===============0798512936== 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 --===============0798512936==-- From ecrit-bounces@ietf.org Thu Mar 15 15:41: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 1HRvpk-0004wR-9d; Thu, 15 Mar 2007 15:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRvpj-0004wD-0i; Thu, 15 Mar 2007 15:41:55 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRvpg-00007Q-FY; Thu, 15 Mar 2007 15:41:54 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HRvpU-0001DA-0f; Thu, 15 Mar 2007 14:41:40 -0500 From: "Brian Rosen" To: "'Andrew Newton'" Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 15:41:47 -0400 Message-ID: <006301c76739$fa4c7520$640fa8c0@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <0B003BCE-0BA4-485D-8F9A-D397698BC516@hxr.us> Thread-Index: AcdnOKD77ncrsVtUSbeMTYI5uEuZtQAAMYqQ 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: 'GEOPRIV' , '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="===============1755855907==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1755855907== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01C76718.733AD520" This is a multi-part message in MIME format. ------=_NextPart_000_0064_01C76718.733AD520 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Okay, just so you know what you are asking for. For my group to send an email to the ecrit or geopriv list, we discuss it in a conference call, we MAY (but often don't) pass around a draft, and we designate some one to send it. To get a liaison out, we fill out a form, hold a semi-official vote, send it to the "tech lead team", which includes Roger. They approve it, and then Roger sends it. So far, the average time to get through that process is between one and three months, although everyone agrees that is ridiculous, and we should be able to get it down to a couple of weeks. So sure, we can have a formal liaison if you want one. Brian _____ From: Andrew Newton [mailto:andy@hxr.us] Sent: Thursday, March 15, 2007 3:31 PM To: Brian Rosen Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT' Subject: Re: [Geopriv] RE: [Ecrit] NENA On Mar 15, 2007, at 1:33 PM, Brian Rosen wrote: While a formal liaison relationship with NENA is possible, I don't feel we need one. NENA, like IETF, can do formal liaisons, but the organization is not an SDO, and doesn't really have a great process for liaisons. It would be nice to have a better way to get document drafts to IETF folks. Brian, The IETF has liaison relationships with organizations that are not typically classified as SDOs. ICANN is a big example. I would also disagree about NENA not being an SDO, as they appear to be publishing standards in the context of these conversations. The standards may not be typical technical wire protocol specifications, but requirements can also be standards. I just had a conversation with Roger Hixson about the possibility of a formal liaison, and he believes it to be appropriate. -andy ------=_NextPart_000_0064_01C76718.733AD520 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Okay, just so you know what you are = asking for.

 

For my group to send an email to = the ecrit or geopriv list, we discuss it in a conference call, we MAY (but often = don’t) pass around a draft, and we designate some one to send = it.

 

To get a liaison out, we fill out a = form, hold a semi-official vote, send it to the “tech lead team”, = which includes Roger.  They approve it, and then Roger sends it.  So = far, the average time to get through that process is between one and three = months, although everyone agrees that is ridiculous, and we should be able to = get it down to a couple of weeks.

 

So sure, we can have a formal = liaison if you want one.

 

Brian

 

From: = Andrew Newton [mailto:andy@hxr.us]
Sent: Thursday, March 15, = 2007 3:31 PM
To: Brian Rosen
Cc: 'Hannes Tschofenig'; 'GEOPRIV'; 'ECRIT'
Subject: Re: [Geopriv] = RE: [Ecrit] NENA

 

 

On Mar 15, 2007, at 1:33 PM, Brian Rosen = wrote:



While a formal liaison relationship with NENA is possible, I don't feel = we

need one. NENA, like IETF, can do formal = liaisons, but the organization is

not an SDO, and doesn't = really have a great process for liaisons. = It would

be nice to have a better = way to get document drafts to IETF folks.

 

Brian,

 

The IETF has liaison relationships with organizations that are = not typically classified as SDOs. ICANN is a big example. I would also = disagree about NENA not being an SDO, as they appear to be publishing standards = in the context of these conversations. The standards may not be typical = technical wire protocol specifications, but requirements can also be standards. I just = had a conversation with Roger Hixson about the possibility of a formal = liaison, and he believes it to be appropriate.

 

-andy

------=_NextPart_000_0064_01C76718.733AD520-- --===============1755855907== 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 --===============1755855907==-- From ecrit-bounces@ietf.org Thu Mar 15 16: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 1HRwap-00061k-Ep; Thu, 15 Mar 2007 16:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqoE-0001Lx-3X; Thu, 15 Mar 2007 10:20:02 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqoD-0006q0-Fo; Thu, 15 Mar 2007 10:20:02 -0400 X-SEF-Processed: 5_0_0_910__2007_03_15_09_26_01 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, 15 Mar 2007 09:26:00 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:20: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:19:59 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA031B2B60@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAAArn0QAADinsAAAo4DgA== From: "Dawson, Martin" To: "Stark, Barbara" , "Tschofenig, Hannes" , "Dolly, Martin C \(Attlabs\)" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" X-OriginalArrivalTime: 15 Mar 2007 14:20:00.0883 (UTC) FILETIME=[045DA430:01C7670D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 X-Mailman-Approved-At: Thu, 15 Mar 2007 16:30:34 -0400 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 This ends up being a bit of an essay - but it was the only way I felt I cou= ld respond to the question. The executive summary just says "I think the si= gnificance of these forums to the Internet depends on the nature of the for= um." I know there's a mutual dependence between the Internet and these foru= ms - in a very real way, neither would survive without the other.=0D=0A=0D=0A= 1) A number of the forums are specialists in access technology. They care t= o the extent that convention and regulation impact the functionality they n= eed to provide.=0D=0A=0D=0AThe IEEE, for example, reported at the SDO works= hop in Columbia that they were considering dropping work on explicit locati= on support because the "L7" approach was gaining focus - and because the NE= NA requirements were based on that model. They are now thinking that it's b= etter to provide the mechanisms to deliver network measurement parameters b= y which a LIS could determine location - and subsequently package, deliver,= and protect according to a general model, rather than provide a WiMAX spec= ific mechanism to get location information to an end device. For them, it's= kind of a relief that they don't have to push up into the application issu= es associated with location.=0D=0A=0D=0A2) I'm not sure what the implicatio= ns are for the "Internet". My suspicion is that there aren't particularly s= trong implications for it. Access technologies will continue to diversify a= nd evolve as they have done for the last few decades. WiMAX, WiFi, Ethernet= =2E.. none of them are technically just for IP access but the only market w= hich permits them to become commodities is IP and the most common applicati= on for that is Internet access. I think the IEEE and other access forums wi= ll continue to try and keep their products relevant to that use.=0D=0A=0D=0A= 3) In the case of 3GPP/2 however, we have a definite collision of worlds. T= hey represent a complete end to end network architecture covering everythin= g from devices through functional network elements, protocols, and even the= services. While the architecture defines Packet Service (on top of the inc= reasingly defunct Circuit Service) it is definitely not the same as being t= he Internet. Strictly speaking, IMS only has meaning within that constraint= (even though the term is being used for a general Internet based VoIP serv= ice). The most significant convergence issue is between the likes of 3G and= the general Internet model. The probability envelope still hasn't collapse= d on whether 3G is primarily just another Internet access technology or whe= ther it's a complete network itself - with Internet access bolted on the si= de as a peripheral function. I think market forces will not permit it to co= ntinue as a relatively complete but closed network - but that's just my vie= w.=0D=0A=0D=0A4) NENA, ETSI TISPAN, and similar organizations represent spe= cial interest groups that live on the Internet - I think we'll see increasi= ng numbers of such organizations - NENA didn't used to worry about it, but = now it does. The Internet is paying the price of its success; people wanted= everyone to use it, now they do and they have things to say about how they= 'd like it to be. To some extent they will just want to refine their own ap= plications and conventions but, also, they will seek to influence the funct= ionality that is available in the Internet to make it optimal for their int= erests.=0D=0A=0D=0A5) The role of the IETF in all this... I am not sure. I = understand that in principal it may be the anointed party that ensures ther= e is consistency and integrity to support global interoperability and some = principles in support of users. When I look around, though, I see many many= working groups focusing on very eclectic topics - and I'm not sure what so= rt of constitutional governance is used to really decide what's pertinet fo= r the IETF and what might be better off having its own forum.=0D=0A=0D=0AAn= alternative view would have been to say that "internet" means that it stop= s at the internetworking layer (layer 3 really) and that the Internet is th= e specific most significant global set of interconnected networks. From tha= t perspective, the IETF would have made sure there was a consistent layer 3= , including control functions (like DNS, DHCP, BGCP, etc.) but wouldn't spo= nsor applications - nor necessarily session, transport, and presentation la= yer technologies. In it's purest form the Internet is an openly connected s= et of layer 3 networks; a global platform for any number of applications. V= oice is just a service, instant messaging is just a service, U-Tube is just= a service... they all involve protocols and have interworking issues in th= eir own domain but that's their problem and they shouldn't be able to impac= t a properly robust Internet. I think that's the virtue of the Internet ove= r 3GPP/2 by the way - it's not as heavily prescriptive about what it is use= d for.=0D=0A=0D=0AOf course - the IETF is not as I just suggested it could = be - I said earlier what it looks like to me... confusing. In practice some= of the application protocols are defined in the IETF and others are not. W= 3C was formed by Berners-Lee so he could pursue WWW principles independentl= y of the IETF. It didn't really make any difference to the Internet that he= did that - just added a terrific new application area with its own forum. = It's certainly good that there's a place for people to go if they think the= y have a useful idea for something to do on the Internet but it certainly b= ecomes a "grab bag". Perhaps it was because the IETF inherited other "stuff= " like SMTP, FTP, and SNMP from the original ARPANet suite that opened the = door to make it forum that's an application free for all... I don't know.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com]=20=0D=0ASent: Thursd= ay, 15 March 2007 11:13 PM=0D=0ATo: Tschofenig, Hannes; Dawson, Martin; Dol= ly, Martin C (Attlabs); Hannes Tschofenig; GEOPRIV; ECRIT=0D=0ASubject: RE:= [Geopriv] RE: [Ecrit] NENA=0D=0A=0D=0ADSL Forum is also using the NENA doc= uments to determine requirements for network elements and CPE.=0D=0ABarbara= =20=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Tschofenig, Hannes [ma= ilto:hannes.tschofenig@siemens.com]=20=0D=0ASent: Thursday, March 15, 2007 = 7:58 AM=0D=0ATo: Dawson, Martin; Dolly, Martin C (Attlabs); Hannes Tschofen= ig; GEOPRIV; ECRIT=0D=0ASubject: AW: [Geopriv] RE: [Ecrit] NENA=0D=0A=0D=0A= Hi Martin,=20=0D=0A=0D=0AThanks for the quick response.=20=0D=0A=0D=0AI am = trying to figure out what the impact to the Internet is if many SDOs develo= p their own specifications for emergency services without considering the N= ENA work and I am particularly referring to the SDOs that potentially impac= t real networks.=20=0D=0A=0D=0AMore comments below:=20=0D=0A=0D=0A> -----Ur= spr=FCngliche Nachricht-----=0D=0A> Von: Dawson, Martin [mailto:Martin.Daws= on@andrew.com]=0D=0A> Gesendet: Donnerstag, 15. M=E4rz 2007 12:47=0D=0A> An= : Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig;=20=0D=0A= > GEOPRIV; ECRIT=0D=0A> Betreff: RE: [Geopriv] RE: [Ecrit] NENA=0D=0A>=20=0D= =0A> I think Martin (the other Martin, not me) meant that ATIS works with =0D= =0A> NENA specifications. NENA is not an accredited SDO=0D=0A> - in the sam= e sense, for example, that ATIS is accredited and able to=20=0D=0A> publish= American National Standards. Of course, that doesn't prevent=20=0D=0A> NEN= A from publishing referencable documents.=0D=0A> The E2 interface specifica= tion used for wireless E-9-1-1 is a NENA=20=0D=0A> document and, as ever, t= he i2 architecture specification is a NENA=20=0D=0A> document.=0D=0A>=20=0D= =0A> I don't think there's anything prescriptive about how the work of NENA= =20=0D=0A> interacts with other SDOs. I think it's best understood in terms= of=20=0D=0A> the general role of NENA - which is to provide a national con= sensus=20=0D=0A> view on how the elements of the emergency service fit toge= ther. This=20=0D=0A> ends up covering everything from devices through acces= s and core=20=0D=0A> networks, and into the emergency network elements - th= e routers, call=20=0D=0A> centers, and ALI and ANI databases.=0D=0A>=20=0D=0A= > This is particularly important in an environment such as the US which=20=0D= =0A> is extremely devolved with multiple independent parties operating at =0D= =0A> every level and every function. Without a body like NENA it would all =0D= =0A> deteriorate into chaos - despite how it seems to some, that's not what= =20=0D=0A> it is now. :)=0D=0A>=20=0D=0A> It's good to look at a case study= =2E=0D=0A>=20=0D=0A> NENA had a lot of influence on, for example, the TIA=0D= =0A> J-STD-036 specification for phase 2 wireless which subsequently formed= =20=0D=0A> the deployment model for how the FCC mandate for wireless E-9-1-= 1=20=0D=0A> should be satisfied. This consequently had an impact on 3GPP/2.=0D= =0A=0D=0A>From the last SDO workshop I got the impression that the 3GPP2 ac= tually had nothing expect for a few high-level requirements. Since a lot of= the 3GPP2 work is taken from 3GPP it might well be possible that they also= recycle the emergency services work.=20=0D=0A=0D=0AMaybe they have develop= ed a solution already. Maybe you can point to the relevant documents.=20=0D= =0A=0D=0A There are even=20=0D=0A> parameters in the 3GPP MAP specification= called NA-ESRK and NA-ESRD=20=0D=0A> (the NA part stands for North America= n) - though they do actually have=20=0D=0A> generic utility.=0D=0A=0D=0ABut= the NENA work is more than just these parameters.=20=0D=0A=0D=0A>=20=0D=0A= > A typical chain of influence would go along the lines that US carriers =0D= =0A> need to meet some regulatory requirement for which definitions=20=0D=0A= > originating or influenced by NENA form the model for deployment. The=20=0D= =0A> carriers need their vendors to support the functionality associated =0D= =0A> with the model. Both the vendors and the carriers participate in the =0D= =0A> SDOs governing the specifications for the network elements involved =0D= =0A> and subsequently influence what those specifications look like.=0D=0A>= To a large extent, artefacts turn up in SDO specifications as an=20=0D=0A>= extended phenotype of the significance and influence of the US market=20=0D= =0A> and the role of NENA in that market.=0D=0A=0D=0ABut it is not really g= ood if the NENA work does not appear in the standardization work of other S= DOs.=20=0D=0A=0D=0A>=20=0D=0A> Does that make sense=3F I'm not aware that t= here are any strict=20=0D=0A> definitions for the relationship between NENA= and other SDOs.=0D=0AIt makes sense but to me it looks like the recipe for= a non-working global emergency service solution since there are too many p= layers involved that want to develop their own story.=20=0D=0A=0D=0A=0D=0AC= iao=0D=0AHannes=0D=0A=0D=0A=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -= ----Original Message-----=0D=0A> From: Tschofenig, Hannes [mailto:hannes.ts= chofenig@siemens.com]=0D=0A> Sent: Thursday, 15 March 2007 9:31 PM=0D=0A> T= o: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT=0D=0A> Subje= ct: AW: [Geopriv] RE: [Ecrit] NENA=0D=0A>=20=0D=0A> Hi Martin,=0D=0A>=20=0D= =0A> what do you mean by "ATIS"=3F=0D=0A>=20=0D=0A> You mean that ATIS is u= sing the NENA architecture or I should have=20=0D=0A> included ATIS in the = list of SDOs=3F=0D=0A>=20=0D=0A> Ciao=0D=0A> Hannes=0D=0A>=20=0D=0A> > ----= -Urspr=FCngliche Nachricht-----=0D=0A> > Von: DOLLY, MARTIN C, ATTLABS [mai= lto:mdolly@att.com]=0D=0A> > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28=0D= =0A> > An: Hannes Tschofenig; GEOPRIV; ECRIT=0D=0A> > Betreff: [Geopriv] RE= : [Ecrit] NENA=0D=0A> >=20=0D=0A> > ATIS=0D=0A> >=20=0D=0A> > -----Original= Message-----=0D=0A> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gm= x.net]=0D=0A> > Sent: Thursday, March 15, 2007 5:41 AM=0D=0A> > To: GEOPRIV= ; ECRIT=0D=0A> > Subject: [Ecrit] NENA=0D=0A> >=20=0D=0A> > Hi all,=0D=0A> = >=20=0D=0A> > I would like to better understand the work done by NENA.=0D=0A= > >=20=0D=0A> > Which SDOs are going to make use (or is already used) of th= e work=20=0D=0A> > done by NENA=3F=0D=0A> >=20=0D=0A> > Consider the follow= ing SDOs, as an example=0D=0A> > - 3GPP=0D=0A> > - 3GPP2=0D=0A> > - Wimax=0D= =0A> > - Wifi Alliance=0D=0A> > - DSL Forum=0D=0A> > - ETSI TISPAN=0D=0A> >= - CableLabs=0D=0A> >=20=0D=0A> > Since there is often a mismatch between t= he standards being=20=0D=0A> > developed in=0D=0A> >=20=0D=0A> > these SDOs= I would like to also understand how the NENA work going=20=0D=0A> > to be=0D= =0A> >=20=0D=0A> > used on the Internet=3F=0D=0A> >=20=0D=0A> > Ciao=0D=0A>= > Hannes=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> >=20=0D=0A> > _______= ________________________________________=0D=0A> > Geopriv mailing list=0D=0A= > > Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopri= v=0D=0A> >=20=0D=0A>=20=0D=0A> ____________________________________________= ___=0D=0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1= =2Eietf.org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A> ---------------------= -----------------------------------------=0D=0A> --------------------------= --------=0D=0A> This message is for the designated recipient only and may c= ontain=20=0D=0A> privileged, proprietary, or otherwise private information.=0D= =0A> If you have received it in error, please notify the sender immediately= =20=0D=0A> and delete the original. Any unauthorized use of this email is =0D= =0A> prohibited.=0D=0A> ---------------------------------------------------= -----------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A> =0D= =0A>=20=0D=0A=0D=0A_______________________________________________=0D=0AEcr= it mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/list= info/ecrit=0D=0A=0D=0A*****=0D=0A=0D=0AThe information transmitted is inten= ded only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review, retransm= ission, dissemination or other use of, or taking of any action in reliance = upon this information by persons or entities other than the intended recipi= ent is prohibited. If you received this in error, please contact the sender= and delete the material from all computers. GA621=0D=0A=0D=0A=0D=0A=0D=0A-= ---------------------------------------------------------------------------= --------------------=0D=0AThis message is for the designated recipient only= and may=0D=0Acontain privileged, proprietary, or otherwise private informa= tion. =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 Thu Mar 15 16: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 1HRwap-00061t-Jn; Thu, 15 Mar 2007 16:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRqvo-0006Tw-A5; Thu, 15 Mar 2007 10:27:52 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRqvl-00085I-PD; Thu, 15 Mar 2007 10:27:52 -0400 X-SEF-Processed: 5_0_0_910__2007_03_15_09_33_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); Thu, 15 Mar 2007 09:33:49 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 09:27:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:27:47 -0500 Message-ID: In-Reply-To: <007001c76707$df4ac600$230d0d0a@amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] RE: [Ecrit] NENA Thread-Index: Acdm5nZDo9e+vSXwTWyDOrrBG+jCegABhvEwAAAR9hAAAhESUAACSAmgAAPGYmA= From: "Dawson, Martin" To: "Marc Linsner" X-OriginalArrivalTime: 15 Mar 2007 14:27:49.0339 (UTC) FILETIME=[1B965AB0:01C7670E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d X-Mailman-Approved-At: Thu, 15 Mar 2007 16:30:34 -0400 Cc: GEOPRIV , 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 Marc,=0D=0A=0D=0AI don't know what you mean. NENA wrote requirements. Th= e IETF is defining protocols. I think that's what you just said should happ= en.=0D=0A=0D=0AThe acquisition protocol comparison isn't a NENA document, i= t's an ESIF document. Perhaps you don't distinguish between them. Either wa= y, it's in response to some industry demand for clarity on what they should= be implementing. I think it's been worthwhile in bringing the requirements= to the fore across a number of forums.=0D=0A=0D=0AI haven't been involved = in the NENA/ECRIT work, so I couldn't comment on how effective it's been.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D=0AFro= m: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Friday, 16 March = 2007 12:43 AM=0D=0ATo: Dawson, Martin=0D=0ACc: 'GEOPRIV'; 'ECRIT'=0D=0ASubj= ect: RE: [Geopriv] RE: [Ecrit] NENA=0D=0A=0D=0AMartin D.,=0D=0A=0D=0AAs I h= ave expressed in many NENA venues and will reiterate here, NENA goes=0D=0Aw= ay past their boundary of expertise. I've pleaded many times, for many=0D=0A= years (starting at the 2000 TDC), at many a microphone in NENA venues to=0D= =0Aplease provide the requirements they need to perform their function. IM= O,=0D=0Ano other organization can do that as well as NENA for North America= =2E=0D=0AIf/when NENA does such, the IP/VoIP/Internet industry/SDO communit= y=0D=0Awould/will provide the best solution possible to meet those requirem= ents.=0D=0A=0D=0AMy statement didn't change over time: 'Please draw a line = in the sand, on=0D=0Aone side is the world and the other side is NENA const= ituents, state the=0D=0Arequirements when crossing the line.'=0D=0A=0D=0AIn= stead, many people have promoted to NENA members that they can not only=0D=0A= take NENA requirements to the SDO community, but that NENA can somehow=0D=0A= dictate the solution.=0D=0A=0D=0ANENA's current review of location acquisit= ion mechanisms is an example of=0D=0ANENA crossing the line. Those documen= ts which have now filtered to ATIS=0D=0Athen liaised to a wide variety of S= DOs 'on behalf of NENA' are fraught with=0D=0Atechnical errors and misguide= d assumptions. But, when the responses to the=0D=0Aliaise attempt to point= out those issues, it's passed off as a derelict=0D=0Aresponse. Further di= scussion of the ATIS process wrt this isn't warranted=0D=0Ain this venue. = But my point is that it seems to be common thread with what=0D=0Awe're expe= riencing in the IETF.=0D=0A=0D=0ABut, there is good in the world!=0D=0A=0D=0A= In my obviously biased opinion, I believe an example of what has worked is=0D= =0Athe relationship between NENA and ECRIT. I believe that LoST/related dr= afts=0D=0Ahave met almost all, if not all of the goals/requirements of the = NENA LTD=0D=0Awg. I did get a little testy when I (possibly mistakenly) se= nsed a late=0D=0Achange in requirements, but I sense that has resolved itse= lf. I've also=0D=0Awitnessed a willingness by the LoST team to make adjust= ments to the solution=0D=0Aas we/NENA gain implementation experience. If t= hat isn't an example of how=0D=0Athings should work, then all hope has vani= shed.=0D=0A=0D=0ASo, I ask that you compare the difference between the NENA= -ECRIT=0D=0Arelationship and the NENA-GeoPriv relationship, what is your op= inion of what=0D=0Aworked/didn't work/isn't working/and why=3F=0D=0A=0D=0AY= es, NENA does count! Threats of regulation do not count!=0D=0A=0D=0A-Marc-=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson= , Martin [mailto:Martin.Dawson@andrew.com]=20=0D=0A> Sent: Thursday, March = 15, 2007 7:47 AM=0D=0A> To: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; H= annes=20=0D=0A> Tschofenig; GEOPRIV; ECRIT=0D=0A> Subject: RE: [Geopriv] RE= : [Ecrit] NENA=0D=0A>=20=0D=0A> I think Martin (the other Martin, not me) m= eant that ATIS=20=0D=0A> works with NENA specifications. NENA is not an acc= redited SDO=20=0D=0A> - in the same sense, for example, that ATIS is accred= ited and=20=0D=0A> able to publish American National Standards. Of course, = that=20=0D=0A> doesn't prevent NENA from publishing referencable documents.= =20=0D=0A> The E2 interface specification used for wireless E-9-1-1 is a =0D= =0A> NENA document and, as ever, the i2 architecture specification=20=0D=0A= > is a NENA document.=0D=0A>=20=0D=0A> I don't think there's anything presc= riptive about how the=20=0D=0A> work of NENA interacts with other SDOs. I t= hink it's best=20=0D=0A> understood in terms of the general role of NENA - = which is to=20=0D=0A> provide a national consensus view on how the elements= of the=20=0D=0A> emergency service fit together. This ends up covering=20=0D= =0A> everything from devices through access and core networks, and=20=0D=0A= > into the emergency network elements - the routers, call=20=0D=0A> centers= , and ALI and ANI databases.=0D=0A>=20=0D=0A> This is particularly importan= t in an environment such as the=20=0D=0A> US which is extremely devolved wi= th multiple independent=20=0D=0A> parties operating at every level and ever= y function. Without=20=0D=0A> a body like NENA it would all deteriorate int= o chaos -=20=0D=0A> despite how it seems to some, that's not what it is now= =2E :)=0D=0A>=20=0D=0A> It's good to look at a case study.=0D=0A>=20=0D=0A>= NENA had a lot of influence on, for example, the TIA=20=0D=0A> J-STD-036 s= pecification for phase 2 wireless which=20=0D=0A> subsequently formed the d= eployment model for how the FCC=20=0D=0A> mandate for wireless E-9-1-1 shou= ld be satisfied. This=20=0D=0A> consequently had an impact on 3GPP/2. There= are even=20=0D=0A> parameters in the 3GPP MAP specification called NA-ESRK= and=20=0D=0A> NA-ESRD (the NA part stands for North American) - though the= y=20=0D=0A> do actually have generic utility.=0D=0A>=20=0D=0A> A typical ch= ain of influence would go along the lines that US=20=0D=0A> carriers need t= o meet some regulatory requirement for which=20=0D=0A> definitions originat= ing or influenced by NENA form the model=20=0D=0A> for deployment. The carr= iers need their vendors to support=20=0D=0A> the functionality associated w= ith the model. Both the vendors=20=0D=0A> and the carriers participate in t= he SDOs governing the=20=0D=0A> specifications for the network elements inv= olved and=20=0D=0A> subsequently influence what those specifications look l= ike.=20=0D=0A> To a large extent, artefacts turn up in SDO specifications a= s=20=0D=0A> an extended phenotype of the significance and influence of=20=0D= =0A> the US market and the role of NENA in that market.=0D=0A>=20=0D=0A> Do= es that make sense=3F I'm not aware that there are any strict=20=0D=0A> def= initions for the relationship between NENA and other SDOs.=0D=0A>=20=0D=0A>= Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> F= rom: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=0D=0A> Sent:= Thursday, 15 March 2007 9:31 PM=0D=0A> To: DOLLY, MARTIN C, ATTLABS; Hanne= s Tschofenig; GEOPRIV; ECRIT=0D=0A> Subject: AW: [Geopriv] RE: [Ecrit] NENA=0D= =0A>=20=0D=0A> Hi Martin,=20=0D=0A>=20=0D=0A> what do you mean by "ATIS"=3F=0D= =0A>=20=0D=0A> You mean that ATIS is using the NENA architecture or I shoul= d=20=0D=0A> have included ATIS in the list of SDOs=3F=20=0D=0A>=20=0D=0A> C= iao=0D=0A> Hannes=0D=0A>=20=0D=0A> > -----Urspr=FCngliche Nachricht-----=0D= =0A> > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=0D=0A> > Gesen= det: Donnerstag, 15. M=E4rz 2007 11:28=0D=0A> > An: Hannes Tschofenig; GEOP= RIV; ECRIT=0D=0A> > Betreff: [Geopriv] RE: [Ecrit] NENA=0D=0A> >=20=0D=0A> = > ATIS=0D=0A> >=20=0D=0A> > -----Original Message-----=0D=0A> > From: Hanne= s Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=0D=0A> > Sent: Thursday, Ma= rch 15, 2007 5:41 AM=0D=0A> > To: GEOPRIV; ECRIT=0D=0A> > Subject: [Ecrit] = NENA=0D=0A> >=20=0D=0A> > Hi all,=0D=0A> >=20=0D=0A> > I would like to bett= er understand the work done by NENA.=0D=0A> >=20=0D=0A> > Which SDOs are go= ing to make use (or is already used) of=20=0D=0A> the work done=20=0D=0A> >= by NENA=3F=0D=0A> >=20=0D=0A> > Consider the following SDOs, as an example=0D= =0A> > - 3GPP=0D=0A> > - 3GPP2=0D=0A> > - Wimax=0D=0A> > - Wifi Alliance=0D= =0A> > - DSL Forum=0D=0A> > - ETSI TISPAN=0D=0A> > - CableLabs=0D=0A> >=20=0D= =0A> > Since there is often a mismatch between the standards being=20=0D=0A= > developed=20=0D=0A> > in=0D=0A> >=20=0D=0A> > these SDOs I would like to = also understand how the NENA=20=0D=0A> work going to=20=0D=0A> > be=0D=0A> = >=20=0D=0A> > used on the Internet=3F=0D=0A> >=20=0D=0A> > Ciao=0D=0A> > Ha= nnes=0D=0A> >=20=0D=0A> >=20=0D=0A> > _____________________________________= __________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > htt= ps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=20=0D=0A> > ____________= ___________________________________=0D=0A> > Geopriv mailing list=0D=0A> > = Geopriv@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/geopriv=0D= =0A> >=20=0D=0A>=20=0D=0A> _______________________________________________=0D= =0A> Geopriv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.= org/mailman/listinfo/geopriv=0D=0A>=20=0D=0A> -----------------------------= ---------------------------------=0D=0A> ----------------------------------=0D= =0A> This message is for the designated recipient only and may=20=0D=0A> co= ntain privileged, proprietary, or otherwise private information. =20=0D=0A>= If you have received it in error, please notify the sender=20=0D=0A> immed= iately and delete the original. Any unauthorized use of=20=0D=0A> this ema= il is prohibited.=0D=0A> --------------------------------------------------= ------------=0D=0A> ----------------------------------=0D=0A> [mf2]=0D=0A> =0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Geopr= iv mailing list=0D=0A> Geopriv@ietf.org=0D=0A> https://www1.ietf.org/mailma= n/listinfo/geopriv=0D=0A=0D=0A---------------------------------------------= ---------------------------------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y 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 Mar 15 16:30: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 1HRwap-00063e-VZ; Thu, 15 Mar 2007 16:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwSr-0004Cq-GF for ecrit@ietf.org; Thu, 15 Mar 2007 16:22:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRwSp-0007hu-2n for ecrit@ietf.org; Thu, 15 Mar 2007 16:22:21 -0400 Received: (qmail invoked by alias); 15 Mar 2007 20:22:17 -0000 X-Provags-ID: V01U2FsdGVkX1+tvb4v7OWtddGd4woh2kjRMAlVrEUQdBCAkFtQi7 I3hfhSF/s8Gj4u Message-ID: <45F9AAF6.5010805@gmx.net> Date: Thu, 15 Mar 2007 21:22:14 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT , peter_blatherwick@mitel.com, Dorothy Stanley , Bernard Aboba , "Cullen Jennings (fluffy)" , OPS ADs , "Richard L. Barnes" , Brian Rosen , Marc Linsner , Henning Schulzrinne , "Winterbottom, James" , "James M. Polk" , lixia@CS.UCLA.EDU References: <45F56A82.5060108@gmx.net> In-Reply-To: <45F56A82.5060108@gmx.net> 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: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Thu, 15 Mar 2007 16:30:34 -0400 Cc: Subject: [Ecrit] IETF ECRIT / IEEE Meeting @ IETF#68: Room Tyrolka 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 got a room, namely Tyrolka, for your meeting on Monday. It will hold around 40 person (the room setting is u-shaped). Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > I wanted to inform you that we picked > > *19th March 2007 (Monday) > 11:30 - 13:00 > > *for our meeting (based on the preference indicated on the Wiki page). > I am still waiting for the room reservation. * > > *Ciao > Hannes > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 16: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 1HRwap-000622-Oy; Thu, 15 Mar 2007 16:30:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRsJD-000301-FD; Thu, 15 Mar 2007 11:56:07 -0400 Received: from mail.opengeospatial.org ([208.44.53.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRsJA-0003wX-Sh; Thu, 15 Mar 2007 11:56:07 -0400 Received: from SusieandCarl (c-67-174-113-243.hsd1.co.comcast.net [67.174.113.243]) (authenticated bits=0) by mail.opengeospatial.org (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l2FFtkjg010496 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Mar 2007 11:55:48 -0400 Message-ID: <012101c7671a$6684fa70$6401a8c0@SusieandCarl> From: "Carl Reed OGC Account" To: "Tschofenig, Hannes" , "Dawson, Martin" , "DOLLY, MARTIN C, ATTLABS" , "Hannes Tschofenig" , "GEOPRIV" , "ECRIT" References: <8F6CBC7005099442AECDB784C9E9D7E701903C2C@MCHP7R6A.ww002.siemens.net> Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Thu, 15 Mar 2007 09:53:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Status: No, score=-96.0 required=5.0 tests=BAYES_50, RCVD_IN_NJABL_DUL, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, USER_IN_WHITELIST autolearn=disabled version=3.1.4 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-26) on mail.opengeospatial.org X-Virus-Scanned: ClamAV 0.90.1/2841/Thu Mar 15 07:11:45 2007 on mail.opengeospatial.org X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.opengeospatial.org id l2FFtkjg010496 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 X-Mailman-Approved-At: Thu, 15 Mar 2007 16:30:34 -0400 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 - A really interesting question - especially from the perspective of locati= on=20 payloads and location provision. We in the OGC struggle with this issue o= n a=20 regular basis. This is perhaps why the OGC has formal agreements with abo= ut=20 a dozen SDOs and other organizations that develop specifications in the=20 location/geospatial space. And even with lots of coordination and=20 collaboration, sometimes folks go their own way - which plays havoc with=20 consistent architecture and infrastructure. And we find new efforts cropp= ing=20 up on a regular basis. That said, from a standards "professional" perspective, I am very pleased= =20 with how the IETF GeoPRIV collaboration and standard work is progressing.= I=20 know that there is a bit of concern about discord in some of the recent=20 discussions . . . but compared to some standards discussions I have=20 witnessed over the years, the ones in the GeoPRIV WG are consistently=20 professional and well mannered! Regards Carl ----- Original Message -----=20 From: "Tschofenig, Hannes" To: "Dawson, Martin" ; "DOLLY, MARTIN C, ATTLAB= S"=20 ; "Hannes Tschofenig" ; "GEOPR= IV"=20 ; "ECRIT" Sent: Thursday, March 15, 2007 5:57 AM Subject: AW: [Geopriv] RE: [Ecrit] NENA > Hi Martin, > > Thanks for the quick response. > > I am trying to figure out what the impact to the Internet is if many SD= Os=20 > develop their own specifications for emergency services without=20 > considering the NENA work and I am particularly referring to the SDOs t= hat=20 > potentially impact real networks. > > More comments below: > >> -----Urspr=FCngliche Nachricht----- >> Von: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >> Gesendet: Donnerstag, 15. M=E4rz 2007 12:47 >> An: Tschofenig, Hannes; DOLLY, MARTIN C, ATTLABS; Hannes >> Tschofenig; GEOPRIV; ECRIT >> Betreff: RE: [Geopriv] RE: [Ecrit] NENA >> >> I think Martin (the other Martin, not me) meant that ATIS >> works with NENA specifications. NENA is not an accredited SDO >> - in the same sense, for example, that ATIS is accredited and >> able to publish American National Standards. Of course, that >> doesn't prevent NENA from publishing referencable documents. >> The E2 interface specification used for wireless E-9-1-1 is a >> NENA document and, as ever, the i2 architecture specification >> is a NENA document. >> >> I don't think there's anything prescriptive about how the >> work of NENA interacts with other SDOs. I think it's best >> understood in terms of the general role of NENA - which is to >> provide a national consensus view on how the elements of the >> emergency service fit together. This ends up covering >> everything from devices through access and core networks, and >> into the emergency network elements - the routers, call >> centers, and ALI and ANI databases. >> >> This is particularly important in an environment such as the >> US which is extremely devolved with multiple independent >> parties operating at every level and every function. Without >> a body like NENA it would all deteriorate into chaos - >> despite how it seems to some, that's not what it is now. :) >> >> It's good to look at a case study. >> >> NENA had a lot of influence on, for example, the TIA >> J-STD-036 specification for phase 2 wireless which >> subsequently formed the deployment model for how the FCC >> mandate for wireless E-9-1-1 should be satisfied. This >> consequently had an impact on 3GPP/2. > >>From the last SDO workshop I got the impression that the 3GPP2 actually= =20 >>had nothing expect for a few high-level requirements. Since a lot of th= e=20 >>3GPP2 work is taken from 3GPP it might well be possible that they also=20 >>recycle the emergency services work. > > Maybe they have developed a solution already. Maybe you can point to th= e=20 > relevant documents. > > There are even >> parameters in the 3GPP MAP specification called NA-ESRK and >> NA-ESRD (the NA part stands for North American) - though they >> do actually have generic utility. > > But the NENA work is more than just these parameters. > >> >> A typical chain of influence would go along the lines that US >> carriers need to meet some regulatory requirement for which >> definitions originating or influenced by NENA form the model >> for deployment. The carriers need their vendors to support >> the functionality associated with the model. Both the vendors >> and the carriers participate in the SDOs governing the >> specifications for the network elements involved and >> subsequently influence what those specifications look like. >> To a large extent, artefacts turn up in SDO specifications as >> an extended phenotype of the significance and influence of >> the US market and the role of NENA in that market. > > But it is not really good if the NENA work does not appear in the=20 > standardization work of other SDOs. > >> >> Does that make sense? I'm not aware that there are any strict >> definitions for the relationship between NENA and other SDOs. > It makes sense but to me it looks like the recipe for a non-working glo= bal=20 > emergency service solution since there are too many players involved th= at=20 > want to develop their own story. > > > Ciao > Hannes > > >> Cheers, >> Martin >> >> -----Original Message----- >> From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com] >> Sent: Thursday, 15 March 2007 9:31 PM >> To: DOLLY, MARTIN C, ATTLABS; Hannes Tschofenig; GEOPRIV; ECRIT >> Subject: AW: [Geopriv] RE: [Ecrit] NENA >> >> Hi Martin, >> >> what do you mean by "ATIS"? >> >> You mean that ATIS is using the NENA architecture or I should >> have included ATIS in the list of SDOs? >> >> Ciao >> Hannes >> >> > -----Urspr=FCngliche Nachricht----- >> > Von: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com] >> > Gesendet: Donnerstag, 15. M=E4rz 2007 11:28 >> > An: Hannes Tschofenig; GEOPRIV; ECRIT >> > Betreff: [Geopriv] RE: [Ecrit] NENA >> > >> > ATIS >> > >> > -----Original Message----- >> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> > Sent: Thursday, March 15, 2007 5:41 AM >> > To: GEOPRIV; ECRIT >> > Subject: [Ecrit] NENA >> > >> > Hi all, >> > >> > I would like to better understand the work done by NENA. >> > >> > Which SDOs are going to make use (or is already used) of the >> > work done >> > by NENA? >> > >> > Consider the following SDOs, as an example >> > - 3GPP >> > - 3GPP2 >> > - Wimax >> > - Wifi Alliance >> > - DSL Forum >> > - ETSI TISPAN >> > - CableLabs >> > >> > Since there is often a mismatch between the standards being >> > developed in >> > >> > these SDOs I would like to also understand how the NENA work >> > going to be >> > >> > used on the Internet? >> > >> > Ciao >> > Hannes >> > >> > >> > _______________________________________________ >> > Ecrit mailing list >> > Ecrit@ietf.org >> > https://www1.ietf.org/mailman/listinfo/ecrit >> > >> > _______________________________________________ >> > Geopriv mailing list >> > Geopriv@ietf.org >> > https://www1.ietf.org/mailman/listinfo/geopriv >> > >> >> _______________________________________________ >> Geopriv mailing list >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv >> >> -------------------------------------------------------------- >> ---------------------------------- >> 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] >> >> > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 15 17:09: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 1HRxCc-0006sL-MT; Thu, 15 Mar 2007 17:09:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxCb-0006rf-GO for ecrit@ietf.org; Thu, 15 Mar 2007 17:09:37 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRxCZ-0007W2-9x for ecrit@ietf.org; Thu, 15 Mar 2007 17:09:36 -0400 Received: (qmail invoked by alias); 15 Mar 2007 21:09:34 -0000 X-Provags-ID: V01U2FsdGVkX18ao+5ZxScaZ7DJWovUoLFNdZF/vt3exNsKW8SJsV 6hYWGzwU9Z6tRn Message-ID: <45F9B60D.20900@gmx.net> Date: Thu, 15 Mar 2007 22:09:33 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] Unauthenticated Network Access 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, next Monday we are going to have our information sharing event with the IEEE. I went through their documents to get a better idea of their work and I noticed that the IEEE is working on solutions for unauthenticated network access. This essentially allows an emergency caller without credentials to access an IEEE 802 network. (Hence, I am not talking about unauthenticated emergency calls at the SIP layer). The support for unauthenticated network access raises a number of security challenges including architectural questions. I was wondering whether there are some regulatory requirements that require an architecture to support this type of functionality. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 16 10:57: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 1HSDrR-0002mk-3s; Fri, 16 Mar 2007 10:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSDrP-0002m8-2M; Fri, 16 Mar 2007 10:56:51 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HSDrJ-0001lC-SS; Fri, 16 Mar 2007 10:56:51 -0400 Received: from [172.16.9.198] ([::ffff:208.50.38.5]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Fri, 16 Mar 2007 10:53:24 -0400 id 015886A6.45FAAF64.00003908 In-Reply-To: <006301c76739$fa4c7520$640fa8c0@cis.neustar.com> References: <006301c76739$fa4c7520$640fa8c0@cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable Message-Id: <8FC935A8-F14F-42CE-BD94-DE8BF52CD003@hxr.us> From: Andrew Newton Subject: Re: [Geopriv] RE: [Ecrit] NENA Date: Fri, 16 Mar 2007 10:56:40 -0400 To: Brian Rosen X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 'GEOPRIV' , '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 Mar 15, 2007, at 3:41 PM, Brian Rosen wrote: > To get a liaison out, we fill out a form, hold a semi-official =20 > vote, send it to the =93tech lead team=94, which includes Roger. They = =20 > approve it, and then Roger sends it. So far, the average time to =20 > get through that process is between one and three months, although =20 > everyone agrees that is ridiculous, and we should be able to get it =20= > down to a couple of weeks. All I ever wanted to do was write software. How did I get myself =20 into this mess? -andy= _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 18 07:37: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 1HStgv-0000Ul-Fp; Sun, 18 Mar 2007 07:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSt6F-0004Lv-C1 for ecrit@ietf.org; Sun, 18 Mar 2007 06:58:55 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSt69-0007Of-QR for ecrit@ietf.org; Sun, 18 Mar 2007 06:58:55 -0400 Received: (qmail invoked by alias); 18 Mar 2007 10:58:45 -0000 X-Provags-ID: V01U2FsdGVkX19nR7wDSLJn43cZD0aUHL34xDUDTl1MvrVWt7EbTx dH2qFI4wek7xgK Message-ID: <45FD1B65.6080604@gmx.net> Date: Sun, 18 Mar 2007 11:58:45 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/mixed; boundary="------------030506000101080307060708" X-Y-GMX-Trusted: 0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b8a9ecf218c3964a19788e471a4e588d X-Mailman-Approved-At: Sun, 18 Mar 2007 07:36:48 -0400 Subject: [Ecrit] [Fwd: IEEE 802.11 Review Comments on IETF ECRIT Framework internet draft] 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. --------------030506000101080307060708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, IEEE members have provided a response to our review request. I would like to thank them for their quick response. Ciao Hannes -------- Original Message -------- Subject: IEEE 802.11 Review Comments on IETF ECRIT Framework internet draft Date: Sun, 18 Mar 2007 02:06:37 -0700 From: Dorothy Stanley To: , "Hannes Tschofenig" , , , CC: , "Dorothy Stanley" , , , , "McCann, Stephen" Hannes, The attached document, 11-07-0476-01-0000-liaison-response-to-ietf-ecrit contains the response to your request that the IEEE 802.11 Working Group provide comments on the IETF ECRIT Framework for Emergency Calling in Internet Multimedia internet draft, available at http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-framework/draft-ietf-ecr it- framework-00.txt . The attached response document was approved by the IEEE 802.11 Working Group on March 16th, 2007 and is also available at ftp://ftp.802wirelessworld.com/11/07/11-07-0476-01-0000-liaison-response -to-ietf-ecrit.doc . Please let me know if there are further questions. Thanks, Dorothy Stanley Liaison from IEEE 802.11 to IETF ----------------- Dorothy Stanley Aruba Networks 630-363-1389 (cell) 630-836-9734 (office) --------------030506000101080307060708 Content-Type: application/msword; name="11-07-0476-01-0000-liaison-response-to-ietf-ecrit.doc" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename*0="11-07-0476-01-0000-liaison-response-to-ietf-ecrit.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAApQAAAAAA AAAAEAAApwAAAAEAAAD+////AAAAAJ8AAACmAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////spcEAI2AJBAAA+BK/AAAAAAAAEAAAAAAABgAA HzAAAA4AYmpiajVHNUcAAAAAAAAAAAAAAAAAAAAAAAAJBBYAMXgAAFctAABXLQAA/hwAAAAA AADFAAAAAAAAAAAAAAAAAAAAVgoAAAUAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8A AAAAAAAAAAAAAAAAAAAAAKQAAAAAAGwNAAAAAAAAbA0AAGwNAAAAAAAAbA0AAAAAAAAwDgAA AAAAADAOAAAAAAAAMA4AABQAAAAAAAAAAAAAAEQOAAAAAAAAMCsAAAAAAAAwKwAAAAAAADAr AAA4AAAAaCsAALQAAAAcLAAAZAAAAEQOAAAAAAAAEogAAFACAACMLAAA7gAAAHotAABMAAAA xi0AAAAAAADGLQAAAAAAABIuAAAAAAAAPjAAAAAAAAA+MAAAAAAAAD4wAAAAAAAAkYcAAAIA AACThwAAAAAAAJOHAAAAAAAAk4cAAAAAAACThwAAAAAAAJOHAAAAAAAAk4cAACQAAABiigAA aAIAAMqMAADCAQAAt4cAABUAAAAAAAAAAAAAAAAAAAAAAAAAMA4AAAAAAADfMwAAAAAAAAAA AAAAAAAAAAAAAAAAAAD6LwAAQAAAADowAAAEAAAA3zMAAAAAAADfMwAAAAAAALeHAAAAAAAA AAAAAAAAAABsDQAAAAAAAGwNAAAAAAAAxi0AAAAAAAAAAAAAAAAAABIuAADoAQAAzIcAABYA AAAHNwAAAAAAAAc3AAAAAAAABzcAAAAAAADfMwAAhAEAAGwNAABSAAAAxi0AAEwAAADgDQAA OAAAABIuAAAAAAAAkYcAAAAAAAAAAAAAAAAAAAc3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3zMAAAAAAACRhwAAAAAAAAAAAAAAAAAA BzcAAAAAAAAHNwAAEgMAACN9AAA0AgAAvg0AACIAAAAYDgAAGAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4MAAAAAAAASLgAA AAAAAIAsAAAMAAAAUEz3/UdnxwEAAAAAAAAAADArAAAAAAAAYzUAAKAAAABXfwAAPgAAAAAA AAAAAAAAXYYAADQBAADihwAAMAAAABKIAAAAAAAAlX8AAHoDAACMjgAAAAAAAAM2AACgAAAA jI4AAHwAAAAPgwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPgwAAWgEAAIyOAAAAAAAAAAAAAAAAAAAwDgAA AAAAAGmEAAD0AQAAPjAAAK4AAADsMAAAfAAAAAc3AAAAAAAAaDEAAGQAAADMMQAAEwIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPjAAAAAAAAA+MAAAAAAAAD4wAAAAAAAA t4cAAAAAAAC3hwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAozYAAGQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD4wAAAAAAAAPjAAAAAAAAA+MAAA AAAAABKIAAAAAAAA3zMAAAAAAADfMwAAAAAAAN8zAAAAAAAA3zMAAAAAAAAAAAAAAAAAAEQO AABkAAAAqA4AAAAAAACoDgAA5BIAAIwhAACkCQAARA4AAAAAAACoDgAAAAAAAKgOAAAAAAAA jCEAAAAAAABEDgAAAAAAAEQOAAAAAAAARA4AAAAAAABsDQAAAAAAAGwNAAAAAAAAbA0AAAAA AABsDQAAAAAAAGwNAAAAAAAAbA0AAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAElFRUUgUDgwMi4xMQtXaXJlbGVzcyBMQU5zDUxpYWlz b24gUmVzcG9uc2UgdG8gSUVURiBFQ1JJVCAHB0RhdGU6ICAyMDA3LTAzLTE1BwdBdXRob3Io cyk6BwdOYW1lB0NvbXBhbnkHQWRkcmVzcwdQaG9uZQdlbWFpbAcHRG9yb3RoeSBTdGFubGV5 B0FydWJhICBOZXR3b3JrcwcxMzIyIENyb3NzbWFuIEF2ZSANU3Vubnl2YWxlLCBDQQcrMSA2 MzAtMzYzLTEzODkHEyBIWVBFUkxJTksgIm1haWx0bzpkc3RhbmxleUBhcnViYW5ldHdvcmtz LmNvbSIgARRkc3RhbmxleUBhcnViYW5ldHdvcmtzLmNvbRUHB1N0ZXBoZW4gTWNDYW5uB1Nl aW1lbnMgUm9rZSBNYW5ub3IHUm9rZSBNYW5vciBSZXNlYXJjaCBMdGQNT2xkIFNhbGlzYnVy eSBMYW5lDVJvbXNleSxIYW1wc2hpcmUNU081MSAwWk4sIFVLBys0NCAxNzk0IDgzMzM0MQcT IEhZUEVSTElOSyAibWFpbHRvOnN0ZXBoZW4ubWNjYW5uQHJva2UuY28udWsiIAEUc3RlcGhl bi5tY2Nhbm5Acm9rZS5jby51axUgDQcHCA0IDEZyb206IFN0dWFydCBKLiBLZXJyeSAoEyBI WVBFUkxJTksgIm1haWx0bzpzdHVhcnRAb2stYnJpdC5jb20iIAEUc3R1YXJ0QG9rLWJyaXQu Y29tFSApLCBDaGFpciBJRUVFIDgwMi4xMSBXb3JraW5nIEdyb3VwDQ1UbzogQnJpYW4gQ2Fy cGVudGVyICgTIEhZUEVSTElOSyAibWFpbHRvOmJyY0B6dXJpY2guaWJtLmNvbSIgARRicmNA enVyaWNoLmlibS5jb20VICkgDQ1jYzogSGFubmVzIFRzY2hvZmVuaWcgKBMgSFlQRVJMSU5L ICJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldCIgARRIYW5uZXMuVHNjaG9mZW5p Z0BnbXgubmV0FSApIE1hcmMgTGluc25lciAoEyBIWVBFUkxJTksgIm1haWx0bzptYXJjLmxp bnNuZXJAY2lzY28uY29tIiABFG1hcmMubGluc25lckBjaXNjby5jb20VKSwgSm9uIFBldGVy c29uICgTIEhZUEVSTElOSyAibWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpeiIgARRq b24ucGV0ZXJzb25AbmV1c3Rhci5iaXoVKSwgQ3VsbGVuIEplbm5pbmdzICgTIEhZUEVSTElO SyAibWFpbHRvOmZsdWZmeUBjaXNjby5jb20iIAEUZmx1ZmZ5QGNpc2NvLmNvbRUpIA0NVGl0 bGU6IFJlc3BvbnNlIHRvIElFVEYgRUNSSVQgTGlhaXNvbiBSZXF1ZXN0IGZvciBSZXZpZXcg b2YgZHJhZnQtaWV0Zi1lY3JpdC1mcmFtZXdvcmstMDAudHh0DQ1QdXJwb3NlOiBUbyBwcm92 aWRlIElFRUUgODAyLjExIHJldmlldyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWVjcml0LWZy YW1ld29yay0wMC50eHQNDURlYXIgQnJpYW4gQ2FycGVudGVyLA0NSUVFRSA4MDIuMTEgaGFz IHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBJRVRGIEVDUklUIGNoYWlyLCBIYW5uZXMg VHNjaG9mZW5pZyB0byBwcm92aWRlIHJldmlldyBjb21tZW50cyBvbiB0aGUgSUVURiBFQ1JJ VCBpbnRlcm5ldCBkcmFmdCBkcmFmdC1pZXRmLWVjcml0LWZyYW1ld29yay0wMC50eHQuIElF RUUgODAyLjExIGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtZWNyaXQtZnJhbWV3b3JrLTAwLnR4 dCBhcmUgaW5jbHVkZWQgYXMgYW4gYXR0YWNobWVudCB0byB0aGlzIGRvY3VtZW50LiBJbiBh ZGRpdGlvbiB0byBwcm92aWRpbmcgdGhlIHJldmlldyBjb21tZW50cywgdGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgdHdvIGFyZWFzIGluIHdoaWNoIHRoZSBJRUVFIDgwMi4xMSBlbWVyZ2Vu Y3kgY2FsbCBzdXBwb3J0IGludGVyZmFjZXMgd2l0aCBlZmZvcnRzIGluIHRoZSBJRVRGLg0N Rmlyc3QsIHRoZXJlIGFyZSB0d28gcHJvY2VkdXJlcyB0byBlbmFibGUgZW1lcmdlbmN5IGNh bGxzIGF0IHRoZSBsaW5rIGxheWVyIGN1cnJlbnRseSBiZWluZyBjb25zaWRlcmVkIGluIElF RUUgODAyLjExOiANDUFuICJlbWVyZ2VuY3kgc2VydmljZXMgb25seSIgcHJvY2VkdXJlIHRo YXQgcHJvdmlkZXMgYWNjZXNzIHRvIHRoZSBjbGllbnQgd2l0aCBubyBsaW5rIGxheWVyIHNl Y3VyaXR5IGZlYXR1cmVzIGVuYWJsZWQuICANQSBzZWN1cmUgcHJvY2VkdXJlIHByb3ZpZGlu ZyBjbGllbnQgYWNjZXNzIHdpdGggbGluay1sYXllciBzZWN1cml0eSwgdXNpbmcgYW4gYWR2 ZXJ0aXNlZCBlbWVyZ2VuY3kgc2VydmljZXMgTmV0d29yayBBY2Nlc3MgSWRlbnRpZmllciAo TkFJKSB0byB0cmlnZ2VyIGVtZXJnZW5jeSBjYWxsIGhhbmRsaW5nIChzZWUgEyBIWVBFUkxJ TksgImZ0cDovL2Z0cC44MDJ3aXJlbGVzc3dvcmxkLmNvbS8xMS8wNy8xMS0wNy0wMjkwLTAy LTAwMHUtZW1lcmdlbmN5LWNhbGwtc2V0dXAucHB0IiABFGZ0cDovL2Z0cC44MDJ3aXJlbGVz c3dvcmxkLmNvbS8xMS8wNy8xMS0wNy0wMjkwLTAyLTAwMHUtZW1lcmdlbmN5LWNhbGwtc2V0 dXAucHB0FSApLiANDVRoZSBzZWN1cmUgcHJvY2VkdXJlIHVzZXMgRXh0ZW5zaWJsZSBBdXRo ZW50aWNhdGlvbiBQcm90b2NvbCAoRUFQKS4gQSBtZWNoYW5pc20gaXMgcHJvdmlkZWQgdG8g ZW5hYmxlIHRoZSBjbGllbnQgdG8gZGlzY292ZXIgdGhlIGFwcHJvcHJpYXRlIEVBUCBtZXRo b2QgdG8gdXNlIGJlZm9yZSBjb21tZW5jaW5nIHRoZSBhdXRoZW50aWNhdGlvbiBoYW5kc2hh a2UsIHRvIGVsaW1pbmF0ZSBwb3RlbnRpYWwgZGVsYXlzIGR1ZSB0byBFQVAgbWV0aG9kIG5l Z290aWF0aW9uLiAgVGhlIGN1cnJlbnQgYXBwcm9hY2ggdG8gYWR2ZXJ0aXNlIEVBUCBtZXRo b2Qgc3VwcG9ydCBpcyB2aWEgYW4gSUVFRSA4MDIuMTEgZGVmaW5lZCBhZHZlcnRpc2VtZW50 IHNlcnZpY2UuDQ1TZWNvbmRseSwgSUVFRSA4MDIuMTEgVEd1IGhhcywgYXMgcGFydCBvZiBp dHMgZW1lcmdlbmN5IHNlcnZpY2VzIHN1cHBvcnQsIGRlZmluZWQgQ2l2aWMgYW5kIEdlb2xv Y2F0aW9uIE1JQiBhdHRyaWJ1dGVzLCBiYXNlZCBvbiBkcmFmdC1pZXRmLWdlb3ByaXYtcmV2 aXNlZC1jaXZpYy1sby0wNS50eHQgZGVmaW5pdGlvbnMsIHNlZSATIEhZUEVSTElOSyAiZnRw Oi8vZnRwLjgwMndpcmVsZXNzd29ybGQuY29tLzExLzA3LzExLTA3LTAyNzQtMDEtMDAwdS1z c3BuLWludGVyZmFjZS1pbnRlcm5hbC1jb21tZW50LXJlc29sdXRpb24uZG9jIiABFGZ0cDov L2Z0cC44MDJ3aXJlbGVzc3dvcmxkLmNvbS8xMS8wNy8xMS0wNy0wMjc0LTAxLTAwMHUtc3Nw bi1pbnRlcmZhY2UtaW50ZXJuYWwtY29tbWVudC1yZXNvbHV0aW9uLmRvYxUgLg0NUGxlYXNl IGNvbnRhY3QgU3R1YXJ0IEouIEtlcnJ5LCBJRUVFIDgwMi4xMSBXb3JraW5nIEdyb3VwIGNo YWlyLCB0b2dldGhlciB3aXRoIERvcm90aHkgU3RhbmxleSwgSUVFRSA4MDIuMTEgdG8gSUVU RiBMaWFpc29uLCBhbmQgU3RlcGhlbiBNY0Nhbm4sIFRHdSBjaGFpciwgd2l0aCBhbnkgcXVl c3Rpb25zLg0NQmVzdCBSZWdhcmRzLA0NDQ1TdHVhcnQgSi4gS2VycnkNDUF0dHM6IENvbnRh Y3QgSW5mb3JtYXRpb24NTGlzdCBvZiBjb21lbnRzDQ1Db250YWN0IGluZm9ybWF0aW9uOiAN U3R1YXJ0IEouIEtlcnJ5DRMgSFlQRVJMSU5LICJtYWlsdG86c3R1YXJ0LmtlcnJ5QHBoaWxp cHMuY29tIiABFHN0dWFydC5rZXJyeUBwaGlsaXBzLmNvbRUgIA0rMSA0MDggNDc0IDczNTYN DURvcm90aHkgU3RhbmxleQ0TIEhZUEVSTElOSyAibWFpbHRvOmRzdGFubGV5QGFydWJhbmV0 d29ya3MuY29tIiABFGRzdGFubGV5QGFydWJhbmV0d29ya3MuY29tFQ0rMSA2MzAgMzYzIDEz ODkNDVN0ZXBoZW4gTWNDYW5uDRMgSFlQRVJMSU5LICJtYWlsdG86c3RlcGhlbi5tY2Nhbm5A cm9rZS5jby51ayIgARRzdGVwaGVuLm1jY2FubkByb2tlLmNvLnVrFSANKzQ0IDE3OTQgODMz MzQxDQ1JRUVFIDgwMi4xMSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLWVjcml0LWZyYW1ld29y ay0wMC50eHQNDUFic3RyYWN0IJYgVGhlIGxpc3Qgb2YgZW1lcmdlbmN5IHNlcnZpY2VzIGNv bXBvbmVudHMgaXMgbGlzdGVkIGluIHRoZSBBYnN0cmFjdC4gIFRoZSBjb21wb25lbnQgdG8g k2RldGVybWluZSB0aGUgY2FsbGVyknMgbnVtYmVyLCBmb3IgY2FsbGJhY2sgcHVycG9zZXOU IGlzIG5vdCBsaXN0ZWQuIElzIHRoaXMgY29tcG9uZW50IHByb3ZpZGVkPw0NU2VjdGlvbiAx LCBsYXN0IHNlbnRlbmNlLCBjaGFuZ2UgkzgwMi4xMZQgdG8gk0lFRUUgODAyLjExlC4NDSBT ZWN0aW9uIDIsIHNlY29uZCBwYXJhZ3JhcGggbGlzdCBvZiBkaWZmZXJlbmNlcy4gU3VnZ2Vz dCBjbGFyaWZ5aW5nIHRoYXQgdGhlc2UgYXJlIGF0dHJpYnV0ZXMgb3IgY2hhcmFjdGVyaXN0 aWNzIG9mIGFuIElQLWJhc2VkIHRlbGVwaG9ueSBzeXN0ZW0gd2hpY2ggYXJlIG5vdCBwcmVz ZW50IGluIHRoZSBQU1ROLg0NU2VjdGlvbiAyLCA1dGggcGFyYWdyYXBoLCBzdWdnZXN0IGNo YW5naW5nIJNkb2VzIG5vdCByZXNwZWN0IG5hdGlvbmFsIGJvdW5kYXJpZXOUIHRvIJNjcm9z c2VzIG5hdGlvbmFsIGJvdW5kYXJpZXOULiBBbHNvIGNoYW5nZSCTZXF1aXBtZW50IGFuZCBz b2Z0d2FyZSByZXF1aXJlZJQgdG8gk2VxdWlwbWVudCBhbmQgc29mdHdhcmUgYXJlIHJlcXVp cmVklC4NDVNlY3Rpb24gMywgZmlyc3QgcGFyYWdyYXBoIGJlbmVhdGggdGhlIGxpc3Q6IFN1 Z2dlc3QgY2hhbmdpbmcgk2xvY2F0aW9ulCB0byCTbG9jYXRpb24gZGF0YZQuIFRoZSB0ZXJt cyCTbG9jYXRpb24gZGF0YZQgk2xvY2F0aW9uIGluZm9ybWF0aW9ulCBhbmQgk2xvY2F0aW9u lCBzZWVtIHRvIGJlIHVzZWQgc3lub25vbW91c2x5IGluIHRoZSBkcmFmdC4gU3VnZ2VzdCB1 c2luZyBvbmUgdGVybS4gQWxzbyBpbiB0aGUgZmlyc3Qgc2VudGVuY2UsIGNoYW5nZSCTaG9t ZSBvciB2aXNpdGVkIGlzIGRldGVjdGVklCB0byCTaG9tZSBvciB2aXNpdGVkIGRpYWwgc3Ry aW5nIGlzIGRldGVjdGVklC4NDVNlY3Rpb24gMywgdGhlIGZpcnN0IHNlbnRlbmNlIGRlc2Ny aWJlcyBhIGNhc2UgaW4gd2hpY2ggdGhlIJNVQSByZWNlaXZlcyBtZWFzdXJlZCBsb2NhdGlv biBmcm9tIHRoZSBuZXR3b3JrlCwgYWxzbyBpbiBzZWN0aW9uIDUuMy4gTm90ZSB0aGF0IHRo ZSBJRUVFIDgwMi4xMWsgYW5kIElFRUUgODAyLjExdiBhbWVuZG1lbnRzIGN1cnJlbnRseSB1 bmRlciBkZXZlbG9wbWVudCBhcmUgYWRkaW5nIHRoZSBhYmlsaXR5IHRvIHN1cHBvcnQgbG9j YXRpb24gZGV0ZXJtaW5hdGlvbiBhbmQgbG9jYXRpb24gZGF0YSBleGNoYW5nZS4NDVNlY3Rp b24gMywgNHRoIHBhcmFncmFwaCwgc3VnZ2VzdCBjaGFuZ2luZyCTZGlhbHN0cmluZ5QgdG8g k2RpYWwgc3RyaW5nlCBoZXJlIGFuZCB0aHJvdWdob3V0IHRoZSBzcGVjaWZpY2F0aW9uLg0N U2VjdGlvbiA1LjIsIHNlY29uZCBwYXJhZ3JhcGgsIGNoYW5nZSCTbW9yZSBmaW5lciBncmFp bmVkIGluZm9ybWF0aW9ulCB0byCTbW9yZSBmaW5lbHkgZ3JhaW5lZJQgYW5kIGNoYW5nZSCT cG9zdGFsIGFkZHJyZXNzlCB0byCTcG9zdGFsIGFkZHJlc3OUIGFuZCCTcm9vbSBjdWJpY2xl lCB0byCTcm9vbSBvciBjdWJpY2xllCBhbmQgk2RhdHVtc5QgdG8gk2RhdHVtlC4gSW4gdGhl IDNyZCBwYXJhZ3JhcGgsIHRoZSB0ZXJtIJNXR1M4NJQgaXMgbm90IGRlZmluZWQsIGFsc28g QS1HUFMgYW5kIFdBQVMgaW4gc2VjdGlvbiA1LjMuMyBhcmUgbm90IGRlZmluZWQuDQ1TZWN0 aW9uIDUuMy4yLCBzZWNvbmQgcGFyYWdyYXBoLiBTdWdnZXN0IGluc2VydGluZyB0aGUgZm9s bG93aW5nIHNlbnRlbmNlIGFmdGVyIHRoZSBmaXJzdCBzZW50ZW5jZSBvZiB0aGUgcGFyYWdy YXBoOiCTSG93ZXZlciwgdGhpcyBtYXkgbm90IGJlIHRydWUgZm9yIGxhcmdlciBzY2FsZSBz eXN0ZW1zIHN1Y2ggYXMgSUVFRSA4MDIuMTYgYW5kIElFRUUgODAyLjIyIHdoaWNoIHR5cGlj YWxseSBoYXZlIGxhcmdlciBjZWxscyB0aGFuIHRob3NlIG9mIElFRUUgODAyLjExLpQgU3Vn Z2VzdCBpbnNlcnRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5jZSBhdCB0aGUgZW5kIG9mIHRo ZSBzZWNvbmQgcGFyYWdyYXBoOiCTSG93ZXZlciwgdGhlIGNpdmljIGxvY2F0aW9uIG9mIGFu IElFRUUgODAyLjE2IGJhc2Ugc3RhdGlvbiBtYXkgYmUgb2YgbGl0dGxlIHVzZSB0byBlbWVy Z2VuY3kgcGVyc29ubmVslC4NDVNlY3Rpb24gNS4zLjMsIGZpcnN0IHBhcmFncmFwaCwgc3Vn Z2VzdCBjaGFuZ2luZyCTR1BTIHRlY2hub2xvZ3kgaXMgaW1wcm92aW5nlCB0byCTR1BTIHRl Y2hub2xvZ3kgaXMgaW1wcm92aW5nIChlLmcuIEdhbGlsZW8plC4NDVNlY3Rpb24gNS40LCBz dWdnZXN0IGNoYW5naW5nIJNWYWx1ZSBjYW4gZml4ZWQgYXQgdGltZSBvZiBkZXJlZmVyZW5j ZS4gIFZhbHVlIGNhbm5vdCBiZSBjaGFuZ2VkIGJ5IGVuZHBvaW50lCB0byCTVGhlIHZhbHVl IGNhbiBiZSBmaXhlZCBhdCB0aW1lIG9mIGRlcmVmZXJlbmNlLiAgVGhlIHZhbHVlIGNhbm5v dCBiZSBjaGFuZ2VkIGJ5IHRoZSBlbmRwb2ludJQuDQ1TZWN0aW9uIDUuNSwgc2Vjb25kIHBh cmFncmFwaC4gQ29tbWVudDogTExEUC1NRUQgZXh0ZW5zaW9ucyBtYXkgYmUgcmVxdWlyZWQg Zm9yIHdpcmVsZXNzIGFjY2VzcyBuZXR3b3Jrcy4NDVNlY3Rpb24gNS43LiBDb21tZW50OiBB bm90aGVyIHVzZSBjYXNlIG1lbnRpb25lZCwgd2hlcmUgY2l2aWMgbG9jYXRpb24gbWF5IGJl IG1lYW5pbmdsZXNzIGlzIGEgeWFjaHQgKG9mZi1zaG9yZSkgd2hpY2ggaGFzIHdpcmVsZXNz IGFjY2VzcyB0byBsYW5kLg0NU2VjdGlvbiA1LjguIENvbW1lbnQ6IElFRUUgODAyLjIxIGlz IGNvbnNpZGVyaW5nIHN1Y2ggYW4gSW5mb3JtYXRpb24gU2VydmVyLCB3aGljaCBjb3VsZCBi ZSB1c2VkIGZvciB0aGlzIHB1cnBvc2UuDQ1TZWN0aW9uIDYsIJNNZWRpYSBDYXBhYmlsaXRp ZXMgb2YgQ2FsbGVylCBsaXN0IGl0ZW0sIGxhc3Qgc2VudGVuY2UsIHN1Z2dlc3QgY2hhbmdp bmcgk2NhbGxlZZQgdG8gk2NhbGxlcpQuDQ1TZWN0aW9uIDcuIENvbW1lbnQ6IEFueSBzaWdu YWxpbmcgb2YgZW1lcmdlbmN5IGNhbGxzIHdoaWxlIGluIGEgc3RhdGlvbpJzIElFRUUgODAy LjExIHVuLWF1dGhlbnRpY2F0ZWQgc3RhdGUgd2lsbCBiZSBpbiBjbGVhciB0ZXh0LCBhcyBh IHNlY3VyaXR5IGFzc29jaWF0aW9uIGlzIG5vdCB5ZXQgZXN0YWJsaXNoZWQuIFRoZSBjdXJy ZW50IHZpZXcgaXMgdGhhdCB0aGlzIGlzIGEgbmVjZXNzYXJ5IGV2aWwsIHRvIGFsbG93IGVt ZXJnZW5jeSBjYWxscyB0byBiZSBwb3NzaWJsZSBpbiBhbGwgY2lyY3Vtc3RhbmNlcywgaW5j bHVkaW5nIGZvciBleGFtcGxlIHByaW9yIHRvIHRoZSBjb21wbGV0aW9uIG9mIElFRUUgODAy LjExIHNlY3VyaXR5IGFzc29jaWF0aW9uIGVzdGFibGlzaG1lbnQuIEVtZXJnZW5jeSBzZXJ2 aWNlcyBvcGVyYXRpb24gaW4gdGhlIElFRUUgODAyLjExIHVuLWF1dGhlbnRpY2F0ZWQgc3Rh dGUgaW1wYWN0cyBTZWN0aW9uIDE2IChTZWN1cml0eSBDb25zaWRlcmF0aW9ucykuDQ1TZWN0 aW9uIDkuIENvbW1lbnQ6IEluY2x1c2lvbiBvZiBhIENhbGwtQmFjayBJZGVudGlmaWVyIGhh cyBub3QgYmVlbiBjb25zaWRlcmVkIGluIElFRUUgODAyLjExIGF0IHRoaXMgdGltZS4NDVJl c29sdmUgkz8/lCwgcmVmZXJlbmNlcyBhbmQgk1RCRJQgdGhyb3VnaG91dC4NDQMNDQQNDQMN DQQNDU1hcmNoIDIwMDcJCRMgVElUTEUgIFwqIE1FUkdFRk9STUFUIBRkb2MuOiBJRUVFIDgw Mi4xMS0wNy8wNDc2cjEVDQ0TIFNVQkpFQ1QgIFwqIE1FUkdFRk9STUFUIBRTdWJtaXNzaW9u FQlwYWdlIBNwYWdlIBQxFQkTIENPTU1FTlRTICBcKiBNRVJHRUZPUk1BVCAURG9yb3RoeSBT dGFubGV5LCBBcnViYSBOZXR3b3JrcxUNDQ0NTm90aWNlOiBUaGlzIGRvY3VtZW50IGhhcyBi ZWVuIHByZXBhcmVkIHRvIGFzc2lzdCBJRUVFIDgwMi4xMS4gSXQgaXMgb2ZmZXJlZCBhcyBh IGJhc2lzIGZvciBkaXNjdXNzaW9uIGFuZCBpcyBub3QgYmluZGluZyBvbiB0aGUgY29udHJp YnV0aW5nIGluZGl2aWR1YWwocykgb3Igb3JnYW5pemF0aW9uKHMpLiAgVGhlIG1hdGVyaWFs IGluIHRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBjaGFuZ2UgaW4gZm9ybSBhbmQgY29u dGVudCBhZnRlciBmdXJ0aGVyIHN0dWR5LiBUaGUgY29udHJpYnV0b3IocykgcmVzZXJ2ZShz KSB0aGUgcmlnaHQgdG8gYWRkLCBhbWVuZCBvciB3aXRoZHJhdyBtYXRlcmlhbCBjb250YWlu ZWQgaGVyZWluLg0NUmVsZWFzZTogVGhlIGNvbnRyaWJ1dG9yIGdyYW50cyBhIGZyZWUsIGly cmV2b2NhYmxlIGxpY2Vuc2UgdG8gdGhlIElFRUUgdG8gaW5jb3Jwb3JhdGUgbWF0ZXJpYWwg Y29udGFpbmVkIGluIHRoaXMgY29udHJpYnV0aW9uLCBhbmQgYW55IG1vZGlmaWNhdGlvbnMg dGhlcmVvZiwgaW4gdGhlIGNyZWF0aW9uIG9mIGFuIElFRUUgU3RhbmRhcmRzIHB1YmxpY2F0 aW9uOyB0byBjb3B5cmlnaHQgaW4gdGhlIElFRUWScyBuYW1lIGFueSBJRUVFIFN0YW5kYXJk cyBwdWJsaWNhdGlvbiBldmVuIHRob3VnaCBpdCBtYXkgaW5jbHVkZSBwb3J0aW9ucyBvZiB0 aGlzIGNvbnRyaWJ1dGlvbjsgYW5kIGF0IHRoZSBJRUVFknMgc29sZSBkaXNjcmV0aW9uIHRv IHBlcm1pdCBvdGhlcnMgdG8gcmVwcm9kdWNlIGluIHdob2xlIG9yIGluIHBhcnQgdGhlIHJl c3VsdGluZyBJRUVFIFN0YW5kYXJkcyBwdWJsaWNhdGlvbi4gIFRoZSBjb250cmlidXRvciBh bHNvIGFja25vd2xlZGdlcyBhbmQgYWNjZXB0cyB0aGF0IHRoaXMgY29udHJpYnV0aW9uIG1h eSBiZSBtYWRlIHB1YmxpYyBieSBJRUVFIDgwMi4xMS4NDVBhdGVudCBQb2xpY3kgYW5kIFBy b2NlZHVyZXM6IFRoZSBjb250cmlidXRvciBpcyBmYW1pbGlhciB3aXRoIHRoZSBJRUVFIDgw MiBQYXRlbnQgUG9saWN5IGFuZCBQcm9jZWR1cmVzIDwTIEhZUEVSTElOSyAiaHR0cDovLyUy MGllZWU4MDIub3JnL2d1aWRlcy9ieWxhd3Mvc2ItYnlsYXdzLnBkZiIgXHQgIl9wYXJlbnQi IBRodHRwOi8vIGllZWU4MDIub3JnL2d1aWRlcy9ieWxhd3Mvc2ItYnlsYXdzLnBkZhU+LCBp bmNsdWRpbmcgdGhlIHN0YXRlbWVudCAiSUVFRSBzdGFuZGFyZHMgbWF5IGluY2x1ZGUgdGhl IGtub3duIHVzZSBvZiBwYXRlbnQocyksIGluY2x1ZGluZyBwYXRlbnQgYXBwbGljYXRpb25z LCBwcm92aWRlZCB0aGUgSUVFRSByZWNlaXZlcyBhc3N1cmFuY2UgZnJvbSB0aGUgcGF0ZW50 IGhvbGRlciBvciBhcHBsaWNhbnQgd2l0aCByZXNwZWN0IHRvIHBhdGVudHMgZXNzZW50aWFs IGZvciBjb21wbGlhbmNlIHdpdGggYm90aCBtYW5kYXRvcnkgYW5kIG9wdGlvbmFsIHBvcnRp b25zIG9mIHRoZSBzdGFuZGFyZC4iICBFYXJseSBkaXNjbG9zdXJlIHRvIHRoZSBXb3JraW5n IEdyb3VwIG9mIHBhdGVudCBpbmZvcm1hdGlvbiB0aGF0IG1pZ2h0IGJlIHJlbGV2YW50IHRv IHRoZSBzdGFuZGFyZCBpcyBlc3NlbnRpYWwgdG8gcmVkdWNlIHRoZSBwb3NzaWJpbGl0eSBm b3IgZGVsYXlzIGluIHRoZSBkZXZlbG9wbWVudCBwcm9jZXNzIGFuZCBpbmNyZWFzZSB0aGUg bGlrZWxpaG9vZCB0aGF0IHRoZSBkcmFmdCBwdWJsaWNhdGlvbiB3aWxsIGJlIGFwcHJvdmVk IGZvciBwdWJsaWNhdGlvbi4gIFBsZWFzZSBub3RpZnkgdGhlIENoYWlyIDwTIEhZUEVSTElO SyAibWFpbHRvOnN0dWFydEBvay1icml0LmNvbSIgARRzdHVhcnRAb2stYnJpdC5jb20VPiBh cyBlYXJseSBhcyBwb3NzaWJsZSwgaW4gd3JpdHRlbiBvciBlbGVjdHJvbmljIGZvcm0sIGlm IHBhdGVudGVkIHRlY2hub2xvZ3kgKG9yIHRlY2hub2xvZ3kgdW5kZXIgcGF0ZW50IGFwcGxp Y2F0aW9uKSBtaWdodCBiZSBpbmNvcnBvcmF0ZWQgaW50byBhIGRyYWZ0IHN0YW5kYXJkIGJl aW5nIGRldmVsb3BlZCB3aXRoaW4gdGhlIElFRUUgODAyLjExIFdvcmtpbmcgR3JvdXAuIElm IHlvdSBoYXZlIHF1ZXN0aW9ucywgY29udGFjdCB0aGUgSUVFRSBQYXRlbnQgQ29tbWl0dGVl IEFkbWluaXN0cmF0b3IgYXQgPBMgSFlQRVJMSU5LICJtYWlsdG86cGF0Y29tQGllZWUub3Jn IiBcdCAiX3BhcmVudCIgFHBhdGNvbUBpZWVlLm9yZxU+Lg0NQWJzdHJhY3QNVGhlIElFVEYg RUNSSVQgV29ya2luZyBHcm91cCBoYXMgcmVxdWVzdGVkIHRoYXQgdGhlIElFRUUgODAyLjEx IFdvcmtpbmcgR3JvdXAgcmV2aWV3IGFuZCBwcm92aWRlIGNvbW1lbnRzIG9uIHRoZSBJRVRG IEVDUklUIGRyYWZ0LWlldGYtZWNyaXQtZnJhbWV3b3JrLTAwIGludGVybmV0IGRyYWZ0LCBh dmFpbGFibGUgYXQgEyBIWVBFUkxJTksgImh0dHA6Ly90b29scy5pZXRmLm9yZy93Zy9lY3Jp dC9kcmFmdC1pZXRmLWVjcml0LWZyYW1ld29yay9kcmFmdC1pZXRmLWVjcml0LWZyYW1ld29y ay0wMC50eHQiIFx0ICJfcGFyZW50IiAUaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2Vjcml0 L2RyYWZ0LWlldGYtZWNyaXQtZnJhbWV3b3JrL2RyYWZ0LWlldGYtZWNyaXQtZnJhbWV3b3Jr LTAwLnR4dBUuDQ1UaGlzIGRvY3VtZW50IGNvbnRhaW5zIHRoZSBsaWFpc29uIHJlc3BvbnNl IHRvIHRoYXQgcmVxdWVzdC4gIA0NLg0NDQ0NDQ0NDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAbCAAAKwgAAC4IAAAvCAAAMwgAADQI AAA5CAAAPAgAAEEIAABGCAAARwgAAEoIAABLCAAATQgAAE4IAABPCAAAWggAAFsIAAB9CAAA jAgAAI0IAACcCAAAnQgAAL0IAAC+CAAAzQgAAM4IAADPCAAA/ggAAP8IAAAACQAAGgkAABsJ AAAcCQAAHQkAAEAJAACICQAAiQkAAJgJAAD8+PT88Pzs/Obf2NHK0eb85vzmw9/D38Pfw9+3 sKC3lbeO/Id+dWsAAAAAAAAAAAAAAAAAAAATFWg6VscAFmg6VscANQiBQ0oUABAVaDpWxwAW aJVvPABDShQAABAVaDpWxwAWaDpWxwBDShQAAA0WaJVvPAA1CIFDShQADRZoHjL1ADUIgUNK EAAUFWgpD/wAFmjrZw4AMEoVAENKEAAAHwIIgQNqfgIAAAYIARVoKQ/8ABZo62cOAENKEABV CAENFmjrZw4ANQiBQ0oQABYDagAAAAAWaOtnDgA1CIFDShAAVQgBAA0WaNEQHgA1CIFDShQA DRZoBg50ADUIgUNKFAANFmg6VscANQiBQ0oUAA0WaCB/NgA1CIFDShQADRZoHjL1ADUIgUNK FAAKFmgeMvUAQ0oUAAAGFmgSC7cAAAYWaBMXUAAABhZoKnnpAAAGFmjrZw4AAAYWaB4y9QAn AAYAABsIAAA7CAAAPAgAAE4IAADzAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAIUAAAAAAAAA AAAAAAB7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAChIAD4QAABYkAUlmAQAAAF6EAAAAZAAA a2QAAAAAFiQBFyQBSWYBAAAAAFQBAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAH lOUBCNYaAAGU//wkgAZoJQAAAAAAAAAAAAAAAAAAAAAT1jAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABf2AwAAGPYDAAAa1gQAAAD/G9YE AAAA/xzWBAAAAP8d1gQAAAD/NNYGAAEKA2wAYfYDAACKVAEACRIAFiQBSWYBAAAAZ2TREB4A DBEAFKTwACZkBgEAAFDGCAAAAP8GAQAAAAQABgAA/iQAAMMlAAAZMAAAHjAAAP7+/v4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBBE4I AABPCAAAWggAAFsIAACaAAAAAAAAAAAAAAAAhwAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAABlAABrZBQBAAAWJAEXJAFJZgEAAAAAVAEAApZsAAM0AQXWGAQBAAAEAQAA BAEAAAQBAAAEAQAABAEAAAjWGgABlP/8JIAGaCUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQB AAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAX9gMAABj2 AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zTWBgABCgNsAGH2AwAAZjQBilQBABMS AAMkAA6EAAAPhAAAFKQAABYkAUlmAQAAAF2EAABehAAAYSQAAGQAAGtkigAAABYkARckAUlm AQAAAABUAQAClmwABdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAAB5RnAQjWGgABlP/8JIAG aCUAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAFPYBAAAX9gMAABj2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYE AAAA/zTWBgABCgNsAGH2AwAAilQBAAADWwgAAGAIAABoCAAAcAgAAHYIAAB8CAAAfQgAAOwA AAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAA AAAAAAAAAAAAPQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArgAAa2SgAQAAFiQBFyQB SWYBAAAAAFQBAAKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1nIABZT/zATcDNoX jR78JIAGOAUAAAAAAAAAAAAAAAAAAAAAgAYQCAAAAAAAAAAAAAAAAAAAAACABv4KAAAAAAAA AAAAAAAAAAAAAIAGswYAAAAAAAAAAAAAAAAAAAAAgAZvBgAAAAAAAAAAAAAAAAAAAAAT1jAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABf2 AwAAGPYDAAAa1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xvWFAAAAP8AAAD/AAAA/wAAAP8AAAD/ HNYUAAAA/wAAAP8AAAD/AAAA/wAAAP8d1hQAAAD/AAAA/wAAAP8AAAD/AAAA/zTWBgABCgNs AGH2AwAAilQBABMSAAMkAA6EAAAPhAAAFKQAABYkAUlmAQAAAF2EAABehAAAYSQAAAZ9CAAA jQgAAJ0IAACwCAAAvggAAM4IAAAcCQAAHQkAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAEAA AAAAAAAAAAAAAAAAAAAAAACuAABrZG0DAAAWJAEXJAFJZgEAAAAAVAEAApZsAAXWGAQBAAAE AQAABAEAAAQBAAAEAQAABAEAAAjWcgAFlP/MBNwM2heNHvwkgAY4BQAAAAAAAAAAAAAAAAAA AACABhAIAAAAAAAAAAAAAAAAAAAAAIAG/goAAAAAAAAAAAAAAAAAAAAAgAazBgAAAAAAAAAA AAAAAAAAAACABm8GAAAAAAAAAAAAAAAAAAAAABPWMAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEA AAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAABT2AQAAF/YDAAAY9gMAABrWFAAAAP8AAAD/AAAA /wAAAP8AAAD/G9YUAAAA/wAAAP8AAAD/AAAA/wAAAP8c1hQAAAD/AAAA/wAAAP8AAAD/AAAA /x3WFAAAAP8AAAD/AAAA/wAAAP8AAAD/NNYGAAEKA2wAYfYDAACKVAEAEBIADoQAAA+EAAAU pAAAFiQBSWYBAAAAXYQAAF6EAAAABx0JAAAsCQAAQAkAAFgJAABrCQAAfAkAAIkJAACZCQAA 5gkAAOcJAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAA AAAAAAAA4wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA2gAAAAAAAAAA AAAAAO8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAWJAFJZgEAAABnZDpWxwAMAAADJAEWJAFJ ZgEAAABhJAFnZDpWxwAQEgAOhAAAD4QAABSkAAAWJAFJZgEAAABdhAAAXoQAAAAJmAkAAJkJ AACaCQAAyAkAAMkJAADKCQAA4wkAAOQJAADmCQAA5wkAAOgJAADpCQAA6gkAAOsJAADsCQAA 8gkAAAIKAAADCgAABAoAABcKAAApCgAAKwoAACwKAAAtCgAAPwoAAEAKAABlCgAA9eTYxOS2 5NivqpyWnIiCfHZsfGN8U2xIbHYAAAAAAAAAAAAAFBVotyWZABZo1ECxADBKFQBDShgAAB8C CIEDahQGAAAGCAEVaLclmQAWaNRAsQBDShgAVQgBEBVo1ECxABZo1ECxAENKGAAAEwNqAAAA ABZo1ECxAENKGABVCAEKFmgeMvUAQ0oYAAAKFmjUQLEAQ0oYAAAKFmjkdMoAQ0oYAAAaFmge MvUAQ0ocAE9KAgBRSgIAXkoCAGFKHAAAChZoHjL1AENKFgAAGgNqAAAAABZoHjL1AFUIAW1I AARuSAAEdQgBAAkWaJVvPAA1CIENFmiVbzwANQiBQ0oQABsVaDpWxwAWaDpWxwAwShUANQiB Q0oQAGFKEAAmAgiBA2pLBAAABggBFWg6VscAFmg6VscANQiBQ0oQAFUIAWFKEAAAFxVoOlbH ABZoOlbHADUIgUNKEABhShAAIANqAAAAABVoOlbHABZoOlbHADUIgUNKEABVCAFhShAAABMV aDpWxwAWaJVvPAA1CIFDShQAABrnCQAA6AkAAOoJAABkCgAAZQoAALsKAAC8CgAAUAAAAAAA AAAAAAAAAEwAAAAAAAAAAAAAAABJAAAAAAAAAAAAAAAAQwAAAAAAAAAAAAAAAD8AAAAAAAAA AAAAAAA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAyIAFKQAAAAFAAARhNAC YITQAgMAAEAmAAADEQAUpHgAAK4AAGtkNgUAABYkARckAUlmAQAAAABUAQAClmwABdYYBAEA AAQBAAAEAQAABAEAAAQBAAAEAQAACNZyAAWU/8wE3AzaF40e/CSABjgFAAAAAAAAAAAAAAAA AAAAAIAGEAgAAAAAAAAAAAAAAAAAAAAAgAb+CgAAAAAAAAAAAAAAAAAAAACABrMGAAAAAAAA AAAAAAAAAAAAAIAGbwYAAAAAAAAAAAAAAAAAAAAAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8E AQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAX9gMAABj2AwAAGtYUAAAA/wAAAP8A AAD/AAAA/wAAAP8b1hQAAAD/AAAA/wAAAP8AAAD/AAAA/xzWFAAAAP8AAAD/AAAA/wAAAP8A AAD/HdYUAAAA/wAAAP8AAAD/AAAA/wAAAP801gYAAQoDbABh9gMAAIpUAQAABmUKAABpCgAA bwoAAHoKAAB7CgAAjgoAAKAKAACiCgAAowoAAKQKAAC2CgAAtwoAALgKAAC5CgAAugoAALwK AAC/CgAAwAoAANEKAADTCgAA1AoAAAILAAADCwAABAsAAB0LAAAeCwAAHwsAAPfx6N7Yz9i/ 3rTe2Oiu8Z+QgZBxgVtxSnGBAAAAAAAAAAAAAAAAAAAgFWgIXYIAFmgIXYIAMEoVAENKGABh ShgAbUgUBHNIFAQAKwIIgQNqsgcAAAYIARVoCClUABZoCF2CAENKGABVCAFhShgAbUgJBHNI CQQfA2oAAAAAFmgIXYIAQ0oYAFUIAWFKGABtSAkEc0gJBBwVaAhdggAWaAhdggBDShgAYUoY AG1IFARzSBQEABwVaAhdggAWaOR0ygBDShgAYUoYAG1IFARzSBQEABwVaAhdggAWaBszdABD ShgAYUoYAG1IFARzSBQEAAoWaOR0ygBDShgAABQVaAlQ8QAWaJRp6AAwShUAQ0oYAAAfAgiB A2rjBgAABggBFWgJUPEAFmiUaegAQ0oYAFUIARAVaBszdAAWaJRp6ABDShgAAAoWaJRp6ABD ShgAABMDagAAAAAWaJRp6ABDShgAVQgBEBVoGzN0ABZoGzN0AENKGAAAChZoGzN0AENKGAAA EBVoExdQABZoHjL1AENKGAAaHwsAACELAAAtCwAALwsAADALAABbCwAAXAsAAF0LAABzCwAA dAsAAIULAACGCwAAmQsAALELAACzCwAAtAsAALULAADNCwAAzgsAAOALAADx4tPD4q3DnMPi jIBxgFuMSow+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYWaAhdggBDShgAYUoYAG1IFARz SBQEACAVaAgpVAAWaN816QAwShUAQ0oYAGFKGABtSBQEc0gUBAArAgiBA2p8CQAABggBFWgI KVQAFmjfNekAQ0oYAFUIAWFKGABtSBQEc0gUBBwVaAhdggAWaN816QBDShgAYUoYAG1IFARz SBQEABYWaN816QBDShgAYUoYAG1IFARzSBQEAB8DagAAAAAWaN816QBDShgAVQgBYUoYAG1I FARzSBQEIBVoCF2CABZoCF2CADBKFQBDShgAYUoYAG1IFARzSBQEACsCCIEDap0IAAAGCAEV aAgpVAAWaAhdggBDShgAVQgBYUoYAG1ICQRzSAkEHwNqAAAAABZoCF2CAENKGABVCAFhShgA bUgJBHNICQQcFWgIXYIAFmjkdMoAQ0oYAGFKGABtSBQEc0gUBAAcFWgIXYIAFmgIXYIAQ0oY AGFKGABtSBQEc0gUBAAcFWgIXYIAFmggfzYAQ0oYAGFKGABtSBQEc0gUBBPgCwAA4QsAAOIL AADjCwAA9gsAAAYMAAAIDAAACQwAAAoMAAAaDAAAGwwAAB0MAAAeDAAAHwwAACYMAAAyDAAA NwwAADwMAABNDAAAWwwAAHwMAAB9DAAAfgwAAIcMAACKDAAA9e3d0cLRrN2b3dGMf3lzbWdh W09Jc3lDAAAAAAAAAAAAAAoWaJ1IVABDShgAAAoWaFxGgABDShgAABcVaDpWxwAWaJZbNwA2 CIFDShgAYUoYAAoWaIA74ABDShgAAAoWaNwBQABDShgAAAoWaNRAsQBDShgAAAoWaCp56QBD ShgAAAoWaN0qwQBDShgAAAoWaB4y9QBDShgAABgVaAhdggAWaB4y9QBRSgEAbUgUBHNIFAQA HBVoCF2CABZo5HTKAENKGABhShgAbUgUBHNIFAQAIBVoCClUABZoCF2CADBKFQBDShgAYUoY AG1IFARzSBQEACsCCIEDamMKAAAGCAEVaAgpVAAWaAhdggBDShgAVQgBYUoYAG1IFARzSBQE HBVoCF2CABZoCF2CAENKGABhShgAbUgUBHNIFAQAFhZoCF2CAENKGABhShgAbUgUBHNIFAQA HwNqAAAAABZoCF2CAENKGABVCAFhShgAbUgUBHNIFAQOFmgIXYIAbUgUBHNIFAQAFBVoCF2C ABZoCF2CAG1IFARzSBQEGLwKAAAeDAAAHwwAAH0MAAB+DAAA0wwAANQMAADqDAAA6wwAAKkO AACqDgAAIg8AACMPAACdDwAACBEAAAkRAACAEgAAgRIAAB8UAAD4AAAAAAAAAAAAAAAA5QAA AAAAAAAAAAAAAOAAAAAAAAAAAAAAAADgAAAAAAAAAAAAAAAA2AAAAAAAAAAAAAAAANQAAAAA AAAAAAAAAADNAAAAAAAAAAAAAAAAywAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAADLAAAAAAAA AAAAAAAAwgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAAC1AAAAAAAAAAAAAAAApAAAAAAAAAAA AAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAnwAAAAAAAAAAAAAAAJ8AAAAAAAAAAAAA AAAAAAAAAAAAAAAEAABnZDxSjgAAEAAACiYAC0YcAA6Eiv03JAA4JABIJABdhIr9Z2T3ZmwA AAwAAAomAAtGHAA3JAA4JABIJABnZK16NAAJAAA3JAA4JABIJABnZKt2UAAAAQAAAAYiABSk AABnZAkCawAAAyIAFKQAAAgiABSkAABAJgBnZIA74AAFIgAUpAAAQCYAABITAA3GBAFIEgAU pAAAJmQAAAAAUMYIAAAA/wAAAABnZAhdggAABgAAFKTwAGdk5HTKAAASigwAAKUMAACxDAAA zgwAANIMAADTDAAA1AwAANkMAADpDAAA6gwAAOsMAAANDQAAHA0AACENAAAiDQAAKQ0AAC8N AAA6DQAAOw0AAD4NAABIDQAAZw0AAHYNAAB3DQAAmA0AAJkNAACaDQAA+u/j0cv6xb+5xa6m nqaWnod8ru9075bjbFcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA KBVoIH82ABZoIH82AENKGABQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQADhZogDvgAENKGABh ShgAAA4WaJZbNwBDShgAYUoYAAAUFWggfzYAFmgIXYIAQ0oYAGFKGAAAHBVoCF2CABZoCF2C AENKGABhShgAbUgJBHNICQQADhZo3AFAAENKGABhShgAAA4WaNRAsQBDShgAYUoYAAAOFmh9 IgEAQ0oYAGFKGAAAFBVoIH82ABZonUhUAENKGABhShgAAAoWaAkCawBDShgAAAoWaAhdggBD ShgAAAoWaB4y9QBDShgAAAoWaFxGgABDShgAACMVaDpWxwAWaIA74AA2CIFDShgAUEoDAGFK GABuSBEEdEgRBBcVaDpWxwAWaJZbNwA2CIFDShgAYUoYABQVaCB/NgAWaCB/NgBDShgAYUoY AAAKFmggfzYAQ0oYABqaDQAApw0AALINAADQDQAA0w0AANcNAADYDQAA5w0AAO0NAADxDQAA 9Q0AAAMOAAAEDgAAMA4AAEkOAACoDgAAqQ4AAKoOAACyDgAA7tnNt6WTge6B7pOlb11vSzlv AAAAAAAAAAAAAAAAAAAAAAAAAAAiFmirdlAAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgR BAAiFmjYNawAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAiFmjmZ+IAQ0oYAFBKAwBh ShgAbUgJBG5IEQRzSAkEdEgRBAAiFmjbD+kAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgR BAAiFmgSC7cAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAiFmjtLD0AQ0oYAFBKAwBh ShgAbUgJBG5IEQRzSAkEdEgRBAAiFmh9IgEAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgR BAArFWg6VscAFmggfzYANgiBQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBBcVaDpWxwAW aJZbNwA2CIFDShgAYUoYACgVaCB/NgAWaCB/NgBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0 SBEEACIWaDxSjgBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEErIOAAAfDwAAIA8AACIP AAAjDwAAJA8AAJwPAACfDwAApg8AALkPAADIDwAA4g8AAPIPAADzDwAAKBAAAEsQAABNEAAA URAAAFIQAACEEAAArhAAALAQAACxEAAAshAAANgQAADr2cSvxOvE2cTrr52Lneuv63xxxHFf fFIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGBVo2w/pABZorXo0 ADBKFQBDShgAYUoYAAAjAgiBA2oqCwAABggBFWjbD+kAFmitejQAQ0oYAFUIAWFKGAAUFWjb D+kAFmitejQAQ0oYAGFKGAAAHQNqAAAAABVo2w/pABZorXo0AENKGABVCAFhShgAIhZoEgu3 AENKGABQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQAIhZo92ZsAENKGABQSgMAYUoYAG1ICQRu SBEEc0gJBHRIEQQAKBVo2w/pABZo2w/pAENKGABQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQA KBVo2w/pABZorXo0AENKGABQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQAIhZo5mfiAENKGABQ SgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQAKBVo2w/pABZoq3ZQAENKGABQSgMAYUoYAG1ICQRu SBEEc0gJBHRIEQQY2BAAAAIRAAADEQAABBEAAAURAAAGEQAABxEAAAkRAAAdEQAAHhEAAEQR AABkEQAAfBEAALcRAADiEQAAAhIAABQSAAAaEgAASxIAAE4SAABREgAAfxIAAIASAACBEgAA ixIAAOnaxbDFm8WJm8V3xZuJZYmbxYnFiVNLQwAAAAAAAAAAAAAOFmjbD+kAQ0oYAGFKGAAA DhZo5mfiAENKGABhShgAACIWaKt2UABDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACIW aPdmbABDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACIWaGUTwABDShgAUEoDAGFKGABt SAkEbkgRBHNICQR0SBEEACIWaOZn4gBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgV aNsP6QAWaKt2UABDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaNsP6QAWaNsP6QBD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaNsP6QAWaK16NABDShgAUEoDAGFKGABt SAkEbkgRBHNICQR0SBEEAB0DagAAAAAVaNsP6QAWaK16NABDShgAVQgBYUoYACwVaNsP6QAW aK16NAAwShUAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBBiLEgAAmxIAAJ4SAADJEgAA yhIAAMsSAADyEgAAAhMAACwTAAA+EwAAPxMAAEsTAABvEwAAcBMAALETAACzEwAAtBMAALUT AADaEwAAGxQAABwUAAAeFAAA+PDo8Ojd1cndvbWqm4a1dL1nUL0+AAAAAAAAAAAAAAAAAAAA IhZoOlbHAENKGABQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQALBVoCClUABZoOlbHADBKFQBD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEABgVaAgpVAAWaDpWxwAwShUAQ0oYAGFKGAAA IwIIgQNq4wwAAAYIARVoCClUABZoOlbHAENKGABVCAFhShgAKBVoOlbHABZoOlbHAENKGABQ SgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQAHRVoOlbHABZoOlbHAEIqAkNKGABhShgAcGgAAP8A FBVoOlbHABZoOlbHAENKGABhShgAAA4WaDpWxwBDShgAYUoYAAAXA2oAAAAAFmg6VscAQ0oY AFUIAWFKGAAXFWjmZ+IAFmjmZ+IANgiBQ0oYAGFKGAAOFmjmZ+IAQ0oYAGFKGAAAFBVoOlbH ABZolgwxAENKGABhShgAAA4WaJYMMQBDShgAYUoYAAAOFmiTJ0QAQ0oYAGFKGAAADhZo2DWs AENKGABhShgAFR4UAAAfFAAAfhQAAIAUAACEFAAAjxQAAJsUAACcFAAAnRQAALwUAADRFAAA 8xQAAB4VAABEFQAARRUAAHIVAABzFQAAdBUAAIwVAACNFQAAoBUAALEVAACyFQAA4RUAAOIV AADjFQAA/RUAAP4VAAAfFgAAIBYAADMWAABMFgAAThYAAE8WAABQFgAA6+DY4Njg2ODY4NLM 0sLStcKtwtKpoamWoY2hqYHYdthkgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIwIIgQNq lBAAAAYIARVoCClUABZo2DWsAENKGABVCAFhShgAFBVoRwLjABZo2DWsAENKGABhShgAABcD agAAAAAWaNg1rABDShgAVQgBYUoYABAVaCkP/AAWaNg1rAAwShUAABUCCIEDaqUPAAAGCAEW aNg1rABVCAEPA2oAAAAAFmjYNawAVQgBBhZo2DWsAAAOFmjYNawAMEoVAENKGAAAGQIIgQNq 9A4AAAYIARZo2DWsAENKGABVCAETA2oAAAAAFmjYNawAQ0oYAFUIAQoWaLpmOgBDShgAAAoW aNg1rABDShgAAA4WaNg1rABDShgAYUoYAAAUFWgxRKQAFmjYNawAQ0oYAGFKGAAAKBVoPFKO ABZo2DWsAENKGABQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQiHxQAACAUAADQFAAA0RQAAN8U AADgFAAA4RQAAOIUAADyFAAA8xQAAA0VAAAdFQAAHhUAADQVAABEFQAAkBUAAKAVAAChFQAA sRUAAP8VAAAPFgAAEBYAAB8WAABsFgAAfBYAAH0WAAC3FgAA+AAAAAAAAAAAAAAAAPgAAAAA AAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAA AAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAA AADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA 6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsA AAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOEAAAAAAAAAAAAAAAAAAAAA CCIAFKQAAEAmAGdkumY6AAABAAAABAAAZ2TYNawACCIAFKQAAEAmAGdk2DWsAAAGIgAUpAAA Z2TYNawAABpQFgAAaRYAAGoWAABsFgAAexYAAHwWAAB9FgAAlRYAALcWAAC4FgAA4RYAAPkW AAAJFwAAexcAAHwXAAB9FwAAhhcAAIgXAAC3FwAAuBcAAPPn39TQyLyuo458jm2OWI5GjjQA AAAAACIWaLpmOgBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACIWaFpATwBDShgAUEoD AGFKGABtSAkEbkgRBHNICQR0SBEEACgVaLpmOgAWaLpmOgBDShgAUEoDAGFKGABtSAkEbkgR BHNICQR0SBEEABwVaLpmOgAWaO0sPQBDShgAYUoYAG1ICQRzSAkEACIWaPduswBDShgAUEoD AGFKGABtSAkEbkgRBHNICQR0SBEEACgVaLpmOgAWaO0sPQBDShgAUEoDAGFKGABtSAkEbkgR BHNICQR0SBEEABQVaCB/NgAWaLpmOgBDShgAYUoYAAAaFWj3brMAFmi6ZjoANQiBNgiBQ0oY AGFKGAAAFxVoumY6ABZoumY6ADUIgUNKGABhShgADhZoumY6AENKGABhShgAAAYWaNg1rAAA FBVoRwLjABZo2DWsAENKGABhShgAAA4WaNg1rABDShgAYUoYAAAXA2oAAAAAFmjYNawAQ0oY AFUIAWFKGAAYFWgIKVQAFmjYNawAMEoVAENKGABhShgAE7cWAAC4FgAAfBcAAH0XAAC5FwAA uhcAAG8YAABwGAAAPBkAAD0ZAACMGgAAjRoAALgbAAC5GwAAKRwAACocAABpHQAAah0AADAf AAAxHwAAsR8AALIfAAD9AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD1 AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAOIAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAAPUAAAAA AAAAAAAAAADYAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADQAAAAAAAA AAAAAAAAywAAAAAAAAAAAAAAANAAAAAAAAAAAAAAAADGAAAAAAAAAAAAAAAAvgAAAAAAAAAA AAAAALkAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2TKNl8ACAAACiYAC0YaAGdkyjZfAAAE AABnZMAwWAAABAAAZ2T0LlsACAAACiYAC0YaAGdk9C5bAAAEAABnZO0sPQAABAAAZ2RuUhMA AAQAAGdkgBF/AAAIAAAPhGgBXoRoAWdkgBF/AAAEAABnZLpmOgAIAAAKJgALRhoAZ2QgfzYA AAEAAAAVuBcAALkXAAC6FwAAuxcAAMMXAADEFwAA9BcAAP4XAABuGAAAbxgAAHAYAAB4GAAA eRgAAHwYAAB+GAAA4hgAAOMYAADlGAAA7tnEr52Ic4heSa/EiDOIc8QAAAAAAAAAAAAAAAAA KxVoumY6ABZolls3AENKGABIKgFQSgMAYUoYAG1ICQRuSBEEc0gJBHRIEQQoFWi6ZjoAFmiA EX8AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAoFWi6ZjoAFmggfzYAQ0oYAFBKAwBh ShgAbUgJBG5IEQRzSAkEdEgRBAAoFWi6ZjoAFmgIXYIAQ0oYAFBKAwBhShgAbUgJBG5IEQRz SAkEdEgRBAAoFWi6ZjoAFmiWWzcAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAiFmha QE8AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAoFWi6ZjoAFmiiJXkAQ0oYAFBKAwBh ShgAbUgJBG5IEQRzSAkEdEgRBAAoFWi6ZjoAFmjtLD0AQ0oYAFBKAwBhShgAbUgJBG5IEQRz SAkEdEgRBAAoFWi6ZjoAFmi6ZjoAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAiFmjt LD0AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBBHlGAAA6BgAADsZAAA8GQAAPRkAAHYZ AAB3GQAAeBkAAHkZAAB6GQAAmhkAAAUaAACLGgAAqhoAAKsaAAC8GgAA+BoAAPkaAAARGwAA RxsAAGIbAABjGwAAthsAALcbAAC4GwAAxRsAAO7ZxK+ahZqFmoWa2ZqFmoVzmoVhc4WaxE8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIWaO0sPQBDShgAUEoDAGFKGABtSAkEbkgR BHNICQR0SBEEACIWaFpATwBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACIWaD9RoQBD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaLpmOgAWaJZbNwBDShgAUEoDAGFKGABt SAkEbkgRBHNICQR0SBEEACgVaLpmOgAWaG5SEwBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0 SBEEACgVaLpmOgAWaIARfwBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaLpmOgAW aKIleQBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaLpmOgAWaO0sPQBDShgAUEoD AGFKGABtSAkEbkgRBHNICQR0SBEEACIWaDErDQBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0 SBEEGcUbAADHGwAA5BsAAPAbAAD1GwAAGhwAACgcAAApHAAAKhwAADIcAAC6HAAA4hwAAPsc AAAEHQAABh0AAAcdAAAIHQAAEh0AAFcdAABnHQAAaB0AAGkdAABqHQAA4B0AAOnXxdfFs9eh nZmVkZmJmZGZhYGFbFpIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIWaNUDrQBDShgAUEoD AGFKGABtSAkEbkgRBHNICQR0SBEEACIWaPQuWwBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0 SBEEACgVaPQuWwAWaPQuWwBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEAAYWaD9RoQAA BhZoblITAAAPFWh3SyYAFmh3SyYASCoBBhZoZyy/AAAGFmg2aa0AAAYWaHdLJgAABhZofSIB AAAiFmiAEX8AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAiFmh3SyYAQ0oYAFBKAwBh ShgAbUgJBG5IEQRzSAkEdEgRBAAiFmgbM4kAQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgR BAAiFmjtLD0AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAArFWjtLD0AFmjtLD0AQ0oY AEgqAVBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAX4B0AACUeAABAHgAASh4AAE8eAAB3HgAA eB4AANAeAAAaHwAALh8AAC8fAAAwHwAAMR8AAK8fAACwHwAAsR8AALIfAADAHwAA0R8AANof AAD17fXt9eXd0Ma8p5KEdmFTRVM9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOFmisUrgAbUgJ BHNICQQAGhZoWkBPAFBKAwBtSAkEbkgRBHNICQR0SBEEABoWaMo2XwBQSgMAbUgJBG5IEQRz SAkEdEgRBAAoFWjKNl8AFmjKNl8AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAaFmg6 VscAUEoDAG1ICQRuSBEEc0gJBHRIEQQAGhZowDBYAFBKAwBtSAkEbkgRBHNICQR0SBEEACgV aPQuWwAWaMAwWABDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaMAwWAAWaPQuWwBD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEABIWaMAwWABhShYAbUgJBHNICQQAEhZo9C5b AGFKFgBtSAkEc0gJBAAYFWj0LlsAFmj0LlsAYUoWAG1ICQRzSAkEAA4WaPQuWwBtSAkEc0gJ BAAOFmjVA60AbUgJBHNICQQADhZoP1GhAG1ICQRzSAkEABQVaFgFYQAWaNUDrQBtSAkEc0gJ BBPaHwAA2x8AAP8fAAAAIAAAHSAAACggAAAxIAAAMyAAADQgAABYIAAAXCAAAF0gAAByIAAA diAAAH4gAACAIAAAgSAAAIIgAACPIAAAqiAAALIgAADRIAAA6yAAAPDl0+XLwLWmy8DLwMvA y5F8alVKQkoAAAAAAAAAAAAAAAAAAAAAAAAOFmg/UaEAbUgJBHNICQQAFBVoOlbHABZoMEpt AG1ICQRzSAkEACgVaDpWxwAWaDBKbQBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACIW aFpATwBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaKxSuAAWaDBKbQBDShgAUEoD AGFKGABtSAkEbkgRBHNICQR0SBEEACgVaDBKbQAWaMo2XwBDShgAUEoDAGFKGABtSAkEbkgR BHNICQR0SBEEAB0VaDEHBQAWaKxSuABCKgZtSAkEcGj/AAAAc0gJBBQVaDpWxwAWaKxSuABt SAkEc0gJBAAUFWiANNoAFmisUrgAbUgJBHNICQQADhZorFK4AG1ICQRzSAkEACIWaKxSuABD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEABQVaIA02gAWaMo2XwBtSAkEc0gJBAAdFWgx BwUAFmjKNl8AQioGbUgJBHBo/wAAAHNICQQAFrIfAACBIAAAgiAAAOwgAADtIAAAgSEAAIIh AAD1IQAA9iEAAGEiAABiIgAAXyQAAGAkAADNJAAAziQAAP0kAAD+JAAAACUAAAElAAADJQAA 9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAAN0A AAAAAAAAAAAAAADYAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADLAAAA AAAAAAAAAAAAxgAAAAAAAAAAAAAAAMsAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAuQAAAAAA AAAAAAAAALQAAAAAAAAAAAAAAACsAAAAAAAAAAAAAAAAqAAAAAAAAAAAAAAAAKYAAAAAAAAA AAAAAACmAAAAAAAAAAAAAAAApgAAAAAAAAAAAAAAAAAAAAAAAAEAAAADIgAUpAAACAAACiYA C0YaAGdkfSIBAAAEAABnZG5SEwAIAAAKJgALRhoAZ2Q6VscAAAQAAGdk2DWsAAAEAABnZKsT aAAIAAAKJgALRhoAZ2SrE2gAAAQmAGdkhlU/AAAEAABnZIZVPwAIAAAKJgALRhoAZ2SGVT8A AAQAAGdkEHnfAAgAAAomAAtGGgBnZBB53wAABAAAZ2QwSm0ACAAACiYAC0YaAGdkrFK4AAAT 6yAAAOwgAAD6IAAAAyEAAGEhAAB6IQAAgCEAAJghAAC8IQAAzSEAAPQhAAD1IQAA9iEAAGAi AABiIgAAbCIAAHYiAAB3IgAAeCIAAJ0iAAC5IgAA0yIAANkiAAAoIwAAaCMAAOojAABeJAAA XyQAAMwkAADr4Njg0OC7sNCwu7C7m4abdGnQadBp0GnQXpuGAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUFWg6VscAFmjYNawAbUgJBHNICQQAFBVoOlbH ABZoqxNoAG1ICQRzSAkEACIWaD9RoQBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgV aDpWxwAWaNg1rABDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACgVaDpWxwAWaKsTaABD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEABQVaDpWxwAWaIZVPwBtSAkEc0gJBAAoFWg6 VscAFmiGVT8AQ0oYAFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBAAOFmg/UaEAbUgJBHNICQQA DhZoWkBPAG1ICQRzSAkEABQVaDpWxwAWaBB53wBtSAkEc0gJBAAoFWg6VscAFmgQed8AQ0oY AFBKAwBhShgAbUgJBG5IEQRzSAkEdEgRBBzMJAAAzSQAANokAADmJAAA/SQAAP4kAAD/JAAA ACUAAAElAAACJQAAAyUAAAQlAAAFJQAABiUAAAclAAAIJQAACSUAAAolAAAWJQAAFyUAAC4l AAAvJQAASiUAAEslAABNJQAATiUAAGclAABoJQAAciUAAHMlAAB5JQAAeiUAAH8lAACAJQAA gSUAAIIlAACDJQAAhCUAAJ4lAACfJQAAviUAAL8lAADCJQAAwyUAAMolAAAtJwAA69bB1rmx q6exq6exq6exq6ejm6Obl5ujm6Obl5ujm6Objpujm6Obl5ujp4J4AAAAAAAAAAAAAAATFmjb D+kAQioBQ0oSAHBoAAAAABYWaNsP6QA1CIFCKgFDShIAcGgAAAAAABEWaBILtwBtSAAEbkgA BHUIAQYWaJMnRAAADwNqAAAAABZo2w/pAFUIAQYWaNsP6QAABhZo7WWbAAAKFmjtZZsAQIgi AAAPA2oAAAAAFmjtZZsAVQgBDhZoHjL1AENKGABhShgAACgVaDpWxwAWaNUDrQBDShgAUEoD AGFKGABtSAkEbkgRBHNICQR0SBEEACgVaDpWxwAWaG5SEwBDShgAUEoDAGFKGABtSAkEbkgR BHNICQR0SBEEACgVaDpWxwAWaDBKbQBDShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEELQMl AAAEJQAABiUAAAclAAAJJQAACiUAAEwlAABNJQAAwCUAAMElAADCJQAAwyUAAC0nAAAuJwAA XykAAGApAAA7LgAAPC4AAEUuAADSLwAA0y8AABIwAAATMAAAFTAAAP0AAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADoAAAAAAAA AAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA3gAAAAAAAAAA AAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANQAAAAAAAAAAAAA AADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAADJAFhJAFnZNl9sgAABAAAZ2TrZw4A AAQAAGdklW88AAADEQAUpHgABgAANyQAOCQASCQAAAQAAAMkA2EkAwgPAA3GCgFQGQJIEpAk AQIIEAANxgoBUBkCSBKQJAECAAEAAAAXLScAAC4nAAA2JwAAYCkAAH0pAADKKQAAyykAABcq AAAYKgAARyoAAEgqAACULAAAlSwAAKgsAAC6LAAAvCwAAL0sAAC+LAAA0CwAANEsAACqLQAA 9S0AAPYtAAAnLgAAKC4AADcuAAA4LgAAOS4AADouAAA7LgAA69/V39XG1ca+xtWvpZilg694 r9VsXGxcU1xs1U0AAAAAAAoWaNsP6QBDShIAABEWaNsP6QAwShUANQiBQ0oSAB8DagAAAAAW aNsP6QA1CIFCKglDShIAVQgBcGgAAIAAFhZo2w/pADUIgUIqCUNKEgBwaAAAgAAAFBVoCClU ABZoZRPAADBKFQBDShIAACgCCIEDan8RAAAGCAEVaAgpVAAWaGUTwABCKgFDShIAVQgBcGgA AAAAABkVaGUTwAAWaGUTwABCKgFDShIAcGgAAAAAExZoZRPAAEIqAUNKEgBwaAAAAAAcA2oA AAAAFmhlE8AAQioBQ0oSAFUIAXBoAAAAAAAOFmjbD+kAMEoVAENKEgAAHANqAAAAABZo2w/p AEIqAUNKEgBVCAFwaAAAAAAAExZo2w/pAEIqAUNKEgBwaAAAAAAWFmjbD+kANQiBQioBQ0oS AHBoAAAAAAAnFmjbD+kAQioBQ0oSAE9KBABQSgQAUUoEAG1ICQRwaAAAAABzSAkEAB07LgAA RS4AAMEuAADeLgAA+y4AAPwuAAD9LgAAcy8AAHQvAADPLwAA0C8AANIvAADTLwAAEjAAABMw AAAVMAAAGDAAABkwAAAdMAAAHjAAAPzx5fHVuqS6jHNhTNU/N/wz/DMAAAAGFmgeMvUAAA4W aNsP6QBDShgAYUoYAAAZFmjbD+kAQ0oYAFwIgWFKGABtSAkEc0gJBCgVaJVvPAAWaNsP6QBD ShgAUEoDAGFKGABtSAkEbkgRBHNICQR0SBEEACIWaNsP6QBDShgAUEoDAGFKGABtSAkEbkgR BHNICQR0SBEEADEDagAAAAAVaJVvPAAWaNsP6QBDShgAUEoDAFUIAWFKGABtSAkEbkgRBHNI CQR0SBEELxVolW88ABZo2w/pADBKFQBDShgAUEoDAFwIgWFKGABtSAkEbkgRBHNICQR0SBEE KxVolW88ABZo2w/pAENKGABQSgMAXAiBYUoYAG1ICQRuSBEEc0gJBHRIEQQ0A2oAAAAAFWiV bzwAFmjbD+kAQ0oYAFBKAwBVCAFcCIFhShgAbUgJBG5IEQRzSAkEdEgRBAAfFWiVbzwAFmjb D+kAQ0oYAFwIgWFKGABtSAkEc0gJBBcVaJZbNwAWaNsP6QA2CIFDShgAYUoYABQVaJVvPAAW aNsP6QBDShgAYUoYAAAGFmjbD+kAExUwAAAWMAAAFzAAABgwAAAZMAAAGjAAABswAAAcMAAA HTAAAB4wAAAfMAAA8wAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAA AAAAAAAAAADxAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAADIgAUpAAAAAEAAAALIwADJAERhAAAYIQAAGEkAWdk2X2yAAAKHjAAAB8w AAD4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4WaB4y9QBDShgAYUoYAAEvABQwPyZQAQAfsNAvILDgPSGwOAQisDgEI5A4BCSQOAQl sNACF7CwARiwsAEMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIgAFiQBFyQB SWYBAAAAAZYAACF2AAFoATXWBQABA2glI3YAAWglOlYLAAKWbAAHlOUBE9YwAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAY9gMAACzWAwAB ATXWBQABA2glNNYGAAEFAAAAilQBAIgAFiQBFyQBSWYBAAAAAZYAACF2AAFoATXWBQABA2gl I3YAAWglOlYLAAKWbAAHlGcBE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAA AAD/BAEAAAAAAP8EAQAAFPYBAAAY9gMAACzWAwABATXWBQABA2glNNYGAAEFAAAAilQBAIoA FiQBFyQBSWYBAAAAAZYAACF2AAFoATXWBQABA2glI3YAAWglOlYLAAKWbAADNAET1jAAAAD/ BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEAABj2AwAA LNYDAAEBNdYFAAEDaCU01gYAAQUAAABmNAGKVAEA3AAWJAEXJAFJZgEAAAABlgAAIXYABWgB NdYFAAEDOAU11gUBAgMQCDXWBQIDA/4KNdYFAwQDswY11gUEBQNvBiN2AAE4BSN2AQIQCCN2 AgP+CiN2AwSzBiN2BAVvBjpWCwAClmwAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAY9gMAACzWAwAFATXWBQABAzgFNdYFAQIDEAg1 1gUCAwP+CjXWBQMEA7MGNdYFBAUDbwY01gYAAQUAAACKVAEA7wAAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnq efm6zhGMggCqAEupCwIAAAAXAAAAGwAAAGQAcwB0AGEAbgBsAGUAeQBAAGEAcgB1AGIAYQBu AGUAdAB3AG8AcgBrAHMALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQtEAAAAbQBhAGkAbAB0 AG8AOgBkAHMAdABhAG4AbABlAHkAQABhAHIAdQBiAGEAbgBlAHQAdwBvAHIAawBzAC4AYwBv AG0AAADcABYkARckAUlmAQAAAAGWAAAhdgAFaAE11gUAAQM4BTXWBQECAxAINdYFAgMD/go1 1gUDBAOzBjXWBQQFA28GI3YAATgFI3YBAhAII3YCA/4KI3YDBLMGI3YEBW8GOlYLAAKWbAAT 1jAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA/wQBAAAU9gEA ABj2AwAALNYDAAUBNdYFAAEDOAU11gUBAgMQCDXWBQIDA/4KNdYFAwQDswY11gUEBQNvBjTW BgABBQAAAIpUAQDrAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAaAAAA cwB0AGUAcABoAGUAbgAuAG0AYwBjAGEAbgBuAEAAcgBvAGsAZQAuAGMAbwAuAHUAawAAAODJ 6nn5us4RjIIAqgBLqQtCAAAAbQBhAGkAbAB0AG8AOgBzAHQAZQBwAGgAZQBuAC4AbQBjAGMA YQBuAG4AQAByAG8AawBlAC4AYwBvAC4AdQBrAAAA3AAWJAEXJAFJZgEAAAABlgAAIXYABWgB NdYFAAEDOAU11gUBAgMQCDXWBQIDA/4KNdYFAwQDswY11gUEBQNvBiN2AAE4BSN2AQIQCCN2 AgP+CiN2AwSzBiN2BAVvBjpWCwAClmwAE9YwAAAA/wQBAAAAAAD/BAEAAAAAAP8EAQAAAAAA /wQBAAAAAAD/BAEAAAAAAP8EAQAAFPYBAAAY9gMAACzWAwAFATXWBQABAzgFNdYFAQIDEAg1 1gUCAwP+CjXWBQMEA7MGNdYFBAUDbwY01gYAAQUAAACKVAEAzwAAAEQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnq efm6zhGMggCqAEupCwIAAAAXAAAAEwAAAHMAdAB1AGEAcgB0AEAAbwBrAC0AYgByAGkAdAAu AGMAbwBtAAAA4Mnqefm6zhGMggCqAEupCzQAAABtAGEAaQBsAHQAbwA6AHMAdAB1AGEAcgB0 AEAAbwBrAC0AYgByAGkAdAAuAGMAbwBtAAAAzwAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCq AEupCwIAAAAXAAAAEwAAAGIAcgBjAEAAegB1AHIAaQBjAGgALgBpAGIAbQAuAGMAbwBtAAAA 4Mnqefm6zhGMggCqAEupCzQAAABtAGEAaQBsAHQAbwA6AGIAcgBjAEAAegB1AHIAaQBjAGgA LgBpAGIAbQAuAGMAbwBtAAAA6wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAX AAAAGgAAAEgAYQBuAG4AZQBzAC4AVABzAGMAaABvAGYAZQBuAGkAZwBAAGcAbQB4AC4AbgBl AHQAAADgyep5+brOEYyCAKoAS6kLQgAAAG0AYQBpAGwAdABvADoASABhAG4AbgBlAHMALgBU AHMAYwBoAG8AZgBlAG4AaQBnAEAAZwBtAHgALgBuAGUAdAAAAN8AAABEAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ 6nn5us4RjIIAqgBLqQsCAAAAFwAAABcAAABtAGEAcgBjAC4AbABpAG4AcwBuAGUAcgBAAGMA aQBzAGMAbwAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEupCzwAAABtAGEAaQBsAHQAbwA6AG0A YQByAGMALgBsAGkAbgBzAG4AZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0AAADnAAAARAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAZAAAAagBvAG4ALgBwAGUAdABlAHIAcwBv AG4AQABuAGUAdQBzAHQAYQByAC4AYgBpAHoAAADgyep5+brOEYyCAKoAS6kLQAAAAG0AYQBp AGwAdABvADoAagBvAG4ALgBwAGUAdABlAHIAcwBvAG4AQABuAGUAdQBzAHQAYQByAC4AYgBp AHoAAADHAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAARAAAAZgBsAHUA ZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQswAAAAbQBhAGkA bAB0AG8AOgBmAGwAdQBmAGYAeQBAAGMAaQBzAGMAbwAuAGMAbwBtAAAAuQEAAEQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAUQAAAGYAdABwADoALwAvAGYAdABwAC4AOAAw ADIAdwBpAHIAZQBsAGUAcwBzAHcAbwByAGwAZAAuAGMAbwBtAC8AMQAxAC8AMAA3AC8AMQAx AC0AMAA3AC0AMAAyADkAMAAtADAAMgAtADAAMAAwAHUALQBlAG0AZQByAGcAZQBuAGMAeQAt AGMAYQBsAGwALQBzAGUAdAB1AHAALgBwAHAAdAAAAODJ6nn5us4RjIIAqgBLqQuiAAAAZgB0 AHAAOgAvAC8AZgB0AHAALgA4ADAAMgB3AGkAcgBlAGwAZQBzAHMAdwBvAHIAbABkAC4AYwBv AG0ALwAxADEALwAwADcALwAxADEALQAwADcALQAwADIAOQAwAC0AMAAyAC0AMAAwADAAdQAt AGUAbQBlAHIAZwBlAG4AYwB5AC0AYwBhAGwAbAAtAHMAZQB0AHUAcAAuAHAAcAB0AAAAEQIA AEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEupCwIAAAAXAAAAZwAAAGYAdABwADoALwAvAGYA dABwAC4AOAAwADIAdwBpAHIAZQBsAGUAcwBzAHcAbwByAGwAZAAuAGMAbwBtAC8AMQAxAC8A MAA3AC8AMQAxAC0AMAA3AC0AMAAyADcANAAtADAAMQAtADAAMAAwAHUALQBzAHMAcABuAC0A aQBuAHQAZQByAGYAYQBjAGUALQBpAG4AdABlAHIAbgBhAGwALQBjAG8AbQBtAGUAbgB0AC0A cgBlAHMAbwBsAHUAdABpAG8AbgAuAGQAbwBjAAAA4Mnqefm6zhGMggCqAEupC84AAABmAHQA cAA6AC8ALwBmAHQAcAAuADgAMAAyAHcAaQByAGUAbABlAHMAcwB3AG8AcgBsAGQALgBjAG8A bQAvADEAMQAvADAANwAvADEAMQAtADAANwAtADAAMgA3ADQALQAwADEALQAwADAAMAB1AC0A cwBzAHAAbgAtAGkAbgB0AGUAcgBmAGEAYwBlAC0AaQBuAHQAZQByAG4AYQBsAC0AYwBvAG0A bQBlAG4AdAAtAHIAZQBzAG8AbAB1AHQAaQBvAG4ALgBkAG8AYwAAALEAAABEAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANDJ6nn5us4RjIIAqgBLqQsCAAAAAwAAAODJ6nn5us4RjIIAqgBLqQtAAAAAbQBhAGkAbAB0 AG8AOgBzAHQAdQBhAHIAdAAuAGsAZQByAHIAeQBAAHAAaABpAGwAaQBwAHMALgBjAG8AbQAA AO8AAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABsAAABkAHMAdABhAG4A bABlAHkAQABhAHIAdQBiAGEAbgBlAHQAdwBvAHIAawBzAC4AYwBvAG0AAADgyep5+brOEYyC AKoAS6kLRAAAAG0AYQBpAGwAdABvADoAZABzAHQAYQBuAGwAZQB5AEAAYQByAHUAYgBhAG4A ZQB0AHcAbwByAGsAcwAuAGMAbwBtAAAA6wAAAEQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA0Mnqefm6zhGMggCqAEup CwIAAAAXAAAAGgAAAHMAdABlAHAAaABlAG4ALgBtAGMAYwBhAG4AbgBAAHIAbwBrAGUALgBj AG8ALgB1AGsAAADgyep5+brOEYyCAKoAS6kLQgAAAG0AYQBpAGwAdABvADoAcwB0AGUAcABo AGUAbgAuAG0AYwBjAGEAbgBuAEAAcgBvAGsAZQAuAGMAbwAuAHUAawAAAM8AAABEAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAANDJ6nn5us4RjIIAqgBLqQsCAAAAFwAAABMAAABzAHQAdQBhAHIAdABAAG8AawAtAGIA cgBpAHQALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQs0AAAAbQBhAGkAbAB0AG8AOgBzAHQA dQBhAHIAdABAAG8AawAtAGIAcgBpAHQALgBjAG8AbQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhgInABIAAQCcAA8ABAAAAAAA AAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAQPH/AgA8AAwAAAAAAAAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABQAQ0oWAF9IAQRtSAkIc0gJCHRICQROAAFAAQACAE4A DAAAAAAAAAAAAAkASABlAGEAZABpAG4AZwAgADEAAAAPAAEABSQBBiQBE6RAAUAmAAASADUI gT4qAUNKIABPSgIAUUoCAE4AAkABAAIATgAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAA MgAAAA8AAgAFJAEGJAETpBgBQCYBABIANQiBPioBQ0ocAE9KAgBRSgIAUAADQAEAAgBQAAwA AAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAAzAAAAEwADAAUkAQYkAROk8AAUpDwAQCYCAA8A NQiBQ0oYAE9KAgBRSgIAAEoABEABAAIASgAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAA NAAAABAABAAGJAETpPAAFKQ8AEAmAw4ANQiBQ0ocAFwIgWFKHABOAAVAAQACAE4ADAAAAAAA AAAAAAkASABlAGEAZABpAG4AZwAgADUAAAANAAUAE6TwABSkPABAJgQAFAA1CIE2CIFDShoA XAiBXQiBYUoaAEQABkABAAIARAAMAAAAAAAAAAAACQBIAGUAYQBkAGkAbgBnACAANgAAAA0A BgATpPAAFKQ8AEAmBQAKADUIgVwIgWFKFgBCAAdAAQACAEIADAAAAAAAAAAAAAkASABlAGEA ZABpAG4AZwAgADcAAAANAAcAE6TwABSkPABAJgYACABDShgAYUoYAEgACEABAAIASAAMAAAA AAAAAAAACQBIAGUAYQBkAGkAbgBnACAAOAAAAA0ACAATpPAAFKQ8AEAmBwAOADYIgUNKGABd CIFhShgASgAJQAEAAgBKAAwAAAAAAAAAAAAJAEgAZQBhAGQAaQBuAGcAIAA5AAAADQAJABOk 8AAUpDwAQCYIABAAT0oCAFFKAgBeSgIAYUoWAEQAQUDy/6EARAAMAQAAAAAAAAAAFgBEAGUA ZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABWAGlA8/+zAFYA DAEAAAAAAAAAAAwAVABhAGIAbABlACAATgBvAHIAbQBhAGwAAAAgADpWCwAX9gMAADTWBgAB BQMAADTWBgABCgNsAGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4AbwAgAEwA aQBzAHQAAAACAAwAAAAAAD4AIEABAPIAPgAMAAAAAAAAAAAABgBGAG8AbwB0AGUAcgAAABMA DwAkZAYBAAENxggAAlAZoDIBAgAEAENKGABCAB9AAQACAUIADAAAAAAAAAAAAAYASABlAGEA ZABlAHIAAAATABAAJmQGAQACDcYIAAJQGaAyAQIABwA1CIFDShwAAC4A/k8BABIBLgAMAAAA AAAAAAAAAgBUADEAAAAIABEAAyQBYSQBBwA1CIFDShwAADQA/k8RASIBNAAMAAAAAAAAAAAA AgBUADIAAAAWABIADoTQAg+E0AIUpPAAXYTQAl6E0AIAAEAA/k8RATIBQAAMAAAAAAAAAAAA AgBUADMAAAAaABMAAyQADcYFAAFIEgEUpPAAJmQGAQABYSQABwA1CIFDShgAAFAAQ0ABAEIB UAAMAAAAAAAAAAAAEABCAG8AZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUAbgB0AAAAEgAUAA+E 0AIRhDD9XoTQAmCEMP0EAENKFgA2AFVAogBRATYADAAAAAAAAAAAAAkASAB5AHAAZQByAGwA aQBuAGsAAAAMAD4qAUIqAnBoAAD/AEAAakBxAXIBQAAMBQAAAAAAAAAADwBDAG8AbQBtAGUA bgB0ACAAUwB1AGIAagBlAGMAdAAAAAIAFgAGADUIgVwIgTgAHkABAHIBOAAMAQAAAAAAAAAA DABDAG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAFwAEAENKFABIAJlAAQCCAUgADAUAAAAA AAAAAAwAQgBhAGwAbABvAG8AbgAgAFQAZQB4AHQAAAACABgAFABDShAAT0oFAFFKBQBeSgUA YUoQAKYA/k8RAJIBpgAMAAAAAAAAAAAAMQBOAG8AcgBtAGEAbAAgACsAIAAxADQAIABwAHQA LABHAHIAYQB5AC0ANAAwACUALABMAGUAZgB0ADoAIAAgADAAIgAsAEYAaQByAHMAdAAgAGwA aQBuAGUAOgAgACAAMAAiAAAACQAZAAUkABOkAAAAHwA1CIE+KgBCKg9DShwAT0oAAFFKAABh SiAAcGiZmZkAAFoA/k8BAaIBWgAMAAAAAAAAAAAAGgBOAG8AcgBtAGEAbAAgACsAIABHAHIA YQB5AC0ANAAwACUALABDAGUAbgB0AGUAcgBlAGQAAAACABoACQBCKg9waJmZmQAATAATQAEA AgBMAAUBAAAAAAAAAAAFAFQATwBDACAAMQAAAA0AGwANxggAAlgCVicACgAZADUIgUNKGABc CIFhSigAbUgABG5IAAR1CAEAMgAUQAEAAgAyAA0BAAAAAAAAAAAFAFQATwBDACAAMgAAAAoA HAAPhMgAXoTIAAQAQ0oUADwAIkABAAIAPAAMAQAAAAAAAAAABwBDAGEAcAB0AGkAbwBuAAAA CgAdABOkeAAUpHgACgA1CIFDShQAXAiBWgBeQAEA4gFaAAwAAAAAAAAAAAAMAE4AbwByAG0A YQBsACAAKABXAGUAYgApAAAAEAAeABOkZAAUpGQAWyQBXCQBGABDShgAT0oEAFBKBABRSgQA XkoEAGFKGABGAFZAogDxAUYADAAAAAAAAAAAABEARgBvAGwAbABvAHcAZQBkAEgAeQBwAGUA cgBsAGkAbgBrAAAADAA+KgFCKgxwaIAAgAAuABVAAQACAC4ADQEAAAAAAAAAAAUAVABPAEMA IAAzAAAACgAgAA+EuAFehLgBAABSAFlAAQASAlIADAEAAAAAAAAAAAwARABvAGMAdQBtAGUA bgB0ACAATQBhAHAAAAATACEALUQgAU3GCgAAAP8AAIAAAAAADABPSgUAUUoFAF5KBQA4AP5P 8f8iAjgADAAAAAAAAAAAAAQAYgBvAGQAeQAAAAYAIgAUpHgAEABfSAEEbUgJBHNICQR0SAkE TABSQAEAMgJMAAwAAAAAAAAAAAASAEIAbwBkAHkAIABUAGUAeAB0ACAASQBuAGQAZQBuAHQA IAAyAAAACgAjABGE0AJghNACBABDShgAkABlQAEAQgKQAAwAAAAAAAAAAAARAEgAVABNAEwA IABQAHIAZQBmAG8AcgBtAGEAdAB0AGUAZAAAADcAJAANxjIAEJQDKAe8ClAO5BF4FQwZoBw0 IMgjXCfwKoQuGDKsNUA5AAAAAAAAAAAAAAAAAAAAAAAcAENKFABPSgQAUEoEAFFKBABeSgQA bUgJBHNICQRaAFNAAQBSAloADAAAAAAAAAAAABIAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4A ZABlAG4AdAAgADMAAAATACUAD4TQAjckADgkAEgkAF6E0AIACABDShgAUEoDAEwAWmABAGIC TAAMBAAA1QOtAAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAmABwAQ0oUAE9KBgBQSgcA UUoGAF5KBgBuSBIEdEgSBAAAAAB5CAAAVAoAAB8oAAABAAAAAAAAAAAA/////wQEAAAAAAAA AQAAAAAAAAAAAP////8DBAAAAAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAeQgAAFQK AABYCgAAAAAAAAAAAQAAAAAQ//8AAAAAAAAAAAMAAAAfKAAA/////wAAAAABAP////8AAAAA AAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAcAAAAAAAAAAAj//wAAAAAAAAAA HygAABoAAHgAABsA/////wAAAADDHQAA0ycAACAoAAAKAAAAADAAAAAAAAAAAAAAAAADMAAA AAAAAAAHus4AMAAwAAAAAAAAAQAAAAAAAAAAAD4YKSqQBwoAAAAAMAAAAAAAAAAAAAAAAAYw 1gAAAAAAAAcAAAAAGwAAADsAAAA8AAAATgAAAE8AAABaAAAAWwAAAGAAAABoAAAAcAAAAHYA AAB8AAAAfQAAAI0AAACdAAAAsAAAAL4AAADOAAAAHAEAAB0BAAAsAQAAQAEAAFgBAABrAQAA fAEAAIkBAACZAQAA5gEAAOcBAADoAQAA6gEAAGQCAABlAgAAuwIAALwCAAAeBAAAHwQAAH0E AAB+BAAA0wQAANQEAADqBAAA6wQAAKkGAACqBgAAIgcAACMHAACdBwAACAkAAAkJAACACgAA gQoAAB8MAAAgDAAA0AwAANEMAADfDAAA4AwAAOEMAADiDAAA8gwAAPMMAAANDQAAHQ0AAB4N AAA0DQAARA0AAJANAACgDQAAoQ0AALENAAD/DQAADw4AABAOAAAfDgAAbA4AAHwOAAB9DgAA tw4AALgOAAB8DwAAfQ8AALkPAAC6DwAAbxAAAHAQAAA8EQAAPREAAIwSAACNEgAAuBMAALkT AAApFAAAKhQAAGkVAABqFQAAMBcAADEXAACxFwAAshcAAIEYAACCGAAA7BgAAO0YAACBGQAA ghkAAPUZAAD2GQAAYRoAAGIaAABfHAAAYBwAAM0cAADOHAAA/RwAAP4cAAAAHQAAAR0AAAMd AAAEHQAABh0AAAcdAAAJHQAACh0AAEwdAABNHQAAwB0AAMEdAADCHQAAwx0AAC0fAAAuHwAA XyEAAGAhAAA7JgAAPCYAAEUmAADSJwAA0ycAABIoAAATKAAAFSgAABYoAAAXKAAAGCgAABko AAAaKAAAGygAABwoAAAdKAAAICgAAJgAAAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAACpAAAA EjAAAAAAAAAAgAAAAIABAACoAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAArAAAAAAgAKkA AAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAADUAAAAACAA qQAAABIwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEAAKwAAAAA IACpAAAAEjAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAAqAAA AAAgAKkAAAASMAAAAAAAAACAAAAAgAEAAKgAAAAAIACpAAAAEjAAAAAAAAAAgAAAAIABAACo AAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAAqAAAAAAgAJkAAAAAMAAAAAAAAACAAAAAgAEA AKwAAAAAIACpAAAAEjAAAAAAAAAAgAAAAIABAACoAAAAACAAqQAAABIwAAAAAAAAAIAAAACA AQAAqAAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAAKgAAAAAAACpAAAAEjAAAAAAAAAAgAAA AIABAACoAAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAAqAAAAAAgAKkAAAASMAAAAAAAAACA AAAAgAEAAKgAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAACsAAAAACAAqQAAABIwAAAAAAAA AIAAAACAAQAA0AAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAANAAAAAAIACpAAAAADAAAAAA AAAAgAAAAIABAADQAAAAAAAAqQAAAAAwAAAAAAAAAIAAAACAAQAA0AAAAAAAAKkAAAAAMAAA AAAAAACAAAAAgAEAANAAAAAAAACpAAAAADAAAAAAAAAAgAAAAIABAADQAAAAACAAqQAAABIw AAAAAAAAAIAAAACAAQAA0AAAAAAgAKkAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAAACpAAAA EjAAAAAAAAAAgAAAAIABAADQAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAA1AAAAAAgAJgA AAARMAAAAAAAAACAAAAAgAAAAAAAAAAAAAAIAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIDqAQAAAAAAAAAAAAAAAJgAAAAiMAAAAAAAAACA6gEAAAAAAAAAAAAA AACYAAAAIjAAAAAAAAAAgOoBAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIDqAQAAAAAAAAAA AAAAAJgAAAATMAAAAAAAAACA6gEAAAAAAAAAAAAAAAAIAAAAIjAAAAAAAAAAgAAAAIAAAAAA AAAAAAAACAAAACIwAAAAAAAAAIAAAACAAAAAAAAAAAAAAAgAAAAiMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAAIjAAAAAAAAAAgH4EAAAAAAAAAAAAAIAAmAAAACIwAAAAAAAAAIB+BAAA AAAAAAAAAACAAJgAAAAAMAAAAAAAAACAfgQAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgH4E AAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIB+BAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA fgQAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgH4EAAAAAAAAAAAAAAAAmAAcIAAwAAAAAAAA AIB+BAAAAAAAAAAAAAAAAJgAHCAAMAEAAAAAAACAfgQAAAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgH4EAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIB+BAAAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAfgQAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgH4EAAAAAAAAAAAAAAAAmAAAACIw AAAAAAAAAIB+BAAAAAAAAAAAAAAAAJgAAAAiMAAAAAAAAACAfgQAAAAAAAAAAAAAAACYAAAA IjAAAAAAAAAAgH4EAAAAAAAAAAAAAAAAmAAAACIwAAAAAAAAAIB+BAAAAAAAAAAAAAAAAJgA AAAiMAAAAAAAAACAfgQAAAAAAAAAAAAAAACYAAAAIjAAAAAAAAAAgH4EAAAAAAAAAAAAAAAA mAAAACIwAAAAAAAAAIB+BAAAAAAAAAAAAAAAAAgAAAAiMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAADAAAAAAAAAAgOIMAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIDiDAAAAAAAAAAA AAAAAJgAAAAAMAAAAAAAAACA4gwAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgOIMAAAAAAAA AAAAAAAAmAAAAAAwAAAAAAAAAIDiDAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA4gwAAAAA AAAAAAAAAACYAAAAADAAAAAAAAAAgOIMAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIDiDAAA AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA4gwAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgOIM AAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIDiDAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA 4gwAAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgOIMAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIDiDAAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA4gwAAAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgOIMAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIDiDAAAAAAAAAAAAAAAAAgAAAAiMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgH0OAAAAAAAAAAAAAAAAmAAaIAAw AAAAAAAAAIB9DgAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAfQ4AAAAAAAAAAAAAAACYABog ADABAAAAAAAAgH0OAAAAAAAAAAAAAIAAmAAAAAAwAAAAAAAAAIB9DgAAAAAAAAAAAACAAJgA GiAAMAIAAAAAAACAfQ4AAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgH0OAAAAAAAAAAAAAAAA mAAaIAAwAwAAAAAAAIB9DgAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAfQ4AAAAAAAAAAAAA gACYABogADAEAAAAAAAAgH0OAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIB9DgAAAAAAAAAA AAAAAJgAGiAAMAUAAAAAAACAfQ4AAAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgH0OAAAAAAAA AAAAAAAAmAAaIAAwBgAAAAAAAIB9DgAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAfQ4AAAAA AAAAAAAAgACYABogADAHAAAAAAAAgH0OAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIB9DgAA AAAAAAAAAAAAAJgAGiAAMAgAAAAAAACAfQ4AAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgH0O AAAAAAAAAAAAAAAAmAAaIAAwCQAAAAAAAIB9DgAAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA fQ4AAAAAAAAAAAAAAACYABogADAKAAAAAAAAgH0OAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA AIB9DgAAAAAAAAAAAAAAAJgAGiAAMAsAAAAAAACAfQ4AAAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgH0OAAAAAAAAAAAAAAAAmAAaIAAwDAAAAAAAAIB9DgAAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAfQ4AAAAAAAAAAAAAAACYABogADANAAAAAAAAgH0OAAAAAAAAAAAAAAAAmAAAACYw AAAAAAAAAIB9DgAAAAAAAAAAAAAAAJgAGiAAMA4AAAAAAACAfQ4AAAAAAAAAAAAAAACYAAAA ADAAAAAAAAAAgH0OAAAAAAAAAAAAAAAAmAAaIAAwDwAAAAAAAIB9DgAAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAfQ4AAAAAAAAAAAAAAACYABogADAQAAAAAAAAgH0OAAAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIB9DgAAAAAAAAAAAAAAAJgAGiAAMBEAAAAAAACAfQ4AAAAAAAAAAAAA AACYAAAAIjAAAAAAAAAAgH0OAAAAAAAAAAAAAAAAmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AAAAB7iOADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAkAeYQAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAHuI4AMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACQB5hAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAAAe4jgAwADAAAAAAAAABAAAAAAAAAAAAAAAAAJAHmEAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAAAAB7iOADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAkAeYQAAAEDAAAAAAAAAAgAAA AIAAAAAAAAAAAAAHmEAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJhAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAAGYQAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmEAAAAAwAAAAAAAA AIAAAACAAAAAAAAAAACAALiOADAAMAAAAAAAAAEAAAAAAAAAAAAAAHgykAeYAAAAADAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA ETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAAIzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAgAeYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAIAHmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACAAAAAgAAA AAAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAIAHmAAAAAAwAAAAAAAAAIAAAACA AAAAAAAAAACAB5gAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAAcAAAAAGwAAADsAAAA8AAAA TgAAAE8AAABaAAAAWwAAAGAAAABoAAAAcAAAAHYAAAB8AAAAfQAAAI0AAACdAAAAsAAAAL4A AADOAAAAHAEAAB0BAAAsAQAAQAEAAFgBAABrAQAAfAEAAIkBAACZAQAA5gEAAOcBAADoAQAA 6gEAAGQCAABlAgAAuwIAALwCAAAeBAAAHwQAAH0EAAB+BAAA0wQAANQEAADqBAAA6wQAAKkG AACqBgAAIgcAACMHAACdBwAACAkAAAkJAACACgAAgQoAAB8MAAB8DgAAuA4AAH0PAAC6DwAA bxAAAHAQAAA8EQAAPREAAIwSAACNEgAAuBMAALkTAAApFAAAKhQAAGkVAABqFQAAMBcAADEX AACxFwAAshcAAIIYAADNHAAA/RwAACAoAACYAAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA qwAAABIwAAAAAAAAAIAAAACAAQAAAAAAAAAgB5kAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAA IACpAAAAEjAAAAAAAAAAgAAAAIABAAAAAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAABAAA AAAgAKkAAAASMAAAAAAAAACAAAAAgAEAAAAAAAAAIACZAAAAADAAAAAAAAAAgAAAAIABAAAE AAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAAAAAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEA AAAAAAAAIACpAAAAEjAAAAAAAAAAgAAAAIABAAAAAAAAACAAqQAAABIwAAAAAAAAAIAAAACA AQAAAAAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAAAAAAAAAIACZAAAAADAAAAAAAAAAgAAA AIABAAAEAAAAACAAqQAAABIwAAAAAAAAAIAAAACAAQAAAAAAAAAgAKkAAAASMAAAAAAAAACA AAAAgAEAAAAAAAAAIACpAAAAEjAAAAAAAAAAgAAAAIABAAAAAAAAAAAAqQAAABIwAAAAAAAA AIAAAACAAQAAAAAAAAAgAKkAAAASMAAAAAAAAACAAAAAgAEAAAAAAAAAIACpAAAAEjAAAAAA AAAAgAAAAIABAAAAAAAAACAAmQAAAAAwAAAAAAAAAIAAAACAAQAADAAAAAAgAKkAAAASMAAA AAAAAACAAAAAgAEAAAAAAAAAoACpAAAAEjAAAAAAAAAAgAAAAIABAAAAAAAAAKAAqQAAAAAw AAAAAAAAAIAAAACAAQAAAAAAAACAAKkAAAAAMAAAAAAAAACAAAAAgAEAAAAAAAAAgACpAAAA ADAAAAAAAAAAgAAAAIABAAAAAAAAAIAAqQAAAAAwAAAAAAAAAIAAAACAAQAAAAAAAACgAKkA AAASMAAAAAAAAACAAAAAgAEAAAAAAAAAoACpAAAAADAAAAAAAAAAgAAAAIABAAAAAAAAAIAA qQAAABIwAAAAAAAAAIAAAACAAQAAAAAAAACgAJkAAAAAMAAAAAAAAACAAAAAgAEAAAQAAAAA oACYAAAAETAAAAAAAAAAgAAAAIAAAAAAAAAAAIAACAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA AACAAJgAAAAAMAAAAAAAAACA8AEAAAAAAAAAAAAAgACYAAAAIjAAAAAAAAAAgPABAAAAAAAA AAAAAIAAmAAAACIwAAAAAAAAAIDwAQAAAAAAAAAAAACAAJgAAAAAMAAAAAAAAACA8AEAAAAA AAAAAAAAgACYAAAAEzAAAAAAAAAAgPABAAAAAAAAAAAAAIAACAAAACIwAAAAAAAAAIAAAACA AAAAAAAAAACAAAgAAAAiMAAAAAAAAACAAAAAgAAAAAAAAAAAgAAIAAAAIjAAAAAAAAAAgAAA AIAAAAAAAAAAAIAAmAAAACIwAAAAAAAAAICEBAAAAAAAAAAAAACAAJgAAAAiMAAAAAAAAACA hAQAAAAAAAAAAAAAgACYAAAAADAAAAAAAAAAgIQEAAAAAAAAAAAAAIAAmgAAAAAwAAAAAAAA AICEBAAAAAAAAAAAAAAAB5gAAAAAMAAAAAAAAACAhAQAAAAAAAAAAAAAAACYAAAAADAAAAAA AAAAgIQEAAAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAICEBAAAAAAAAAAAAAAAAJgAHCAAMAAA AAAAAACAhAQAAAAAAAAAAAAAAACaABwgADABAAAAAAAAgIQEAAAAAAAAAAAAAAAHCEAAAAAw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQhAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEIQAAA ADAAAAAAAAAAAAAAAAAAAAAAAAAAAAABCkAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAABwhA AAAAMAAAAAAAAAAAAAAAAAYwnQAAAAAAAAeaAAAAADAAAAAAAAAAgNsDAAAAAAAAAAAAAIAH mgAaIAAwAAAAAAAAAIDbAwAAAAAAAAAAAAAAB5oAGiAAMAEAAAAAAACA2wMAAAAAAAAAAAAA AAeaABogADACAAAAAAAAgNsDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDbAwAAAAAAAAAA AAAAB5oAGiAAMAMAAAAAAACA2wMAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgNsDAAAAAAAA AAAAAAAHmgAaIAAwBAAAAAAAAIDbAwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA2wMAAAAA AAAAAAAAAAeaABogADAFAAAAAAAAgNsDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAAAIDbAwAA AAAAAAAAAAAAB5oAGiAAMAYAAAAAAACA2wMAAAAAAAAAAAAAAAeaAAAAADAAAAAAAAAAgNsD AAAAAAAAAAAAAAAHmgAaIAAwBwAAAAAAAIDbAwAAAAAAAAAAAAAAB5oAAAAAMAAAAAAAAACA 2wMAAAAAAAAAAAAAAAeaABogADAIAAAAAAAAgNsDAAAAAAAAAAAAAAAHmgAAAAAwAAAAAAAA AIDbAwAAAAAAAAAAAAAAB5oAGiAAMAkAAAAAAACA2wMAAAAAAAAAAAAAAAeaAAAAADAAAAAA AAAAgNsDAAAAAAAAAAAAAAAHmgAaIAAwCgAAAAAAAIDbAwAAAAAAAAAAAAAAB5oAGiAAMAsA AAAAAACA2wMAAAAAAAAAAAAAAAeaABogADAEAAAAAAAAgEEDAAAAAAAAAAAAAAAHmgAAAAAw AAAAAAAAAIAAAACAAAAAgAAAAIDaBwAAAAADAAAABgAAAAYAAAAJAAAADAAAAAwAAAAMAAAA TwAAAE8AAADEAAAAxAAAAMQAAADHAAAAAAYAAJgJAABlCgAAHwsAAOALAACKDAAAmg0AALIO AADYEAAAixIAAB4UAABQFgAAuBcAAOUYAADFGwAA4B0AANofAADrIAAAzCQAAC0nAAA7LgAA HjAAAB8wAAAZAAAAIAAAACIAAAAjAAAAJAAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAAC0A AAAvAAAAMAAAADEAAAAyAAAAMwAAADUAAAA2AAAAOAAAADkAAAA7AAAAAAYAAE4IAABbCAAA fQgAAB0JAADnCQAAvAoAAB8UAAC3FgAAsh8AAAMlAAAVMAAAHzAAABoAAAAcAAAAHQAAAB4A AAAfAAAAIQAAACUAAAAsAAAALgAAADQAAAA3AAAAOgAAAAAGAAAeMAAAGwAAAM4AAAD/AAAA GgEAAJkBAADJAQAA4wEAAAMCAAAsAgAAPwIAAHoCAACjAgAAtgIAANMCAAADAwAAHQMAAC8D AABcAwAAcwMAAIUDAAC0AwAAzQMAAOIDAAAJBAAAGgQAAFEIAACxCAAAAgkAAD4LAAC0CwAA GwwAAEQNAABzDQAAjA0AALENAADiDQAA/Q0AAB8OAABPDgAAaQ4AAB8oAAATWBT/FYATWBT/ FYQTWBT/FYATWBT/FYQTWBT/FYATWBT/FYATWBT/FYATWBT/FYATWBT/FYQTWBT/FYATWBT/ FYQTWBT/FYQTWBT/FYQYAAAAMAAAAEwAAABPAAAAaQAAAHQAAAB7AAAAgQAAAIMAAACFAAAA oAAAAMAAAADHAAAAEw+U/5WAExAU/5WAEyEU/xWAExMU/5WABwQAAFQEAACEBAAA0QYAAPoG AAANBwAAMggAAGQIAAB0CAAAOQkAALAJAAAMCgAAWAoAABNY1P8VjBNYFP8VgBNY1P8VjBNY FP8VjA8AAPBAAAAAAAAG8CAAAAACDAAAAwAAAAcAAAACAAAAAQAAAAYAAAACAAAAAwAAAEAA HvEQAAAA//8AAAAA/wCAgIAA9wAAEAEPAALwSAAAACAACPAIAAAAAQAAAAIIAAAPAAPwMAAA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAAAPAALw RgEAABAACPAIAAAAAwAAAAUEAAAPAAPw5AAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAA AAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBcAAAAogwK8AgAAAADBAAAAAoAADMAC/ASAAAA gAAAAAIAigADBAAA/wEAAAgAEwAi8QYAAAC/AwAAAIAAABDwBAAAAAAAAAAAABHwBAAAAAEA AAAAAA3wBAAAAAAAAgAPAATwSAAAAKIMCvAIAAAABAQAAAAKAAAjAAvwDAAAAIAAAAABAIoA BAQAAAAAEPAEAAAAAQAAAAAAEfAEAAAAAQAAAAAADfAEAAAAAAABAA8ABPBCAAAAEgAK8AgA AAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQA AAABAAAA6AEAAOoBAAAfKAAAAwQAAJ3///9EAQAALSQAAEcKAAB0AAEAAAAEBAAAnf///1YM AADhJAAAfiIAAHUAAQAAAMcAAAD//wwAAAAGAEp8WgsQAAEAtCnKCAYAS3xaCwgAAQA8ciIA BgBMfFoLEQABAFwiIQAGAE18WgsQAAEAHP/ICAYATnxaCxEAAQCsfjIMBgBPfFoLEQABACzB GwYGAFB8WgsIAAEAvOscBgYAUXxaCxEAAQDUVksMBgBSfFoLEAABAOzAGwYGAFN8WgsRAAEA FP3NCAYAVHxaCwgAAgDkRB8GBgBVfFoLCAACAGRJ5giNAAAAnQAAAJ0AAACwAAAAsAAAALsA AABcAQAAXAEAAIYBAACGAQAAbwwAAKENAAAgKAAAAAAAAAEAAQAAAAIAAgAAAAIABAAAAAIA AwAAAAIABQAAAAIABgAAAAIABwAAAAIACAAAAAIACQAAAAIACgAAAAEACwAAAAEAkgAAAK4A AACuAAAAuQAAAL0AAAC9AAAAagEAAGoBAACIAQAAiAEAAH4MAACwDQAAICgAAAAAAAABAAAA AgAAAAQAAQADAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAcAAAA6AAAACgAAACqA dXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzBoBTdHJlZXQAgDkA AAAHAAAAKoB1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MFgFN0 YXRlAIBCAAAAAwAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0 YWdzDoBjb3VudHJ5LXJlZ2lvbgCAOwAAAAsAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOnNtYXJ0dGFncweAYWRkcmVzcwCAOAAAAAgAAAAqgHVybjpzY2hlbWFzLW1p Y3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwSAQ2l0eQCAOQAAAAwAAAAqgHVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWAcGxhY2UAgD4AAAACAAAAKoB1 cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MKgFBlcnNvbk5hbWUA gAwAAAEA370JAAAAAAwAAAAAAAsAAAAAAAoAAAAAAAwAAAAAAAgAAAAAAAcAAAAAAAsAAAAA AAoAAAAAAAwAAAAAAAMAAAAAAAIAAAAAAAIAAAAAAAAAAAAsAQAAMwEAADQBAAA4AQAAOQEA AD8BAABAAQAARAEAAGsBAAB7AQAAvAIAAL8CAADAAgAA0QIAAAQDAAAdAwAAIQMAAC0DAABd AwAAcwMAAHcDAACFAwAAtQMAAM0DAADRAwAA4AMAAAoEAAAaBAAAlwoAAJoKAADdCgAA6AoA ALEMAAC0DAAA8wwAAPcMAAAVDQAAHA0AAOoRAAD2EQAA5RMAAO8TAACdFAAApRQAAOgUAADu FAAATBoAAFIaAAD+HAAA/hwAAAAdAAAAHQAAAR0AAAEdAAADHQAABB0AAAYdAAAHHQAACR0A AAodAADCHQAAwx0AABkoAAAgKAAABwAcAAcAHAAHABwABwAcAAcAHAAHAAUABwAFAAcABQAH AAUABwAFAAcABQAHAAUABwAFAAcABQAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAEAAcABAACAAQABwAEAAcABAAHAAQABwACAAcABwAAAAAAvAIAAB0EAABw EAAAkRAAALkTAADaEwAAMRcAAFgXAAD2GQAAQRoAAP4cAAD+HAAAAB0AAAAdAAABHQAAAR0A AAMdAAAEHQAABh0AAAcdAAAJHQAACh0AAMIdAADDHQAAGSgAACAoAAAHAAUABwAzAAcAMwAH ADMABwAzAAcABAAHAAQAAgAEAAcABAAHAAQABwAEAAcAAgAHAAcAAAAAAEABAAB8AQAA6gEA AGwOAAB8DgAAUxgAAIAYAAD+HAAA/hwAAAAdAAAAHQAAAR0AAAEdAAADHQAABB0AAAYdAAAH HQAACR0AAAodAABLHQAAwh0AAMMdAADTJwAAFSgAABkoAAAgKAAABQAHAAUABwAFAAcABQAH AAQABwAEAAIABAAHAAQABwAEAAcABAAFAAcAAgAHAAUABwAHAAAAAAD+HAAA/hwAAAAdAAAA HQAAAR0AAAEdAAADHQAABB0AAAYdAAAHHQAACR0AAAodAADCHQAAwx0AABkoAAAgKAAABwAE AAcABAACAAQABwAEAAcABAAHAAQABwACAAcABwAcAPv///8I59CQ/w//D/8P/w//D/8P/w// D/8PAAAOD+UD8khSGP8P/w//D/8P/w//D/8P/w//DxAA9xAqClZBSl3/D/8P/w//D/8P/w// D/8P/w8QAKt6CQsBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQAxbyoLRHTAf/8P/w//D/8P/w// D/8P/w//DxAA0mxpD0IGEBT/D/8P/w//D/8P/w//D/8P/w8QAIwx7RNgKtwp/w//D/8P/w// D/8P/w//D/8PEAAKI3cV4rUE6/8P/w//D/8P/w//D/8P/w//DxAAkkdIFw8ACQT/DwAAAAAA AAAAAAAAAAAAAAABAEciuR+w1IpM/w//D/8P/w//D/8P/w//D/8PEAAFWY0hSg8UpP8P/w// D/8P/w//D/8P/w//DxAAaAGiJNoGmFr/D/8P/w//D/8P/w//D/8P/w8QAC1+1yTYPjaR/w// D/8P/w//D/8P/w//D/8PEAAAcsoljJ3eWP8P/w//D/8P/w//D/8P/w//DxAAqnkIMxBbcGb/ D/8P/w//D/8P/w//D/8P/w8QAN8pHzmC8cQv/w//D/8P/w//D/8P/w//D/8PEADJaQZA7LAO lf8P/w//D/8P/w//D/8P/w//DxAAmSWDQGzZUlD/D/8P/w//D/8P/w//D/8P/w8QAE0pFEPa uAKH/w//D/8P/w//D/8P/w//D/8PEADrL0BDJQAJBP8P/w//D/8P/w//D/8P/w//DwAATE9Z SK4uHr7/D/8P/w//D/8P/w//D/8P/w8QAMsw4kyIhdA6/w//D/8P/w//D/8P/w//D/8PEAAW OMxVVkM2pP8P/w//D/8P/w//D/8P/w//DxAAMzVcW/7nyCX/D/8P/w//D/8P/w//D/8P/w8Q ABIQb3SSSiwy/w//D/8P/w//D/8P/w//D/8PEAB8BiN1ru1u5/8P/w//D/8P/w//D/8P/w// DxAATmvydph4uJb/D/8P/w//D/8P/w//D/8P/w8AAA1SY3vAJNYN/w//D/8P/w//D/8P/w// D/8PEAABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJg hDD9bygAAgAAAC4AAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgBAA+EoAURhDD9FcYFAAEA AAZehKAFYIQw/W8oAAQAAAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAMGAIAD4Rw CBGEMP0VxgUAAXAIBl6EcAhghDD9QioQbygAcGiysrIABgAAAC4AAQAuAAIALgABAAAAAAAB AwUHAAAAAAAAAAAAAAAAAAAMGAMAD4RACxGEMP0VxgUAAagMBl6EQAtghDD9QioQbygAcGiy srIACAAAAC4AAQAuAAIALgADAC4AAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAADBgEAA+EEA4R hDD9FcYFAAHgEAZehBAOYIQw/UIqEG8oAHBosrKyAAoAAAAuAAEALgACAC4AAwAuAAQALgAB AAAAAAABAwUHCQsAAAAAAAAAAAAAAAAMGAUAD4TgEBGEMP0VxgUAAbATBl6E4BBghDD9QioQ bygAcGiysrIADAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAAAAABAwUHCQsNAAAAAAAA AAAAAAAMGAYAD4SwExGEMP0VxgUAAegXBl6EsBNghDD9QioQbygAcGiysrIADgAAAC4AAQAu AAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAADBgHAA+EgBYR hDD9FcYFAAEgHAZehIAWYIQw/UIqEG8oAHBosrKyABAAAAAuAAEALgACAC4AAwAuAAQALgAF AC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAMGAgAD4RQGRGEMP0VxgUAAfAe Bl6EUBlghDD9QioQbygAcGiysrIAEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAu AAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFg hJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkY AAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACISAAAAQBv AAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5P SggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E cAgRhJj+FcYFAAFwCAZehHAIYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAAZGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oGAFFKBgBe SgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4QQDhGE mP4VxgUAARAOBl6EEA5ghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAA AAAAAABoAQAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgEAUUoBAG8oAIdo AAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EsBMRhJj+FcYFAAGw EwZehLATYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAA AGgBAAAAAAAAFRgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KCABRSggAbygAh2gAAAAA iEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdACBl6E 0AJghJj+T0oBAFFKAQBvKAABALfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXEAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSggAUUoIAG8oAAEAp/ABAAAAFxAA AAAAAAAAAAAAaAEAAAAAAAAZGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oGAFFKBgBe SgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4QQDhGE mP4VxgUAARAOBl6EEA5ghJj+T0oGAFFKBgBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8o AAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZg hJj+T0oGAFFKBgBvKAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EUBkRhJj+ FcYFAAFQGQZehFAZYISY/k9KCABRSggAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AAsYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAATGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+T0oBAFBKAABRSgEA XkoAAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SgBRGEmP4VxgUAAaAF Bl6EoAVghJj+T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAAVGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oIAFFKCABvKACHaAAAAACI SAAAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhEALEYSY/hXGBQABQAsGXoRA C2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA GRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAAB AG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAFRgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY /k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAA D4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAABkYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgYAUUoG AF5KBgBvKACHaAAAAACISAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhFAZ EYSY/hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABcQAAAA AAAAAAAAAGgBAAAAAAAAFRgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygA h2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4SgBRGEmP4VxgUA AaAFBl6EoAVghJj+T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAAVGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oIAFFKCABvKACHaAAA AACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhEALEYSY/hXGBQABQAsG XoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhI AAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E4BARhJj+FcYFAAHgEAZehOAQ YISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAV GAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgYA UUoGAF5KBgBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAP hFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABcQ AAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAQBRSgEA bygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4SgBRGEmP4V xgUAAaAFBl6EoAVghJj+T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAA AAAAAAAAaAEAAAAAAAAVGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+T0oIAFFKCABvKACH aAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgB AAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAA AIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E4BARhJj+FcYFAAHgEAZe hOAQYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC3 8AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAPhIAWEYSY/hXGBQABgBYGXoSAFmCEmP5P SgYAUUoGAF5KBgBvKACHaAAAAACISAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUY AAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAA ABcQAAAAAAAAAAAAAGgBAAAAAAAAHhgAkQ+EaAERhJj+FcYFAAFoAQZehGgBYISY/kIqAE9K AQBRSgEAbygAcGgAAAD/h2gAAAAAiEgAAAEAt/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAe GAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+QioAT0oBAFFKAQBvKABwaAAAAP+HaAAAAACI SAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhKAFEYSY/hXGBQABoAUGXoSg BWCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oG AFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAX kAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSgEAUUoB AG8oAIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EsBMRhJj+ FcYFAAGwEwZehLATYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAAFRgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KCABRSggAbygA h2gAAAAAiEgAAAEAp/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RoARGEmP4VxgUA AWgBBl6EaAFghJj+AgAAAC4AAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAAFRgAAA+E0AIRhJj+ FcYFAAHQAgZehNACYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAAF5AAAAAAAAAA AAAAaAEAAAAAAAAZGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oGAFFKBgBeSgYAbygA h2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RwCBGEmP4VxgUA AXAIBl6EcAhghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAAAAAAAAAAAABo AQAAAAAAABUYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAIdoAAAAAIhI AAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EEA4RhJj+FcYFAAEQDgZehBAO YISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAAAAAAAGgBAAAA AAAAFRgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAh2gAAAAAiEgAAAEA p/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+ T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABkYAAAP hIAWEYSY/hXGBQABgBYGXoSAFmCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACISAAAAQBvAAEA AAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhFAZEYSY/hXGBQABUBkGXoRQGWCEmP5PSggA UUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABcQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EvgIR hJj+FcYFAAG+AgZehL4CYISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhI4FEYSY/hXGBQABjgUGXoSOBWCEmP5PSgYAUUoGAG8oAAEAbwABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4ReCBGEmP4VxgUAAV4IBl6EXghghJj+T0oIAFFKCABv KAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+ELgsRhJj+FcYFAAEuCwZehC4L YISY/k9KAQBRSgEAbygAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhP4NEYSY /hXGBQAB/g0GXoT+DWCEmP5PSgYAUUoGAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAA AAALGAAAD4TOEBGEmP4VxgUAAc4QBl6EzhBghJj+T0oIAFFKCABvKAABAKfwAQAAABeQAAAA AAAAAAAAAGgBAAAAAAAACxgAAA+EnhMRhJj+FcYFAAGeEwZehJ4TYISY/k9KAQBRSgEAbygA AQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhG4WEYSY/hXGBQABbhYGXoRuFmCE mP5PSgYAUUoGAG8oAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4Q+GRGEmP4V xgUAAT4ZBl6EPhlghJj+T0oIAFFKCABvKAABAKfwAQAAAAAQAQAAAAAAAAAAAGgBAAAAAAAA ChgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/odoAAAAAIhIAAACAAAALgABAAAABJABAAAA AAAAAAAAaAEAAAAAAAAKGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+h2gAAAAAiEgAAAIA AQAuAAEAAAACkgEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCE TP+HaAAAAACISAAAAgACAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EQAsRhJj+ FcYFAAFACwZehEALYISY/odoAAAAAIhIAAACAAMALgABAAAABJABAAAAAAAAAAAAaAEAAAAA AAAKGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+h2gAAAAAiEgAAAIABAAuAAEAAAACkgEA AAAAAAAAAABoAQAAAAAAAAoYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP+HaAAAAACISAAA AgAFAC4AAQAAAACQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EsBMRhJj+FcYFAAGwEwZehLAT YISY/odoAAAAAIhIAAACAAYALgABAAAABJABAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4SAFhGE mP4VxgUAAYAWBl6EgBZghJj+h2gAAAAAiEgAAAIABwAuAAEAAAACkgEAAAAAAAAAAABoAQAA AAAAAAoYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCETP+HaAAAAACISAAAAgAIAC4AEAAAABcA AAAAAAAAAAAAAAAAAAAAAAAAExgAAA+E0AIRhJj+FcYFAAHQAgZehNACYISY/k9KAABQSgAA UUoAAF5KAABvKAABAC0AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KCABRSggAbygAh2gA AAAAiEgAAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RACxGEmP4VxgUAAUAL Bl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAABkYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACI SAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAGXoTg EGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA FRgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oG AFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAA D4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAABUYAIEPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoB AG8oAIdoAAAAAIhIAAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KCABRSggAbygA h2gAAAAAiEgAAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RACxGEmP4VxgUA AUALBl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAABkYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgYAUUoGAF5KBgBvKACHaAAA AACISAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAG XoTgEGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAAFRgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEA t/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+ T0oGAFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAV GAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5vKAAC AAAALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVg hJj+AgABAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EcAgRhEz/FcYFAAFwCAZe hHAIYIRM/wIAAgAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP4CAAMALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4QQDhGEmP4V xgUAARAOBl6EEA5ghJj+AgAEAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+E4BAR hEz/FcYFAAHgEAZehOAQYIRM/wIABQAuAAEAAAAAgAEAAAAAAAAAAAAAAAAAAAAAAAAYAAAP hLATEYSY/hXGBQABsBMGXoSwE2CEmP4CAAYALgABAAAABIABAAAAAAAAAAAAAAAAAAAAAAAA GAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+AgAHAC4AAQAAAAKCAQAAAAAAAAAAAAAAAAAA AAAAABgAAA+EUBkRhEz/FcYFAAFQGQZehFAZYIRM/wIACAAuAAEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oGAFFK BgBvKAABAG8AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZe hHAIYISY/k9KCABRSggAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oGAFFKBgBvKAABAG8AAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggA bygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSw E2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGE mP4VxgUAAYAWBl6EgBZghJj+T0oGAFFKBgBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAACxgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KCABRSggAbygAAQCn8AEAAAAXAAAA AAAAAAAAAABoAQAAAAAAABUYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8o AIdoAAAAAIhIAAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAGRgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KCABRSggAbygAh2gA AAAAiEgAAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAAD4RACxGEmP4VxgUAAUAL Bl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAABkYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACI SAAAAQBvAAEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAGXoTg EGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA FRgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAZGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oG AFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAVGAAA D4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAA EAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACI SAAAAgAAAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/odoAAAAAIhIAAACAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4Rw CBGETP8VxgUAAXAIBl6EcAhghEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAAAABo AQAAAAAAAAoYAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAA AASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAA AIhIAAACAAQALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQ Bl6E4BBghEz/h2gAAAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAP hLATEYSY/hXGBQABsBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAChgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgAB AAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gA AAAAiEgAAAIACAAuAAEAAAAXEAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhNACEYSY/hXGBQAB 0AIGXoTQAmCEmP5PSgEAUUoBAG8oAIdoAAAAAIhIAAABALfwAQAAABcQAAAAAAAAAAAAAGgB AAAAAAAACxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBgBRSgYAbygAAQBvAAEAAAAX kAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSggAUUoI AG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6E QAtghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4R hJj+FcYFAAEQDgZehBAOYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAA AAAAAAsYAAAPhOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSggAUUoIAG8oAAEAp/ABAAAAF5AA AAAAAAAAAAAAaAEAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBv KAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY /hXGBQABUBkGXoRQGWCEmP5PSggAUUoIAG8oAAEAp/ABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAKGAAAD4SwARGEUP4VxgUAAbABBl6EsAFghFD+h2gAAAAAiEgAAAEAAAABAAAAAAABAwAA AAAAAAAAAAAAAAAAAAAKGAAAD4RAAhGEwP0VxgUAAUACBl6EQAJghMD9h2gAAAAAiEgAAAMA AAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAChgAAA+E0AIRhDD9FcYFAAHQAgZehNAC YIQw/YdoAAAAAIhIAAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAAKGAAA D4RgAxGEoPwVxgUAAWADBl6EYANghKD8h2gAAAAAiEgAAAcAAAAuAAEALgACAC4AAwABAAAA AAABAwUHCQAAAAAAAAAAAAAAAAAKGAAAD4TwAxGEEPwVxgUAAfADBl6E8ANghBD8h2gAAAAA iEgAAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAAAAAQMFBwkLAAAAAAAAAAAAAAAAChgAAA+E gAQRhID7FcYFAAGABAZehIAEYISA+4doAAAAAIhIAAALAAAALgABAC4AAgAuAAMALgAEAC4A BQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAKGAAAD4QQBRGE8PoVxgUAARAFBl6EEAVghPD6 h2gAAAAAiEgAAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAA AAAAAAAAAAAKGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6h2gAAAAAiEgAAA8AAAAuAAEA LgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAAChgAAA+E MAYRhND5FcYFAAEwBgZehDAGYITQ+YdoAAAAAIhIAAARAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYALgAHAC4ACAABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUA AdACBl6E0AJghJj+T0oBAFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAA AABoAQAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSggAUUoIAG8oAAEAp/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oB AFFKAQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAP hOAQEYSY/hXGBQAB4BAGXoTgEGCEmP5PSggAUUoIAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAA aAEAAAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAA ABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBgBR SgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkG XoRQGWCEmP5PSggAUUoIAG8oAAEAp/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQ AhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAAACkAAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAA ABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIAAQAuAAEAAAACggEAAAAAAAAAAAAAAAAA AAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8CAAIALgABAAAAAIABAAAAAAAAAAAA AAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+AgADAC4AAQAAAASAAQAAAAAA AAAAAAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/gIABAAuAAEAAAACggEA AAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCETP8CAAUALgABAAAA AIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+AgAGAC4A AQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/gIA BwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQGWCE TP8CAAgALgABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4TQAhGEmP4VxgUAAdACBl6E 0AJghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAAAAAA ABkYAAAPhKAFEYSY/hXGBQABoAUGXoSgBWCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACISAAA AQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCE mP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAFRgA AA+EQAsRhJj+FcYFAAFACwZehEALYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oGAFFK BgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4Tg EBGEmP4VxgUAAeAQBl6E4BBghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8AEAAAAXkAAA AAAAAAAAAABoAQAAAAAAABUYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEAUUoBAG8o AIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAAFRgAAA+EUBkRhJj+FcYFAAFQGQZehFAZYISY/k9KCABRSggAbygAh2gA AAAAiEgAAAEAp/ABAAAAFxAAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4TQAhGEmP4VxgUAAdAC Bl6E0AJghJj+T0oIAFFKCABvKAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABo AQAAAAAAAAsYAAAPhHAIEYSY/hXGBQABcAgGXoRwCGCEmP5PSggAUUoIAG8oAAEAp/ABAAAA F5AAAAAAAAAAAAAAaAEAAAAAAAALGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+T0oBAFFK AQBvKAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/k9KBgBRSgYAbygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhOAQ EYSY/hXGBQAB4BAGXoTgEGCEmP5PSggAUUoIAG8oAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEA AAAAAAALGAAAD4SwExGEmP4VxgUAAbATBl6EsBNghJj+T0oBAFFKAQBvKAABALfwAQAAABeQ AAAAAAAAAAAAAGgBAAAAAAAACxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/k9KBgBRSgYA bygAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAAAsYAAAPhFAZEYSY/hXGBQABUBkGXoRQ GWCEmP5PSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAATGAAAD4TQAhGE mP4VxgUAAdACBl6E0AJghJj+T0oAAFBKAABRSgAAXkoAAG8oAAEALQABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAALGAAAD4SgBRGEmP4VxgUAAaAFBl6EoAVghJj+T0oGAFFKBgBvKAABAG8A AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9K CABRSggAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP5PSgEAUUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAA D4QQDhGEmP4VxgUAARAOBl6EEA5ghJj+T0oGAFFKBgBvKAABAG8AAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAACxgAAA+E4BARhJj+FcYFAAHgEAZehOAQYISY/k9KCABRSggAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAAsYAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5PSgEA UUoBAG8oAAEAt/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAALGAAAD4SAFhGEmP4VxgUAAYAW Bl6EgBZghJj+T0oGAFFKBgBvKAABAG8AAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAACxgAAA+E UBkRhJj+FcYFAAFQGQZehFAZYISY/k9KCABRSggAbygAAQCn8AEAAAAAEAEAAAAAAAAAAABo AQAAAAAAAAoYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP6HaAAAAACISAAAAgAAAC4AAQAA AASQAQAAAAAAAAAAAGgBAAAAAAAAChgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/odoAAAA AIhIAAACAAEALgABAAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4RwCBGETP8VxgUAAXAI Bl6EcAhghEz/h2gAAAAAiEgAAAIAAgAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAP hEALEYSY/hXGBQABQAsGXoRAC2CEmP6HaAAAAACISAAAAgADAC4AAQAAAASQAQAAAAAAAAAA AGgBAAAAAAAAChgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/odoAAAAAIhIAAACAAQALgAB AAAAApIBAAAAAAAAAAAAaAEAAAAAAAAKGAAAD4TgEBGETP8VxgUAAeAQBl6E4BBghEz/h2gA AAAAiEgAAAIABQAuAAEAAAAAkAEAAAAAAAAAAABoAQAAAAAAAAoYAAAPhLATEYSY/hXGBQAB sBMGXoSwE2CEmP6HaAAAAACISAAAAgAGAC4AAQAAAASQAQAAAAAAAAAAAGgBAAAAAAAAChgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/odoAAAAAIhIAAACAAcALgABAAAAApIBAAAAAAAA AAAAaAEAAAAAAAAKGAAAD4RQGRGETP8VxgUAAVAZBl6EUBlghEz/h2gAAAAAiEgAAAIACAAu AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5D ShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/kNKFABPSgYAUUoGAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCABRSggAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQA T0oIAFFKCABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYF AAEQDgZehBAOYISY/kNKFABPSggAUUoIAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCABRSggAbygAAQCn8AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oI AFFKCABvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/kNKFABPSggAUUoIAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCABRSggAbygAAQCn8AEAAAAXEAAA AAAAAAAAAABoAQAAAAAAABUYAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5PSgEAUUoBAG8o AIdoAAAAAIhIAAABALfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAAGRgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/k9KBgBRSgYAXkoGAG8oAIdoAAAAAIhIAAABAG8AAQAAABeQAAAAAAAA AAAAAGgBAAAAAAAAFRgAAA+EcAgRhJj+FcYFAAFwCAZehHAIYISY/k9KCABRSggAbygAh2gA AAAAiEgAAAEAp/ABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAAD4RACxGEmP4VxgUAAUAL Bl6EQAtghJj+T0oBAFFKAQBvKACHaAAAAACISAAAAQC38AEAAAAXkAAAAAAAAAAAAABoAQAA AAAAABkYAAAPhBAOEYSY/hXGBQABEA4GXoQQDmCEmP5PSgYAUUoGAF5KBgBvKACHaAAAAACI SAAAAQBvAAEAAAAXkAAAAAAAAAAAAABoAQAAAAAAABUYAAAPhOAQEYSY/hXGBQAB4BAGXoTg EGCEmP5PSggAUUoIAG8oAIdoAAAAAIhIAAABAKfwAQAAABeQAAAAAAAAAAAAAGgBAAAAAAAA FRgAAA+EsBMRhJj+FcYFAAGwEwZehLATYISY/k9KAQBRSgEAbygAh2gAAAAAiEgAAAEAt/AB AAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAZGAAAD4SAFhGEmP4VxgUAAYAWBl6EgBZghJj+T0oG AFFKBgBeSgYAbygAh2gAAAAAiEgAAAEAbwABAAAAF5AAAAAAAAAAAAAAaAEAAAAAAAAVGAAA D4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+T0oIAFFKCABvKACHaAAAAACISAAAAQCn8BwAAADr L0BDAAAAAAAAAAAAAAAAyWkGQAAAAAAAAAAAAAAAADFvKgsAAAAAAAAAAAAAAAD3ECoKAAAA AAAAAAAAAAAAMzVcWwAAAAAAAAAAAAAAAMsw4kwAAAAAAAAAAAAAAABMT1lIAAAAAAAAAAAA AAAATSkUQwAAAAAAAAAAAAAAAC1+1yQAAAAAAAAAAAAAAAAKI3cVAAAAAAAAAAAAAAAABVmN IQAAAAAAAAAAAAAAAA4P5QMAAAAAAAAAAAAAAADSbGkPAAAAAAAAAAAAAAAAAHLKJQAAAAAA AAAAAAAAAEciuR8AAAAAAAAAAAAAAAAWOMxVAAAAAAAAAAAAAAAAkkdIFwAAAAAAAAAAAAAA AIwx7RMAAAAAAAAAAAAAAAANUmN7AAAAAAAAAAAAAAAA3ykfOQAAAAAAAAAAAAAAAKt6CQsA AAAAAAAAAAAAAAASEG90AAAAAAAAAAAAAAAA+////wAAAAAAAAAAAAAAAKp5CDMAAAAAAAAA AAAAAABOa/J2AAAAAAAAAAAAAAAAmSWDQAAAAAAAAAAAAAAAAGgBoiQAAAAAAAAAAAAAAAB8 BiN1AAAAAAAAAAAAAAAA//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8cAAAAAAASAAEACQQDAAkEBQAJBAEACQQD AAkEBQAJBAEACQQDAAkEBQAJBBIAAQAJBAMACQQFAAkEAwAJBAMACQQFAAkEAQAJBAMACQQF AAkEAAASAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIAAQAJBAMACQQF AAkEAQAJBAMACQQFAAkEAQAJBAMACQQFAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQB AAkEAwAJBAUACQQSAP////8BAAkE/////////////////////////////////////wAAEgAB AAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAHZjuv0DAAkEBQAJBAEACQQD AAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQb AAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAAEACQQDAAkEBQAJ BAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQbAAkEDwAJ BBkACQQbAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAGChoh4D AAkEBQAJBAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBBIADwAJBBkACQQbAAkEDwAJBBkACQQb AAkEDwAJBBkACQQbAAkEEgABAAkEAwAJBAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQA ABIA////////////////////////////////////////////////EgABAAkEAwAJBAUACQQB AAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAAEACQQDAAkEBQAJBAEACQQDAAkEBQAJBAEACQQD AAkEBQAJBBIAgqG46BkACQQbAAkEDwAJBBkACQQbAAkEDwAJBBkACQQbAAkEEgCiyUbIAwAJ BAUACQQBAAkEAwAJBAUACQQBAAkEAwAJBAUACQQSAA8ACQQZAAkEGwAJBA8ACQQZAAkEGwAJ BA8ACQQZAAkEGwAJBAAAEgAE1/DwJrz6N0w1ZKoSR6oa3Au85cxXPk9Iini+eMvwjQydmHIV APZrHwMFTQVsAAAAAAAAHzdJBwAAAAAAAAAAAAECAAIAW2/6CQAAAAAAAAAAAAECAAIANFf6 CgAAAAAAAAAAAAECAAIASgFxDAAAAAAAAAAAAAECAAIAHz5qDRx3bk8AAAAAAgAEAFwNAABz GOUO1nRkfwAAAAAAAPsYRBGHU6NXAAAAABAACAAAAAD/MAEAAOE70BcAAAAAAAAAAAABAgAC ALtsdyLYE6BZAAAAAAAAPhgpKltv+gkAAAAAAACWfUBMcxjlDgAAAAAAABx3bk/7GEQRAAAA AAAAh1OjVzZvA3AAAAAAAQAEALgIAADYE6BZAAAAAAAAAAAAAQIAAgD3PAxaOXYzZgAAAAAA ADl2M2YfPmoNAAAAAAAABU0FbJZ9QEwAAAAAAAA2bwNwNFf6CgAAAAAAAB5ctHwAAAAAAAAA AAABAgACANZ0ZH/3PAxaAAAAAAAAdwAAAAQAAAAIAAAA5QAAAAAAAAB2AAAAyjYAAH0iAQBP YwEAjQADAIB0BwAhcAwAMSsNAOtnDgAhdREAblITAI4FGADREB4AS2MlAHdLJgAkZy4APEov AAB4LwCWDDEArXo0AKNVNgAgfzYAlls3ALpmOgCVbzwA7Sw9AIZVPwDcAUAA1kxDAJMnRAC+ WkkART9LABoETQBaQE8AExdQAKt2UACdSFQAwDBYALJrWABKFVsA9C5bAMo2XwAaBmMApg5k AKsTaAAiRGgAO1lpAAkCawBGBGsAGyprAPdmbADgRm0AMEptAKN8cQDXPHIABg50ABszdACU SXQAPgx2AEAzdwCiJXkA2QV7AMUmfACAEX8A3DyAAFxGgAAIXYIAih2EAKoBhgAbM4kASDCM ADxSjgDJZJEA1jOVAHZFlgC1UpYAKBeYAEQFmgBrKZsA7WWbAD9RoQAxRKQAlkmmALgUpwAj HqcA2DWsANUDrQA2aa0A1ECxANl9sgD3brMAEgu3AKxSuABnLL8AZRPAAN0qwQDzFcIAgQnG AAVrxgA6VscA5HTKAAAU0gAfd9MAqF7VAGg41gCWVtsAEHnfAIA74ACIPuIA5mfiAJRp6ADb D+kA3zXpACp56QC8Q+8ANFXvAB4y9QDWJ/YA9zP8ANxq/AAAAAAAGwAAADsAAAA8AAAATgAA AE8AAABaAAAAWwAAAGAAAABoAAAAcAAAAHYAAAB8AAAAfQAAAI0AAACdAAAAvgAAAM4AAAAc AQAAHQEAACwBAABAAQAAiQEAAJkBAADnAQAA6AEAAP4cAAAAHQAAAx0AAAYdAAAJHQAAFB0A ABYdAABLHQAAwR0AAMMdAADTJwAAEigAACAoAAAAAAAACAAAAAIBAACeAQAEAgEAAJ4BAAQC AQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEABAIBAAACAQAAAgEAAAIBAAACAQAAngEA BAIBAAACAQAAAgEAAAIBAAACAQAAlgEABAAAAAAB/wAAAf8AAAH/AAAB/wAAAf8AAB8y9QAf MvUAHzL1AAAAAAAVAAAAAAAAAP9AA4ABAAAAAAAAAAAAjAKDEwEAAQAAAAAAAAAAAAAAAAAA AAAAAhAAAAAAAAAAHygAAKABABAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAA AAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAkAAABHFpABAAACAgYD BQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8A bQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0A YgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkA YQBsAAAARxGQAYAKAgIGCQQCBQgDBAEAAAAAAAcIEAAAAAAAAAAAAAIAAAAAAE0AUwAgAE0A aQBuAGMAaABvAAAALf8z/yAADmYdZwAAVRKQAQARAgsGBAICAgICBAMAAAAAAAAAAAAAAAAA AAABAAAAAAAAAEEAcgBpAGEAbAAgAFUAbgBpAGMAbwBkAGUAIABNAFMAAABBAHIAaQBhAGwA AAA1JpABAAACCwYEAwUEBAIEh3oAYQAAAIAIAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEA AAA/NZABAAACBwMJAgIFAgQEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQwBvAHUAcgBpAGUA cgAgAE4AZQB3AAAASQGQAYEHAgMGAAABAQEBAQEAAAAAAAYJEAAAAAAAAAAAAAgAAAAAAEIA YQB0AGEAbgBnAAAAogCuAKEA1wBJAG8AVQBBAEEAAAA7BpABAgAFAAAAAAAAAAAAAAAAAAAA ABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAAAiAAQAAwGoGFb80ALkBGgB AAAAAJZ7s4aWe7OGhyKxhgIAKQAAAFMEAACrGAAAAQAOAAAABACDADQAAABTBAAAqxgAAAEA DgAAADQAAAAAAAAAIQNW/BAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAApQbAB7QAtACAABI0AAAQABkAZAAAABkAAADwHAAA8BwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAA AAAMQoNxVvwQBN/fAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhYAAAAAAjw/w8BAAE/ AADkBAAA////f////3////9/////f////3////9/////f2g41gAAAAAAMgAAAAAAAAAAAAAA AAABAAAA//8SAAAAAABsAEMAOgBcAEQAbwBjAHUAbQBlAG4AdABzACAAYQBuAGQAIABTAGUA dAB0AGkAbgBnAHMAXABzAG0ALgBDAE8ATQBNAFwAQQBwAHAAbABpAGMAYQB0AGkAbwBuACAA RABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVABlAG0AcABsAGEAdABlAHMAXAA4ADAA MgAuADEAMQBcADgAMAAyAC0AMQAxAC0AUwB1AGIAbQBpAHMAcwBpAG8AbgAtAFAAbwByAHQA cgBhAGkAdAAuAGQAbwB0ABsAZABvAGMALgA6ACAASQBFAEUARQAgADgAMAAyAC4AMQAxAC0A MAA3AC8AMAA0ADcANgByADEACgBTAHUAYgBtAGkAcwBzAGkAbwBuAAoATQBhAHIAYwBoACAA MgAwADAANwAaAEoAbwBoAG4AIABEAG8AZQAsACAAUwBvAG0AdwBoAGUAcgBlACAAQwBvAG0A cABhAG4AeQAPAEQAbwByAG8AdABoAHkAIABTAHQAYQBuAGwAZQB5AAgAZABzAHQAYQBuAGwA ZQB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAfAAAAAYAAAAcAAAAAAAMAAEADAACAAwAAwAMAAQA DAAFAAwABgAMAAcADAAIAAwACQAMAAoADAALAAwADAAMAA0ADAAOAAwADwAMABAADAARAAwA EgAMABMADAAUAAwAFQAMABYADAAXAAwAGAAMABkADAAaAAwAGwAMAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAA4AEAABIAAAABAAAAmAAAAAIAAACgAAAAAwAAAMQAAAAEAAAA2AAAAAUA AADwAAAABgAAAAQBAAAHAAAALAEAAAgAAABQAQAACQAAAGQBAAASAAAAcAEAAAoAAACQAQAA CwAAAJwBAAAMAAAAqAEAAA0AAAC0AQAADgAAAMABAAAPAAAAyAEAABAAAADQAQAAEwAAANgB AAACAAAA5AQAAB4AAAAcAAAAZG9jLjogSUVFRSA4MDIuMTEtMDcvMDQ3NnIxAB4AAAAMAAAA U3VibWlzc2lvbgAAHgAAABAAAABEb3JvdGh5IFN0YW5sZXkAHgAAAAwAAABNYXJjaCAyMDA3 AAAeAAAAIAAAAERvcm90aHkgU3RhbmxleSwgQXJ1YmEgTmV0d29ya3MAHgAAABwAAAA4MDIt MTEtU3VibWlzc2lvbi1Qb3J0cmFpdAAAHgAAAAwAAABkc3RhbmxleQAAAAAeAAAABAAAADIA AAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29yZAAAAEAAAAAANka6BQAAAEAAAAAAEk+/ IjDHAUAAAAAATLz3R2fHAUAAAAAATLz3R2fHAQMAAAABAAAAAwAAAFMEAAADAAAAqxgAAAMA 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 AAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmu RAAAAAXVzdWcLhsQk5cIACss+a5kAQAAIAEAAA0AAAABAAAAcAAAAA8AAAB4AAAABAAAAJAA AAAFAAAAmAAAAAYAAACgAAAAEQAAAKgAAAAXAAAAsAAAAAsAAAC4AAAAEAAAAMAAAAATAAAA yAAAABYAAADQAAAADQAAANgAAAAMAAAAAAEAAAIAAADkBAAAHgAAABAAAABBcnViYSBOZXR3 b3JrcwAAAwAAAAA+AAADAAAANAAAAAMAAAAOAAAAAwAAAPAcAAADAAAAuh8LAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAcAAAAZG9jLjogSUVFRSA4MDIuMTEt MDcvMDQ3NnIxAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAA/AkAAAgAAAAAAAAA SAAAAAEAAADoAAAAAgAAAPAAAAADAAAAdAkAAAQAAAB8CQAABQAAALQJAAAGAAAA2AkAAAcA AADwCQAABgAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAwAAABQAAABfQWRIb2NSZXZpZXdDeWNs ZUlEAAQAAAAOAAAAX0VtYWlsU3ViamVjdAAFAAAADQAAAF9BdXRob3JFbWFpbAAGAAAAGAAA AF9BdXRob3JFbWFpbERpc3BsYXlOYW1lAAcAAAAZAAAAX1Jldmlld2luZ1Rvb2xzU2hvd25P bmNlAAIAAADkBAAAQQAAAHwIAABgAAAAAwAAAEQAfgADAAAAJAAAAAMAAAAAAAAAAwAAAAUA AAAfAAAAIQAAAG0AYQBpAGwAdABvADoAcwB0AGUAcABoAGUAbgAuAG0AYwBjAGEAbgBuAEAA cgBvAGsAZQAuAGMAbwAuAHUAawAAAAAAHwAAAAEAAAAAAM4RAwAAAEgAdgADAAAAIQAAAAMA AAAAAAAAAwAAAAUAAAAfAAAAIgAAAG0AYQBpAGwAdABvADoAZABzAHQAYQBuAGwAZQB5AEAA YQByAHUAYgBhAG4AZQB0AHcAbwByAGsAcwAuAGMAbwBtAAAAHwAAAAEAAAAAAM4RAwAAACsA WgADAAAAHgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIAAAAG0AYQBpAGwAdABvADoAcwB0AHUA YQByAHQALgBrAGUAcgByAHkAQABwAGgAaQBsAGkAcABzAC4AYwBvAG0AAAAfAAAAAQAAAAAA zhEDAAAAIgAhAAMAAAAbAAAAAwAAAAAAAAADAAAABQAAAB8AAABnAAAAZgB0AHAAOgAvAC8A ZgB0AHAALgA4ADAAMgB3AGkAcgBlAGwAZQBzAHMAdwBvAHIAbABkAC4AYwBvAG0ALwAxADEA LwAwADcALwAxADEALQAwADcALQAwADIANwA0AC0AMAAxAC0AMAAwADAAdQAtAHMAcwBwAG4A LQBpAG4AdABlAHIAZgBhAGMAZQAtAGkAbgB0AGUAcgBuAGEAbAAtAGMAbwBtAG0AZQBuAHQA LQByAGUAcwBvAGwAdQB0AGkAbwBuAC4AZABvAGMAAAAAAB8AAAABAAAAAADOEQMAAAAWAA0A AwAAABgAAAADAAAAAAAAAAMAAAAFAAAAHwAAAFEAAABmAHQAcAA6AC8ALwBmAHQAcAAuADgA MAAyAHcAaQByAGUAbABlAHMAcwB3AG8AcgBsAGQALgBjAG8AbQAvADEAMQAvADAANwAvADEA MQAtADAANwAtADAAMgA5ADAALQAwADIALQAwADAAMAB1AC0AZQBtAGUAcgBnAGUAbgBjAHkA LQBjAGEAbABsAC0AcwBlAHQAdQBwAC4AcABwAHQAAAAAAB8AAAABAAAAAADOEQMAAAAlABwA AwAAABUAAAADAAAAAAAAAAMAAAAFAAAAHwAAABgAAABtAGEAaQBsAHQAbwA6AGYAbAB1AGYA ZgB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AAAAfAAAAAQAAAAAAzhEDAAAAaQAPAAMAAAASAAAA AwAAAAAAAAADAAAABQAAAB8AAAAgAAAAbQBhAGkAbAB0AG8AOgBqAG8AbgAuAHAAZQB0AGUA cgBzAG8AbgBAAG4AZQB1AHMAdABhAHIALgBiAGkAegAAAB8AAAABAAAAAADOEQMAAABKACcA AwAAAA8AAAADAAAAAAAAAAMAAAAFAAAAHwAAAB4AAABtAGEAaQBsAHQAbwA6AG0AYQByAGMA LgBsAGkAbgBzAG4AZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0AAAAfAAAAAQAAAAAAzhEDAAAA JABeAAMAAAAMAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAAbQBhAGkAbAB0AG8AOgBIAGEA bgBuAGUAcwAuAFQAcwBjAGgAbwBmAGUAbgBpAGcAQABnAG0AeAAuAG4AZQB0AAAAAAAfAAAA AQAAAAAAzhEDAAAAawAFAAMAAAAJAAAAAwAAAAAAAAADAAAABQAAAB8AAAAaAAAAbQBhAGkA bAB0AG8AOgBiAHIAYwBAAHoAdQByAGkAYwBoAC4AaQBiAG0ALgBjAG8AbQAAAB8AAAABAAAA AADOEQMAAAAMAHcAAwAAAAYAAAADAAAAAAAAAAMAAAAFAAAAHwAAABoAAABtAGEAaQBsAHQA bwA6AHMAdAB1AGEAcgB0AEAAbwBrAC0AYgByAGkAdAAuAGMAbwBtAAAAHwAAAAEAAAAAAM4R AwAAAEQAfgADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAG0AYQBpAGwAdABvADoA cwB0AGUAcABoAGUAbgAuAG0AYwBjAGEAbgBuAEAAcgBvAGsAZQAuAGMAbwAuAHUAawAAAAAA HwAAAAEAAAAAAM4RAwAAAEgAdgADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIgAAAG0A YQBpAGwAdABvADoAZABzAHQAYQBuAGwAZQB5AEAAYQByAHUAYgBhAG4AZQB0AHcAbwByAGsA cwAuAGMAbwBtAAAAHwAAAAEAAAAAAM4RAwAAAHgAIwADAAAACQAAAAMAAAAAAAAAAwAAAAUA AAAfAAAAXAAAAGgAdAB0AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8A dwBnAC8AZQBjAHIAaQB0AC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAGUAYwByAGkAdAAtAGYA cgBhAG0AZQB3AG8AcgBrAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAGUAYwByAGkAdAAtAGYA cgBhAG0AZQB3AG8AcgBrAC0AMAAwAC4AdAB4AHQAAAAfAAAAAQAAAAAAzhEDAAAAdQBBAAMA AAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAAXAAAAbQBhAGkAbAB0AG8AOgBwAGEAdABjAG8A bQBAAGkAZQBlAGUALgBvAHIAZwAAAAAAHwAAAAEAAAAAAM4RAwAAAAwAdwADAAAAAwAAAAMA AAAAAAAAAwAAAAUAAAAfAAAAGgAAAG0AYQBpAGwAdABvADoAcwB0AHUAYQByAHQAQABvAGsA LQBiAHIAaQB0AC4AYwBvAG0AAAAfAAAAAQAAAAAAzhEDAAAAO2SY2B4AAAAwAAAASUVFRSA4 MDIuMTF1IGRyYWZ0IGxpYWlzb24gbGV0dGVyIHRvIE1PQk9QVFMAAAAAHgAAABwAAABzdGVw aGVuLm1jY2FubkByb2tlLmNvLnVrAAAAHgAAABAAAABNY0Nhbm4sIFN0ZXBoZW4AHgAAAAQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsA AAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA KQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYA AAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAD+////PgAAAD8AAABAAAAAQQAAAEIAAABDAAAA RAAAAEUAAABGAAAA/v///0gAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEA AABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAA XwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwA AABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAA egAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcA AACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACOAAAA/v///5AAAACRAAAAkgAAAJMAAACUAAAA lQAAAJYAAAD+////mAAAAJkAAACaAAAAmwAAAJwAAACdAAAAngAAAP7////9/////f///6IA AAD+/////v////7///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA AEYW/kdnxwGkAAAAgAAAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD0AAABOEgAAAAAAADEAVABhAGIAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB AQAAAAYAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAAAiP AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgECAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAMXgAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAI8AAAAAEAAAAAAAAAUARABvAGMA dQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAA4AAIBBAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA lwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA AAD+//////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARh8A AABNaWNyb3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29y ZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABSAG8A bwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAf//////////AwAAAAYJAgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAACAJQK8 PGnHAa4AAABACwAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPQAAAE4SAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgEBAAAA BgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABHAAAACI8AAAAA AABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAxeAAAAAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAA iQAAAIoAAACLAAAAjAAAAI0AAACOAAAA/v///5AAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYA AAD+///////////////////////////////////////////////9//////////////////// //////////+tAAAA/f////7///+pAAAAqgAAAKsAAACsAAAA/v////7///+oAAAA//////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////AQAAAP7/ //8DAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAA EAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0A AAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAA KwAAACwAAAD+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////IAAAABgAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAwAAABQA AABfQWRIb2NSZXZpZXdDeWNsZUlEAAQAAAAOAAAAX0VtYWlsU3ViamVjdAAFAAAADQAAAF9B dXRob3JFbWFpbAAGAAAAGAAAAF9BdXRob3JFbWFpbERpc3BsYXlOYW1lAAcAAAAZAAAAX1Jl dmlld2luZ1Rvb2xzU2hvd25PbmNlAAIAAADkBAAAQQAAAHwIAABgAAAAAwAAAEQAfgADAAAA JAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIQAAAG0AYQBpAGwAdABvADoAcwB0AGUAcABoAGUA bgAuAG0AYwBjAGEAbgBuAEAAcgBvAGsAZQAuAGMAbwAuAHUAawAAAAAAHwAAAAEAAAAAAM4R AwAAAEgAdgADAAAAIQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIgAAAG0AYQBpAGwAdABvADoA ZABzAHQAYQBuAGwAZQB5AEAAYQByAHUAYgBhAG4AZQB0AHcAbwByAGsAcwAuAGMAbwBtAAAA HwAAAAEAAAAAAM4RAwAAACsAWgADAAAAHgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIAAAAG0A YQBpAGwAdABvADoAcwB0AHUAYQByAHQALgBrAGUAcgByAHkAQABwAGgAaQBsAGkAcABzAC4A YwBvAG0AAAAfAAAAAQAAAAAAzhEDAAAAIgAhAAMAAAAbAAAAAwAAAAAAAAADAAAABQAAAB8A AABnAAAAZgB0AHAAOgAvAC8AZgB0AHAALgA4ADAAMgB3AGkAcgBlAGwAZQBzAHMAdwBvAHIA bABkAC4AYwBvAG0ALwAxADEALwAwADcALwAxADEALQAwADcALQAwADIANwA0AC0AMAAxAC0A MAAwADAAdQAtAHMAcwBwAG4ALQBpAG4AdABlAHIAZgBhAGMAZQAtAGkAbgB0AGUAcgBuAGEA bAAtAGMAbwBtAG0AZQBuAHQALQByAGUAcwBvAGwAdQB0AGkAbwBuAC4AZABvAGMAAAAAAB8A AAABAAAAAADOEQMAAAAWAA0AAwAAABgAAAADAAAAAAAAAAMAAAAFAAAAHwAAAFEAAABmAHQA cAA6AC8ALwBmAHQAcAAuADgAMAAyAHcAaQByAGUAbABlAHMAcwB3AG8AcgBsAGQALgBjAG8A bQAvADEAMQAvADAANwAvADEAMQAtADAANwAtADAAMgA5ADAALQAwADIALQAwADAAMAB1AC0A ZQBtAGUAcgBnAGUAbgBjAHkALQBjAGEAbABsAC0AcwBlAHQAdQBwAC4AcABwAHQAAAAAAB8A AAABAAAAAADOEQMAAAAlABwAAwAAABUAAAADAAAAAAAAAAMAAAAFAAAAHwAAABgAAABtAGEA aQBsAHQAbwA6AGYAbAB1AGYAZgB5AEAAYwBpAHMAYwBvAC4AYwBvAG0AAAAfAAAAAQAAAAAA zhEDAAAAaQAPAAMAAAASAAAAAwAAAAAAAAADAAAABQAAAB8AAAAgAAAAbQBhAGkAbAB0AG8A OgBqAG8AbgAuAHAAZQB0AGUAcgBzAG8AbgBAAG4AZQB1AHMAdABhAHIALgBiAGkAegAAAB8A AAABAAAAAADOEQMAAABKACcAAwAAAA8AAAADAAAAAAAAAAMAAAAFAAAAHwAAAB4AAABtAGEA aQBsAHQAbwA6AG0AYQByAGMALgBsAGkAbgBzAG4AZQByAEAAYwBpAHMAYwBvAC4AYwBvAG0A AAAfAAAAAQAAAAAAzhEDAAAAJABeAAMAAAAMAAAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAA bQBhAGkAbAB0AG8AOgBIAGEAbgBuAGUAcwAuAFQAcwBjAGgAbwBmAGUAbgBpAGcAQABnAG0A eAAuAG4AZQB0AAAAAAAfAAAAAQAAAAAAzhEDAAAAawAFAAMAAAAJAAAAAwAAAAAAAAADAAAA BQAAAB8AAAAaAAAAbQBhAGkAbAB0AG8AOgBiAHIAYwBAAHoAdQByAGkAYwBoAC4AaQBiAG0A LgBjAG8AbQAAAB8AAAABAAAAAADOEQMAAAAMAHcAAwAAAAYAAAADAAAAAAAAAAMAAAAFAAAA HwAAABoAAABtAGEAaQBsAHQAbwA6AHMAdAB1AGEAcgB0AEAAbwBrAC0AYgByAGkAdAAuAGMA bwBtAAAAHwAAAAEAAAAAAM4RAwAAAEQAfgADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA IQAAAG0AYQBpAGwAdABvADoAcwB0AGUAcABoAGUAbgAuAG0AYwBjAGEAbgBuAEAAcgBvAGsA ZQAuAGMAbwAuAHUAawAAAAAAHwAAAAEAAAAAAM4RAwAAAEgAdgADAAAAAAAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAIgAAAG0AYQBpAGwAdABvADoAZABzAHQAYQBuAGwAZQB5AEAAYQByAHUA YgBhAG4AZQB0AHcAbwByAGsAcwAuAGMAbwBtAAAAHwAAAAEAAAAAAM4RAwAAAHgAIwADAAAA CQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAXAAAAGgAdAB0AHAAOgAvAC8AdABvAG8AbABzAC4A aQBlAHQAZgAuAG8AcgBnAC8AdwBnAC8AZQBjAHIAaQB0AC8AZAByAGEAZgB0AC0AaQBlAHQA ZgAtAGUAYwByAGkAdAAtAGYAcgBhAG0AZQB3AG8AcgBrAC8AZAByAGEAZgB0AC0AaQBlAHQA ZgAtAGUAYwByAGkAdAAtAGYAcgBhAG0AZQB3AG8AcgBrAC0AMAAwAC4AdAB4AHQAAAAfAAAA AQAAAAAAzhEDAAAAdQBBAAMAAAAGAAAAAwAAAAAAAAADAAAABQAAAB8AAAAXAAAAbQBhAGkA bAB0AG8AOgBwAGEAdABjAG8AbQBAAGkAZQBlAGUALgBvAHIAZwAAAAAAHwAAAAEAAAAAAM4R AwAAAAwAdwADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGgAAAG0AYQBpAGwAdABvADoA cwB0AHUAYQByAHQAQABvAGsALQBiAHIAaQB0AC4AYwBvAG0AAAAfAAAAAQAAAAAAzhEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABQBTAHUAbQBtAGEA cgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACPAAAA ABAAAAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAIAAACwCgAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAAAE1pY3Jvc29m dCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50 LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAA AAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a5kAQAAIAEAAA0A AAABAAAAcAAAAA8AAAB4AAAABAAAAJAAAAAFAAAAmAAAAAYAAACgAAAAEQAAAKgAAAAXAAAA sAAAAAsAAAC4AAAAEAAAAMAAAAATAAAAyAAAABYAAADQAAAADQAAANgAAAAMAAAAAAEAAAIA AADkBAAAHgAAABAAAABBcnViYSBOZXR3b3JrcwAAAwAAAAA+AAADAAAANAAAAAMAAAAOAAAA AwAAAPAcAAADAAAAuh8LAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEA AAAcAAAAZG9jLjogSUVFRSA4MDIuMTEtMDcvMDQ3NnIxAAwQAAACAAAAHgAAAAYAAABUaXRs ZQADAAAAAQAAAAAATAkAAAMAAAAAAAAAIAAAAAEAAADAAAAAAgAAAA== --------------030506000101080307060708 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 --------------030506000101080307060708-- From ecrit-bounces@ietf.org Sun Mar 18 09:06: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 1HSv4c-0003fl-9r; Sun, 18 Mar 2007 09:05:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSv1K-00029R-Vj for ecrit@ietf.org; Sun, 18 Mar 2007 09:01:58 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSv1G-0007A7-Hl for ecrit@ietf.org; Sun, 18 Mar 2007 09:01:58 -0400 Received: (qmail invoked by alias); 18 Mar 2007 13:01:53 -0000 X-Provags-ID: V01U2FsdGVkX18ZxK5z1KkZEHw2rJxG78j9R2KJD0M28QN1aDRnB0 9l8FjrtDBGe0TN Message-ID: <45FD383D.2050902@gmx.net> Date: Sun, 18 Mar 2007 14:01:49 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT References: <45F56A82.5060108@gmx.net> <45F9AAF6.5010805@gmx.net> In-Reply-To: <45F9AAF6.5010805@gmx.net> 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: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Sun, 18 Mar 2007 09:05:21 -0400 Cc: lixia@CS.UCLA.EDU, Bernard Aboba , Dorothy Stanley Subject: [Ecrit] IETF ECRIT / IEEE Meeting @ IETF#68: Slides available 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, the slides are available at: http://www.tschofenig.priv.at/twiki/pub/EmergencyServices/IetfEcritRoadMap/11-07-0505-01-0000-emergency-services-shortened-tutorial.ppt Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > we got a room, namely Tyrolka, for your meeting on Monday. It will > hold around 40 person (the room setting is u-shaped). > > Ciao > Hannes > > > Hannes Tschofenig wrote: >> Hi all, >> >> I wanted to inform you that we picked >> >> *19th March 2007 (Monday) >> 11:30 - 13:00 >> >> *for our meeting (based on the preference indicated on the Wiki >> page). I am still waiting for the room reservation. * >> >> *Ciao >> Hannes >> >> > > > _______________________________________________ > 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 Mar 18 10:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwnE-00044s-TS; Sun, 18 Mar 2007 10:55:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwnD-000449-A1 for ecrit@ietf.org; Sun, 18 Mar 2007 10:55:31 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSwnC-0004R3-2V for ecrit@ietf.org; Sun, 18 Mar 2007 10:55:31 -0400 Received: (qmail invoked by alias); 18 Mar 2007 14:55:28 -0000 X-Provags-ID: V01U2FsdGVkX19cd8lVP0Bco5NHIW+W25rsKQfg8f5qCyuwBlh0C1 1tbuXwujMN+KZG Message-ID: <45FD52E0.3090100@gmx.net> Date: Sun, 18 Mar 2007 15:55:28 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Ecrit] Presentations 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 send your presentation to us. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 04:24: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 1HTDAJ-00078k-Fg; Mon, 19 Mar 2007 04:24:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTDAH-00076W-P3; Mon, 19 Mar 2007 04:24:25 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTDAG-00081F-FX; Mon, 19 Mar 2007 04:24:25 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2007 01:24:24 -0700 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 l2J8ONgP000758; Mon, 19 Mar 2007 01:24:23 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2J8ONZT021712; Mon, 19 Mar 2007 08:24:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:24:23 -0700 Received: from mlinsnerwxp ([10.21.101.39]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 01:24:19 -0700 From: "Marc Linsner" To: , "'GEOPRIV'" Date: Mon, 19 Mar 2007 04:24:16 -0400 Message-ID: <000001c769ff$fd1fdfd0$2765150a@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: Acdp//mtqtddye4vQAWT3LRxv9eQxA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-OriginalArrivalTime: 19 Mar 2007 08:24:19.0931 (UTC) FILETIME=[FDD1CAB0:01C769FF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=280; t=1174292663; x=1175156663; c=relaxed/simple; s=sjdkim2002; 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:=20IETF=20ECRIT=20/=20IEEE=20Meeting=20@=20IETF#68=3A=20Monday, = 2019th=20March=202007,=2011=3A30=20-=2013=3A00,=20Room=20Tyrolka |Sender:=20; bh=Fo+zuf66WWBAquJ/Xj+l5KdTBtpwGNNYlFcquj15ZGQ=; b=mPcFwOk45UGX0pX/771xReRxbxbAr1BBGz1K0u/zd20jREDtXKQqxi+jZymcS11Kf7D+PucK PYlqUGdonrkDPJ/rY5TTPwO2InK1eD8OY5EoD4dF+6RH5df9PciEsHX0; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [Ecrit] IETF ECRIT / IEEE Meeting @ IETF#68: Monday, 19th March 2007, 11:30 - 13:00, Room Tyrolka 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 Update...... For those worried about eating....there will be pick-up food available in the lobby level of the hotel. Please visit there and bring the food to room Tyrolka on the Mezzanine level. Agenda: 802.11 - Dorothy 802.16 - DJ 802.1 / LLDP MED - Peter, Dan _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 10:46: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 1HTJ7W-0007mh-Jg; Mon, 19 Mar 2007 10:45:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJ7V-0007mb-Pl for ecrit@ietf.org; Mon, 19 Mar 2007 10:45:57 -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 1HTJ7T-00045i-QL for ecrit@ietf.org; Mon, 19 Mar 2007 10:45:57 -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 l2JEjLgH013135; Mon, 19 Mar 2007 16:45:53 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 16:45:27 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 09:45:11 -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] Unauthenticated Network Access Date: Mon, 19 Mar 2007 09:45:08 -0500 Message-ID: In-Reply-To: <45F9B60D.20900@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Unauthenticated Network Access Thread-Index: AcdnRnKcvQgWBw+QTCq2dSzj/TcwgQCLqc+g References: <45F9B60D.20900@gmx.net> From: To: , X-OriginalArrivalTime: 19 Mar 2007 14:45:11.0697 (UTC) FILETIME=[32889010:01C76A35] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070319164553-30679BB0-1977CEB1/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Hello, I do not think this question is relevant from ieee point of view.=20 But as ieee technology is used to deploy commercial cellular radio networks (e.g. wimax), which may (or are already) inherit the current existing requirement of being possible to place an emergency call using a phone without a SIM card (i.e. no credentials), I think it is natural that ieee is going to provide a solution of satisfying the requirement. Gabor =20 -----Original Message----- From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, March 15, 2007 2:10 PM To: ECRIT Subject: [Ecrit] Unauthenticated Network Access Hi all, next Monday we are going to have our information sharing event with the IEEE. I went through their documents to get a better idea of their work and I noticed that the IEEE is working on solutions for unauthenticated network access. This essentially allows an emergency caller without credentials to access an IEEE 802 network. (Hence, I am not talking about unauthenticated emergency calls at the SIP layer). The support for unauthenticated network access raises a number of security challenges including architectural questions. I was wondering whether there are some regulatory requirements that require an architecture to support this type of functionality. Ciao Hannes _______________________________________________ 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 Mar 19 11:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJNZ-0002Uq-TV; Mon, 19 Mar 2007 11:02:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJNY-0002UK-MW for ecrit@ietf.org; Mon, 19 Mar 2007 11:02:32 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJN9-0008FZ-5a for ecrit@ietf.org; Mon, 19 Mar 2007 11:02:32 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTJMc-0007Da-6j; Mon, 19 Mar 2007 10:01:34 -0500 From: "Brian Rosen" To: , , Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 11:01:56 -0400 Message-ID: <009b01c76a37$8c274d80$37158182@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: AcdnRnKcvQgWBw+QTCq2dSzj/TcwgQCLqc+gADA5sQA= 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Okay, but please understand the current situation. The PSAPs have now lived with the "uninitialized device" problem for several years. The current considered position is that the cure is worse than the problem. The number of legitimate emergency calls from uninitialized phones is infinitesimally small. Most PSAPs can go a year without one. The number of prank calls is huge. In many PSAPs, it's their largest source of nuisance calls. They are NOT eager to have more such calls. Nevertheless, there is presently a regulator requirement in some countries to support them on mobile phones. There are some carriers who believe that 802.11 (or whatever) wireless networks which they support seamless roaming to will need to allow them to meet their regulatory obligations when uninitialized devices are on such networks. However, that is ALL that is needed, and you should, I believe, design support for such a circumstance as narrow as possible. It only needs to work on networks which the carriers have roaming agreements with, and it ONLY needs to work for their devices. I would also strongly urge you to copy whatever identity information the device can supply and carry it through, so that we have as much information as possible to track down prank callers. Brian > -----Original Message----- > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] > Sent: Monday, March 19, 2007 10:45 AM > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] Unauthenticated Network Access > > Hello, > > I do not think this question is relevant from ieee point of view. > > But as ieee technology is used to deploy commercial cellular radio > networks (e.g. wimax), which may (or are already) inherit the current > existing requirement of being possible to place an emergency call using > a phone without a SIM card (i.e. no credentials), I think it is natural > that ieee is going to provide a solution of satisfying the requirement. > > Gabor > > > -----Original Message----- > From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 15, 2007 2:10 PM > To: ECRIT > Subject: [Ecrit] Unauthenticated Network Access > > Hi all, > > next Monday we are going to have our information sharing event with the > IEEE. I went through their documents to get a better idea of their work > and I noticed that the IEEE is working on solutions for unauthenticated > network access. This essentially allows an emergency caller without > credentials to access an IEEE 802 network. (Hence, I am not talking > about unauthenticated emergency calls at the SIP layer). > > The support for unauthenticated network access raises a number of > security challenges including architectural questions. > > I was wondering whether there are some regulatory requirements that > require an architecture to support this type of functionality. > > Ciao > Hannes > > > _______________________________________________ > 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 Mar 19 11:27: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 1HTJln-00039j-QM; Mon, 19 Mar 2007 11:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTJlm-00039G-LE for ecrit@ietf.org; Mon, 19 Mar 2007 11:27:34 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTJlP-0003xr-2b for ecrit@ietf.org; Mon, 19 Mar 2007 11:27:34 -0400 Received: from [130.129.55.115] (dhcp-3773.ietf68.org [130.129.55.115]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2JFQfTd002574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 11:26:43 -0400 (EDT) In-Reply-To: <009b01c76a37$8c274d80$37158182@cis.neustar.com> References: <009b01c76a37$8c274d80$37158182@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: <7C50617C-B363-495F-87E4-7495BDDDBE64@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 11:26:41 -0400 To: "Brian Rosen" 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: 8fbbaa16f9fd29df280814cb95ae2290 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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 the IP environment, we have two identities (L2/L3 and L7), instead of one. Thus, I think we have more design freedom. As an example, consider a model where a wireless (802.16 or otherwise) ISP has agreements with a number of modest number of consumer VSPs that allow unauthenticated L2 calls, with the assumption that these VSPs have strong customer identity information. This customer identity information is conveyed to the PSAP, either literally or in some discoverable format should the call pose problems. (In other words, where anonymous emergency calls are a requirement, a PSAP can get a court order if there's a crank call to map the call-ID to an indictable identity.) Sure, it discriminates against small VSPs, non-domestic VSPs or the SIP-proxy-at-home crowd, but I'd rather allow L7-authenticated emergency call to a larger population than not at all. I'm guessing that you'd get 90%+ of all possible callers with fewer than a dozen VSPs. Naturally, nothing prevents customers of these VSPs make calls as authenticated L2 users. Given the widespread and increasing availability of open-access hotspots, I do see this as a more generic problem. Would you suggest preventing emergency calls from such networks? How would you enforce that? Henning On Mar 19, 2007, at 11:01 AM, Brian Rosen wrote: > Okay, but please understand the current situation. > > The PSAPs have now lived with the "uninitialized device" problem > for several > years. The current considered position is that the cure is worse > than the > problem. The number of legitimate emergency calls from > uninitialized phones > is infinitesimally small. Most PSAPs can go a year without one. > > The number of prank calls is huge. In many PSAPs, it's their > largest source > of nuisance calls. They are NOT eager to have more such calls. > > Nevertheless, there is presently a regulator requirement in some > countries > to support them on mobile phones. There are some carriers who > believe that > 802.11 (or whatever) wireless networks which they support seamless > roaming > to will need to allow them to meet their regulatory obligations when > uninitialized devices are on such networks. > > However, that is ALL that is needed, and you should, I believe, design > support for such a circumstance as narrow as possible. It only > needs to > work on networks which the carriers have roaming agreements with, > and it > ONLY needs to work for their devices. I would also strongly urge > you to > copy whatever identity information the device can supply and carry it > through, so that we have as much information as possible to track > down prank > callers. > > Brian > >> -----Original Message----- >> From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] >> Sent: Monday, March 19, 2007 10:45 AM >> To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org >> Subject: RE: [Ecrit] Unauthenticated Network Access >> >> Hello, >> >> I do not think this question is relevant from ieee point of view. >> >> But as ieee technology is used to deploy commercial cellular radio >> networks (e.g. wimax), which may (or are already) inherit the current >> existing requirement of being possible to place an emergency call >> using >> a phone without a SIM card (i.e. no credentials), I think it is >> natural >> that ieee is going to provide a solution of satisfying the >> requirement. >> >> Gabor >> >> >> -----Original Message----- >> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Thursday, March 15, 2007 2:10 PM >> To: ECRIT >> Subject: [Ecrit] Unauthenticated Network Access >> >> Hi all, >> >> next Monday we are going to have our information sharing event >> with the >> IEEE. I went through their documents to get a better idea of their >> work >> and I noticed that the IEEE is working on solutions for >> unauthenticated >> network access. This essentially allows an emergency caller without >> credentials to access an IEEE 802 network. (Hence, I am not talking >> about unauthenticated emergency calls at the SIP layer). >> >> The support for unauthenticated network access raises a number of >> security challenges including architectural questions. >> >> I was wondering whether there are some regulatory requirements that >> require an architecture to support this type of functionality. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 11: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 1HTK1b-0005na-0c; Mon, 19 Mar 2007 11:43:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK1Z-0005nO-7J for ecrit@ietf.org; Mon, 19 Mar 2007 11:43:53 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTK15-0006X3-Db for ecrit@ietf.org; Mon, 19 Mar 2007 11:43:53 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2007 08:43:22 -0700 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 l2JFhMFC003747; Mon, 19 Mar 2007 08:43:22 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2JFhCZx002393; Mon, 19 Mar 2007 15:43:22 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 08:43:12 -0700 Received: from mlinsnerwxp ([10.89.20.132]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 08:43:11 -0700 From: "Marc Linsner" To: "'Brian Rosen'" , , , Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 11:43:09 -0400 Message-ID: <003301c76a3d$4c7f29e0$437b150a@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: <009b01c76a37$8c274d80$37158182@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdnRnKcvQgWBw+QTCq2dSzj/TcwgQCLqc+gADA5sQAAAPeoYA== X-OriginalArrivalTime: 19 Mar 2007 15:43:11.0385 (UTC) FILETIME=[4C96D090:01C76A3D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=430; t=1174319002; x=1175183002; c=relaxed/simple; s=sjdkim2002; 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]=20Unauthenticated=20Network=20Access |Sender:=20; bh=L5lJUR1B7gUcFgQLPhP5cTt5PtDpZs2yiykTHoTLoL0=; b=KSG7KvYcA1KvVWnlijUHASLieelLAbxys0q8bltBlzEKIidJju6kiRLs4qe4zwKb4wHi9MuM M8j4SD/QCl5d/CoG/JxzMymJWSqKeKmPugDYKRpcSZWpb07aaYOow5q2; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 > work for their devices. I would also strongly urge you to > copy whatever identity information the device can supply and > carry it through, so that we have as much information as > possible to track down prank callers. Ah yes, I can see it now. Buy your Linksys 802.11 phone at the Walmart gun counter so they can register your mac address with the Bureau of Alcohol, Tobacco and Firearms. :^) -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 11:44: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 1HTK1h-0005nu-5i; Mon, 19 Mar 2007 11:44:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTK1g-0005np-33 for ecrit@ietf.org; Mon, 19 Mar 2007 11:44:00 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTK19-0006Xk-Om for ecrit@ietf.org; Mon, 19 Mar 2007 11:44:00 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTK0b-00080o-VK; Mon, 19 Mar 2007 10:42:54 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 11:43:24 -0400 Message-ID: <00dc01c76a3d$575f4840$37158182@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: <7C50617C-B363-495F-87E4-7495BDDDBE64@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqOvqysO2miniUSLe+TvQ/8uprCAAAMKwQ 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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 then you are not talking about a non-initialized device. You have a good identity. If you have a good identity, then I'm all for being able to use that to make an emergency call. The problem we are talking about is a device that has no identity at all. I'm not sure how you get into a circumstance where you have a good L7 identity but an unauthenticated L2. How does that arise? It would seem to me that if the ISP supports the VSP, then the device should be able to be authorized on the L2/L3 network. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, March 19, 2007 11:27 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: Re: [Ecrit] Unauthenticated Network Access > > In the IP environment, we have two identities (L2/L3 and L7), instead > of one. Thus, I think we have more design freedom. As an example, > consider a model where a wireless (802.16 or otherwise) ISP has > agreements with a number of modest number of consumer VSPs that allow > unauthenticated L2 calls, with the assumption that these VSPs have > strong customer identity information. This customer identity > information is conveyed to the PSAP, either literally or in some > discoverable format should the call pose problems. (In other words, > where anonymous emergency calls are a requirement, a PSAP can get a > court order if there's a crank call to map the call-ID to an > indictable identity.) > > Sure, it discriminates against small VSPs, non-domestic VSPs or the > SIP-proxy-at-home crowd, but I'd rather allow L7-authenticated > emergency call to a larger population than not at all. I'm guessing > that you'd get 90%+ of all possible callers with fewer than a dozen > VSPs. Naturally, nothing prevents customers of these VSPs make calls > as authenticated L2 users. > > Given the widespread and increasing availability of open-access > hotspots, I do see this as a more generic problem. Would you suggest > preventing emergency calls from such networks? How would you enforce > that? > > Henning > > On Mar 19, 2007, at 11:01 AM, Brian Rosen wrote: > > > Okay, but please understand the current situation. > > > > The PSAPs have now lived with the "uninitialized device" problem > > for several > > years. The current considered position is that the cure is worse > > than the > > problem. The number of legitimate emergency calls from > > uninitialized phones > > is infinitesimally small. Most PSAPs can go a year without one. > > > > The number of prank calls is huge. In many PSAPs, it's their > > largest source > > of nuisance calls. They are NOT eager to have more such calls. > > > > Nevertheless, there is presently a regulator requirement in some > > countries > > to support them on mobile phones. There are some carriers who > > believe that > > 802.11 (or whatever) wireless networks which they support seamless > > roaming > > to will need to allow them to meet their regulatory obligations when > > uninitialized devices are on such networks. > > > > However, that is ALL that is needed, and you should, I believe, design > > support for such a circumstance as narrow as possible. It only > > needs to > > work on networks which the carriers have roaming agreements with, > > and it > > ONLY needs to work for their devices. I would also strongly urge > > you to > > copy whatever identity information the device can supply and carry it > > through, so that we have as much information as possible to track > > down prank > > callers. > > > > Brian > > > >> -----Original Message----- > >> From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] > >> Sent: Monday, March 19, 2007 10:45 AM > >> To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > >> Subject: RE: [Ecrit] Unauthenticated Network Access > >> > >> Hello, > >> > >> I do not think this question is relevant from ieee point of view. > >> > >> But as ieee technology is used to deploy commercial cellular radio > >> networks (e.g. wimax), which may (or are already) inherit the current > >> existing requirement of being possible to place an emergency call > >> using > >> a phone without a SIM card (i.e. no credentials), I think it is > >> natural > >> that ieee is going to provide a solution of satisfying the > >> requirement. > >> > >> Gabor > >> > >> > >> -----Original Message----- > >> From: ext Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >> Sent: Thursday, March 15, 2007 2:10 PM > >> To: ECRIT > >> Subject: [Ecrit] Unauthenticated Network Access > >> > >> Hi all, > >> > >> next Monday we are going to have our information sharing event > >> with the > >> IEEE. I went through their documents to get a better idea of their > >> work > >> and I noticed that the IEEE is working on solutions for > >> unauthenticated > >> network access. This essentially allows an emergency caller without > >> credentials to access an IEEE 802 network. (Hence, I am not talking > >> about unauthenticated emergency calls at the SIP layer). > >> > >> The support for unauthenticated network access raises a number of > >> security challenges including architectural questions. > >> > >> I was wondering whether there are some regulatory requirements that > >> require an architecture to support this type of functionality. > >> > >> Ciao > >> Hannes > >> > >> > >> _______________________________________________ > >> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 11:56: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 1HTKDz-0006aS-Og; Mon, 19 Mar 2007 11:56:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKDy-0006Vk-5L for ecrit@ietf.org; Mon, 19 Mar 2007 11:56:42 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTKDt-00081J-Ah for ecrit@ietf.org; Mon, 19 Mar 2007 11:56:42 -0400 Received: from [130.129.55.115] (dhcp-3773.ietf68.org [130.129.55.115]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2JFuM04016340 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 11:56:24 -0400 (EDT) In-Reply-To: <00dc01c76a3d$575f4840$37158182@cis.neustar.com> References: <00dc01c76a3d$575f4840$37158182@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: <2FFB4368-7C6B-4338-97CE-644CEA4200A1@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 11:56:22 -0400 To: "Brian Rosen" 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: 8b431ad66d60be2d47c7bfeb879db82c Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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 Mar 19, 2007, at 11:43 AM, Brian Rosen wrote: > But then you are not talking about a non-initialized device. You > have a > good identity. If you have a good identity, then I'm all for being > able to > use that to make an emergency call. The problem we are talking > about is a > device that has no identity at all. I think part of the problem is defining "identity" and "device". In this particular case, the device has no identity as such; rather a piece of software running SIP has a L7 identity and happens to reside on a laptop using a non-authenticating network. I don't think it is helpful to conflate 'device' and 'service'. If they are the same, we could greatly simplify the SIPPING configuration discussion :-) If we agree that authenticated means "has a traceable identity either at L2 or L7 (or both)", we are in agreement, but clearly, unauthenticated network access doesn't imply that. > > I'm not sure how you get into a circumstance where you have a good L7 > identity but an unauthenticated L2. How does that arise? It would > seem to > me that if the ISP supports the VSP, then the device should be able > to be > authorized on the L2/L3 network. I gave two examples: - 802.11 networks with no authentication (e.g., all city parks in NYC in the near future, Columbia University and many other universities, Panera Bread, non-WEP home networks with SSID linksys, corporate networks with 'guest' access) - 802.16 networks that explicitly allow non-authenticated emergency call access, as I described in my note. At a more basic level, this is even true for the IETF Ethernet. A few years ago, the Lexington airport offered Ethernet plugs on their lower level for free, without any authentication. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 11:59: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 1HTKGI-0000Oq-O2; Mon, 19 Mar 2007 11:59:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKGH-0000Ok-Ga for ecrit@ietf.org; Mon, 19 Mar 2007 11:59:05 -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 1HTKGF-0008Oj-3T for ecrit@ietf.org; Mon, 19 Mar 2007 11:59:05 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 19 Mar 2007 08:59:02 -0700 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 l2JFx2Ek023496; Mon, 19 Mar 2007 08:59:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l2JFwpZV015555; Mon, 19 Mar 2007 15:59:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 08:58:51 -0700 Received: from mlinsnerwxp ([10.89.20.132]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 08:58:50 -0700 From: "Marc Linsner" To: "'Brian Rosen'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 11:58:45 -0400 Message-ID: <004701c76a3f$7c9baed0$437b150a@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: <00dc01c76a3d$575f4840$37158182@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqOvqysO2miniUSLe+TvQ/8uprCAAAMKwQAADYnkA= X-OriginalArrivalTime: 19 Mar 2007 15:58:51.0073 (UTC) FILETIME=[7CAFD310:01C76A3F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=402; t=1174319942; x=1175183942; c=relaxed/simple; s=sjdkim1004; 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]=20Unauthenticated=20Network=20Access |Sender:=20; bh=9mGDUas5JI8XHzpu+K7r7ZegCzKySLWshWyy8aTuGzw=; b=PGQBJGLcJq3Hr38UdzG8T7JxWkJE367RL4rZaihvY0PmOHz7JMul3+ND/IYxdjEcgvZVT6AT kZxagzxEvcfcWq8ZjM8BuH6Q7U+v/8Bc8x5ui7mRBnsZLLdMvSwWezLIlVRHj9k0PmDmCbPuaT VnJtOrN7UQ+VM4Onv1HOcsWrM=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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'm not sure how you get into a circumstance where you have a > good L7 identity but an unauthenticated L2. How does that > arise? It would seem to me that if the ISP supports the VSP, > then the device should be able to be authorized on the L2/L3 network. Your 802.11 phone works, Vonage is your VSP, but you don't have $6 in your pocket to buy time on T-Mobile. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 12:09: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 1HTKQS-0004sE-IV; Mon, 19 Mar 2007 12:09:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKQR-0004s4-QR for ecrit@ietf.org; Mon, 19 Mar 2007 12:09:35 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKQQ-0001p0-Ib for ecrit@ietf.org; Mon, 19 Mar 2007 12:09:35 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTKPh-0004tM-C8; Mon, 19 Mar 2007 11:08:49 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 12:09:23 -0400 Message-ID: <00ed01c76a40$f8e1fe80$37158182@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: <004701c76a3f$7c9baed0$437b150a@amer.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqOvqysO2miniUSLe+TvQ/8uprCAAAMKwQAADYnkAAAGl+YA== 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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 Vonage doesn't have an agreement with T-Mobile that would permit this. If they did, then it would work. That was Henning's preposition. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, March 19, 2007 11:59 AM > To: 'Brian Rosen'; 'Henning Schulzrinne' > Cc: Gabor.Bajko@nokia.com; ecrit@ietf.org > Subject: RE: [Ecrit] Unauthenticated Network Access > > Brian, > > > I'm not sure how you get into a circumstance where you have a > > good L7 identity but an unauthenticated L2. How does that > > arise? It would seem to me that if the ISP supports the VSP, > > then the device should be able to be authorized on the L2/L3 network. > > Your 802.11 phone works, Vonage is your VSP, but you don't have $6 in your > pocket to buy time on T-Mobile. > > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 12:11: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 1HTKSG-0005YN-AJ; Mon, 19 Mar 2007 12:11:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKSF-0005XT-0I for ecrit@ietf.org; Mon, 19 Mar 2007 12:11:27 -0400 Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKRx-0002DZ-E2 for ecrit@ietf.org; Mon, 19 Mar 2007 12:11:26 -0400 Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id l2JGAarV013081 for ; Mon, 19 Mar 2007 16:10:38 GMT 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: Mon, 19 Mar 2007 16:10:36 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF ECRIT / IEEE Meeting @ IETF#68: Monday, 19th March 2007 Thread-Index: AcdqOvqysO2miniUSLe+TvQ/8uprCAAAMKwQAADYnkAAACppYA== References: <004701c76a3f$7c9baed0$437b150a@amer.cisco.com> From: "McCann, Stephen" To: X-MailScanner-roke-co-uk: Found to be clean X-MailScanner-roke-co-uk-SpamCheck: X-MailScanner-From: stephen.mccann@roke.co.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ecrit] IETF ECRIT / IEEE Meeting @ IETF#68: Monday, 19th March 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 Dear all, I listened in to today's lunch time meeting (thanks for setting up the audio link by the away) and I just wanted to state a couple of things from the IEEE 802.11 point of=20 view: 1) The presentation from Dorothy is very much work in progress and we require assistance from the IETF to fill in some of our gaps. 2) The whole issue of emergency services is now gaining momentum within IEEE 802 (not just specifically 802.11) and is not something it can ignore or dismiss. 3) I think it might be useful for ECRIT to write a list of issues that IEEE 802.11 needs to respond to, as an outcome of this meeting. Kind regards Stephen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 12:18: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 1HTKYs-0004bn-QQ; Mon, 19 Mar 2007 12:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTKYr-0004a8-Ka for ecrit@ietf.org; Mon, 19 Mar 2007 12:18:17 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTKYp-0003hl-9Q for ecrit@ietf.org; Mon, 19 Mar 2007 12:18:17 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTKYH-0007Hr-Qp; Mon, 19 Mar 2007 11:17:42 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 12:18:08 -0400 Message-ID: <00f101c76a42$31c02410$37158182@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: <2FFB4368-7C6B-4338-97CE-644CEA4200A1@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqPxYfSq8T7xxwTsCmwAdlL7jopwAAeHSA 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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 Perhaps I'm wrong, but I think that if the user has an identity acceptable to the VSP, then it can be arranged that he has an identity acceptable to the L2/L3 operator. I think that is the direction everyone is heading, so that a phone can roam. For example, most pay-for-service wifi hotspots have roaming agreements that allow subscribers to other hotspot users to use their credentials. The VSP could arrange the same courtesy. Traceable identity, either by the L2/L3 operator or the L7 operator is acceptable, I agree. I still don't understand the examples. They seem to already allow unfettered L2/L3 access, but would require identity to the L7 provider. If the L2/L3 provider starts requiring some kind of credentials for access, then the L7 provider can arrange such credentials as above. I don't think we need more than that. The work that I'm objecting to seems to provide for any device to gain access by declaring that it's trying to place an emergency call without regard to whether it has L7 credentials or not. Brian > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, March 19, 2007 11:56 AM > To: Brian Rosen > Cc: Gabor.Bajko@nokia.com; Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: Re: [Ecrit] Unauthenticated Network Access > > > On Mar 19, 2007, at 11:43 AM, Brian Rosen wrote: > > > But then you are not talking about a non-initialized device. You > > have a > > good identity. If you have a good identity, then I'm all for being > > able to > > use that to make an emergency call. The problem we are talking > > about is a > > device that has no identity at all. > > I think part of the problem is defining "identity" and "device". In > this particular case, the device has no identity as such; rather a > piece of software running SIP has a L7 identity and happens to reside > on a laptop using a non-authenticating network. > > I don't think it is helpful to conflate 'device' and 'service'. If > they are the same, we could greatly simplify the SIPPING > configuration discussion :-) > > If we agree that authenticated means "has a traceable identity either > at L2 or L7 (or both)", we are in agreement, but clearly, > unauthenticated network access doesn't imply that. > > > > > I'm not sure how you get into a circumstance where you have a good L7 > > identity but an unauthenticated L2. How does that arise? It would > > seem to > > me that if the ISP supports the VSP, then the device should be able > > to be > > authorized on the L2/L3 network. > > I gave two examples: > > - 802.11 networks with no authentication (e.g., all city parks in NYC > in the near future, Columbia University and many other universities, > Panera Bread, non-WEP home networks with SSID linksys, corporate > networks with 'guest' access) > > - 802.16 networks that explicitly allow non-authenticated emergency > call access, as I described in my note. > > At a more basic level, this is even true for the IETF Ethernet. A few > years ago, the Lexington airport offered Ethernet plugs on their > lower level for free, without any authentication. > > > Henning > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 13:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLJB-0000De-4y; Mon, 19 Mar 2007 13:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLJA-0000C1-6R for ecrit@ietf.org; Mon, 19 Mar 2007 13:06:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLJ2-0004AV-SV for ecrit@ietf.org; Mon, 19 Mar 2007 13:06:08 -0400 Received: from [130.129.22.195] (dhcp-16c3.ietf68.org [130.129.22.195]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2JH5oYf005472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 13:05:51 -0400 (EDT) In-Reply-To: <00f101c76a42$31c02410$37158182@cis.neustar.com> References: <00f101c76a42$31c02410$37158182@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] Unauthenticated Network Access Date: Mon, 19 Mar 2007 13:05:50 -0400 To: "Brian Rosen" 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: 4d87d2aa806f79fed918a62e834505ca Cc: Gabor.Bajko@nokia.com, ecrit@ietf.org 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 Mar 19, 2007, at 12:18 PM, Brian Rosen wrote: > Perhaps I'm wrong, but I think that if the user has an identity > acceptable > to the VSP, then it can be arranged that he has an identity > acceptable to > the L2/L3 operator. I think that is the direction everyone is > heading, so > that a phone can roam. For example, most pay-for-service wifi > hotspots have > roaming agreements that allow subscribers to other hotspot users to > use > their credentials. The VSP could arrange the same courtesy. > This might be true and I'm clearly only guessing, but I'm guessing that it's a lot easier to simply route calls to a proxy than authenticate users and share IDs. The latter requires some kind of AAA access, and then distinguish emergency-only from fully-paid customers. Given that wireless hotspots charge $10 or more a day and that VSPs charge $10 or so a month, I'm not quite sure that courtesy wireless roaming is imminent. > Traceable identity, either by the L2/L3 operator or the L7 operator is > acceptable, I agree. > > I still don't understand the examples. They seem to already allow > unfettered L2/L3 access, but would require identity to the L7 > provider. If > the L2/L3 provider starts requiring some kind of credentials for > access, > then the L7 provider can arrange such credentials as above. I > don't think > we need more than that. > > The work that I'm objecting to seems to provide for any device to gain > access by declaring that it's trying to place an emergency call > without > regard to whether it has L7 credentials or not. > I think we're in general agreement; we just need to be precise in our discussions. "unrestricted unauthenticated network access" is bad, "L7-authenticated unauthenticated network access" is ok. > Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 15:00: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 1HTN5G-0004K2-3q; Mon, 19 Mar 2007 14:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTN5E-0004Jt-U6 for ecrit@ietf.org; Mon, 19 Mar 2007 14:59:52 -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 1HTN4r-00056z-GO for ecrit@ietf.org; Mon, 19 Mar 2007 14:59:52 -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 l2JIwmRY029812; Mon, 19 Mar 2007 20:58:59 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 20:58:51 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 13:58:41 -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] Unauthenticated Network Access Date: Mon, 19 Mar 2007 13:58:38 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Unauthenticated Network Access Thread-Index: AcdqSOiPNu1/MpvbRn6XjWZXBzQxyQADq13g References: <00f101c76a42$31c02410$37158182@cis.neustar.com> From: To: , X-OriginalArrivalTime: 19 Mar 2007 18:58:41.0822 (UTC) FILETIME=[9C7973E0:01C76A58] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070319205900-72F6BBB0-59C61F48/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ecrit@ietf.org 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 =20 -----Original Message----- From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Monday, March 19, 2007 10:06 AM To: Brian Rosen Cc: Bajko Gabor (Nokia-NET/MtView); Hannes.Tschofenig@gmx.net; ecrit@ietf.org Subject: Re: [Ecrit] Unauthenticated Network Access > The work that I'm objecting to seems to provide for any device to gain > access by declaring that it's trying to place an emergency call=20 > without regard to whether it has L7 credentials or not. > I think we're in general agreement; we just need to be precise in our discussions. "unrestricted unauthenticated network access" is bad, "L7-authenticated unauthenticated network access" is ok. IEEE is trying to solve the "unauthenticated network access" case, not the "unrestricted unauthenticated network access". Unauthentication here referring to L2. Whether L-7 authentication will be required or not, that is going to be decided by the carrier which will deploy ieee technology for commercial VoIP services. So, if e.g. wimax is going to use the "unauthenticated network access" solution provided by ieee, you can ask wimax to require L-7 authentication in their specs. Gabor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 17:11: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 1HTP7Z-0005gx-PM; Mon, 19 Mar 2007 17:10:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTP7Z-0005gp-0p for ecrit@ietf.org; Mon, 19 Mar 2007 17:10:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTP7Q-0000Sh-Az for ecrit@ietf.org; Mon, 19 Mar 2007 17:10:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HTP6p-0005Nr-Fw; Mon, 19 Mar 2007 16:09:39 -0500 From: "Brian Rosen" To: , Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 17:10:11 -0400 Message-ID: <017601c76a6a$fd6a7ac0$37158182@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: AcdqSOiPNu1/MpvbRn6XjWZXBzQxyQADq13gAASpZnA= 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ecrit@ietf.org 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 continue to not understand why the credentials used for L7 access are not acceptable for L2 access. They are for WiFi now. Why would you supply a solution that is not as good as they do today? Today, the carrier wishing to provide L2/L3 authenticated access on a partner's WiFi network would provide (something like) a RADIUS authentication of the subscriber username/password collected by the partner. The partner would only provide access if the user correctly authenticated via the carrier's RADIUS server. Brian > -----Original Message----- > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] > Sent: Monday, March 19, 2007 2:59 PM > To: hgs@cs.columbia.edu; br@brianrosen.net > Cc: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] Unauthenticated Network Access > > > > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, March 19, 2007 10:06 AM > To: Brian Rosen > Cc: Bajko Gabor (Nokia-NET/MtView); Hannes.Tschofenig@gmx.net; > ecrit@ietf.org > Subject: Re: [Ecrit] Unauthenticated Network Access > > > > The work that I'm objecting to seems to provide for any device to gain > > > access by declaring that it's trying to place an emergency call > > without regard to whether it has L7 credentials or not. > > > > I think we're in general agreement; we just need to be precise in our > discussions. "unrestricted unauthenticated network access" is bad, > "L7-authenticated unauthenticated network access" is ok. > > > IEEE is trying to solve the "unauthenticated network access" case, not > the "unrestricted unauthenticated network access". Unauthentication here > referring to L2. Whether L-7 authentication will be required or not, > that is going to be decided by the carrier which will deploy ieee > technology for commercial VoIP services. So, if e.g. wimax is going to > use the "unauthenticated network access" solution provided by ieee, you > can ask wimax to require L-7 authentication in their specs. > > Gabor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 17:17: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 1HTPDu-0007Ef-Cf; Mon, 19 Mar 2007 17:16:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPDt-0007EZ-Vz for ecrit@ietf.org; Mon, 19 Mar 2007 17:16:57 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTPDr-0001i4-5o for ecrit@ietf.org; Mon, 19 Mar 2007 17:16:57 -0400 Received: from [130.129.55.115] (dhcp-3773.ietf68.org [130.129.55.115]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2JLGnTm022118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 17:16:52 -0400 (EDT) In-Reply-To: References: <00f101c76a42$31c02410$37158182@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] Unauthenticated Network Access Date: Mon, 19 Mar 2007 17:16:46 -0400 To: 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: a7d6aff76b15f3f56fcb94490e1052e4 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 Please remember that the WiMax provider may not necessarily be the VoIP provider. The case where ISP = VSP is the easy one. We certainly don't want to imply this. On Mar 19, 2007, at 2:58 PM, wrote: > > > -----Original Message----- > From: ext Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, March 19, 2007 10:06 AM > To: Brian Rosen > Cc: Bajko Gabor (Nokia-NET/MtView); Hannes.Tschofenig@gmx.net; > ecrit@ietf.org > Subject: Re: [Ecrit] Unauthenticated Network Access > > >> The work that I'm objecting to seems to provide for any device to >> gain > >> access by declaring that it's trying to place an emergency call >> without regard to whether it has L7 credentials or not. >> > > I think we're in general agreement; we just need to be precise in our > discussions. "unrestricted unauthenticated network access" is bad, > "L7-authenticated unauthenticated network access" is ok. > > > IEEE is trying to solve the "unauthenticated network access" case, not > the "unrestricted unauthenticated network access". Unauthentication > here > referring to L2. Whether L-7 authentication will be required or not, > that is going to be decided by the carrier which will deploy ieee > technology for commercial VoIP services. So, if e.g. wimax is going to > use the "unauthenticated network access" solution provided by ieee, > you > can ask wimax to require L-7 authentication in their specs. > > Gabor > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 17:34: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 1HTPV5-0004RF-Mz; Mon, 19 Mar 2007 17:34:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPV3-0004Qu-M9 for ecrit@ietf.org; Mon, 19 Mar 2007 17:34:41 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTPUc-0003yC-5p for ecrit@ietf.org; Mon, 19 Mar 2007 17:34:41 -0400 Received: from [130.129.55.115] (dhcp-3773.ietf68.org [130.129.55.115]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id l2JLY3p9013463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Mar 2007 17:34:08 -0400 (EDT) In-Reply-To: <017601c76a6a$fd6a7ac0$37158182@cis.neustar.com> References: <017601c76a6a$fd6a7ac0$37158182@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: <5A286D7E-7B57-441F-A0F8-6B8808AECB45@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 17:33:59 -0400 To: "Brian Rosen" 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: ea4ac80f790299f943f0a53be7e1a21a 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 Mar 19, 2007, at 5:10 PM, Brian Rosen wrote: > I continue to not understand why the credentials used for L7 access > are not > acceptable for L2 access. They are for WiFi now. Why would you > supply a > solution that is not as good as they do today? Do know any any WiFi credentials that can be used for SIP or vice versa? It's theoretically possible, but requires a significant change in AAA mechanisms, for example. > > Today, the carrier wishing to provide L2/L3 authenticated access on a > partner's WiFi network would provide (something like) a RADIUS > authentication of the subscriber username/password collected by the > partner. > The partner would only provide access if the user correctly > authenticated > via the carrier's RADIUS server. > This requires a full-fledged business relationship, given the high relative charges for WiFi access. If it's so easy, why hasn't Vonage done this already, say? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 19 17:57: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 1HTPqT-0007sJ-1g; Mon, 19 Mar 2007 17:56:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTPqR-0007rt-IZ for ecrit@ietf.org; Mon, 19 Mar 2007 17:56:47 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTPpv-00088X-GK for ecrit@ietf.org; Mon, 19 Mar 2007 17:56:47 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 19 Mar 2007 14:56:11 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l2JLuBir024180; Mon, 19 Mar 2007 14:56:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l2JLu5x7001707; Mon, 19 Mar 2007 21:56:11 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 14:56:10 -0700 Received: from mlinsnerwxp ([10.21.80.199]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 14:56:09 -0700 From: "Marc Linsner" To: "'Brian Rosen'" Subject: RE: [Ecrit] Unauthenticated Network Access Date: Mon, 19 Mar 2007 17:56:08 -0400 Message-ID: <00e901c76a71$66ebda10$437b150a@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: <017601c76a6a$fd6a7ac0$37158182@cis.neustar.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdqSOiPNu1/MpvbRn6XjWZXBzQxyQADq13gAASpZnAAAauPYA== X-OriginalArrivalTime: 19 Mar 2007 21:56:09.0447 (UTC) FILETIME=[66F41770:01C76A71] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=447; t=1174341371; x=1175205371; c=relaxed/simple; s=sjdkim5002; 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]=20Unauthenticated=20Network=20Access |Sender:=20; bh=S9uuD3GgSPZ3IeQiGMEyvfCm6NLLatOLwp82ifRxzU0=; b=SthA5v4cYG5Cn1PVOwjhY4TgbY+WioyqYL82G1kkqY0B+foNbX315Lp8u1EDbNm84UJgoXMw olrjF6gi039D57tXnTjI3haWMKybSHUCg3b7xOmrgooa3Qvl2Y0OgGXk; Authentication-Results: sj-dkim-5; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ecrit@ietf.org 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 continue to not understand why the credentials used for L7 > access are not acceptable for L2 access. They are for WiFi > now. Why would you supply a solution that is not as good as > they do today? Can you provide an example of L7 service credentials used for roaming/multi-carrier L2 access? I'm only familiar with those like IPass that is strictly L2/L3. IPass doesn't buy you much in the L7 world. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 21 08:08: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 1HTzbU-0007SL-Gc; Wed, 21 Mar 2007 08:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzbO-0007NJ-47 for ecrit@ietf.org; Wed, 21 Mar 2007 08:07:38 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTzXD-0000b6-64 for ecrit@ietf.org; Wed, 21 Mar 2007 08:03:20 -0400 Received: (qmail invoked by alias); 21 Mar 2007 12:03:18 -0000 Received: from dhcp-1453.ietf68.org (EHLO [130.129.20.83]) [130.129.20.83] by mail.gmx.net (mp010) with SMTP; 21 Mar 2007 13:03:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+FHiMpHX+FHjO4NAH6NVW98AKKgE9u2f83BQah1B GG5CmJNDg5XVyo Message-ID: <46011F03.1000002@gmx.net> Date: Wed, 21 Mar 2007 13:03:15 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 7d33c50f3756db14428398e2bdedd581 Subject: [Ecrit] AD Draft Reviews 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 today's WG chairs lunch presentation about the PROTO writeup Marc and myself checked the I-D Tracker and noticed that Jon's comments are not available in the tracker and are therefore not visible to ECRIT working group members. Jon recently did the AD review for draft-ietf-ecrit-requirements-12.txt, draft-ietf-ecrit-service-urn-05.txt and draft-ietf-ecrit-security-threats-03.txt. The draft editors quickly reacted and responded to the review comments to publish a draft update. An update to draft-ietf-ecrit-requirements-12.txt, and to draft-ietf-ecrit-service-urn-05.txt was published. An update to draft-ietf-ecrit-security-threats-03.txt will be published within the next few days. The PROTO shepherd will post the AD review and the proposed resolution. We would like to make sure that you feel comfortable with the changes. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 21 08:24: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 1HTzrc-0007pj-EO; Wed, 21 Mar 2007 08:24:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzra-0007pP-EW for ecrit@ietf.org; Wed, 21 Mar 2007 08:24:22 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTzrT-0006Ue-EF for ecrit@ietf.org; Wed, 21 Mar 2007 08:24:22 -0400 Received: (qmail invoked by alias); 21 Mar 2007 12:24:13 -0000 Received: from dhcp-1453.ietf68.org (EHLO [130.129.20.83]) [130.129.20.83] by mail.gmx.net (mp038) with SMTP; 21 Mar 2007 13:24:14 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19rMzp4JVdrh7hUIK8Ke+ts49ORBIclrQmgIc4Kzn XlSQIPtg3r1mEc Message-ID: <460123EE.4000204@gmx.net> Date: Wed, 21 Mar 2007 13:24:14 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Ecrit] [Fwd: AD review of draft-ietf-ecrit-service-urn-05.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 all, I am the PROTO shepherd for draft-ietf-ecrit-service-urn. You can find Jon's review in the attachment. Henning published a draft update. Here is the diff version: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-service-urn/draft-ietf-ecrit-service-urn-06-from-05.diff.html Here is the list of updates: * Updated Registration Template * Added introduction to the IANA Considerations section for better readability. * Minor update to the introduction section Ciao Hannes -------- Original Message -------- Subject: AD review of draft-ietf-ecrit-service-urn-05.txt Date: Fri, 2 Mar 2007 06:31:11 -0500 From: Peterson, Jon To: CC: Hannes Tschofenig , Marc Linsner Very nice document, in good shape. Given that the urn-nid review was performed some time ago for the service URN, I assume that any outstanding issues from that review were already incorporated here. Nit in the Introduction, the first citation of the SIP reference does not coincide with the first use of the term. Also nit in the Intro, end of the 5th to last paragraph, "Rather, protocols would carry the service URN described here, allowing universal identification." - it's unclear from the preceding paragraph what "rather" is intended to contrast. In Section 3, I note that "Declared registrant of the namespace" is still "TBD". I assume we would make the organization the ECRIT WG and assign Henning as the responsible entity? I think the IANA Considerations section might be a little difficult for IANA to parse. In Section 4 (before we get into the subsections), please do a sort of an overview - explicitly direct the IANA to create a new registry for "Service URN Labels" which will be initially populated with the values given in 4.4. Furthermore note that the definitions of those initially populated values are given in 4.2 and 4.3. Finally, state that the rules that are to be followed for handling new registrations in the "Service URN Labels" registry are given in Section 4.1. Finally, Section 4 should note that this document registers a new URN scheme and that the registration template for that scheme is given in Section 3. Again, might seem obvious, but best to be explicit. A note on the last sentence of the Sec Cons - the threats document does in fact characterize itself as investigating threats related to the "marketing" of signals (including the service URN), not just the mapping protocol. It would be appropriate to point to [18] more generally as a source of security considerations for use of the service URN, the mapping protocol aside. - J _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 21 08:24: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 1HTzrP-0007lF-UO; Wed, 21 Mar 2007 08:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTzrO-0007l1-E1 for ecrit@ietf.org; Wed, 21 Mar 2007 08:24:10 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HTzrI-0006Ou-Dl for ecrit@ietf.org; Wed, 21 Mar 2007 08:24:10 -0400 Received: (qmail invoked by alias); 21 Mar 2007 12:24:03 -0000 Received: from dhcp-1453.ietf68.org (EHLO [130.129.20.83]) [130.129.20.83] by mail.gmx.net (mp033) with SMTP; 21 Mar 2007 13:24:03 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18EQtY/XjsEAiqtNYeujn5wjcP4HXtufPewQTzZiS v0NhSwzdELs/MH Message-ID: <460123E4.90907@gmx.net> Date: Wed, 21 Mar 2007 13:24:04 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Ecrit] [Fwd: AD review of draft-ietf-ecrit-requirements-12.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 all, I am the PROTO shepherd for draft-ietf-ecrit-service-urn. You can find Jon's review in the attachment. Henning published a draft update. Here is the diff version: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/draft-ietf-ecrit-requirements-13-from-12.diff.html Here is the list of updates: * Update to the introduction * Terminology: Changed "Internet Attachment Provider (IAP)" to "Internet Access Provider (IAP)"; Updated "Emergency Service Routing Proxy (ESRP)" term * Editorial change to Lo5 * Deleted requirement Ma9 regarding "URI alternate contact" * Clarified Ma15 * Deleted requirement Ma18 regarding "Alternate mapping sources" * Boilerplate update Scanning through the diff I noticed two nits: * The intended status of the document is not "Standards Track" * I-D.hardie-ecrit-lost reference needs to be replaced with I-D.ietf-ecrit-lost Ciao Hannes -------- Original Message -------- Subject: AD review of draft-ietf-ecrit-requirements-12.txt Date: Fri, 2 Mar 2007 06:30:00 -0500 From: Peterson, Jon To: , CC: Hannes Tschofenig , Marc Linsner Document is in fine shape. You may need a pass to meet current I-D nits constraints introduced since it was last issued. I expected the last paragraph in Section 1 to have an additional sentence saying something to the effect that the latter use (displaying location information at the PSAP) is orthogonal to the mapping protocol problem and the scope of this document. 3.2 - The term "Internet Attachment Provider" is not a common one, and doesn't seem to be distinguished from the more common concept of an access network. I would suggest that "access network" at least be provided as a synonym in the definition. 3.4 - I'm not sure what the need is to suggest that the ESRP function might be performed by a B2BUA. At a high level, I suppose I see the mapping client function as one that could be performed by a number of entities, including entities that instantiate the SIP proxy role and the SIP user agent client role. I think language to that effect would be preferable to suggesting that there is some motivation for pairing the mapping client function with a B2BUA. 3.6 - This sentence is broken: (Emergency) service URL: The service URL is a protocol-specific (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the address of the PSAP or other emergency service. after the im: citation, you probably want the words: "identifier which" In Section 6, why is Lo5 called "Validation resolution"? The description of the requirement doesn't seem to relate to validation or resolution, as far as I can tell. "Additional Information" or something might be a better name for this requirement. In Section 8, Ma11 uses the seemingly innocuous name "URI properties" to provide requirements that seem to contradict Ma8. If the mapping protocol is going to return multiple PSAP URIs as described in Ma11, there should be a story stronger than "local policy" to meet the requirement of Ma8. You might want to find a better name for Ma11 than "URI properties", too. Also in 8, how is Ma15 different from Ma18? - J _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 21 09:13: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 1HU0d6-0001TK-E5; Wed, 21 Mar 2007 09:13:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HU0d6-0001TF-2q for ecrit@ietf.org; Wed, 21 Mar 2007 09:13:28 -0400 Received: from [206.173.41.176] (helo=sea-mimesweep-1.telecomsys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HU0d4-0005Mb-HZ for ecrit@ietf.org; Wed, 21 Mar 2007 09:13:28 -0400 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 21 Mar 2007 06:13:19 -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] [Fwd: AD review of draft-ietf-ecrit-requirements-12.txt] Date: Wed, 21 Mar 2007 06:13:17 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A657507118DFD@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <460123E4.90907@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Fwd: AD review of draft-ietf-ecrit-requirements-12.txt] Thread-Index: Acdrs/y1PdLDAKzZS9mY3y5knCP2fQAAY1YA References: <460123E4.90907@gmx.net> From: "Roger Marshall" To: "Hannes Tschofenig" , "ECRIT" X-Spam-Score: 0.5 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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: Clarification: I think what we're talking about is the draft-ietf-ecrit-requirements, (rather than service-urn). As such, the next version, (-14), will at least fix the two nits mentioned below: >Scanning through the diff I noticed two nits: >* The intended status of the document is not "Standards Track" Changed this to "info" >* I-D.hardie-ecrit-lost reference needs to be replaced with=20 >I-D.ietf-ecrit-lost Done. Anything else? -roger marshall. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Wednesday, March 21, 2007 5:24 AM >To: ECRIT >Subject: [Ecrit] [Fwd: AD review of=20 >draft-ietf-ecrit-requirements-12.txt] > >Hi all, > >I am the PROTO shepherd for draft-ietf-ecrit-service-urn. You=20 >can find Jon's review in the attachment. Henning published a=20 >draft update. Here is the diff version: >http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-requirements/dr >aft-ietf-ecrit-requirements-13-from-12.diff.html > >Here is the list of updates: >* Update to the introduction >* Terminology: Changed "Internet Attachment Provider (IAP)" to=20 >"Internet Access Provider (IAP)"; Updated "Emergency Service=20 >Routing Proxy (ESRP)"=20 >term >* Editorial change to Lo5 >* Deleted requirement Ma9 regarding "URI alternate contact" >* Clarified Ma15 >* Deleted requirement Ma18 regarding "Alternate mapping sources" >* Boilerplate update > >Scanning through the diff I noticed two nits: >* The intended status of the document is not "Standards Track" >* I-D.hardie-ecrit-lost reference needs to be replaced with=20 >I-D.ietf-ecrit-lost > >Ciao >Hannes > > >-------- Original Message -------- >Subject: AD review of draft-ietf-ecrit-requirements-12.txt >Date: Fri, 2 Mar 2007 06:30:00 -0500 >From: Peterson, Jon >To: , >CC: Hannes Tschofenig , Marc Linsner=20 > > > > >Document is in fine shape. You may need a pass to meet current=20 >I-D nits constraints introduced since it was last issued. > >I expected the last paragraph in Section 1 to have an=20 >additional sentence saying something to the effect that the=20 >latter use (displaying location information at the PSAP) is=20 >orthogonal to the mapping protocol problem and the scope of=20 >this document. > >3.2 - The term "Internet Attachment Provider" is not a common=20 >one, and doesn't seem to be distinguished from the more common=20 >concept of an access network. I would suggest that "access=20 >network" at least be provided as a synonym in the definition. > >3.4 - I'm not sure what the need is to suggest that the ESRP=20 >function might be performed by a B2BUA. At a high level, I=20 >suppose I see the mapping client function as one that could be=20 >performed by a number of entities, including entities that=20 >instantiate the SIP proxy role and the SIP user agent client=20 >role. I think language to that effect would be preferable to=20 >suggesting that there is some motivation for pairing the=20 >mapping client function with a B2BUA. > >3.6 - This sentence is broken: =20 > > (Emergency) service URL: The service URL is a protocol-specific > (e.g., SIP) or protocol-agnostic (e.g., im: [5]) contains the > address of the PSAP or other emergency service.=20 > >after the im: citation, you probably want the words: "identifier which" > >In Section 6, why is Lo5 called "Validation resolution"? The=20 >description of the requirement doesn't seem to relate to=20 >validation or resolution, as far as I can tell. "Additional=20 >Information" or something might be a better name for this requirement. > >In Section 8, Ma11 uses the seemingly innocuous name "URI=20 >properties" to provide requirements that seem to contradict=20 >Ma8. If the mapping protocol is going to return multiple PSAP=20 >URIs as described in Ma11, there should be a story stronger=20 >than "local policy" to meet the requirement of Ma8. You might=20 >want to find a better name for Ma11 than "URI properties", too. > >Also in 8, how is Ma15 different from Ma18? > >- J > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > 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 Thu Mar 22 10:51: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 1HUOdl-0007BD-JR; Thu, 22 Mar 2007 10:51:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOd7-0005EW-Fg; Thu, 22 Mar 2007 10:51:05 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUOd7-0005da-2H; Thu, 22 Mar 2007 10:51:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7AFED2ACEA; Thu, 22 Mar 2007 14:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HUOc7-0008B1-7O; Thu, 22 Mar 2007 10:50:03 -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: Thu, 22 Mar 2007 10:50:03 -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-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 --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-01.txt Pages : 9 Date : 2007-3-22 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-01.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-01.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-01.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-3-22084217.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-dhc-lost-discovery-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-22084217.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 Thu Mar 22 11:31: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 1HUPGC-0007Jq-Io; Thu, 22 Mar 2007 11:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUPGB-0007JM-Qg for ecrit@ietf.org; Thu, 22 Mar 2007 11:31:27 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HUPFl-0002rC-TG for ecrit@ietf.org; Thu, 22 Mar 2007 11:31:27 -0400 Received: (qmail invoked by alias); 22 Mar 2007 15:24:18 -0000 Received: from dhcp-1453.ietf68.org (EHLO [130.129.20.83]) [130.129.20.83] by mail.gmx.net (mp049) with SMTP; 22 Mar 2007 16:24:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18z7t1Qaf0zBtgi0+6fceOpVYWh0vQrBpG+kYX7kv pBjqgxQcExusSF Message-ID: <46029FA1.4070405@gmx.net> Date: Thu, 22 Mar 2007 16:24:17 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Leslie Daigle Subject: Re: [Ecrit] I-D ACTION:draft-ietf-ecrit-dhc-lost-discovery-01.txt 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: d185fa790257f526fedfd5d01ed9c976 Cc: ecrit@ietf.org 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 Leslie, you provided review comments for this document. Could you please check whether you are OK with the draft update? Here is the diff: http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-dhc-lost-discovery/draft-ietf-ecrit-dhc-lost-discovery-01-from-00.diff.html Ciao Hannes Internet-Drafts@ietf.org wrote: > 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-01.txt > Pages : 9 > Date : 2007-3-22 > > 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-01.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-01.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-01.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. > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mar 23 08:18: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 1HUiik-00065G-IF; Fri, 23 Mar 2007 08:18:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUiii-00062k-TV for Ecrit@ietf.org; Fri, 23 Mar 2007 08:18:12 -0400 Received: from lin.calsoft.co.in ([203.129.222.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUiig-0003Ml-11 for Ecrit@ietf.org; Fri, 23 Mar 2007 08:18:12 -0400 Received: from SHELTAN ([220.227.139.90]) (authenticated bits=0) by lin.calsoft.co.in (8.13.1/8.13.1) with ESMTP id l2NCHxFV016222 for ; Fri, 23 Mar 2007 17:47:59 +0530 Message-ID: <01a301c76d45$884ff160$0d0310ac@SHELTAN> From: "SHELTAN" To: Date: Fri, 23 Mar 2007 17:49:40 +0530 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 X-Spam-Status: No, score=-2.6 required=1.0 tests=BAYES_00,HTML_MESSAGE autolearn=failed version=3.0.6, No X-Spam-Checker-Version: SpamAssassin 3.0.6 (2005-12-07) on lin.calsoft.co.in X-calsoft.co.in-MailScanner-Information: Please contact the ISP for more information X-calsoft.co.in-MailScanner: Found to be clean X-calsoft.co.in-MailScanner-From: sheltant@calsoft.co.in X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Subject: [Ecrit] Equivstor 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="===============0648816611==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0648816611== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A0_01C76D73.A1C30E10" This is a multi-part message in MIME format. ------=_NextPart_000_01A0_01C76D73.A1C30E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hai,=0A= =0A= Can you people help me In Knowing about equivstor , which can be implemente= d in the layer two devices ...=20=0A= =0A= IF SNMP is not supported..Equivstor is implemented instead of SNMP , in whi= ch the functional equivalent is provided in the depending on the mode of O= peration ( Tx, Rx , Tx &Rx ) ....=0A= =0A= Destination address,Source address,Ethertype, LLDPD= U.=0A= =0A= LLDPDU Contains=20=20=20=20=0A= Chassis ID TLV.=0A= =0A= Port ID TLV.=0A= =0A= Time To Live TLV.=0A= =0A= Optional TLVs Such as System Capabilities (may be inserted in any= order).=0A= =0A= The End Of LLDPDU TLV ( the last TLV in the LLDPDU).=0A= =0A= LLDP agents need to have a place to store both information about the local = system and information they have received about remote systems=0A= =0A= LLDP Entity's Data storage and retrieval is provided by the LLDP/LSAP and= LLC to transmit and receive LLDPDUs...=0A= =0A= =0A= Regards,=0A= =0A= Sheltan.T.T=0A= =0A= ------=_NextPart_000_01A0_01C76D73.A1C30E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= = =0A= =0A= =0A= =0A= =0A=
Hai,
=0A=
 
=0A=
Can you people help me In Knowing about equivstor ,= which can=20=0A= be implemented in the layer two devices ...
=0A=
 
=0A=
=0A=

IF SNMP is not supported..Equivstor is implemented instead of= SNMP ,=20=0A= in which the functional equivalent is provided in the depending o= n the=20=0A=  mode of Operation ( Tx, Rx , Tx &Rx )=20=0A= ....

=0A=
           =             =20= =0A= Destination address,Source=20=0A= address,Ethertype, LLDPDU.
=0A=
 
=0A=
=0A=
=0A=
    LLDPDU=20=0A= Contains   
=0A=
=0A=
=0A=

Chassis ID TLV.

=0A=

 Port ID TLV.

= =0A=

 Time To Live TLV.

=0A=

 Optional TLVs=20= =0A= Such as System Capabilities  (may be inserted in any=20= =0A= order).

=0A=

 The End Of LLDPDU=20=0A= TLV ( the last TLV in the=20=0A= LLDPDU).

=0A=

LLDP agents need to have a plac= e to store=20=0A= both information about the local system and information they have received = about=20=0A= remote systems

=0A=
=0A=
LLDP Entity's Data storage and=20=0A= retrieval is provided by the LLDP/LSAP and LLC to transmit and recei= ve=20=0A= LLDPDUs...
=0A=
 
=0A=
 
=0A=
=0A=
Regards,
=0A=
 
=0A=
Sheltan.T.T
= =0A= ------=_NextPart_000_01A0_01C76D73.A1C30E10-- --===============0648816611== 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 --===============0648816611==-- From ecrit-bounces@ietf.org Tue Mar 27 07:07: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 1HW9VY-0003lh-Jr; Tue, 27 Mar 2007 07:06:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW9Tg-0003WH-FN for ecrit@ietf.org; Tue, 27 Mar 2007 07:04:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HW9Td-0000rJ-Gj for ecrit@ietf.org; Tue, 27 Mar 2007 07:04:36 -0400 Received: (qmail invoked by alias); 27 Mar 2007 11:04:21 -0000 Received: from ip-90-187-102-7.web.vodafone.de (EHLO [90.187.102.7]) [90.187.102.7] by mail.gmx.net (mp046) with SMTP; 27 Mar 2007 13:04:21 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/8Ys4AWPv8btv27rV6UxpT2CCMs++u8uJWRDaeas Bf97+E4hZa+Xl5 Message-ID: <4608FA31.2060803@gmx.net> Date: Tue, 27 Mar 2007 13:04:17 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: ECRIT Content-Type: multipart/mixed; boundary="------------090207020203080603050609" X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d7ef08699010bf3e567f9799847f2bd X-Mailman-Approved-At: Tue, 27 Mar 2007 07:06:30 -0400 Cc: "Liess, Laura" Subject: [Ecrit] ECRIT Architecture Review by Deutsche Telekom 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. --------------090207020203080603050609 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, the chairs have sent request for reviews to VoIP providers and we have already received a few responses. Here is another one from the Deutsche Telekom. We would like to thank Deutsche Telekom for their honest review comments. Ciao Hannes --------------090207020203080603050609 Content-Type: application/octet-stream; name="Ecrit_comments_final_DT.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Ecrit_comments_final_DT.pdf" JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1d27LdxnGtOPeTVPIL+y17p3wgDDCDi98SXWylHMeWTyUPUh6O eDmkKR1SFEnbv6GfyG9mBrfu6V6YAfbZpOKqFEviJjCYG2ZWd6/uHnx3KAtzKMOf6e9H3159 9EV/uPv+arh6+OLn04/Xd1ffXZnx9/TXo28P/3rjixtz6Iu+Odw8vRorMYe2LHrTdYe6K+rG 1Iebb6+Oh9PN764qUxem8mVuHl99efztyRRtZ213fHK6nn8+P5VF11eVNcc34WfXt/18vypr X891VfR907VHc7puitK2xvqr/33zb1eVLQvbjdWPDQ7d63yh0L1r6+qiObS+W50VZYyZCpmq 8NVUh5tfXt3885fHz0+mDS03x09PVVGXtj7enK67wjW2q4+f+RE0zvS+W8vtj0910bu2ro9f LL/mWuZnXXjik5MtmrJrji8fheE11vmBvP02FDV1OU3KWPv9m9P1VPgw1tpUNS/w7mT8XDW9 8fM3l2S3fz835WevLMqyddZU3TRr0Rz5aoax+3v/dNX72SzLbvm3nqm6F3fneirThDdtbWGa MJt4ssMML9NwS/0dhuu6ro5m4WfD0Oqy7sM4/HSG54YF4eejcNWxdH7FlKZu/AQfi3Icq5+p puuPdVGV5WkYfFmbpjq24+j9KHrHRjH879Obq99clYU7zP+FjcD+mdoO9cE4sR+s9Y2Y/tA2 4eWbsB++PP5ZWDul787xJ37p9LY2brjm+tJ3l6795GT8sq1NH3o7dMwMlfoujT/2dsZ1fv90 cWf+PMxyaaqmOf5FmDZnrWvt8S/9WiubznXHv/L9KfuqqY9/HYr2xr+R49+En7ZyTXf82/BU XfuptL4GWztfRbP0+HJT6fy6cnHv/Qz5hXWJmZlfkw0Lf5oZ/iIe/ssev7pn88vn+u8CgLQe 9saLrm5dffx7v2Jd7eq+OX71elgwfeWO/xAwsGpDdal1ctlZ93s9npl/XBYr/1W1vUe6ZgKW +lCNWDH0rJ+gmV7YIl3M4flV0/qF5ZHZC4K2aDx4FK3H+W75+/WTq6dbCzW+E24pVBnniiou U3V1qCldkS/ka+qXQr4eG5ewdV/yErAaX8hvCFaNB/hCVORc5bL92VRomSIvj4qSCjlbD3sn LlT1fVHlakoXmiZ7KpSc7KlLXsT1XsjHXVoKpVpb3shUKPFGUm0thVJtLa9tbiv12lKTvRRK tbap0KKXnaGOtVW5YOYsjB2VNl7ZKg0pPl5XMm3fH+/97u5r19lRLNfWtOb4epACtfNqyMtB DausbY6PT/PFt8uvR2NJW5r5+aquBjWvrWxdL8/XnRubcn3ruGrCOugChsyS2v+7nST3qEdc B83Ri/ZFn6war1Cd5soHdbI3pcfK7/3gvBws3di7tqu9gvdsKOnK5fFw0WsXXgT6F2+C7uaB 0ZW+UlbgG9JX2dUXS11sdF6186K3qbu51qozXN8de9Xamrf6nHp9v1T6Bjb6epzevmn5VaoV P/V47GAQ7XO3nOXdGpsV928jjXy+OrbVVIa3dUvKPY2AtcruTyPorJsLhLKhL17hKNtqbMCv QMdNAlYU9/D1aB2UAZYm2+MR3X22jC9ne7CH6P7bZUxj710p7RXRo9WJmIpav+de0VWq9SVd pObZRda9lzQl38gFFl4P69XTk5ckfVAr2EPsRbCizEyb1rLj19hDd8P4StPy+/fLxUd08Y+h oqCTzw2VfqTT/d5vFTZpbCTjT2/51Xqlhgbulvn9KU3qQf0Mbf3+VAXbwGPSs2mZ2AA40zp5 Tg2xThFUsDrHkTZ927KOXJ88xHmjowpVX1tvXpnmcB2gazKLvpxHGPbi1wQW4wg5msWbmUHE NAJrOdgwMGDz9pgKTE+5hs8gu49B8D8nlA14xFr7nFr7tX/OG5GNa/lzrDaCQYxddwiH7xcY Z6tcrZ2wSNn9xNoZ9g4EuTv5bndskrAMxgJl58UhggZW6TSXQ/tsG3++lP31uCD9IKtuXpCs JTZSamkSbd6QgxgxTX7VcIyi3tHThdosocu/wF2mPcRqfSffo8AIvTNDCwwP36IKWFEmY15C EUAzoGR7T1I4gMA7hFesrxClvoHt01xoPBerhj0VFlhbBs1KCqHxJ2uWXmEkOUfs6gpr56VC IMxQjKBp7p4fFLW+trz9lRHBKq99VwLB3hBWPTul8UMDhe2tR0nfvrEMMvqa4yLtfqytAFSS O2loq63aoa2mta3l3SJcxZj0bukAez1s/0mI7vz+nxd4qJ/1lXAXz9A9gj+2KvEM3KLd/BAl JzTF1l9Gy4Gaxe20Jr0htOhdhLN4HMmNktN8Qp/ZVQJ6gjX9IgbBz1XN8RE1d1DaD/fpjbEN +TXqB9YLJXiLaczCnHojoX1RaWOMATAaRsLqz8Ekq+APAlxIwRyaYpUqKRvqv2MwNK4SE6tc QqEjhGLLgk03bJkVHaajdF4os7UilDOv+LkJ2ga7UkAbWZIzMJRwDxN0BftTa2x9zVQgek3K Eg0tMVy4FRAjl/Mr0sbYHqDm6RebYKVwMuvQ4/uiBkwYNntePjvNXcEaJ169YputGL1wRQtt jiaADZWgZVwMjaknCLZ2Bvsy0NZQW5nu2ypCJsKDCK4Gx0FgaeY1i81httQgPrPmScGkFUG4 Qb8mRaQCADCsc7ZD3wFUYy0qPSXUxKZz7FGzpnGRQMHOuVH2Nq4xx09DBSOsMQ7ls5PAIuO6 FTnExkdDwcoRw61pk7WOX5yqqt2DbFSmfbOXq+yMWfy1yJxExiqrHrMirNFnCIDfUP3DoLrS ln0K8qpg665qcznIKwjS2P75r9N161tujQHwKHR8Rm9hhYBEBoMa/e7ZNhD81zuEOuw+6WMM bF9BWMM9YFcZhr+EyMqaYKwVW/WYN3vOV5VWamZbrZyxiTyZKYr346A1t1XdVjFLWTkP/l3H fj0htndkgxvbcDb3+4Es7mO9RfK6w0NsAmY2OWDJXDtrKDIaZi7609P0yM3847NQbLwp6YaI fw4/GWnN+GfqR6xPD6R23U9PhTXOqOyxy+HXWJNzrp9rCuDyhIpOT7EpM2bix8O113R7fKhq BsGe4r/D25s2XHANTgJp3sTjfQa1I1RYu6auDHus7ruZChr2PlvL2FBRwkCYR1LZE/oM5J8Y R6+0bmpT3MfdY1fZUNhuThra220qMer3QRw/B3s+Q3Mw8IgGN2oupV9lkUgiiTr80pzv2XaO 7HHZNJ1Wl6qu5QYZU0NobjSNKewgsaKk2oZJJNbVDDemeEmaE8G+QyWNbLtJve5dJNrfIXnO JHfcfS+3u95VG5ibRaNQkrTvuZJ0S0rS44l3rJjhjjvFNC/AZoYGPidMnEmYsuGEktePrBVW F9uwwy6x/jfz/TANhTkfc7wyWRoF6Srjjgh4+QvmP2Sii8h15lQkOgg3dR7zM65V/zsWnfNb +2FQyLtYSZi2T2kaDb1CT1FsOnM/CWzG2g32StK0v0oYk+sbTHg1Jf4gcFvBw9n0uCQXNqrw fdEsrOp2Uizn+oMwQf1gnYMTx7Y2tIcZINxLWUo+jabDaJv19VKdb5f5XLyCX0PlVtVeklcz YAWBGbuPjVuGVkT9qBEHNKXbK06/NOxC8o8zCCNUmqJELhqt5AMjrCoXSn1BQAKrRwQ7zAhj G5BxOFi9wwW+oRq0J8fD3c8kyDC8HOMvOmE4GsLiYsZ3r8G2iwbbFl5LblsVoLtouKUXBeUi cpQGu67sSYEhNiW2DGE8BVvhnzCvwtwXRyU6Tl5p1jE0xjg7DMR3Egz6SLPbrPixN8hWH/IK Zl1paqpF0XkmvGVE/hUK5Wbu3385+eVhnO/er5hu8NHSaXr83wN4u6bu26kmCJ9Na/vZ0WX8 kxcJ5tjn54DvBqJrwvcoJhS7EaX1hKqPlpNgt0hkaE9uQMDp5dQaH0NBQmLMQ7GKIBJDqMXu hxcLACsFNXanan9xqF6t3JHQG+V2yeQ2UzmNXVivBXAZ2DAf5W8Xoluva3/7VwwhLh7sIJwC UFvQwQ4iJo2h/PZohwzsoBADegRGWmzfNxkjkALrCnqGPT69GzfF+HWd6dVek4gptxpx/MGf 7hpA8kNHHUSc7dMKl7+WTCLyAxrdUAPexhjEHAV7htB6I5/PvKThaoLPT0U7KM057G9t/+cc maJfereHzgy7fbDLs1LswMFoQJVprcQq0Z8IEqyKmVvYVRg0i9+kXgBpEkzq+XCnbAykzMYT iA3Grp4XSokIqG8QMB4W1xAFdmGTaZtGsWoOsk0NbUgcg6WICqGx4BA7COcbQU28VXLN4VWR DWTQgRIJXQHVxWirEe4GtUbC3YAV2PuYgrvBP4eRfc3tN66XqliWC7RbpXevCVYpCmiQdgjb 0QllWBpQ7OUxGhhXy5BEmiUi7Ar6CFKMGY95EDwVEWFZmQpBEVoOCnNWVX9tlsVMMM0EC/hm kAVVILx7qFGoQWnvq8Dsp3Pw87zAKCIBMjjbGbwXsYgQqh+ewkwcwjaGL27yfMeMRB+8XdWQ AqPFsAGGNUl/vTLjltGzlrBTANpxXx2Hquq6RS5rAcvsOSjW7ybvkSuaGIXGh2fzqu77QupB 2DEuDIkoN8df/OpEqDNr+90sPK8F/TTSSYHIr348GupiPscHK1zbQT3DcCRSk27VlghP3aXr X3NMSkkC/WxCoSeISoUFzXxGFL+fI7tD9RqTYy/n88Wb2gEmCtpTz+EehJoTtcNqItUfx6mz 54E/LrTAzB2dqRFb97iJd4hh06HQYlWohCaph0P3J6bPWQUEepgd0otJ6Gbsdb8FLgOM+lkt DgaU3S5KHIXofw2NixVUJ4D18t3CqC0RjQF9b3v8fNk4KBldJSO5UjHuQm3TUxmKQlcos2Wh MfzBnPo4whPafEj5UWlqjM0K64hp1W/TShZs/fsl75GcU4lMmVSMuZqndQDfznxn/BM4jAHT 5RcCXrG7Ufz5lN/llg42tWlwUg4Ogs+1vyOkA0bFZ+3kFUptFGZNIf2YAUez2EjhHCHGUNic Wa3n8ji0LZvxXiLlakCoXnUi3hO7+sbO9MZqHBNWGdvqMNCdwRM2mbbJ7dgmwmI7ky0DdS3o JlcZgDH2/nERiOTKy3H16uXMO3ZKEL8/uaLva29bw/RD5LpAqcwp17Ag4FWyhUh/p4vKY8E8 6tdVVYZp0CaNaQsp6/+DuZ3WnY8rTLjYAlgAwzQ+neARp85ld54Oi7pkTGcuPUBo96moemRe 7fEfCzUXSz9lXqn0OcTtMpygwXLufoDxrg8aYhk5IUSnoQOMSZxlW0C4wCkPWZaJBnoL8Yw2 LbuP+CV2m5x22Izdkbu9w4Ok7ai6qabk0tb0YKbjsCT6hX1kWHeAYo4VhXnKr4iPYszSy8XD uQh8XXsdhTDF9HLdD4e9xaI+F3qp6YMt8YhPl9DHbL4ZpHFheBA55HCAlJQB0suPhT9bWPNk T+FaXguoywqLQpJL2COj6XXhUWP7gSAIag/QIQ1tCoxg3yGbhGpaSQ8elcvh4MVI0lemJg9q OGXMAhH40RemJ3ZukYfTojv+z1SGGD6bY/jqiOGToD+8acJUpdusrjMVF0yxAiJILBEKK0Qx 3DtZhVl5FmJzk96SxuH1WPltHkghZx8p6bOqbuaiKkhxJkyHI6HYjzdiYVIyMAcGJcRn9yy5 Q7LifDvFiDO/4LEkuTM00qTCfsm2Ho+Gj+RRUmowm1lIb8LCFntHmb1CXo07xk1Q15VdPKod BnaSgl716nDROlu70xKJtXOKGVPnTzQ2Clb64iScqqTOiKyi8wJN9ZzENJp2uIX7tJBzIReQ EtM03JYDr8arxnWzkt+03tTcbrOyVief17A/YDioRHYcMiIUStrJOX1SUUEjtOvzWfRIhK7/ AAEsH9ps5BIGz+63UJOKIY1MV1sHuf7h5XZWCmIzVJKyHGqF7Fb4vZr4iOUgVDzhZtbnBK6d rfbD7BKGPA1kTTBNfZZbCkkcuCP2sMs43GqZh1dQYMLuv1nOZqB9BuUxnLzNKTFI/3gCgUkT +4BNkzQDiWg2HW/RdlVSi4ckhatK0RReL3UelAiUwvEB0MFF1DDRxUyAMwdcLiYrKaFFMAUu ACdYHc5g+qqoGx0hXvdewxBiPZ1mE6ncMKwJW7YJ9xY36CugajJzmPFNwhxOBaAKXIE8irKh l/MwTBkTPhdzheW0jtQ5ESzvLT4sag8aKV91V1Wzs6Fs+1gtmT1slFCdNaNgB6FFBbEnhfDr ERbP0VN7PRHc7zMmCqMwS5npnPFERBEEKKiJk+clzQUdd+E1ELOQ57N2sUaeo6yuJjoMjinT 0mKWEZDs5347XRyFsl9DWSflc1T++1xOW429dUG7CP6HLuVdZ9tOx5CFXMxpJ2865FYY0gow YexAHKUNd/wD/XXrM4ycyNt0GfxWYdZuLtR6T2Rlsmx8IqbWcQJM3ceSWQZJbtR2ppN952VC /pUNZyoROOyIqYacDbb0z3OnnXuY76WigtaD17Aykcgw2CL4d6bDbiI6H25uzZmK8ozMc+2u HBNxltWXC2nPptmk4jPWZxcH7ecA5X2rIjusF2hdMQVKnlEnD4WJoWVaJrHHbfdx2e8lbyw0 FZ8VOf/cGD4NQ1hg6HJo6hVUphRUrJ8zC7cG2mM4l00dhbQaNoiZPZXfwOhWJv3Edsh9XiHq q/rkwXjIcjgvLJFdEQ5hpIKrONh57bthBWFCBj2NSRCUpSG42dp0PTuxWVOzYj9v0itbh7fo 6mFLMUkt4QKrJ9izhHEaeu3lULDqun4OuRZCAXBYwsnzJeKvQdGhHLpQdN+i28Bzh5RoEsoC kREp14U8nYTqZwCTO0xWk4vxx1iSxxaFbv3hAdSEOCqaqsJL+R6oKLQ5oDcQ58HDbyueFQ2Y IkbEV0kUL+J1R6LXsvpfKqdWn9KtZPW6mx5B+llJfbtYIzY5OzQgATlb9/aOcGOhjXxN3tYU 3RMu4rR7WbSxXZvQYcY1Eesw0F5IHK8vaRaIJlDdURH1Ydurkju9PFuDgxf1W6lTF/O6vBft /4EnhY0EgW2i6Rt/9tHp05Pn1nTDiGfDCKWk7rbVVo/sx7t9d2YCTGCPI200p8JOEqnr2d8a ijJMn5VqN8d2Xk9zot2t14DtrMfhXSwZcjrbuav1AUsrgeA745GTIb4whVLG5X2oFEqm0Qjd D6u7H5JU+BHQROUGp4jhuBeQwNwdJbUasKFTJ4SCxoRC5kzGHMToqGDXV8xOwo7u/1NRwcvV HQpLKppaRoQdQCxo/mAO8sxafVwsDNrF/lYcEZKigdYPwN7xgaJcKnUuJARzxXqIG1Yr3BfY iKD4NUhSaDolMqyhw5dtAOjGQcHLkAGBDAo/BGNaZeDwrmwo56SHAC8Mt/hdqU9YZEwjCXcd 1j2fVMvOUoQG1e9O1/PhU9DepA+dMOUB2yTQyHwikWXYrGx+1sglZKqkhPz6d4Ryh3phwJHZ 4vIDjdhPBF1CjxePjkUnuG7OfAzHXljJjXygUDF8qJjhZ0ZD2LmY4QLjSgU588G9v+g4rkSM 1YYsa/XFxRiooJeEOydnUqQSYeVh2D8sKKaQz8YJHhSok8z6Xc1+j5mQMKuUmyckwMbtLfBz 7zSxYL8qY2etfgARfqMHRaRhaPiEnZYxobJfv5KPTcWnZzFLysOmDZ8jJCTTPEm1LbsKErAq nmpHWMiDE553QINIYs1leklwADZQNipli0Nz+yEGO1gFzIBuomJd1c5Ur42TCD5e5JdZrHSk lmACMxPi8tBjDrc7iHHUGfy6CLTREgcNDsoBDi15yEGD2rDZHP2ivUcCQd4b7au+XDdkJlam cfy0CxnRolLTv9y6UTMOnk25Kfhswe2o96AsAIG1mg3H0ZOhCw/gEkJJIJJYoOImn0SmMZg0 ch5hGkHbCEhNYePEYnxmlNBYIEG0l/hlCkE1fy5n/dMgmMohlMOhaNCKSn6clwFawIsdof07 8tLxYaOE4y9i0SBj4XYctww/NgU/pI1H8hIw/NzV3CxEzwI650Xmjs0PGUvQq4sdwJgJwgSb Oo+q6yodDlM35ZLrbDoQrRxOL7QXJux5uPNG9BPkvNI0hcqW+z5BLupHyzpGd5+naa5HCKAU 4vftPkvRy+tpfnvPX90UdxTNhD6DGmqLOqb2fCZdne8hDCMyF3MiIXGEvogFxW8CH56CIJsd 5wq7L09zlVFZ8DuzPyVlEaMvROfUp0K2fEl2O+Rzc3pJda7kwV4w0YnhxXm8+iUPHcRZUSTb U0El5CsUeEIyFFodVHvue+5rH1H+k3cEhkRneOYg7AZENYV/66kAMOcCW+sZAMGolDqJLP6K OEbFpJ5eLqdQCogAqmBZJwWrYNnPjgvMGZGLOgXPH4SkHraenwFfICTXgzbYSxP0l6eucH1Z RdhwBnmNIguH4Y3+L39b74/3Y/gKnKGTJBSixb4poCHYlSi6S+cbM5Y3ps2hxYmC8FLni+2k 90boadlq2hGmCT+imPryYpjYF8iyfeDp9iTFaV6xDQpHh1W3HT677PkoygiSDFsi+3ooqjlC 8Lk6mWw6lrS1BScV7gfBGXgqtFTWv6OBPHsPsUQuhyi5WOkB0R6Qbg5juYW/OeF5mj7eFx5q XGMekjx50WxzHfnAQhtY1J2IWR0Nb/UJTPf/4XYfPtxO629bMoBywezQQ4TPz+QnbouAD7Gu oPTda9+OcnoEsJqdnYvBmo2TdZksE5RokPuoO3YWZ+UGPuJentsmfMQZc4Xd/jkjzCFnAh3H yObF1nlWjcdKMLmesyE0uW82NCAhVxzHsuJH158ekId5Og9jP15q4fr3bZVg3ejPFooaZH5z J6wlEh4Fmszvxas8lHrDvDbg24Grj9E3LNnbHvrX1quBaqwm0qPw5yWgws1WE/WEbU1ujo9h LBXj7XWwaUxx0kcUCZbplUNTmrbtWW+BbR/4/BuAtDgCf6y/6lqrc1nXHR3a5yO6ohh4+T0R GNGSxaBLhvVuQ5jhXIS1fJ9Pb65+4//8L+ZXwFBlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoK Njc2NQplbmRvYmoKMjMgMCBvYmoKPDwvTGVuZ3RoIDI0IDAgUi9GaWx0ZXIgL0ZsYXRlRGVj b2RlPj4Kc3RyZWFtCnic7L3bkie5ceZ5n0+RezWVGlYKZ0TsnUTJZBqTNBx2r+aCnIsm+1Ac VXdTzW5yNI+xT7yICPgBHzwjq8gerWgGo5lU9svAweMPBxyOwNf/+uie/aM7/tf//6+/fvjL n4f6+NXvHk78+PO/6//47quHf33w17/7//v1149//Wl73vvH/Xkvj59++XDV4h+re979tj3G 7TkWHx8//frhzePTp//zIfj47EN75tPPH37x5pMn/1y3lLY3Xzy9pX/+5sk9b3sIyb/5/vjn tted/h5cbPW8Dc/7Xrb6Jjy9Lc8uVZ8a/R+f/peHkNxz2q7qrwbfJl+fy2ON9TmHq9Wvnlqh kB23GkN5880J45bf/Fqa+rcnvz27Graj0fjsfMhJ//0zKf9een390zuftS3fcKtfcVO9Vh+9 rup7KaQeUA18e5p91vCHpxCfg8vF6OFRV380lPjmd0/xOeWaom7ggiV4Xf5XUsh8Az88jXVu pcyWHn+WN61Ky4/6Dn+I/vPSk2pQ/C9+9DdcXBqXKm9e+NEhVfnPWuXuucHQhuE5dtxRCQ3N T9uf83N2Jb35p6e3+INMFVA//+rJ+2efc+Y/56o6qopbdqg//wv3+YtXxqNU9M2Hvu7fvDIA Tli893qofCa/xvVCna/6J+rl077TqDua+vKpPtf2pNd/v2ptbht7p16u6p/Vy1fV/v3T2/Qc 05aGF63KfS7Pqop/b7U2eZZ3cXvzW6ng7VOMrV4XjmHyto+Tt+2HrnnfruHy9fHL7CUac8pR w/cyJTyLS1/ddSnEPn299b3e4oJMYdzQPzx8+he/eFOujqVUWl2t9qNgm4QrT8Jtpst7rXoW HCfpNkcmF4yRPjnkYYWagxRVc8x312+xlzrN3ZPTfGYWU5WZg1TVZXdBPfADV3A1kB2uHtSX z2UaVdOkGhimY8qPqoajbeyvpSrVQB8qrde/FfievdT0cXFiVdG1EG57DqqnqlO9oWx4ls8v vJ5/lep/6LNi818eK+o3MYuLbQqCG7w858G0UfY95FffgnL0z6yZ8v89ayov/Jrq1Viv6zuZ Zsw5T0zrv/XeZoDetgw253Y1pX4hT/bqY1suZGZS71gNIByWZ1VqvjMXPvX3v1Pz6FXXnsLe e1CiL+q3+wwNPLqlreqzzts+OPSU9QvtoWquk6DnWYagmlqO3/bo3TAFTLNQ60nRE/618B5/ n9frc7ZVU6xZrK/XbQ6iP6ekIqVXwz5zyZUASI1TGbx2pNV/lEBdzp4XsePPssqrUS6zhnK3 q1AMe321KtOHlaHS51fmp9cixi/6XLI/+0Jziby6z4c57S7KVN2Uvk+OfYz3X74R1/0T5o1j BjJDJDP6mwbhVmPcdbdwENY9c9BY9zloVK0es8jk5Ydnqr/PXo7T2Ed4OdcqMZoqY4ZSemo4 f+txavitrLjvcBk94DevxB+ySZNVXiKvX0lFqrgKMya/ho2X+ff/fKyybVponpmkgV3+WWRM 7TKmfvpEb1z+FeXJXz7x8H2WQaXGFw2lOMXtsn5um6fBldJQ+m5tPyr6wYqyqBCPnVLb6P7g JV01rwIb6Yk5F/aJIbjnwlsvteq9tlNVf39nbZgMh+Xp396uRR1MPYvjPpq/kspF9Ag+5HKY oncHPYrfwBnqiuN/nDhedUDV+vJoV0vf6ZZTaFV8nAbZqwmLY5DMORoVGqrIYVxbf2MtT2Zg YW31JVJWTQ4T/jGw/L49b4mGymfi3mbqRNX0Sk7hW3Pp/tW0+ba3XrDfUq9PLP09vnNY0BS1 44jPrYGgKrBe6lfW4jpNNnbW4nhU1vZXExVqD6B2Bl9Z7mOmZZQln5kT52u/6zDJXWMl00CR yETyOLMTwy8iQUDc4zHqxlTJ9BrVgv1Bnv3yu8Hspipv51d/I3mZyfeObv0EkzW8V+mlPmKm neJdlQF+2Sd+bxk77wvhxb23HFSVenke+rAJYIoiX8uWH43Ku1KFtM9de4TwzJGAMu4nuOhu QeLRcS9kzdfqNfwAXn6w88E2uPc/bt6fnXxrS8jbw2V83IeXpGajz60oSTUgEY+54+9lYqTI rLRgwY7vzeSAucH4iDlOyquWMFrcdz/sf2hbBtPds1QrU6+Cel9xjI8xkpJDkCnWACdVnvmP xyjKpWxJ70DUHkLV9X6a8sDN/14mGjXL9yD/xM86UuRy//3pbX3e3BajPZO8vPp+WND7sekt WGan9Jbp5sfvasc44pPvrVnmlROa104pzCOnYQRQAjMWI4Fpr5Z2ODHOPuMxhvoh4PWpvvYh 2gIu9c7NWdY8M7ubz9U7t1b+VwPLwxLq3vbCqH8vBzaq1BzmweGNfQiDYd71TzOfcBvngQ3q UKmbu+/bx81tnNSMmLn48OThvJ0/HP0DN2f8W08HvXb68TbMk4wKnDVPjnP8fdhH5DZVxZop PZyLt5f8Pyp4kP21TF/m+iyj3o7sP3SbAQ+Yc9Efu804p5g2DDhmMa1Xv6k5fcoKZk4k5muc 8nfw99eOZSTm+LC5/4BmenCOK48lXU0Zynr7xGKKb17Mdf5GarXH/ofO6tPO5/qn46PYEPZn K49zHMFuP3Lq5m/UiYWaFO4mSpg/ptzNWdcrq8rd+vXqpKRWoCiTwo84KR0NvJ7c+LEmJVmg zWB/ykyPezPTrWxfVVTykH/PhVQesk8ubmthqrEjkrf0at5DlYL95Pma1NpiRy/2PPiVUZX1 Tc6HHdqM20pVxjynmHdE45PqbPy1wOKVIw81hsRg+bMqY2f/1JQ4xy1HsS/pgNoe4q8HMLRt llEi26V0RCgBMjDWbiWp7er8/dh4OGMe09hZ3Gnegp3V9zcL4zErqBMjNcWpXmF+5Jz35lQK zJH3HwXcp1llDKs5RzYop0U1b1mP9h9wMR3nqVdy3fcnRFZI+dHpIPoArnCO+I+aRf+4BPWP G1geP8IriZ+7wFJtbCAV9ydtbNSj8OXHF69NEGo3cxdRjimpvp5tL+x1zNNjc6bVqZdzfLz4 tQd+A1dq2vUO4t/xu1s7rjDPd81wyZ6h5jATZjt7kzC6Ly1LPcyEnabEmP+1x4QlbHbANCW4 dB69yO5zj3q+vMu+wySp2pI3p96BSmOrCuyUuY5w1cQ1h0gS2Rz12pHNq4uC8l/1Qyn6yucs 5pQko8PcwpnH2+bEbEaI1sypRrz+3uHacpbnwHO1PV/h56dqA+ZKsc4lITKSjkrv7oK5+lLm 3zx3M5e6s8+JwsfaioQP/LH0Qd5Xxnr62uIiM960V3ot17dz3uzcmM7Bm/Xlj/5gqLmI9ZX5 MSdL9KpWv1c/EaStQ/tZaIxMHyDCj40fIJ6mqK8aza98kt9pSdg25/UB3zlxfSsbZTUd9Qza Vq1INA0zl8rHTx/qqA/CDjifqh0Tzz+riUfNEHbC/lFt5rNs5stzijsneL5uDz3XNpLasPbP eyzp6lDx9RwnZ8XnxkQqk53/sSofb8pNX0R9WHx7M/POx45W3v+PSf18yOney2l/TEZDViKN wfdriThz8p2+f1Y5RfO0G2Lpv1HOZy9P5lws7/HlyQy+kno9E3hN7208GRlF9R7+5eWDPPUt 9YsZ/xdiPZ535hEku/IP/zL6gB+YPjzmGNUp+/Dh1fmavzxoLzDil8m/kYmJYtWgPVAFkCqO kkdfu9qBS8x0B8zcTU8hHT76ER/WmXvsebawTwmtGB5jwmm+GDNR/x7zxcu7PnOGezXhRRl8 +QDxtU8Nv522aWME9xH368xfUbmBCoDnoHacq+2t7LX+6b3/8eztV0nmdDd+h21+APbaPCER yJx4PyaCKaHx8q2wKbY8HlV7ajthKVPG/FHj0YH7VeB6m9doSc8pGdPzS6+Vw6VQ5mzcnfcd 88/kfbDPm1bro6b/kzdXYdzbH2n9AMvTsXdUfza34h9xHqFc/X9Zc575OdgHTSk6Vr//uH/6 KPZPOHEbw4Vf8x5Pvtn8wF/UWjvhK9NXfs8PnFyOR184trCO+DAfWIapQbVpTTLqySmTCid9 MlvdfeELn1Jh8/j3/mvWrGab6cM2O5l2hDVDnZT/UfdLrxmkdbUHsjVvQRVSb1GdeL/v32ru aipSdv7EnGJfWsRkP1fa9gTCJjVXXIvpsZ1TOzsVVn1u7vfePcGjxwSDhymwbzPPGMzb7uYg +/00U7oXbsDf3G+AfJkUn+7wqo/A8via1d/tOde8umm7uHW387d6RBgznfk9oXnuaeouTJ/O XaHQlV1ISsrhtSOIj7yRotzebzS1bq68dEj4wXdM8bRtDML+uK/s7lI7xwWe++XiT/s477Ud FkRLdzsszHFbn8P/ROYS1YA5v/6Wd7IRj6+PB1Wn7M837P5Z11APiY+EN/JVFkomGDVr9dHh zBTKLluZkuxtmwq27K0Snib8iF9kmF+Wv5wvn4L541FzMlSWzrHoEMG8cj3S3KhOh2JqLwM3 T8+f2asl9SMjkxdue10jMqtbqHPgoroPKRf7wv88pj/8ADNl44PBWBxdxXjbO2sfEU0bpmNc 26NZZTnUaFRjfAqhICVpD0L7yqX9sVBfadLwXaSMQvNCqCz4H7ZheDkjqtx1Oo047JvWp1dO UHRcOAeY56oj/5qkU+x18qhSTsvNQ3tZrqc17Tphv0Z4kLz/y4vbB11tsPbEcajrYxVa6DP4 m93SqyfH/25Z6jG/eLlq2GoS/zxe9fyVYPu//+n6P4ej9kO349uafjKzl2bloehyPqMUXsaC /X5A9S9dPDDuYbqX5gD1rPiVfZHTbsxcnW6Fqz7yK0P168iwVb+uOPmPdKlUGwvfvCmfVZm3 Kdf6clT4OW7w8Flz4fwoeZkrDM/PO4fhH3nSKsfVmC54QcbBKK5+NPOE3Z5X7rzf+fgfw/tf TBDJbci7j/ZO2RGZR+bt23hLSw0Y+4BXdQA/Hb25YNp1fNpfypzg/sBMLcT7fVpKpYzOo9MI +eb0BbfXJ7wLaHVyYB9OV8ZzkiO54vak3EAFPl9Zcc18Ne/lGEJFTpNHppiMpKn5yY4dr8Ds IWv6D/CyzIkMnHu+r/Sh3zjLaewpG/MZdu5c/Kwc3fSlDHyZbM7tn/Pl9LQNV7TOKv+3BANf TD+TnbX8kA+jf3UX3L98/vLK3DjvY2BHoDxF7Y7Mz6Tto5wPWx3HFMqH7VNeWBwhdfra6bF9 LetjtlKzaMLRgqLv+5JX1Ieqr2V0P8aY32NYw5/2tBkqDNcgRlHA1FZhjzPe/O2ZOmWGKY92 gZ62fn/587A/7s9HkfPDkb1N3/GQN01X5f9PK7s9x5pz29e2dpvntgC9/X1vv0Zt3WtWV1dy ePPTYyppjnskMtxz9jn6Q9YlP9eU3blUtMUsbzW/+Wt+8rPzdmzYzuzRcVulhPDmXwT+7VN6 zudHzt9InZ8/+di2B/7YnIS6na4tHwi5RO/lEy78hdT43bGNKNWHUNvPQE2+8MDvLlziMb3m 54Zao1+eJvt0Di/u1HdPLUSPvsb+5F7LsWaSyT87+pLqflzXPjqc+qUfFymR9Gvpgqr2m8vW uPUXEM5Akrqtynz/tD2HmtyR/OZWxcDfcKe+v7pf3THB5FzOcbX75/AYwrPjr6uO3zjHcBwW XL9x2raP+In/+Xz3+5kLOy3Ifnod509zvq3or+OB68es53dQ+Gv+jGt8L/V8Zr2A/gPlWlXj 7Wc9PnbJ+3F3vU1a56gp+/H1htHM0TMZPp/yq/8nfgHK1r873CumcB4wHS8875leczqng3Cs Y+0F/aE92SaJvqE6vsirx5dGLZxK/rnEofG253tOoU03f9VmgOe8hTPwaitYc+NwXHA3fm8Z I4/4rvO2Xxa1Kax2i+revPoyKbdZ6ZdPraVj21yPl/O3nz78t4ftmG9OgeWt2eUfv37w2TW7 dibvFSltVB9ESs2ESr17aJNifc5Huf186qi7TTxnTbUFEGfd/Eym1qDU+4cvH47B+4c/i76+ e/jkwT8e//vuq4et7u13LcefXZu0H9vYPAbX47HuHNPCd188fPkXH6CLXR9bGNy6k7Q09h6O n788Jte6WfwhjX3cyIltOd/3/fzV91jbDuif27+2NsOd01UbnXvaLplDf4yQrU3Bx99zOmZb Ku3b+lV9GyjtX+eDu8tvHEPlyXsDgSRlf8qNfnY8G87LTG/9sWL5Y9ELzy3sOz/GoJq+Oxbd c8D/p3PT0dz0OLJ82+baUk45buqSmPazo8NbbVHj26O025I/l65jTTsi/bnuZ+rvOeYPmfLY gpq0Xz+Tz4fPtl+xxuakx2/fFsv47IW8V8TXPhq41Eyo1LtWrl7jsabjLRx1p+Cup0K6RpE8 47i1sdThA0Ovf/53fxa9HrzBl9I7c/05n76zPfpQG94Hb/gguXjTLXwNx5hsrRzXHSe3OMdO LekQYz6coS0UbeyQA+ixc/611u3VwRPraVWqrr+qQ62o2UXkvSI5X69KSs2ESr07pqDrjaW2 eoRzUmpx5lVTCdeEI89sXNNYyh48//F7fQyeP3k05BY9HLXmvU1HfTT8jH/vT3hqlDHwM2aP Ml1+wwPjB/7X120FbyO4DecWlRP8YhpB+VBmpOEn01lb32l2+t8tQiqp+qIe/GvuhS7M/fnP R0TSgqIWASVuced/FcXO6XtrZa7JOcWk/hXlz0dw0DqU2ib5J7fTe+vxt1z/N1LBN8ZL+LXM 5N+zHb/hdUDXI2uLzPhs79881RDYB30M16jzNHqja4tMPUkfPUJ4rHKp3KcwrOcYc9G5/VzS /TUyj7rz5Qe+BRDnU/JM4tbGUmfQ8mfQy8PHPtKjjv8AxtGbtpk4Y2oMO451+FgletxxuJT8 eQg7aMV+HGdn5ZnHv/6KPeFnKlA5R0aL9W49Mx83uEI+kk3Xnr2PVAkMfmJ45k+7CSmY41ON +NfHeQvC9/3MUgxekuO+q+AFBrpvEbosOLFt2Y6VN+ztx7t+6j2ePyOR90K2PdNP3UvNhEu9 O8r5Y2iFPaQ+RNsO8hiQ7alwDT9+5ohmy0B6qWOw/zn08uMHe3OqM1CPLj5v82CXofmPT2/3 tv0ue8DR3CKcOKwzNOr1OkMl+tjaQxxHM9X9K2vsfafm7cstzv8OhAzsNqBKBQZrylSE5//g oh/n/2Pd+Eo6Inb8E//5//4/4kzPx6CAapphLlEsF/akfp3ZlVLM55BoW/XtGkhM0t7nyNb9 M1ZppM+2jZybPJP04dfIsaWzSG9LlTKId1zqav2WsBU79Xm06xjqYtm1fdW25gJ1H/EcWd8t M0i9HEtsnQltlaWUQTKX6q3fEbYigfVcs7Y1bldiQEjwWHeQN9t7ZJAep4plM7na0qVmkhyX 6q3fEbZiR+upZm2ri9dEyyRuBeq2iLzrq4/6GSIyPi9b48Yjjay/Wte2ugT1JFe4nm6rELZi JpEmfrGMIighOYK/xhbqj15lkQh2xJzAX2NFL7dIAA+6JWyFB3+NEtEJixn8tYVrWDdt3qVH BtnQMr+Dv/a2dCmDVPCgW8JWFLSeata2Ogf+GrYIdYctgFdZJIJlYUvgr70tbZlBAvrLHWEr PFrv3OSvoWTw15A2qNsiFfxMP9NJduCvIXsY5711Xaqg34eygb8qwlbMJE/+GqK7kqhCfAZ/ PS4/jV5lkYx2+AKjurelS0X0+xBxtlCE+zwTR0ldZn4vMBP5DVdqX3fwIYOoUpcdfvMwhntb utSOXn4eeY+tC+E+z6RM844vHuYdn3Bd9imBx1gkox2pgC/2tnSpgj7tC84EinCfZ+KnWeZI MI6e5z2uwgZxO3iMfmYm3TKPK0xvXZcK6OWKcJ9nUic/c3sAP3MV11xNrvYtUqHXruLq0dvS pXb0V7ejlyvCfZ5JmPzMZYzQXcIIXZPevkEwHncJ14reli6V0V9dQS9XhHo4kzzH4y5gPO4c xuOa9PYNgtG3cxuMxt6WLhXQX11AL1eE+zyTKfpuG2WIvts2HVZPk/jRP4ZnZnJa1gisDNS6 LrU7bGuHWNsi2xRrxz2n0c/iHmGtHEhv3yA79jrBOkBt6VK5YD25jr5wT9gKiLWlLW1rgFg7 7i5i3Q7GlUkSWuZgZaC2dKngsZ4AkfU9YSs8Wh+mWLttdCDWbpshWE8H0g97DQKRddwqrAzU li61Faxng8j6nrAVEGtLW9rWDLF23GLEuiPs6kyS0LJYxvhTDsilVEa/V4R7OJMpjo6bL+CL m3Pgi3WHGNkgm4MY2SK+YCmPPr35HbzjlrAVEEdLW8rWugXwxVpghW0EVmGTQNRskS1gqQ19 um4JvOOWsBUQWUtb2tZUwRdrdFh3xHFlEYijLZIqWpbQp2vawTtuCVuxofXUlrbVB/DFssMq PJCrRxaByLoRyN1QW9oyjz5dfQLvVIT7PJMweWepG3hnKQG8sxSIo00CcbRFKvq0QTaIGu8J 9Xlz4J1cs7Y1JfDOEnAVLgHXbotArG2RhD5tEYgj7wlbkdH6lCbvLFeuWdmad1yF845rt0Ug +jZIcRB9x+LRy4v36C93hKzAHLq0pWzNV65Z25pxFbYIrub6GSIQocdcIHdDretSFf0+V8jr asJWzCRN/poTZGpiDgn8NQeMxy2S0I6AEXpO6OUWwVjzlrAVAfyVa9a2OsjdHEoZUHfacH23 CEbxx8nQ6K/ZoZdbBGPNW8JWYFzPNStbU4VsTkwZV+qUcX23CMbsBqno5RbBWPOWsBUY13PN 2tYr16xt9bhSWwRXfP1MJwGj+OMcaBznKaLfp4h+f5zfjP6qCFsxkzL5a3J+zGXF4/xm9Ne4 4Q7SIhizty0LjmqHO/Pk0O+PU5+xdUW4zzPhTw3FjoJxfcy4UseM+0WLYBR/nAON3hkx990I enkLpbD1glG8ReYoPkbI+MTocV2OHneHFsGY/Tj1GX0xRvRgi2CseUvYCozruWZla9gxBxQ2 XJctguu7fmYml63HGc84hsOOPh129OnjbGb0RUXIsolwzdrWAiewMSRclzXpPTIIxuwh4QoT CsbsoaBPHyc6oy8qwn2eyXTeGkPAKD54XIWPG+ujx1gEY/ZT8m4kAWP249wF6ok4EyhCPZxJ mGN2v2PM7iuuub7i7tAiGKH7ijkgj/nxRtCnj5MYaH3HCN0ic4TuM0boPuEKaxHcHepnZtIt S7h6eMyYx+MkBtoqGI8bJM/xuA9wcnrcJgI/06S3PxOPsbb3uFb4gLG2D+ivx9nM6Ge3hK3A eJzbUra6HeNxV3GF1eTqkUUw+j5OfcYR63aMvo+TGKhnR7+/JWwFxuPclrY1YzzuIq65mvQe zWTKoZ+3rUYy5dBdRp8+TmtGX1SE+zyTOfp2AaNv5zD61qS3bxCMtY9zoDEidVPG/DibGT1P Ee7hTKbIui16cHIa9gqrZ9gLrLAWqRA1W2SrWGoDDw77Dpnee8JWQGQtbWlbM5ylhj0WrDvC KDIJxNFhj7BWUFu6VE5YT4ZM7z1hKxJan6fT1bB7OF0Nu/NYt4NxZZKAljlYK6gtXcrvWE+A TO89YSt2tN5P561h2yD6DluBNXcgV48sArF2OM6BtpFgxryRhPVsEGtrwn2eyRRrt/B3B+/c IpyyNAJxtEkgjrZIQp82SIZM7z2hPmeItaVmbauHE9hQd1hzG4GV2iQQWRtk8xBZh82jl28e Mr33hK0oaL2fTmBD3eAENtQCa24jsFKbBGJti2wOS23o5XWDTO89YSsgHpe2tK0JTmBDDRvW bZCKfQyw82sE4vFQI2RzqHVdKqHfH+c3o78qwlbMZDqBDdVD7iaUHc5dGoHo2yRwAhvKDvE4 taXtMEhCD7ojbAWc0krNytZSIZsTSsGVumRc3w1SIEK3SEUvtwhElveErYAoXmrWtiY4pQ0l 4EpdAq7vFoEI3SIJvdwiEGveE7YiovVpOqUNxcEpbcg7rtQG2XDF188QgZg95D3gOHfo98Wh 3xcHmV5N2IqZTKe0IVc4pQ3HGc/orznDftEkELOHnCHjQ23pUhX9/ji/gdYrnMmaZDqlDTlC fifkgCt1DrA7NAlG8TlAxofa0qVmgt/23RPqc8JIn2vWtjrI+IS04UqdNlzfLYJxfdowrs8O fdoiGH3eErYCI32uWdmaCuSAQsq4UlsEV3z9zEy69RlXoVTQy49b4VBPhayQJtTnmZQpKxRS hFPacJzojP6RPO4pLYJRfAqQJ6K2dKmIXn6c1kDrETI+JpnOZEPcMa6PG67LccMdpEUwio8b ZIWoLW2HQy8/Tn3G1hUhOybCNWvLCkbxMeEqHBPuFy2CMXvMkAOitnSpgj4dC84EinCfZzLH 7DFizB49rrkWwf2ifmYm3TKP60nEjHk4dH6grYgRukXmCD3scLoaQsUVVpOrfYNsGH2HDVeP sGP0HXb017Cjl98StgIjdG5L21owQg8J11xNeo8MgvH4cY9nHLGhYDweCnpwKOj3inCfZzLH 4yFgPB48xuOa9PYNgtF38LgyBMyYhxDQg9vrB89ThPs8kzn69jtG375i9K3J1b5FMNY+Tn3G iNRjfjwcJzGjnynCPZzJHFn7DCenwSdcKzXp7RsEo2afcB3wGaPm49wF6imY6b0lbAVG1tyW tjXAyWkbaLh6atJ7ZBCMo73DlcEHjKN9QH/1ATO9t4StwFib21K2ug1jbVdxPdXk6pFFMLJ2 FVcGN2XMHd5ZbwQj61tCfZ6y6tyWtjVjrO0irrCa9B4ZBCNrFzGb46aMucM764cwOXinItzn mcyRtQvw9XxwDk5ZGsGo2SIYNRsE76MHF9DLXcBM7y1hKzCy5rbEVr9vcN7q9wIrbCOwLluk QhxtEbyP3gh4ud83yPTeE7YCYm1pS9ua4bzV7zFh3TFgjwwCkbVFssNSeEO9Ecj03hO2IqD1 eTpv9buH81a/7bAKD+Tq0Ux2B7G23x3kbqgtXQpvqPsd77Vrwn2eyXTe6rcNMjV+K3DK4rcC kbVJILK2CN4+NwlEjfeErYAzWalZ25rgTNZv0WHdAVZzi0SIvi2S0KcNkiGOvCdsxYbWU81f Mls6LVD30mlBsnRatK1LpwXJ0ml5gbAVS6dltHXptIz+unRaRjuWTgvUs3RagCydFqh76bSM diydlrHU0mkZLVs6LaMvLp0WrHvptIxk6bSMb3HptLxE2Iql0zJ659JpGb1q6bSMvrh0WkZ/ XTotowctnZZxxC6dFvTXpdMy+uvSaRntWDotSJZOy2Dr0mlBy5ZOy9CjpdMCluF36Eun5WXC ViydFrB16bSM7S+dlrHU0mkZ3/TSaRltXTot4J1Lp2X0qqXTMnrn0mkZ/XXptIAHLZ2WwbKl 04L+unRaRn9dOi1gx9JpGUotnRaoZ+m0AFk6LaMvLp2W9CLpli2dlrH1pdMCZOm0jHUvnZZx NC6dFqhn6bS8RKjPS6cFvHPptAw9Wjoto3cunRa0bOm0vETYiqXTctr6yUPbGoTzBiMrtTBh hZVGzpKi3RKOeza71m4Jxz2buo/k7PdQ6iKsp8KlWHOFa74lvT+qntEKi7xTlpFSixD6glxs pdVKbKVVT2xVpNuqSnVCsYOUoq/MpeY7Qv2RekYrLKJtJaUWIbRaSd20Wkn7BnFoh3qm2zoT iiakFH0vLjXfEeqh1DPaZRFtPWm3MGHNFa5bkd4+K7VwrzW5LNOluq30dbjYIYTsUIR6mNjW oc+DHazLIiTLr9/tEEJ20GoldijS7VClOqkexjkrrEjNd4T6I/WMVlhE20q6LEL8hnULofZp 1ZNeK9ItU6U6iQVGNSusSM13hPoj9YxWWETbSrosTFhhhVuzSIBe62cuy2bC6iliqwvgebeE bJV6RissomxlXRYh2YF/KEK20voltirSbc245rB6itRT0O81oR4W8EWluSKMNFeE+Ay+qAi1 T+e7Yocivdce1xPWSpF6Ivq9JtTDgJaJwgozVlgRsuEKq0hvnxVW2A5Nrl7rUp3s6K+KUFs7 zuiswoJ9Hu0gPRUhCddTi+C6rJ/pvZ5JQV9UhOxQhHoY0DJRTxFG6ilCfIAxyzoo0r4ivY8z CehDmvR6InqeeoZ7OJM6+QdrpQipFcYsK6Nwa5pcvTbIjl6lCNW847zL6inYw7HXGeNfVjSR uhPGv5r0Ps6koA8pQjUXnEFZGQV7OPY6YCTLaiVSt8NIVpPex5kE9BhFqGZFqD8YpSr9EmKi XyKkpnGkixIJtT+Qs48W2d040gfS69nDOPb0M9SfmWxTdClqJULiPo5H0SaR1iJEjhbJZVwt RGVE6rkj1HqGeNMkCb1BtEmEuDSOWVEikfYdxJIWCRBdiqaI1HNHqPUA0aVJpuhSlEiElH0c 16I7wu1rctlhkA1iSVEQkXruCLW+QSxpkimWFN0RIRH2H6IpIu3HOEaFA+mWqVKd5AB+pkmv OScY+eoZ7vNMpshRlEiEOA8jnbVJuDVWIuE+atLtcBA5il6IWOZ3GOe3hPrjIbo0SZk8j5VI hJQCY5+1ScTWAtHlQC7LdKlOtgi+yJoiUvMdof5sEIGaJEy+yEokQqIHb2DdEWk/QnRpkbSB L7KCiNRzR6j1BDGpSerki6w7woT1Qrhu1hTh9ll3hHutyWWZLtVt9QnHuUcvr76gd8gzZKuH TITol6Bdg62sRCKkwB5FtEnE1oIrtSbd1gLZCtELkVIbxGT3hPqzQSZCdEdmom0lJRIhAfYx ok0i7QdczTXplgXIVoheiJRKEMndE+pPgohYdEdmom0lJRImrCDCdecdV2qL4Iqvn7lsnUnx kG8UlRGx9Y6Q9R4ia4uINonYStokQvIGHqMI2Sp5ZLJVkW5rxlWIFUSkVMW5IVeMI9Uz1J8K +QtRNEG7RlsTZDREZUTqDriaszaJ9DpgPK5LdZIgJykqI1LzHaH+JMhxiBLJTLStDrIeojLC dSvS208bRgUJ879DqW6rqzjyHUaWt4RsdZAHESWSmShbWZtESIY9nKiViK0GwThBP9Otn0mF LGVk3RGp+Y5QDytkT2LCzHJUaiXCSK1ESIBzBU2ofQ8nFgPplgVcqVhTROqJOFtoQj2s4J1K iUQYKZEwYU0RrluR3j4rkbAdmly91qW6HQ69XBGyw+HqkRxG8Up3RHpdMIqPGddlRciOjCt+ xGzvUKqTgh6sCLVVIMMi2iTY59GOCDkX0QuR1gyCq7l+pvd6JhGylKIXIjXfEbI1Ql5GNEVm omxllREhG5wHiF4It6/JZcdMWPlDeu3QOzWh/sA5oNYLEVbg1E+UP6TXCVdYTXqvZ1LQzxSh mgvOzawggj0cex0wjmZVD6nb48oYPK6nmvRee8zCsIaH1BPRFzXp/YkYNSvlD2as/CGk4hpn EVwr9TNXrw2yo58p0u3QhHqIEbHS+RCWMf71CfdMrNgh7SfMnhikwEncQHo9BfMp6hnqz0zy HMmyqocQD+duouEhrTmMUg0SMG5lNQ6p545Q6wHjVotMJ3Gi4SGkwnmAKHZw+5pcdhhkR69i 7Q2p545Q6ztGqRaZo1RW7BCS4MxA9Dmk/YgRqEEyep4iVHPGHIfLGIEqNQ5hAeNNVtGQuh2u Vs7hGqdJ77XDPAjrakipgL7oAuZB1DPc55lMsaTocwipcDYnih3UmuhzUB8Hcn1fqkt1skHe UpQ2pOY7Qv3ZIN40yXR+J/ocQiKcK4gah7QfIZa0SIYspehqSD13hFrPEIGaZDrjEzUOIQ7O FUR7Q9p3EF1axMOpuKhoSD13hFr3EJOaZDoHFO0NIQX2H6Krwe1vBU4sBnJZpkt1skGWciC9 5g2iK/0M9WeD3IRoeKBdo62kxiEkwh5F9Dmk/eix19GjZRHyF6KZIaUyZDLvCfUnQyQr2hsz 0bZ6OGEUFQ2uu+6wwooaB/e6YtZ4KNVt9ZClDKyrIZbdEbLVQ/xrkunMUdQ4hBQ4aRB9DrHV ILB2D89062eyQZZSlDak5jtCPdwgajbJdC4p+hxCApxGaELtBzjnGEi3LOCawyoaUirh3FAT RIT6GepPgvyFqHqgXaOtHjIaorTBdSvS2y87rPgDuSzTpbqtPqAv+IT+ckfIVg85DlHjmImy lfU5hBTYaYlih9iaMQYomDUeSnVSIUspShtS8x2h/lTIg4gax0y0rQnOLkVXQ+oOuL5bBOME /Uy3dSYJspSivSE13xHqYYLMiOhzzERb7+A0U5Q2uG5Fevusz8G91uSyTJfqtjqcCRQhOxyu MMVBXK/VOKTXFc4uRVdD7Mi4vueMUYEm3Y6MqxCraEg9FWcCTaiHELNr7Q1hEfIpoqIhdQdc u3PAFT9jtnco1UmCLKWoaEjNd4T6kyDDIkobM9G2Osi5iIoGt2YRXPH1M5dlM2GFDLEVvzC7 J2SrgyyMKG3MRNnK2htCMpwZiIqG2JrhhNEiFb1TEaq54qzP2hvYw7HXEc4TRQ9D6va45rKK hvxCHuNxXaqTiN6pCLUVcUZPEePxFKezQtHMELLhWqlIbz9uuAprcvVal+p2OPRORcgOh3Nz wqyxVsgQVjCyZq0L6bVBcIXVz3Q7ZlLQ8xShd1YgwyIqGtjn0Y6IUfNx0jCOWVa2kPY9ZFgs EuH8biC9ngg5F/0M93Amc/zL6hdCNjgPEK0Lbk2Tq9cG2dGHwo5+dkuo9R2jXYtM53eidSEk wZmBKFtI+wkjWYMU9DNFqOaCc2ooGMkqHQthAeNWVqSQuj3GrZr0Ps4koFcpQjUHzHqEgDGp 0qhgxhoVQiruWlh/gtv3FVc0Ta5e61Kd7JC3HEivecfMiHqG+zyTObpk1QohCU7iRKNCWksY ORokY5bSF8xk3hJqPWO8aZHptE40KoQ4OCEQRQpp32EsaZAAZ+CiLSH13BFqPWAEapHpRE8U KYRUOCEQ/QluX5PLDoPgvVtRkpB67gi1vmO8aZBtjjdZf0JIxP2Hi3DSIPoT0uuI0aUu1UnG LKXDu7nBZcxfqGeoPxlzEy5jBKoUKYQF+K5alCSkbofroHO4emrSLXOYv2DdCCkVMJN5S6g/ AaNUi0xfWosihZAK5wqiUUHtiyIF9Xogp2VDqU7wlq1oS0jNd4T6s0Eka5Lp9FAUKYREOGkQ jQpp3yAB7YgQyVoE7+aK2oTUfEeohxniX5NMJ4yiUSHEwWmEJr39bYdzjoF0yxzkL0RbQmzF +7t+9xDb6WeoPx7yF6J1gXYNtrJqhZAC+yHRsRBbC6zvA7ks06U62SBLKfoTUvMdof5skOMQ jYqZaFsTnFSK2oTUHR22H3bsNWaNh1Kd4N1c0Z+Qmu8I9SdBjkM0KmbyJbOlWTGuuEuzYiJL s0JbtjQrXiTUn6VZYZOlWUFkaVaMvV6aFYMdS7NiaVYMZGlWwNhfmhVAlmbF2PrSrIDvqpdm xegNS7Ni9LylWTGO/KVZMXre0qxA71yaFaM3LM0KJEuzYrB1aVYMvrA0K14kZOvSrBisX5oV S7NisGNpVrxEyNalWQGjeGlWQD1LswJWz6VZMY79pVkxeszSrECPWZoV47ekS7MCyNKseIlQ 6x7vaizNCvTFpVkxesPSrECyNCsGy5ZmxWjr0qx4iVB/lmbFaOvSrADvXJoVo+ctzYrRq5Zm BXrV0qwYvWppVoyevzQrlmbF0P7SrBj7uDQrwD+WZsXoDUuzYvSqpVkxxptLswLJ0qzYRluX ZsVY99KsGG1dmhUj+f9Ds+LdwycP+x6f81aUagUTVq04rnnFrSr9CUV6D/bt6FKyCZVqE07d sq6ZCGtLcClWpBBCXxtz6wbhUmCXRd4pW0nHQgitg2IrrXqKZOijRQrYKjUzoVhGStG3xYpk 7I9BqBTYZRFtPSlbCKF1UOqmVc8ibfBtWtlCes3PGISs57aYUOQipSgmEkJfJEt/ZsKlwFKL 6PdBWhdMWKOC67ZIITt6Hy3C47zbOhPWsRBb6YtkseyOsBVUD9g12Mp6GEJyBC+3SAB/tUgE vzdIxdmCtS4UwXnIIh7GudQ8EW09KWQI8RvWbZCKfTTIBn5vkIizBatfKILzkEUKjGqpeSLa etLMYMJaF1z3Lel+H7YAvZZnyNaZsLKF2OpwtmDNDLHVIB68XGqeiLKeVTSEZAdeZRBaYcXW mXAptn4mBecGVtGQtu4IW1HAy5XShjBS2hDiM/i0RRJ4p0Uy+LRBIs4NrLQhbd0RtiKg9aLG wYzVOIRsGCcYpGK8YRAuRZYZZMeZgNU4pK07wlZUsF4pdggjxQ4hCaOCW9I9mDU8pNf8DFs2 k4J+z4od0tYdYSsCWi+qHsJI1UOID+AfrNghPbojZAfXwySgT98RfosRZwv1DFsxkzr5Kyt/ CKkV/INVPbhHt6RbJvUw2dGnWflD2roj3OcE3qnUQYRl3GewOojUnTAGuCVkR8JdBSt/SKmC fn9LuM+4q1AKIsIC7iFYQUTqdri+3xKyw+GOgdVBpFRAL78l3GfcMSiVEWKiMiKkpnGki4II 9eieXHaoepjsDkvdkO55okQi/ZFnqM8z2abYX5RIhMR9HPuiMiI9uiNkGdfDJBcsZZCKrRsE Yn+TJPRF0SYR4tLoDaI7Ij26I2QZ18MkeCxlkICtGwQifZNMkb6olQgp++gfokTCPbol3TKp h8lWsJRBKrZuEIjrTTLF9aJfIiTCflGUSBSJY/RtkgQeLDUzyej3d4Q8mDVOpD/yDNs1kymu F40TIQ7yVqJWwoQVTbiPM5FSbKuDVUi0SaSUQXBGsQhE+iYpk0+z6omQAnkr0S9RBGIAk0Bc r2pmsuHcYBGcYywCsb9JwuTlrIMiJELeSjROpEd3hCyLkLcS/RIpZRCcYywCsb9J6uTlrIzC hJVRuG7WOFEkg09bpICXS81svce5gVVPDEJezuopYr3HeUgRthR2DFo9Rawn9RQhBfaUooOi CEYXFoH9gaqZScXZgpVRFMF5yCKQt1I1T0RbT3oqQgLsMkUZRRGMNyxS0daAayCrnkipBLkt 0VOR1g0CuwpV80S09aSwwoQVVrhuVkaxSB+feceYRJ4xSLde2uL34XFGsQjOTBaBvYhFRHNF rCfNFSF5Az+zSAWftsgGc4NBKs4orKdiEH73FWcv9cxM2FLY02hdFmEJ8l+ipyJ1GwTjFovg DsYgCWcU1lxRBOcqi0D+S9U8EW29g4yYKKxw3RbBuMUiuKeZCeupiK2uopc5nKssAhkxVfNE lPWs3SIkw85YNFcs0sdnyhjJyDMGofeRIWsmCitSquIcw9ot0h+DQNZM1TwR/T5IzUVIgJMz i3g4gbNIgMyaRSLOKKzmIm3dEbaigt8rxRdhpPjChJVauG6LYCRjEdz3zITVXMRWh3PMLWEr cN+jVGHEsoL7HlZzEcsMglGKRXCXY5CCcwOrwkhbd4StwF2OUo4RFiHXJoovUvcd6T4dPUYp 8gxbNpOIMwGrwiiCc4xFIPumap6Isp61ZIRscComOjHco1vSLZN6mOzo5awlI3bcEe4znMVr vRlhBU7eRW9GLEsYS9wSsiPhDoa1ZKRUwZnglnCfcb+iNGmEBdydsJaM1G0QjBMsgnsRg0T0 adakkbbuCPU54u5E6dYwY90aIRVX81vSvdNXjBPkGbLMIDv6NOvWSFt3hK3AvYjSthGWcefB 2jZSd8K98i0hOxLm2lilRkrdEH6LBecG9Qz1eSZ53lWw/o0Qj3k01raRHt0RssxjZo11a6SU QXBusAjuGCwynZiLIo6QilkzV3HXe0u6ZVIPkx192iI4N1gE9wcWmfcHrJEjJMGpmOjfSI/u CFmWMI/G+jdSKuNMcEu4z7gbUDo6wgLG/qyjI3U7XJedw9XcIhjXS81MAnr5HSF/Za0d6U/A /JdFpkhftHaEVMh/iWqOkAIrvkUqxPWqZiYb+L1Fdof9mckGsb9JpjN0Ud8REiH/Jco60qM7 QpZFyIiJao6UMkjG1g0Csb9JplN10eMR4iDbJVo70qM7QpY5yHaJjo6Umklw2PpMPMT+JpnO 2UWhR0iB/aJo7SgCJ3AmgXN2VTOTLWGpDbJdinSfFhUf6c+WsYcbZLJUW2D7+D5IxUdIhD2l 6PEo4rHXBglofYTVTLR2pFSGbJeo+EjrBoEdg6p5Itp6D+f1ouvDdVc8FxEVH+6jRWDHoGpm 6z3OFhbBWccisKswyXSCL0o/QgpkskShxyJ9fNYC8YZ6xiD0Pgpku0ShR0oZBGcmi8DOwyTT Kb9o/wgJcN5mEji3Mwmc8lsk4YzCuj4G4XefcPZSz8yELYX9itYHEuYh/yW6Ply3RSBKMQns TgzCKj5ivQ/oZR7nKotA/kvVPBFlPSsGCSmwxxXtHyEZoxSDFNivqJqZ4JmHqAEpgnOVRSAj pmqeiLY+wZcAoiEkdQeMQBTp47MEjGTkGYOQ9QGyZqL0I6USzjGsIST9MQjkyFTNE9Hvw8G3 AaIGxHVbBM7tTAJ5NIOwYpDY6nAeuiVsBeyEtPKQWFbh2wBRDBLLDIKRjEVgl2ORirMFKw9J W3eErYBdjlYnEhYhsyaqQlK3QTBKsQjuaQwScW5g5SFFcNaxCGTWVM0T0dY7yLWJzhDXfUu6 l6cN4xZ5hmydCasKia0O5wbWKxJbDQK5NlXzRJT1rGAkJMM5magTiWV3hGzNkI8TdSIpVXG2 uCXUwwon+FrlSFiEE3xRJ5K6DYLxhkVwT2OQiH7PKkfS1h1hK3BPo5SQmLESkpANYwCLYCxh EdyvzIRVjsRWh7PFLSHL8MxDqyUJK7hfYZUjseyOdH+NCWMJeYZtnUlBL2e1JGnrjrAVuDtR ikrCIu5OWFFJ6va4n74lZIeH7JtoI0mpG8JvMeJsoZ5hK2Yy7zxYdUnIhpk1VlTiHt2SbpnU w2RHn7YIzg0WwV2FRaZTddFhEpLgnEw0lqRHd4QsS5hrY40lKVVwJrgl3GfcQyitJmEBdwys 1SR1e1zfbwnZ4XF/wDpMUiqg398S7jPuD5SeEzPWcxJScZfJykyK4GpuEYz0pWYmO/r0HSHv ZM0n6c+OGTGLzLE/az4JSZgRYz0n6dEdIcsS5shYq0lKzaTg3GCQjLG/RaYzdFGBEuIw/+Ud 7k1vCVnmMCPG6k1SyiA4N1gEY3+LTKfqogslpGK2y1Xcd96SbpnUwwSVLUyCs4VFMNI3yDZH +qwUJSTiftFFODkTXSjpo0HgDF3VzASVLUQFyiDkwQ5VNPQzM2FLcTeg1KSEBbjlEhyqIoi+ lPTxjpCtDlchhzoWJsEZxSK4G7BI3x98yWyps4y7vKXOMo6rpc4y+v1SZwF/XeosSJY6i7Z1 qbMAWeosY1tLnWWwdamz4Gy11FlG/1jqLGDHUmcZ21rqLNqypc4yfZW91FnGr7KXOksZ+7jU WcZeL3WWwdalzgKlljrLC2Sps2xLnWWpswBZ6izDu1/qLKOtS50FyFJnGclSZxnJUmcZ57il zvIiWeosS51lqbOMbS11lsHWpc6C885SZxn9Y6mzvEjIsqXOMpZa6iwjWeosQJY6y0iWOstI ljoLWL/UWZY6i7ClzrLUWcTWpc6y1FmELXWW0bKlzjL2camzDL1e6iyjBy91FmhrqbMM43Op s+DctNRZRv9Y6iwvErJsqbOMbS11lrE/S50FyFJnGf11qbMkIEudZejjn486y7uHTx781nbF cVf6LExYRaWR+Ox3pbSiSB9Zjbjn+gLhUm0fkseaO2HNFC7FSitC6Mtkbt0gqtRgl0XeKVtJ n0UIjSyxlcaRIhn6aJECtqqaidBcIKXoG2NFMvbHIFJqsMsi2nrSZxFCI0vqpnFkEt+GqNJn kV6rZyZC1ktbRGi+kFI0Xwih75ClPzNRpQZLLaLfB+mzMGEVFa7bIoXbv/poES7VbZ0J66qI rTRfiGW3hKyQega7BltZn0VIjuDlFgngrxaJ4PcGqThbsNKKIjgPWcTDONc1A9HWkz6LEL9h 3Qap2EeDbOD3Bok4W7DSiiI4D1mkwKjWNQPR1pM+CxNWUeG678nl96zPwr1Wz3RbZ8KaKWKr w9mC1VjEVoN48HJdMxBlPeuzCMkOvMogdJomts5ESpH1Myk4N7D2irR1S8iKAl6u9FmEkT6L EJ/Bpy2SwDstksGnDRJxbmDtFWnrlpAVAa0XfRZmrM8iZMM4wSAV4w2DSKlumUF2nAlYe0Xa uiVkRQXrlT6LMNJnEZIwKrgnlwezPov0Wp4hy2ZS0O9Ze0XauiVkRUDrRZ9FGOmzCPEB/IO1 V6RHd4TskHqIBPTpe9LfYsTZQj9DVsykTv7K+ixCagX/YO0V7tEt6Zapeojs6NOsvSJt3RLq cwLvVPoswjLuM1hXRepOGAPcErIj4a6CdVWkVEG/vyfUZ9xVKH0WYQH3EKyrInU7XN9vCdnh cMfAuipSKqCX3xPqM+4YlD4LMdFnEVLTONJFe4V6dE8uO3Q9RHaHpW7J6XmizyL9Uc/0Ps9k m2J/0WcREvdx7Iv2ivTojpBlUg+RXLCUQSq2bhCI/U2S0BdFn0WIS6M3iPaK9OiOkGVSD5Hg sZRBArZuEIj0TTJF+qLPIqTso3+I9gr36JZ0y1Q9RLaCpQxSsXWDQFxvkimuF30WIRH2i6K0 okgco2+TJPBgVTORjH5/Ty4PZn0W6Y96huyayRTXiz6LEAd5K1FaYcJqLNzHmahSZKuDVUhU VKSUQXBGsQhE+iYpk0+zPouQAnkrUVpRBGIAk0Bcr2smsuHcYBGcYywCsb9JwuTlrM8iJELe SrRXpEd3hCyLkLcSFRUpZRCcYywCsb9J6uTlrM/ChFVUuG5WWlEkg09bpICXq5rJeo9zA+uq mOTyctZnEes9zkOakKWwY9D6LGI96bMIKbCnFKUVRTC6sAjsD3TNRCrOFqy0ogjOQxaBvNVQ MxBtPemzCAmwyxSlFUUw3rBIRVsDroGsmSKlEuS2RI1FWjcI7CqGmoFo60mfhQlrpnDdGc8z BnKNz7xjTKKfmUi3XrVF78PjjGIRnJksAnsRi4g+i1hP+ixC8gZ+ZpEKPm2RDeYGg1ScUVhX xST93VecvfQzMyFLYU+j9VmEJch/iYqK1G0QjFssgjsYgyScUVhpRRGcqywC+a+hZiDaegcZ MVFR4botgnGLRXBPM5PscEZhpRVFcK6yCGTEhpqBKOtZn0VIhp2x6KqY5BqfKWMko5+ZCL2P DFkz0UyRUhXnGFZjkf4YBLJmQ81A9PsgfRYhAU7OLOLhBM4iATJrFok4o7D2irR1S8iKCn6v 9FmEkT4LE1ZR4botgpGMRXDfM5PkcLZg7RWx7JaQFbjvUfosYlnBfQ+rqIhlBsEoxSK4yzFI wbmBtVekrVtCVuAuR+mzCIuQaxMVFan7llw+HT1GKeoZsmwmEWcCVlpRBOcYi0D2bagZiLKe 9VmEbHAqJtor3KNb0i1T9RDZ0ctZe0XsuCXUZziL1/oswgqcvIuuiliWMJa4JWRHwh0M66pI qYIzwT2hPuN+RemzCAu4O2EVFanbIBgnWAT3IgaJ6NOsvSJt3ZLe54i7E6XPwoz1WYRUXM3v yeWdvmKcoJ7plhlkR59m7RVp65aQFbgXUfoswjLuPFhXRepOuFe+JWRHwlwbq6hIqVvS32LB uUE/0/s8kzzvKlifRYjHPBprr0iP7ghZ5jGzxioqUsogODdYBHcMFplOzEWfRUjFrBlrr3CP bkm3TNVDZEeftgjODRbB/YFF5v0B67MISXAqJtor0qM7QpYlzKO5jD7N2ivS1i2hPuNuQOmz CAsY+7OKitTtcF12Dldzi2Bcr2omEtDL78nlr6zPIv0JmP+yyBTpiz6LkAr5L1FaEVJgxbdI hbhe10xkA7+3yO6wPzPZIPY3yXSGLvosQiLkv0R7RXp0R8iyCBkxUVGRUgbJ2LpBIPY3yXSq LvosQhxku0R7RXp0R8gyB9kuUVGRUjMJDlufiYfY3yTTObvoswgpsF8UpRVF4ATOJHDOrmsm siUstUG2ayCnT4s+i/Rny9jDDTJZQ1uD7eP7IH0WIRH2lKK0oojHXhskoPURVjPRTJFSGbJd osYirRsEdgxDzUC09R7O60VFheuueC4iaizcR4vAjkHXTNZ7nC0sgrOORWBXYZLpBF/0WYQU yGSJropJrvFZC8QbwzMTofdRINslKipSyiA4M1kEdh4mmU75RZ9FSIDzNpPAuZ1J4JTfIgln FNZVMUl/9wlnL/3MTMhS2K9ofRZhHvJfoqLCdVsEohSTwO7EINXjjMJKK4rgXGURyH8NNQNR 1rM+i5ACe1xRWhGSMUoxSIH9iq6ZCJ55iNKKIjhXWQQyYkPNQLT1Cb4EEM0UqTtgBKLJNT5L wEhGPzMRsj5A1kw0U6RUwjmmJJy9LAI5sqFmIPp9OPg2QFRUuG6LwLmdSSCPZpDicEZh7RWx 7JaQFbAT0vosYlmFbwNERUUsMwhGMhaBXY5FKs4WrL0ibd0SsgJ2OVqfRViEzJqoqEjdBsEo xSK4pzFIxLmBlVYUwVnHIpBZG2oGoq13kGsTFRWu+55cXp42jFvUM93WmWSHcwMrrSiCs45F INc21AxEWc/6LEIynJOJ9opYdkfI1gz5ONFVkVIVZ4t70ntY4QRf67MIi3CCLyoqUrdBMN6w CO5pDBLR71l7Rdq6JWQF7mmUPgsz1mcRsmEMYBGMJSyC+5WZJId+z9orYtkt6ZbhmYfWZxFW cL/CKipi2S25/DUmjCXUM2TrTAp6OWuvSFu3hKzA3YnSZxEWcXfCuipSt8f99C0hOzxk30RF RUrdkv4WI84W+hmyYibzzoP1WYRsmFlj7RXu0S3plql6iOzo0xbBucEiuKuwyHSqLvosQhKc k4n2ivTojpBlCXNtoaBPh4IzwT2hPuMeQumzCAu4Y2BdFanb4/p+S8gOj/uDENCDWXtF2rol 1GfcHyh9FmaszyKk4i6TlVYUwdXcIhjpq5qJ7OjT9+TyTr/jbKGfIbtmMsf+rM8iJGFGjLVX pEd3hCxLmCNjFRUpNZOCc4NBMsb+FpnO0EWfRYjD/Jd3uDe9JWSZw4yYD+jTFsG5wSIY+1tk OlUXfRYhFbNdruK+85Z0y1Q9RFDZwiQ4W1gEI32DbHOkz/osQiLuF12EkzNRY5E+GgTO0HXN RFDZQnRVTHJ5sEMVjeGZmZCluBtQ+izCAtxyEV0VqRu1FO4J2epwFXKoY2ESnFEsgrsBi/T9 wZfMljrLuMtb6izjuFrqLKPfL3UW8NelzoJkqbNoW5c6C5ClzjK2tdRZBluXOgvOVkudZfSP pc4Cdix1lrGtpc6iLVvqLNNX2UudZfwqe6mzlLGPS51l7PVSZxlsXeosUGqps7xIljrLUmdZ 6iwjWeosw7tf6iyjrUudBchSZxnJUmcZyVJnGee4pc7yMlnqLEudZamzDG0tdZbB1qXOgvPO UmcZ/WOps7xIyLKlzjKWWuosI1nqLECWOstIljrLSJY6C1i/1FmWOouwpc6y1FnE1qXOstRZ hC11ltGypc4y9nGpswy9XuosowcvdRZoa6mzDONzqbPg3LTUWUb/WOosLxKybKmzjG0tdZax P0udBchSZxn9damzJCBLnWXo45+POsu7h08eSnuBeStKn4UJ66qU9gLjVpX2Smkv0G/bKyS2 nygN9YTnumWlz8KENVO4FCutcM2sxsL9UYSt4FKjXYe1YlntJzxCaIyIrTRGxLI7QrZKPWQr jVAh5PlSqiYqRTXTV8fSHyFsRQLrlfaKMNJeEUIjQuoWQu0Hhz2SZ6jXQsgyGo9CyPOlFHm+ 1ExfFEt/hLAVO1ovuirCSFeFCaufcN2smcLt35Lea1VPt2wmrIcitpKfi61CuM8z4XVI7KgO vJO1TsQyOvMSO+4IWSb1kGUzqejTrIciNdcAHqQIW+HBO5VmijDSTBHiN6ybTrik/TtCvZZ6 yLKZRPRpVj+RmmMFD1KErShovSikCCOFFCasY8J1K9LbZz0URSL44kxYo0Qsc+j3rH4ilgnh Pnu0VdRPxA5SPxGSHfgiK5uIHXek91rVQ7bOpKAHs7KJ1CyE+zyTPPkia50I8Rl8kXVMpLU7 Qn2UesiOmUT0YNYxkZqFcJ9nwt9pMWNlEyEbrrmsWsKt3ZLeR1VPt8MgO/orq5ZIzUK4zzMp 05zCOiZCEq6wilBrCddl9Qz1eiYlgJ+xIonUI4R7OBM/zResUSLEO/AYRah9IdRHH8BjWDdE 6plJRA9Wz3APZ1InH2L9ESEV10pFuh2K9F6z2oiQHb2KlUSkZiHcn5mEyT9YW0RIwnVQEWo/ YfzLSiJCMnoMq4RIzQWjXYPkOdpl3RAhDlc0Rah9h5Esq4QICQlLBfQhRbg/M5niVtEEEVLD OB41udrX5OqjKIAI2R3WY5AwjnT9DPVnJtsUk4reh5AIK5EmZEfcsNdxH0eRaHBIqVyw5lzH lUkT7iFEoFrLQ1iACFRUOaQ1BzsbTajXLo3jSvQ1pFTwWHOA6FIT7qFHy8IUXYpOh5ACq4wm vUeK9F6zKoeQrWCprWDNG0SOmnAPIXLUGhzCMkSOop0hdUdYd+4J9VrqIcsizLuilCH1GCSB D6ln2IqZTLGkKG4IcbASiZoGt39LyFbn0DIHs7XoYkgpjx7M+hpiq4dMhC412jXYyvoaQgpE l6KdIZbdkd5rVU+3jPU1hGzowYpQzVsCX1SErYB4U6tpCCM1DSERVj1NqEfRYa8jZCJE4UJK JfRyVsoQOxJkGXSpsc+jHaSUwYQVLrhuVsHg9m9J77Wqp1vGShliq0cPZoULsdUgBT1InmG7 ZhIm72RdDCEFV0/WvBBb7whZXyBKFV0MIRV9mhUupOYNMpmaUJ+l1GjXaCupYAgJuMKywoW0 f0eo16GiZQHXHFamkFIJYlvRvJD+JFxPVKnRrtFW0rxgkndchRXp7ecd1271TO91xvyvKFyI rR79XhGy1UMmUxOyAnPEWs9CLKsJPJhVJ8RWyeSSZXeEbJV6yNaZVPR71qGQmg0CuU39DNs1 kzR5MKtXCAm4dueA6/stITsCRt8GSej3rEMhNSfIdmrCVgTwYKVVIcxBjkMUJbjutOH6fkt6 r1U93bKZZId+z6oTYqvb0MscrkKq1GjXYCsrUwjJuHYrQpZlXPHVM2RrxiiedSiEVIzrU8XZ glUnpD8V8iC61GjXaCupTggJcK4gihLS/h2hXgfInlgkot+zooTUHCEzYpIyeSdrTDBhJQi2 jPUjuLVb0vuo6ul2zCQ59GnWjxDLhHCfZ8Jfw4gdBeN61n0QyzKu5reELMsYxRukoAezWoTU XDCKt8gcxbN+hBCP67Ii1JrH1Vw9Q72eScSYnXUfpJ4I2U5NuM8YxSttCGasDSFkg1METXqP FOm9ZiUIITt6Hqs8iB0Ocy4zUboPwgqcDIqCg/Q6wZmBJtTHhNE3qzNIqYLRniLcn5lMp36i 6SDE4zoYPK6Vt4T66DGONkhEr2K9Bqk5YhxtkDDH0azgIKTiqqdIb81XXCvVM73XBtnhRE+0 GKSeHWNki8wxMqszCEmYYVGE2k8Y7bIWg5CCXmUROK3Tz1B/ZpLn+JeVF4Q4XL8UITscRrKs syAkoFcpQjUHjGQV4R5iJKtUFZixqoKQiquVIr1HbsoRs4aCkB19SBGqeUfvVIR7iFGqUkwQ ljFKdRHXJkWoR1OOmPURhOSKpTL6mSLcn5nM8SarIQhxuO44h2vTLaE+OowuWQ1BSEDPswjm SNUzbMVMpnhTtA+EVIg3RdeA2r8nl626nssy0T4QsoEvakI175Aj1YStgAhUKx0Iy3BaJ5oF 0lqEnY0m1OsIOQ5RH5BSOWHNGfKfmnAPE1qWp/M7UTEQ4mBF04R6hBlh0SwQ4ncs5XesOcBZ uibcwx0t89OJnigUCClwriDqA9z+Lem9VvV0y1ihQMiWsNQGmUyTQEZUP8N2zWSKQEWPQEgM WHf02P4dITtiQFsjrAyiESClMkSpoj4g/ckw6+tSo12jrR5OD0U1gOuuO6yn96T3umIeWdQH xFaPPq0I2eoh/6kJW1HQej+dMIrWgJAC66kmZFmBVVg/Q7Zi1liUBYRs6PeKUM0b5D81YSsg /tU6AsISnELKbX+pO8C6fE+o1wHOJS2S0O/5/r/UbBDIiOpn2K6ZTGeXohrAhO/2c91lh7X7 nnQ7VD3d1plUj37P9//FVp/QyzyuMKrUaNdgK2sECCm4LpeMa/ctIVsLxNqiESCkot+XCplM UQSQ/lRchVSp0a7R1gRnl3JvX+oOkOOQ+/+KwI5NE7IsQB5E7uRLqYSzRUmQ/9SErYhofZrO LuW2PxO+k891801+bv+W9F6rerplMykO/Z5v8outDk4zTTKdZsrdfiEZ126+ty923BGyLEPM bpGKPs339qXmCueSJplOKuUmv5CAK3UOuJrfEupjwAjdIBE9mO/kS80J8p+aUJ8TRvHq3r4w BxkWuV3PdSvS208bru/qmW7HTLLDKJ7v24tlDvKfmnCfMa5Xd/LFjgI5F7ldL73OcOaoCdmR IQsjN+elVMWoURFqfSZlyrDIfXshHtdTvksvrd0R6qPHCN0gEX2R79JLzREyLCaZTg/ldr2Q DVfPuOEKe0t6H1U93Y6ZJIe+yDfnxTKH0fdM1F16YQWjb77xLpYl3OfFhCuseobsmEnBWJtv xUs9BSNri8yRNd+TF+Ih56IJte8xRuZb8UIiep5F4IxPP8M9nMkcNfMdeCEVVz1Fuh2K9F7z jXchO3qVIlTzjv6qCPcQ4191v11Ywfg3JFzjFKEeYY5YbrMLKehDAb8M04T7M5M5kuW760I8 rl+KUPuYEZab6kLChqUCepUi3J+ZzDEp30sXUnEl8hVXq1vS+6jq6XbwvXQhO/qZRSBHqp9h K2Yyx6R8C11IwvVLEbIjYXTJd86FZPQqRajmgvlPRbiHGIGqG+bCApzWyV1xac3hzsZjRlju kwsJ6FWKUM0BTtc14R5ivKlujzPj2+NCKq5NivQeuSnb6yrmLxzestWEasb7u5pQf6aMsLoZ LixjLOkinNbJrW9p/45QryOc1snNcCEZPY9vdEvNBsGMqHqG7ZrJHG/yPXAhDseMw7ufmpAd Dmdrh3dqNaGaA+Y2FeEeYgTKd7y/ZLZueEPd64Y39Gjd8NbeuW54gy+sG97j+Fw3vNcN76G1 dcN7sGPd8B59aN3wXje8h1Lrhjd8SbxueI9f760b3uM3h+uG97rhrdtfN7zHXq8b3lDzuuE9 etC64T1457rhvW54D7bmdcN7aH/d8B58cd3wHj143fAevWPd8IYs0LrhDd6wbniPpdYN73XD W7e2bngjWTe8RzvWDW/o9brhDWTd8FaWrRve64b30Ot1wxtsXTe8B+9cN7xHD143vEd/XTe8 0YPXDW+oe93wfonQ7dh1w3sstW54j5atG97geeuG9+hD64Y3jOF1wxvmgnXDe/SPdcMbybrh /SLpfVw3vKHmdcMb7Fg3vF8k1Ot1w3ss9WPf8D7+K97/+hBzi2724w516itoLC3WVuQ9E7/R nTcqJeTdw39//OZ4Mh3/zfFWtmexhFCuqZF4/LfLG9m4fiJ9FDTij/8uuSLcTy4FPdelFAnH f7u8kYqtq2eIZG59sMIi7xTzjt/cRRJllrhuiwTotRCyLFEWS2ylPJLYSrkmscMgjtsa+mwR ZVm/Wa4to8yS2DGTXKGPQtgyylkJoayRlKLMktRskMxtDX22iLaMvmsUEnA8pCC/PpHE7V/j iu+1S6/5GbZsJpRHkpoNEritoc8W0ZbRV4xM4u5h7Mfdga2RvkdkO4RQr6UU2+HQgy1SwYf4 XvtMlB2Rck1CcoFxHXNGy+jrQ7GDCduRYRZrbUWsxyABPOaGaDtiBR+KIcAojsGhZX4HHxLC veZSTCjbI6USeqdBYgWPuSHaMhfAh8KGv37YCrSmyeVDYUvQa3mGLJtJdOidFkkw0vjO+kyU Zf22t7Ys43gIOaCt9B2h9HomFT3PIGUHj+Hb5zPRvaYvC4X4DcZV8LgOBo+rpxDutcf5O0T0 PIsk8A++az4TZYen7wiFbAlGkd9wjfMbroxCqNdSiu1w6Hkz8fsO3sA3y2ei7aAvC4Vk/K19 whVNk8s/fMKVUZ5hy2ZS0PPuydBni2jLKGskxOOv731CW+k7QunjTOgbQbFVkf4+InqefmYm Q58toizrt72VZW7D8eAqRrKuYkxqkB09zyIFxhXfPp+J7nXBCNQl/K1dwgjUJYwuDVLQzyzi Yczw7fOZ6F4HjC6dx9/ReVytnMPI0SABveqeDP2xiPSa7n9/rUiFyNEkeRzpFtnjOPYHco79 RhLWvEPkOJChzxbRluU6jv24J/itG4FYshGICi2St3GNaWTHegwCs6zcUJ+JtiNA5NgCV/j1 GylomYOo0CIhjmtMIwnrMQjMqXJDfSbKjm2DyLHt8fG33irEko1AVGiR3WGpmWzbGCnJffSZ 6F5TRkhIhKjQJDJfXW9WCPc6Qi6gtZXBYzS5PGbL6Iv6GSIQJ94RbavfwWM2B3GiSTz22nm0 zEEuIG7BgQ9tAX3RIjATy+3zmSjL+r1tZVktEEuaBGJJRciOWiCWbG1l8Kq6oXdaBGZruWs+ E20ZfSMoJOJ4qBHizUZkJrzGFd8sl15HiC4tktFfLQL7fLl9PhNtmYedf6wO4k2D8K1xtkMI 9brskAtobUGmbiD9DXn0cv0MEYhA74iytd/SVraWAhGoSXCFFcK2FsgXtLYgU9cI+rRFIAK9 I9oylYftJEIEapGAK2zBPGkjkEFobUGmrhH0aYtAlHpHtGX0bR+TvON4yDvErY0k8Dy+Ec69 lmfIspkUjz5tEcgOyK3xmSjL+n1rbVmBPUojHm1VmdNuBxO2o+DKkOuO9RgEYts7ou1IkEGI OcAepRFcT3PAVVgI9zrgOpATZOpiTuivFsHY9oZoyxzkFGLaMbZNmCeNacc1N2EOVJViy9yO 49OjvxrEYbR7Q5Rl/Va0tizjeEiYOR3I5VUp4yosz7CtM6norxZJ4FWpYkTMRFtG3+QJCbj7 SQEj4qSyq90OJtzrgLN+SuidFoEMgtzSnom2w2FEfOTWx5EWMXPaCK6wQqjXUortcOidFoGc gtzJnomyIxaMdmPGvU7EPGmMGVdPIWxHhrxDjBV90SIY20bMnArRdkTIO8QY8LeOmDkdyOUx 0ePqKc+wHTOJ6Iv3ZOizRbRlDk61Ytjw1w8bRrthg/Mpg0SHfmYRzDJEh5EsE9XrfuNZ9zrj bx0wcxpDwpjUIAW9yiKYUwiYFRWiex0xAg0ef8eAWdEYPEaXBonoQxbBDELAjKcQ1Wu/Y3Tp N/wdPWY8B3KNfV9xjZNnyA6D7OhV92Tos0W0ZQVOo6JP+Fv7hPGmT5hlMEhJsKJo0t9HQa/S z8xk6LNFtGUBo0vvcTx4j/Gm9xg5GiTAqW/0Ef3MIAFnWY+5VCHKjn7jWdnhKv76rmK86SpG jgbZMZZ0O3qeRTBf4KbMKRNtR8ZY0iX8rd2UOXUJ40SDFPS8ezL0xyK61yGBfziHcaJF4OxJ Ee61w3yBC5jN0+TyGBfQF/UzMxmssIjYSreZv1akQuRoEogcFemWNQKRY2sLsnlh3wPWbBCY reUG9ky0ZRnOp8IeIZY0CcSJFsmQuwt7rliPQWBulhvYM9F2BDixCruDXz8cerDb2JqDONEi IWApg8CuXu5bz0T1ut9UVr3eKkSOFinwVYYi1Outws4/bBvk5QZy+lAjO7a1wUmH3K5GKyyi bc1wzhW2CLGkSRL2Oia0LEJ2oLUFebmwZfROi0C8eUe0ZR7OucLmIN40CN+B5j4KYTscZAfC 5iEvFzaP3mkRiEnviLKs3zlWltWC46EWiFJDVXnSa1zxHWixFb/8tMiG/moR2PnLPemZaMsS 5AJCjRC3hhoD2qrypN2OCDGpKsUkQ15uIP0NZfRy/UwnCSLZO6Jt9ZAvCGWHSLYRWD1D2WHN VYQsk1Jsq884qj36tEUgkr0jyrJ+e1hbViCSNQmusAWzoqEUyCmEskHuLpQNfdogFWLbO6It S3BeFkrE8VACRLuhqOzqNa5KwFVYnmHLZpLQpy0CGQS53zwTbZmD87KQd9jrhLxD/BvyDt/F KkK9llJsh0cPtgjEv3J3eSbKjn4PWNtRYGcTMmZOQ864CgthOzKuA7mid1oEYlu5qTwTbUeC vEPIAXY2IWOetBFcYTPmQFUpJgnjVotgJHtDtB0OMhEh7fhbJ8yTDuTymLThCivPkB0zyQ59 0SLwvYPcS56Jsqzf+tWWZfz1U8ZoN2U4sbJIRT+zCOQU5BbyTHSvI8a2KeBvnTBPGlLAuNUg Eb3KIpBBkBvGM9G9dhilxg33KBFzoI3gqieEei2l2A6HXmURyCDIfeKZKDv6bV1tR8ZfNmJW dCCXN8SMq548w5bNpKCf3ZOhzxbRlkU4nwrR468fPUap0UOWwSIRvhsfSH8fEf1MPzOToc8W UZb1O77KsrDheAiYXQ1hw3hzJtFhBBodep5FMIMQMJcqRNtRMN4MCX/9gLnURjCWNEhBz7MI 5gsC5kmF6F4HjCWDx182YJ40BI9xokEi+tk9GfpjEdXrfqNX9dpvGCcapMJJkyLUa18xp+B3 yN0N5PIPv6Pn6WdmMlhhEW1rgdOo4BNGjhbBqNAgBTN1vqCfWQRnYo+5VCHajgDnU8F7HA/e YyzpHUaFBsH7jsHjnUiT4LzrMU8qRNnR7/gqO1zF39pVjCVdxajQIDv6mUVwn++mHCgT3esM X8EGlzBONEiE8ylFuNcJcwEuY6ZOk8tjHN53HJ4hgpHjDdG2BjjDCs5h5GgRXAeFsGUOcwEu YKbO4X1Hk2B0eUPEMr9vcIbl9wrRpUlgHVSk29EI5AJaW5Cp8zved7TIBvM39dki2rIMp1p+ jzAe/B4hJvW7ypye46qRjL2OEIFaBG9AmgT2+dRni2jLPOz8/ZGRH8a+311AWx18F6sI99pB LsDvATJ1A+lvCO9NDs904iFKvSPK1m2D7IDfCkSpJoEVVhGybCuQL/DbBpk6v20VazYIRKl3 5Etm6yb+OELWTXywY93Eh5rXTfxxhVs38cGH1k38kayb+Ogx6yb+6DHrJj7UvG7iB5Osm/jU x3UT35tk3cSnutdN/NGOdRMfe71u4o91G2TdxB/IuokPZN3EN8m6iU91r5v4Q6/XTXwk6yY+ WLZu4r9I1k38dRN/3cQff+t1E38k6yY+esO6iT+O/XUTH2peN/HBY9ZN/HGNWzfxoa11Ez+Y ZN3EZ7Ju4isfWjfxwWPWTfx1E38k6ya+tmzdxIea1018m6yb+EzWTfyhnnUT3ybrJj71cd3E H3u9buKDN6yb+KN/rJv44yhaN/HXTfzBjnUTH8i6iT+O2XUTH3rtMHJcN/Gh5nUT3ybrJj6R P+eb+O8ePnn4bw//+uDd4/G//v9+/fXjX3/68Jc/D/tjs+T4Mv7x0y8f/PXI43mZuB63ceOz b21/+vXDL9787dPbtvyEfd/efP2Un2tqm+I3Xzy9Dc/5OM9+893TW/dcqg+hvvnqyT1nX9sA 1E9889SCsNxm9je/fnrr83Nu8e6bf3s6RnIs+c3j09v6XPNW85ufPjUvcTltbz6T4u9bqyGG /o/QWnrzGynSK4+bbvzxKdTtf3z6Xx6akW2vFR/ftuW6Tfbh8dPPm0k/fXqbnw/j65tvuW/f SPHvn962t9nmlThY9608IV0xe28a//3T9nzkRMNLb497fZzS171evY5twJy9/scn/1yd3453 e8QaudX0u7OmUGJu75bgO/NX+Jw78sVTbjNE+0GPtv720zZM2s/f/KvuqY2gx+++ejg3JMdS F2oPfNLeNnZnaExJKyF0+UtKzaRyMNLY3rcPve72r3wuP4EuBsgzNEljqUNqYuj1z//uz6LX h1tertg6fP2jve+X3NTXx/Kcc3JJu2lsca0/W27De+tu2sZ0+/1jbb//t0/lGL17bYNP/nUM ptwmnvbzEzzcMTyX4lMbnPH5mJ725lvhuRmwYzXnIHrbSrQJZtvf/D0X+JunGvztcEqhrX5n Xi4l+mGSv7IlFNkLoW/UpdRMEu8G09725SfLfa1Ke9sZXRmlPhPLM3TWgaWs4fTn0OsfYzil mI5f78gJtl8WhpPLLwwn+tcX18DaQ2zDqcUdqfqCo2mr/pg9+cGjdKm51jae4nMrUROMp7bM uyDjqfWrzZH70eHnQ/5lO38gC99Y39a8ZuBefBicybWl4Dx5aN5cuvV//9TipVSaJV+2Xj8f X9m22ZlYc5vyHJ2P/lim6J/vzzdWsyvtn0d80QbA8Xbo798d/2z/CFlV9Xmz2rsar9fTrN72 1Aq16HHv0zsVlzLfqDL0r++Nbqq+SZFeY0pv/nA2eBzBqAZ7J9uQePN/PR0ZL+f866uEo49t 0hFEnpsEujoohLaMUmom8rlLc6xypSdcP1ZLR8B+bi7oyI6f4Q0ZlrpdJf4D9/rHWSVSc7Kz 1jYg+sD+B/bbb61V4DOG358T/Z7aetFcuMUT+57JhY9FRCaAR3bcX745vPn4OE+vRryeqCr/ 7SnE5xaf1Dc/OUqXWL2q55MWRzXHbkGizCPfXQtPrZtav76Yupv2q8azzD+1evZzLP/AD37d AqI2z8YWG/0K57AtHe0cJhz1PHM91r9++dTdI7286h3Zpio7gq8f8rEHjyfpOzQh9O2AlKLv C7Cec6D50ncSdGaT2sRy7RLoyz95ZpO6h1Lmqvdn0OsfZdVrC7e/dpnaPXiNmvzjWK60fwwr XIvWx7gr58ID4xiZuWyPf2iNt+D+8X8+HF845K00k/Y+T/gjoXhuBOmT1E+mn4ZL1a0nifzx 0e/xQ1SSNVEv5uPeRzn6vh378P25Fj1dtAnu8rTjH18JGeeCg30uf9T2lxYgX1VfyZNDSac1 83hMsbWUx+++aOPw43p7fP68X6PkiBSu3v7Xp7ctIG4TVXnz2yk+cdmcs674ZHdJ/VV+W5lg rnkhlHBGBMcP6vR0qebQL1Qrsp9ro7m90394+PQvftECnGtybFvaT6/etd/vI/rEBkmn5EHp 03sOvWRKfJQ5+LeGbd9K3dafJZj7wujYZzIiaLbOu5rqH4clpVf02lvnWf9LKa1fO0Wc1wCN 6qVfrtfGCjvREbIcX5wc3x6X3Bf/kK8tWiM9X91Ivu6L0pzUyPXFMt8VDsfdyXqSnttpJF/3 Z+lkvZFwPUNfq4fcZrLr9rCneg6/O0mhekq++rP3zFYjsd/KzlRzOYMKucutSKJ6Wu/PO9j0 VYMQyjNKqYSt1yx2+YsUrqfbXukGSHs/9boBzhvf417vqVlAJ5LnFzknoa932ojyo65BaIHA 2dYWuVTuz1DuPpTS6yG9o1C23hZ9iRyqu/qz0a2dUEOvmb7eDsf9+fMZCsxCrb0tCgPbtH6N hI2+ozu/1NxPZRCqZ7vSAI3sRPrvvtO+rYU/7tJuoS8jwh6uPrNWyPkd9VmK9o1h367fYufv HJ3vz/C3Ei71elhx5dAmOvvD9w+8v37BnU/afIq9FGWTm/G9FJHor7EhpWLyvRTVfGjkXaWo 9eNmYR56mCJakfoYY0vjoXI5aqnkPjZ2+ZYkXX7KbzUeHnf9FniHhX+deHxNd2qAyLeR+fot lLpJt2KTbwH3OI6WeHwlOYyoWGMvxd+/HzoOZ82sxFW7v/PoPfUoqh7h8fiG+NLyoHe4+V4P f+e2hWvWYm+KxxfUg8e1Vq8+s1fGIzqr2nNP3ZPBu5s919vgGaCRa/SKJsZWrtFS+Xsxfobv E3E9/P0ztVU27E/hc2rqM8+ibFfh76XIdlEYoPdT+PsgeoeFT0HpPRf+cpV+i8J3Vej3yvxt Lf2mmccG/e55GhtZlHj6+MkFx1iWM78+DjN+naNuwdN4znIzo4/5zHf9yC/kNj35TuYbDeRf 2aMPZlZbIz+Vm+rky5lPF8nfM9+woDkhszYNzRuZv0UJ/TfNPFZ9XxkVSf39cCnP/Qk8j1Hr NCe4uPVS9H6c62+M15TjBPF8hu5dhiNDd93Ap/l5D70temPH9rS/VZqxt52eoeTuVvszdKcy bPSe6cugthbQM5WeoTdPJ81hC72HiVcQd83hmVe0Fq5c7znz2rRdc3imb8LO7/qvEcWrVe7v mb6fbmscjUzqz6FZcxK619RWxv5b0Ll/iDvVw1HKGDW1feNf/LH7rmbJmW+Lx/aOIvef8k7d TDF8Y+z4Pzx3fVRYjoOmM9lYWiA+JBs5UfGoIlkq/Ttpxfrz45SfSMfxShtFLmxZx6xmTPuF YeEZ0rYRvlsbiTbuH9+2VxVc9NehkNj+rdGr9/P7eCHb8+obPDfFj/Nz0nNl7beweThSQl+f u7NQ9qB3Cq+fO5z/kg3D72Q3zq+lvZLUxtT1btrz/ZgPtkJH3e9VOvoD9/fyM3xuvQirt0cq uC0FvtXYtz97VkVeeFE8LB6NttXbM4fSV4aLqDMf2SjpDvXX1xaXfOzH29vrR43mIBlf4vEP axv3lTT6qLadd5syv12LYwj0gb7frok9BPrYw9crGJaPBf1x/eg6f+tLqm9efNVDIiX+mNzO D/HoEpgvez//o88Zfam9HpLH9CX3euhTd39c3LgI9ec4cD8Jfdjh8+Y6oR7m3O2iC3D+WMij /njQp82Pnxz641Pxi5BdKeTxk0Mf9wT1xGuTqNqKkQj15xBs8EOfjzc+2nWcaubhbRzSv+Mb 83u3lN+qv0LERjYicesfbvbNgj9yNtcv2Bcs7+h0lC45eFfy+Imsd6nXTB/neBf6OyQJAO+c 7x/N9oVvb8XbgDk+Ge717CV1QmH2fu6c0vFhb7d9P36crR6kW7of+62zFC3Nx87iyMG1l9rf 4aGbeJWiRfaIFK5nSGBpO/esR1sUWG7F92co+Dzj5YMk2s4c0cRFaBN07DXPehJdWTsj6PMZ OlzcUreCLw/IM5SKlXroI1Jpa5v6Q5ccuc+Zwn62K9OHOWx7ppHJ74cvjvA7zDR++D1nOoPn 3yLTx138e2Xa4PBvmmls8O+eSViXx0ZxPMb6+CkUDPMYKzQ2eBzyRSseq4U+FefxXCi04zHP V6/YLwoFcuw7hbaN7F98pY198BCi2wY/LSRewr5cKJBjfy90QsVzQqGPPHneKDQyeW7hK23+ uCrjB5KDg1JHYJqHmvNGhFovngjPvcmBFaX0ttjS48ridS2Q3kYNCd5YvTaS6q3Wa+uk3vxG l+f419nCNc/LL7ilOl6n88cl7LNmHgnbjqNl96FfMaN69uj7dTaqZ0/9khHPWvTdCY9ev290 DYws3fvaxF4Q3LXVFU85P9o8CXlTiwUvu9jjwiFGcV0L41L5Ggnsuefp43l5irw7uL6e8gzQ CF06ok2Qq/3KFc0kQpI80y9hRamZrgFxf0r/2IHTX657SqINu/SQE2vuSinI9Zlm6eWVced6 ElwCau/naivSddBGrpojJwNd6CsIJwydpws2tL06NpvDdRq/d2+KdLGy/aZ0WYTeYeifdfiN R90Y7fwpm6k2Tx0B73WiQoc26kzhnfXVTwvGmgGlsX+QP387bkDOUPHlMB0iaOtgRbZYL+wQ aJOkjgXkpME6X1DRrnUQ8fuz37sLQ8Q+baFaDS9uE36wDJae0tlxvT8or4Xj5xin85jjWKfv D9oooXC8lhe2FNyhF8oYRypf4mnPcVQl9rw7T0racDRPqp7j+WLGN/TyduBs8L3xa6gTIDFM fo5v1XaFj5x+x7/goxo8/OdvjTFhbcrVS/sdj+U/nBkGGlmn+cOO6/bQ6LhEdKYs6PJ68HtP 0fLhwXFIfaaMSTgt+J6a3+ga4XltI+vUc/B0ULHzvEyHGXR9os2D13HLRlf32zzYU/MkpdZm tH7kQF+QtPkrdUJrdl9d4k4Sp37vx1o7zbltlaLUPO0H9gwy5+cn6NdBBa3ih7z5kOJva2Q/ 8KBjgLaOXukqPjw4P3C+jiVoP9CGy0XoKO785GDX8vH+SD2f9RRe13Ovhw7n/CH5cfawlHGl b4TW4y1dKa29cn9Sf6sky++32A9FKscHsb9V+jihkf5+Nu5z2PozhZ7pyd99YytCP4ChC8/+ EO4+raBDPn8cNZ017/wOr0gxOcfRiT/fWHJ07KdI4WfOtV/+IwlC6OJbI/6q2XOfiQTuIZUK /A6pLd5Pcg+TvI14kSyW7p1wPVdiN7nCfU7nGEuucj3Xryz/6Y3zs/qz1Ma/8hWDJrfzb3od 4DVCtveRmbxEb+F6xlMSuUVvsROqeS/X2/BBfKf/x0k4QXzsNLL+j5NQVNEIe+4VnSTP6eAe CSVPMcT5Pdn1H32huOf4D6mcJAeaN+J+leIjz0Na7qyZ45X/r733a/5kN8777vdVbK6y6+hs 8H9mcicpKpdSsiKbJ/aF5QtS5OFxhYe0Kdkq5dVn/qD7aTzoHZkSmehUoXjBrc8ZAN3zRQMN YPD8TlcfC3Ub91ppVPsHXeQbZvwZmDMr6b5Ljn6vj+/W5Y8InLne8ZRScl2Cv1vXUjV3mxuO lvvbaDho3/szYmGL7EUr3Qv1tLVus76NNr2xrfdVvNXrOOtuXd/81nsUfp1t2/rvJb/gdnQL cQwg71B6gmzxo7fcYkYP0U3/1t+Y9Lq0P9k/embajx470nvT8XwThB6erpE22ihIxzPyI1LS 8eyCIZrS8WTJiDg5bEZUpquHV/snYdLR37NGdzp6X9URACSiVHta15WG1hPUntbHBP1Y4Wjd C/2g4egHisehvtc+hosgX7quNT3jqr6N/rmAjr3pml2eZ5K+jT6GyzGkHhHpH21J1xw3zA7p WuPd4/OmFqY+DzY9apJDa/1M5DqsfuYvtTDKnz9RC0P/gEA/QNllpq561HTI0bv2w/6Rih7P nxlYn3dEVPAWInvmZf00oX9Kcoh0bLq2ee56Mj5o6PNp1t5b5PMFie7r+HqzWYEea+mfMUl7 z5rw0cMe+u8lsrl60IVPJa593ttCyVLSJlmBXLC9haeeg389MKv99woa76WX0oxok7lbV499 lMi77MHJSGKyr9Z6zqYZWusHnPqnT85Ri3M/OTDb5bs8/fRn11XotYK/87pNP7WJ/WMFPYq7 1uLPM+JFaf1Pf+jatWT6WOG+dn4fq2tfpQz2n3WAd77Q+szxX5oc4P3V/clurq1/vHv964+v f51P5vO/fnN/hGwPQXDO9dPxYgAvJH9tFg3O8gwP/sw5ArFrDy2sJ03eYuZ18Xj20u3MtekM 7meo2jvumQ5kLk9/7piIr5TNIZd72nOua0K4DOKbfN9cicH525zjmN52+7/OcucYuNV6/iSn AaG0T99+Pn+PMxDCdQXjuuwWWk39AtsZ7v2qW80xmUt/5qrbn+iTz0W9c4A6+g20ltKn/xvw zz6f3aWeM2K/YHfX2e+i3dfn9BvJ68oEXdT7iRb+BWq0V+b+uzb5lQfMBbmPemfvu+d+39Uh jaO//XxttsUt9yevhfyfw+W/umwp25HPN6YbCcMFvb+BCaZaXFB8XkBqW7/Ad5ltyjz3A89p 215vhIP/WY3q1xO3cH1d2T+0/eYanj5eufr9oenP732gs7l8KR/13/gcTH6Hn/jf3+/+2Kvc kaxxeh33T3O/rRyDWUbreezwa/6V1vgr1PNT7wX0H+jq/2j86v/nqFzv09B9P+5ec46qOX10 mrksQ/f5Vl/9X+oLML7+6/v6TDmz4dOe+xrlobdAr17yiyus7xf093cQ5ufqz7X8iWfxf7jG t2vWzUPj35zpQDmT9zPsriF6T9dbuy7T3ltcf/3J+73RRz7yu6778XjU4jlOfYtLnn+p907v Wwnpyzla6GbGdZJ6fXwtE88P5yAW+jdoMhWByDY8Ss1ESn3/4cy3ZXKUg9vaF9E6GeGZqseZ Y6nrFsLVef/+R2Hrdffg2iC6r3jIaZf88bT7AOD6wv2+H7HfX7b/kyfacxmwXZWfSTG+yMe2 6nO75UxhzkiVKffPsR9odoH/7P7vdfjEJeq0ErHDFuYZT/cBn0/X/1Qb/al86y8bk7F8ZSNQ 9nT/5ycLCCn5n9XAtTub2LfWnk92wl7iPXU9OcTPnbq/DBt4P4Z+9N2PwsrV2//l93a+dxbr s10kf5/uhw9nevgsdPQv1oGIhjBKzURKfX+W24q9MXDWXfr3g5toR+KZoK2Npbx7Zz8Gq4do iK2vpft/rnfs7B+vraLrayobDf/0a2pxS/cJ3/UpSZ3D4u47WzunftzM/2MNgJ97a4fVeVbn +YN1nn5gUja5XZWPZ+OhyId8IKJShFIz2fRqdaz9W+Yi6rexyF+80k/M9JldaxpL+Z3nX77V v48br9d+eb2/6z6uE1C7cXP93rRxczNs65iTZmzIzNeqt+Juw5jT4C/Ozk2/OH5Nbf+Pntji wT9RK2xhted/uRZv5/rxXCwWbfHQfzXDdJ8GH5zjXxn/+VpH9Wvgf/SaG7Tkn9b/bl+s/w99 TqH+3voYKwZXDK4Y/BcSgzGnp9dF6b16UzOqNqES7ataquoHm2M9tz7d9ReZrjVZ3EU39vqY 7xj+Kpk+o7rrVOreY/kRWHnF2O8YUdfXfZc117mTHEfYdaPetf/3GlL4z8O6cT6k4Mi8/vXH Ggl/ZVaa+qHVW2TeoiPyNZkRUMDK7o+cyPx9Knt9Rcil5uMwq0/q6KO414+hG63Ovjr776Wz 59Av9Rz6N1CO59MbIb8C2fWvokipmRzm75Icuf+VtSTq69cHCNv9lNyClWf2Da0Npa7O/mOw 8nfv7KLMdt102OfOjq75b3A3jnrzffpskyrp9Tap4k9NUx57s9T9M6/v/dYkKU9YDLcDn2+t N2L8fS4X0WTnOWO2yc6VJJkrdvADYlf/2x8kmLy7madjQTUh08EifiuUViitUPoDhFLJz0fZ pYauqa6kyGdKp/nPZ7ZF5AlP8nys55He/U7yfL43kyofW2kph8gnWtr6K1EvDrF59OvWjFPP tq6yDiKfhMJX+Tuj8Mwh/bMt+DoTOSNDKYdULdVbfyPqRSHvtWbra+5/XxhEtCpQd8Kb7RY5 pO9vwLOZyFUllJqJfDSL1t+IenGw91Kz9TX0vw6kJMvnrlq3R/CuHxvtM0LQPx9f8649TbyX K8PwVT7RNaRpPd1XEPViJvr3guCZLEZAaqZ4zfJJLvxwSCY/ci0Ur3njKPdIogh6JepFpHjN WByB5UrxmuPOdcvBCyxyyM6exYPiNWeOco9sFEGvRL1o7L3UbH0NgeI17ZnqTnuiqPJIJs/S Xihec+Ao90jieHkj6kVk70OY4jW1SvGa5AIPfHXIRnFmn+mkBorXVCP189Q47lPjuE9tp3g1 RL2YSZ3iNeX+94tAYqV4TfJXTtG+Qyr7ERv16pQD+5E57lPm0cIQtXkm+heNlMWj0UgUd56p 43ZQDDnElHr8iHukPhyPRn7Eg6M8Hjw2GKI2z6RN406/TGI9Kzwvx1IoYjxS2Y/SKBb14gpK NY5pve6C1kHU5pnEaZTpl1CsZ5FnYYeEgyLGPjOT7lnkGUavwKBU4ig3RG2eyTbFWb/yYjwL G8+5lshVsJlsZHXYePbQ6zUodXC8hoOj3BC1eSZpirNQOUMPhTN0S3r7DuF8XC/qgFTOx/XC D0jjKDdELJxJnfPxkDgf1ws+qNuQbbyWaAhn33pRESRx9h0Sx2tIHOWGqM0zmbJvuab5gyEb zZ4uiWN8DM/MRC4Y0cyAS6IodQRu66Bc2yP7lGvno5YxznBBF3Vn6kUuOdjqQvOAtGVL1cb1 1G2MhXeiXlCujbasr4lybaiCou5A/colhT0LNDPgihNKpcj1JMqs34l6Edn7NOXaed8p1857 o/l0IP0rT4dQZp33jWYGacuW2hvXs1Nm/U7UC8q10Zb1tVKunfecue5MqzqXFPYstzH/xJex KFU57g1RC2cy5dF5j41iUdVdte7toBzZIXugHNkjsXGpyDG9x4Oi45WoF5RHoy3j67YnisWt 0Qx7EpqFXUJZs0f2xKV2jultLxQdr0S9oMwabVlfy0axuOXAdWfuVx6hPNojZWPPCsf0Vg6K jleiXuzsvbRlfX0EBIyvqlGudVvyWOQRyqxPQns30pb1LHJMb7FQdBqiNs8kTdHZNYqtZy1R dLZGebRLKI/2yMYx7ZCdssZ3Ijbr39Agv0Zf9e9bKUk8C6uyMixyCOXaHikc0x6hPPKdqBeV vTd/b0tZOCg668GzcD147vYIZd8OaYGy79wiR3mLkePljYgXvIeOtoyvdSsUnbXyLOwRns3t M0IoQ8+10d6NtG5LbRz3daN9XUvUi5mUKV67vrL1NRWK15o4H/dIYT8SZ+i1cJR7hHPNV6Je JIpXrdn6GmjvJpedZ+qy8/zuEc7iy8FZfA0c5R7hXPOVqBec12vNxtey0W5OLpVn6lJ5fvcI 5+wO2TjKPcK55itRLziv15qtr89es/U18kztEZ7x7TOdJM7iS0rUz0vmuC+Z475k2vGxRL2Y SZvitYQ47mXlvNOOz0l4BekRztnzvnGvDrwyL4HjvgQeLQxRm2ei10TgR+O8PleeqXPl9aJH OIu/zoHG6My8930SjvLceGwwRG2eyZzF50w7PjlHnpdz5NWhRzhnz5H2gKQtW8ohnGu+EvWC 83qt2fiaDt4DSjvPyx7h+d0+M5PH17TznJMOjul0cEznwLtChohnE9Gara+NTmBzKjwvW9It cgjn7KnwDJMa5+ypcUynxiOBIWrzTKbz1pwSZ/Ep8iycIq8XPcI5+3XGM/bhlDhnT5ljOmUe CQwRC2eS5pw9Hpyzx43n3Ljx6tAjnKHHjfeAIu+Pn4RjOh48EhiiNs9kztBj5Qw9Fp5hPcKr Q/vMTLpnhWePyDvmOTaOckPEwpnUOR+PiU5OL9EMijNLevsziZxrx8hzRUyca8fE8XqdzYxx 9krUC87HtS3jazg4H7/+cOpYtyWPRR7h7DtsPHuEg7PvcHAEh4Pj/pWoF5yPa1vW18r5eMg8 51rSLZrJtIceCs8VYdpDD5VjOlQeCQxRm2cyZ98hcfYdAmfflvT2HcK59nUONGakYdoxv85m xsgzRC2cyZRZn5MenZymY6PZMx2NZliPbJQ1e2TfuNROEZyOg3Z634l6QZk12rK+VjpLvcXs qO5MvcgllEenI9NcIW3ZUrVwPZV2et+JelHY+zqdrqYj0ulqOkLkugP1K5ck9izQXCFt2VLx 4HoS7fS+E/XiYO/jdN56C0YOsZj2RnPuQB6LPEK5dtob7eZIW7bUXrienXJtS9TmmUy59v1X s8bo3DOdsqQ9Ux7tEsqjPVI4ph1Saaf3nYjNlXJt1Gx9jXQCe0uMjnVvB83ULqHM2iF7pMw6 7ZGjfI+00/tO1IvG3sfpBDZtO53Apq3RnHsSmqldQrm2R/bApXaO8m2nnd53ol5QPo62rK+F TmDTlnau2yEb25ho5XcSysfTlmk3R1q3pQrH/XV+M8arIerFTKYT2LRF2rtJ7aBzl9QOyr5d QiewqR2Uj0tb1g+HFI6gN6Je0Cktaja+9j9wYn1tPFO3yvO7Qxpl6B7ZOMo9QpnlO1EvKItH zdbXQqe0qSWeqVvi+d0jlKF7pHCUe4RyzXeiXmT2vkyntKkFOqVN9eCZ2iE7z/j2GSGUs6d6 JO7ngeO+BY77Fmin1xL1YibTKe39d6jL6Gul/Z2T0HrRJZSz339ReozXuiV+HxvHfd14tDBE bZ7JdEqbaqb9HfzJG9SdaHXoEs7ia6IdH2nLlpoJf9v3TsTmwpm+1mx9DbTjk8rOM3XZeX73 COf1Zee8vgaOaY9w9vlK1AvO9LVm42tptAeUSuWZ2iM849tnZtK9rzwLlcZRXjaO8rLRrpAl YvNM2rQrlEqmU9p0neiM8VEiryk9wll8SbRPJG3ZUpmjvGQeGwxRm2cyncmmfHBen3eel/PO K0iPcBafd9oVkrasH4GjXP9sFDwLnMXPRGu2njXO4nPhWTgXXi96hHP2XGkPSNqypRrHtP7p QbTeOGf3yJyz9z+GaD2LPOd6hNeL9pmZdM8izyeZd8xTzhzlhqjNM5kz9P7nIo1naeMZ1pKn fYfsnH2nnWePdHD2nQ6O13RwlL8S9YIzdG3L+to4Q9c/54m6C/crj3A+ft3jGXtsapyP65/8 NITj3hC1eSZzPp4S5+Mpcj5uSW/fIZx9p8gzQ+Id85QSR3BKHPeGqM0zmbPveHD2HTfOvi15 2vcI59px4x2fyPvj6TqJGePMELVwJnNmHSudnKZYeK60pLfvEM6aY+F5IFbOmmPleI2Nd3pf iXrBmbW2ZX1NdHKaYuDZ05JukUM4j46BZ4aYOI+OieM1Jt7pfSXqBefa2pbxNeyca4eN51NL Hos8wpl12HhmCNOOeeA76yfhzPqViM3Trrq2ZX2tnGuHzDOsJd0ih3BmHTLv5oRpxzzwnfUU +Ka7JWrzTObMOiT6ej6FQKcsJ+Gs2SOcNTuE76PffxCrEeGd3leiXnBmrW3B13jsdN4aj0Yz 7P1nWQeLPLJRHu0Rvo8eD76PHo+ddnrfiXpBuTbasr5WOm+NRy5cd05skUMos/ZIDVyKb6jH g++1vxP1IrH3dTpvjUek89a4HzQLD+SxaCZHoFw7HoH2bqQtW4pvqMeD77VbojbPZDpvjftO OzX3H0Bso2eNMmuXUGbtEb597hLKGt+JekFnsqjZ+lroTDbuOXDdiWZzj2TKvj1SOKYdUimP fCfqxc7eS83fKVs6LVT30mlhsnRarK9Lp4XJ0mn5ClEvlk7L6OvSaRnjdem0jH4snRaqZ+m0 EFk6LVT30mkZ/Vg6LWOppdMyerZ0WsZYXDotXPfSaRnJ0mkZ3+LSafkaUS+WTssYnUunZYyq pdMyxuLSaRnjdem0jBG0dFrGHrt0Wjhel07LGK9Lp2X0Y+m0MFk6LYOvS6eFPVs6LYNFS6eF POPv0JdOy9eJerF0WsjXpdMytr90WsZSS6dlfNNLp2X0dem0UHQunZYxqpZOyxidS6dljNel 00IRtHRaBs+WTgvH69JpGeN16bSQH0unZSi1dFqonqXTQmTptIyxuHRayldJ92zptIytL50W IkunZax76bSMvXHptFA9S6fla0RsXjotFJ1Lp2WwaOm0jNG5dFrYs6XT8jWiXiydltvXn3w4 lwbpvsGoSi1KVGHlJHdJaLek657NYbVb0nXPZjtGcts9lHqI6qloKdVc0ZpfSbfH1DN64ZHv jWei1AIiX5DDV5mt4KvMevDVkO6rKdWJ5A4oJV+Zo+Y3IvagntELj1hfRakFRGYr1C2zFdp3 SGA/zDPd15lINoFS8r04an4jYiHqGf3yiPVetFuUqOaK1m1Ib1+VWtRqSx7PbKnuq3wdDj9A xA9DxMKivg42D36oLgtIxa/f/QARP2S2gh+GdD9MqU62SP1cFVZQ8xsRe1DP6IVHrK+iywIS d64bRNqXWQ9WG9I9M6U6yY16tSqsoOY3IvagntELj1hfRZdFiSqsaGseSWS1febxbCaqngJf Q6LIeyXiK+oZvfCI8VV1WUBqoPgwRHyV+Qu+GtJ9rTznqHoK6mkc95aIhY1i0WiugInmCkis FIuGSPtyvgs/DOlWR55PVCsF9WSOe0vEwsSeQWFFmSqsgOw8wxrS21eFFfXDksdqW6qTg+PV EGnr4BFdVVjY5tEP0VMBKTyfeoTnZftMt3omjWPREPHDELEwsWdQTwET9RSQmKjPqg4K2jek 2ziTxDFkSa8nc+SZZ9TCmWxTfKhWCsi2UZ9VZRRtzZLHaoccHFWGSM0Hj7uqnsIWjlZXzn9V 0QR1F85/Lek2zqRxDBkiNTceQVUZhS0crU6cyapaCeoOnMla0m2cSeKIMURqNkTs4SzV6JcI g34JyFbGng4lEml/ILeNHjnC2NMH0us50tj37DNiz0z2KbuEWglIPsb+CG0StJYpc/RIbeNs AZUR1PNGpPVK+aZLCkcDtElAQhn7LJRI0H6gXNIjibJLaIqgnjcirSfKLl0yZZdQIgFpx9iv oTui7Vvy+OGQnXJJKIignjcire+US7pkyiWhOwKSaf0BTRG0n/OYFQ6ke2ZKdVITxZklveZa qOebZ9TmmUyZI5RIQEKknq7aJNqaKpGojZZ0PwJljtALgWfxoH7+SsSeSNmlS9oUeapEAtIa 9X3VJoGvjbLLgTye2VKd7JliUTVFUPMbEXt2ykBdkqZYVCUSkBwpGlR3BO1nyi49UnaKRVUQ QT1vRFovlJO6ZJtiUXVHlKheiNatmiLavuqOqNWWPJ7ZUt3XWLifR47yLTaODjwjvkbaiYB+ Cfs1+KpKJCCN1ijQJoGvjWdqS7qvjXYroBeCUjvlZO9E7NlpJwK6IzOxvooSCUiidQy0SdB+ 4tncku5Zot0K6IWgVKFM7p2IPYUyYuiOzMT6KkokSlRBROuuB8/UHuEZ3z7z+DqTFmm/ESoj 8PWNiPeRMmuPQJsEvoo2CUjdKWIMEV+xjyy+GtJ9rTwLqYIISm08NtSN80jzjNiz0f4FFE3Y r9HXQjsaUBlB3Ylnc9UmgdWJ83FbqpNCe5JQGUHNb0TsKbTHASWSmVhfA+16QGVE6zakt192 zgoK7/8OpbqvYeOeHzizfCXia6B9ECiRzMT4qtokIJXWcFArga8O4TzBPtO9n8lGu5RZdUdQ 8xsRCzfaPcmFd5azUSsBE7USkETnCpZI+5FOLAbSPUs8U6mmCOrJPFpYIhZuFJ1GiQRMlEiU qKaI1m1Ib1+VSNQPSx6rbanuR+AoN0T8CDx7lMBZvNEdgdWNs/hceV42RPyoPONn3u0dSnXS OIINkbYa7bBAm4RtHv3ItOcCvRC05hCeze0z3eqZZNqlhF4Ian4j4mumfRloiszE+KoqIyA7 nQdAL0Tbt+TxYyaq/AGrA0enJWIPnQNavRCwRqd+UP6A1YVnWEu61TNpHGeGSM2Nx2ZVEGEL R6sT59Gq6oG6I8+MKfJ8akm3OvIujGp4oJ7MsWhJtydz1myUP5Sp8gfIxnOcR3iutM88Vjvk 4DgzpPthiVjIGbHR+QCrnP/GwmsmVexA+4V3TxzS6CRuIL2exvsp5hmxZyZ1zmRV1QMk0rkb NDzQWuAs1SGJ81ZV40A9b0RaT5y3emQ6iYOGB8hG5wFQ7ND2LXn8cMjBUaXaG6jnjUjrB2ep HpmzVFXsACl0ZgB9DrSfOQN1SOXIM0RqrrzHESpnoEaNAyxxvqkqGqg78GwVAs9xlnSrA++D qK4GSiWOxZB4H8Q8ozbPZMoloc8BstHZHBQ7pDXoc4iNA3m+L7WlOtlp3xJKG6j5jYg9O+Wb LpnO76DPAZLpXAFqHGg/Uy7pkUq7lNDVQD1vRFqvlIG6ZDrjgxoHSKBzBWhvoP1A2aVHIp2K Q0UD9bwRaT1STuqS6RwQ2hsgjdYf0NXQ9vdGJxYDeTyzpTrZaZdyIL3mnbIr+4zYs9PeBDQ8 2K/RV1HjAMm0RoE+B9rPka3OkT3LtH8BzQyUqrST+U7EnkqZLLQ3ZmJ9jXTCCBUNrXs7aIaF GodavfGu8VCq+xpplzKprgY8eyPia6T81yXTmSPUOEAanTRAnwO+OoTm7uGZ7v1MdtqlhNIG an4jYuFOWbNLpnNJ6HOAJDqNsETaT3TOMZDuWeI5R1U0UKrw2LAVygjtM2JPof0LqHqwX6Ov kXY0oLShdRvS228HzfgDeTyzpbqvMXEsxMLx8kbE10h7HFDjmInxVfU5QBqttKDYAV8r5wCN d42HUp1stEsJpQ3U/EbEno32QaDGMRPra6GzS+hqoO7E87tHOE+wz3RfZ1JolxLaG6j5jYiF hXZGoM8xE+t9oNNMKG1o3Yb09lWfQ6225PHMluq+Bh4JDBE/As8wLVBeb9U4YPVGZ5fQ1YAf lef3WjkrsKT7UXkWUhUN1LPxSGCJWEg5u9XeAMu0nwIVDdSdeO6uiWf8yru9Q6lOCu1SQkUD Nb8RsafQDguUNmZifQ205wIVDW3NIzzj22cez2aiChnwlb8weyfia6BdGChtzMT4qtobIJXO DKCiAV8rnTB6ZOPoNERq3njUV+0NtnC0OtN5IvQwUHfkOVdVNPALRc7HbalOMkenIdJW5hG9 ZM7HS57OCqGZAbLzXGlIbz/vPAtb8lhtS3U/AkenIeJH4LG58K6xVcgAa5xZq9YFrHYIz7D2 me7HTBpHniHyzhrtsEBFg20e/cicNV8nDWOfVWULtB9ph8Ujmc7vBtLrybTnYp9RC2cy57+q fgGy03kAtC60NUseqx1ycAylg+PslUjrB2e7HpnO76B1AVLozADKFmi/cCbrkMZxZojU3HhM TY0zWaNjAZY4b1VFCtQdOW+1pNs4k8RRZYjUnHjXIyXOSY1GhTLVqADZeNWi+hPaftx4RrPk sdqW6uSgfcuB9JoP3hkxz6jNM5mzS1WtACl0EgeNCrRWOHN0SOVdyth4J/OVSOuV802PTKd1 0KgACXRCAEUKtB84l3RIojNwaEugnjcirSfOQD0ynehBkQJkoxMC6E9o+5Y8fjiE791CSQL1 vBFp/eB80yH7nG+q/gRI5vVHyHTSAP0JWJ05u7SlOqm8Sxn4bm4KlfcvzDNiT+W9iVA5AzWK FGCJvquGkgTqDjwPhsCzpyXds8D7F6obgVKJdzJfidiTOEv1yPSlNRQpQDY6V4BGhbQPRQqx eiC3Z0OpTviWLbQlUPMbEXt2ymRdMp0eQpECJNNJAzQq0L5DEvuRKZP1CN/NhdoEan4jYmGl /Ncl0wkjNCpAAp1GWNLb3w865xhI9yzQ/gW0JeAr39+NR6Tczj4j9kTav4DWBfs1+KqqFSCN 1kPQsYCvjeb3gTye2VKd7LRLCf0J1PxGxJ6d9jigUTET62uhk0qoTaDuHLj9dLDVvGs8lOqE 7+ZCfwI1vxGxp9AeBzQqZvKdsqVZMc64S7NiIkuzwnq2NCu+SsSepVnhk6VZIWRpVoxWL82K wY+lWbE0KwayNCuo7y/NCiJLs2JsfWlW0HfVS7NijIalWTFG3tKsGHv+0qwYI29pVnB0Ls2K MRqWZgWTpVkx+Lo0K4ZYWJoVXyXi69KsGLxfmhVLs2LwY2lWfI2Ir0uzgnrx0qygepZmBc2e S7Ni7PtLs2KMmKVZwRGzNCvGb0mXZgWRpVnxNSKtR76rsTQrOBaXZsUYDUuzgsnSrBg8W5oV o69Ls+JrROxZmhWjr0uzgqJzaVaMkbc0K8aoWpoVHFVLs2KMqqVZMUb+0qxYmhVD+0uzYrRx aVZQfCzNijEalmbFGFVLs2LMN5dmBZOlWbGPvi7NirHupVkx+ro0K0by/4dmxfcffvLhOPKX ujejWqFEVSuua15534z+hCHdgmO/TCo+kVLngLPt1dYsRLUltJQqUoDI18baukO0FPnlke+N r6JjASLzIHyVWc+QSjZ6pJGvqFmJ5DIoJd8WG1LZHodIKfLLI9Z7UbYAkXkQdcus55Gz8+1W 2QJW6zMOEe+1LSWSuaCU5EQg8kUy7JmJliJPPWLfh2hdKFGNCq3bI0386DZ6RPt593UmqmMB X+WLZHj2RtQLqYf8GnxVPQyQminKPZIoXj2SKe4dsvFooVoXhvA45JFI/Rw1T8R6LwoZIHHn uh2ysY0O2SnuHZJ5tFD1C0N4HPJIo16NmidivRfNDCWqdaF1v5Ie92lPZDWeEV9nosoW8DXw aKGaGfDVIZGiHDVPxHivKhogNVBUOURmWPg6Ey2l3s+k8digKhpo642oF42i3ChtgInSBkis FNMeKRSdHqkU0w7JPDao0gbaeiPqRWLvocahTNU4QHbOExyycb7hEC0lnjnk4JFA1TjQ1htR Lzby3ih2gIliB0jhrOCV9AhWDQ9Yrc+oZzNpHPeq2IG23oh6kdh7qHqAiaoHSEwUH6rYAYve iPih9ShJHNNvRN9i5tHCPKNezGSb4lWVP0C2jeJDVT3UolfSPUM9Sg6OaVX+QFtvRG0uFJ1G HQSs8jpD1UFQd+Ec4JWIH4VXFar8gVKN4/6VqM28qjAKImCJ1xCqIIK6A8/vr0T8CLxiUHUQ lEoc5a9EbeYVg1EZEQaVEZCtjD0dCiJi0Tt5/DD1KDkCl3ohPfKgRAJ78IzYPJN9yv2hRAKS j7HvQ2UEFr0R8UzrUVIbl3LIxq07hHJ/lxSORWiTgIQyRgN0R2DRGxHPtB4lKXIphyRu3SGU 6btkyvShVgLSjjE+oESiFr2S7hnqUbI3LuWQjVt3COX1LpnyeuiXgGRaL0KJxJA8Zt8uKRTB qFlJ5bh/IxLBqnECe/CM+jWTKa+HxglIoH0rqJUoUUUTtXEmKKW+BpqFoE2CUg7hEcUjlOm7 pE0xraonII32raBfYgjlAC6hvN7UrGTnscEjPMZ4hHJ/l6QpylUHBSTTvhU0TmDRGxHPMu1b Qb8EpRzCY4xHKPd3yTZFuSqjKFFlFK1bNU4MqRTTHmkU5ahZvY88NqjqiUMkylU9Bd5HHocM UU9pxWDVU+C9qKeANFpTQgfFEM4uPELrA1Ozko1HC1VGMYTHIY/QvpWpeSLWe9FTAUm0yoQy iiGcb3hkY18Tz4GqeoJShfa2oKeC1h1CqwpT80Ss96KwokQVVrRuVUbxSO+f9eCcBM84pHuP tvR9RB5RPMIjk0doLeIRaK7Ae9FcAak7xZlHNoppj+w0Njhk4xFF9VQcou9+49HLPDMT9ZTW NFaXBazQ/hf0VFC3Qzhv8QivYBxSeERRzRVDeKzyCO1/mZonYr0PtCMGhRWt2yOct3iE1zQz UT0V+Bo2jrLAY5VHaEfM1DwR471qt4BUWhlDc8UjvX+WypkMnnGIvI9Ku2ZQWEGpjccY1W6B PQ6hXTNT80Ts+xA1F5BEJ2ceiXQC55FEO2seyTyiqJoL2noj6sVGcW8UX8BE8UWJKrVo3R7h TMYjvO6Ziaq5wNfAY8wrUS943WNUYeBZ43WPqrnAM4dwluIRXuU4pPHYoKowaOuNqBe8yjHK MWCZ9tqg+IK630iP6Rw5S8Ez6tlMMo8EqgpjCI8xHqHdN1PzRIz3qiUDstOpGHRi1KJX0j1D PUoOjnLVkoEfb0RtprN4qzcD1ujkHXoz8KxwLvFKxI/CKxjVkkGpxiPBK1Gbeb1iNGnAEq9O VEsGdTuE8wSP8FrEIZljWjVp0NYbEZszr06Mbo0y1a0B2Xg2fyU9OuPGeQKeEc8ccnBMq24N 2noj6gWvRYy2DVjllYdq26DuwmvlVyJ+FN5rU5UalHoh+hYbjw3mGbF5JnVeVaj+DUjkfTTV toFFb0Q8i7yzpro1KOUQHhs8wisGj0wn5lDEAdl41yxsvOp9Jd0z1KPk4Jj2CI8NHuH1gUfm 9YFq5IAUOhWD/g0seiPiWeF9NNW/QanKI8ErUZt5NWB0dMAS5/6qo4O6A8/LIfBs7hHO61Gz ksRR/kYkXlVrB/Yk3v/yyJTpQ2sHZKP9L6jmgDSa8T2yUV5valayU9x75Ahsz0x2yv1dMp2h Q30HJNP+F5R1YNEbEc8y7YhBNQelHFK5dYdQ7u+S6VQdejwggXa7oLUDi96IeBZotws6Oig1 kxS49ZlEyv1dMp2zQ6EHpNF6EVo7htAJnEvonN3UrGQvXGqn3S5DekxDxQf27JUt3Gkny7RF vo/vQ1R8QDKtKaHHY0hkqx2S2PtMsxm0dlCq0m4XVHzQukNoxWBqnoj1PtJ5PXR9tO6Nz0Wg 4qM2eoRWDKZm9T7yaOERHnU8QqsKl0wn+FD6AWm0kwWFHo/0/rk1yjfMMw6R99FotwsKPSjl EB6ZPEIrD5dMp/zQ/gFJdN7mEjq3cwmd8nuk8Iiiuj4O0XdfePQyz8xEPaX1itUHAou0/wVd H63bI5SluIRWJw5RFR94HxNHWeSxyiO0/2VqnojxXhWDQBqtcaH9A1I5S3FIo/WKqVkJn3lA DcgQHqs8QjtipuaJWO8LfQkADSHUnTgDMaT3z5Y4k8EzDhHvE+2aQekHpQqPMaohBHscQntk puaJ2PcR6NsAqAFp3R6hczuX0D6aQ1QxCL4GHodeiXpBKyGrPATPNvo2AIpB8MwhnMl4hFY5 Htl4tFDlIbT1RtQLWuVYdSKwTDtrUBVC3Q7hLMUjvKZxSOaxQZWHDOFRxyO0s2Zqnoj1PtBe G3SGtO5X0qO87Jy34BnxdSaqKgRfA48NqlcEXx1Ce22m5okY71XBCKTSORnUieDZGxFfK+3H QZ0IpTYeLV6JWLjRCb5VOQLLdIIPdSLU7RDONzzCaxqHZI57VTlCW29EveA1jVFCUqZKSCA7 5wAe4VzCI7xemYmqHMHXwKPFKxHP+MzDqiWBNV6vqMoRPHsjPV5z4VwCz6ivM2kc5aqWhLbe iHrBqxOjqASWeXWiikqoO/J6+pWIH5F236CNhFIvRN9i5tHCPKNezGReeajqEsjOO2uqqKQW vZLuGepRcnBMe4THBo/wqsIj06k6dJhACp2TQWMJFr0R8azwXptqLKFU45HglajNvIYwWk1g iVcMqtWEuiPP769E/Ii8PlAdJpRKHPevRG3m9YHRc1Kmek4gG68yVZnJEJ7NPcKZPmpWcnBM vxGJTtV8gj0H74h5ZM79VfMJpPCOmOo5waI3Ip4V3iNTrSaUmknjscEhlXN/j0xn6FCBAgm8 /xUDr01fiXgWeEdM1ZtQyiE8NniEc3+PTKfq0IUC2Xi3K2y87nwl3TPUo4SVLVzCo4VHONN3 yD5n+qoUBZJ5vRgynZxBFwo2OoTO0E3NSljZAipQDpEIDqyiYZ+ZiXrKqwGjJgWW6JZLCqyK AH0p2PhGxNfAs1BgHQuX8IjiEV4NeKSvD75TttRZxlXeUmcZ+9VSZxnjfqmzULwudRYmS53F +rrUWYgsdZaxraXOMvi61Fl4tFrqLGN8LHUW8mOps4xtLXUW69lSZ5m+yl7qLONX2UudpY02 LnWW0eqlzjL4utRZqNRSZ/kKWeos+1JnWeosRJY6y/DulzrL6OtSZyGy1FlGstRZRrLUWcYx bqmzfJUsdZalzrLUWca2ljrL4OtSZ+FxZ6mzjPGx1Fm+SsSzpc4yllrqLCNZ6ixEljrLSJY6 y0iWOgt5v9RZljoL2FJnWeos8HWpsyx1FrClzjJ6ttRZRhuXOstg9VJnGSN4qbNQW0udZeif S52Fx6alzjLGx1Jn+SoRz5Y6y9jWUmcZ7VnqLESWOssYr0udpRBZ6iyDjT8edZbvP/zkQ9zP VXE+jD6LElVROUn+Eg+jtGJI71knCV+2rxAtda5D6lhzJ6qZoqVUaQVEvkzW1h1iSg1+eeR7 46vos4BIz4Kv0o8MqWSjRxr5amoWImMBSsk3xoZUtschKDX45RHrveizgEjPQt3Sj1wSzy5q 9FlgtXlmIuI92hIi4wVKyXgBIt8hw56ZmFKDpx6x70P0WZSoiorW7ZGm7T82ekRLdV9noroq 8FXGC3j2SsQL1DP4Nfiq+iwgNVOUeyRRvHokU9w7ZOPRQpVWDOFxyCOR+rmtmYj1XvRZQOLO dTtkYxsdslPcOyTzaKFKK4bwOOSRRr3a1kzEei/6LEpURUXrfidP3Ks+i1ptnum+zkQ1U+Br 4NFC1Vjgq0MiRbmtmYjxXvVZQGqgqHKInKbB15mglHg/k8Zjg2qvoK1XIl40inKjzwIm+iwg sVJMe6RQdHqkUkw7JPPYoNoraOuViBeJvYc+izLVZwHZOU9wyMb5hkNQqnvmkINHAtVeQVuv RLzYyHujzwIm+iwghbOCd/JEsOqzwGo8I57NpHHcq/YK2nol4kVi76HPAib6LCAxUXyo9gos eiPiB+oRkjim30l/i5lHC/uMeDGTbYpX1WcB2TaKD9VeUYteSffM1CPk4JhW7RW09UrE5kLR afRZwCqvM1RXBXUXzgFeifhReFWhuioo1Tju34nYzKsKo88ClngNoboqqDvw/P5KxI/AKwbV VUGpxFH+TsRmXjEYfRZh0GcB2crY06G9Iha9k8cPW4+QI3CpV3JHHvRZYI95pts8k33K/aHP ApKPse9DewUWvRHxDPUIqY1LOWTj1h1Cub9LCsci9FlAQhmjAdorsOiNiGeoR0iKXMohiVt3 CGX6LpkyfeizgLRjjA9or6hFr6R7ZuoRsjcu5ZCNW3cI5fUumfJ66LOAZFovQmnFkDxm3y4p FMGmZiGV4/6dPBGs+iywxzwjfs1kyuuhzwISaN8KSitKVI1FbZyJKSW+BpqFoKKCUg7hEcUj lOm7pE0xrfosII32raC0YgjlAC6hvN7WLGTnscEjPMZ4hHJ/l6QpylWfBSTTvhW0V2DRGxHP Mu1bQUUFpRzCY4xHKPd3yTZFueqzKFEVFa1blVYMqRTTHmkU5aZm8T7y2KC6Ki55olz1WeB9 5HHIEvGUVgxWnwXeiz4LSKM1JZRWDOHswiO0PrA1C9l4tFClFUN4HPII7VsNNROx3os+C0ii VSaUVgzhfMMjG/uaeA5UzRSUKrS3BTUWtO4QWlUMNROx3os+ixLVTNG6K59nDOTpn/XgnMQ+ M5HuvWlL3kfkEcUjPDJ5hNYiHoE+C7wXfRaQulOceWSjmPbITmODQzYeUVRXxSX93W88etln ZiKe0prG6rOAFdr/gooK6nYI5y0e4RWMQwqPKKq0YgiPVR6h/a+hZiLW+0A7YlBR0bo9wnmL R3hNM5MaeERRpRVDeKzyCO2IDTUTMd6rPgtIpZUxdFVc8vTPUjmTsc9MRN5HpV0zaKag1MZj jKqxwB6H0K7ZUDMR+z5EnwUk0cmZRyKdwHkk0c6aRzKPKKq9grZeiXixUdwbfRYw0WdRoioq WrdHOJPxCK97ZlICjxaqvQLPXol4weseo88Czxqve1RFBZ45hLMUj/AqxyGNxwbVXkFbr0S8 4FWO0WcBy7TXBhUV1P1KnpjOkbMU84x4NpPMI4EqrRjCY4xHaPdtqJmI8V71WUB2OhWD9opa 9Eq6Z6YeIQdHuWqvwI9XIjbTWbzVZwFrdPIOXRV4VjiXeCXiR+EVjOqqoFTjkeCdiM28XjH6 LGCJVyeqooK6HcJ5gkd4LeKQzDGt2ito65V0mzOvTow+izLVZwHZeDZ/J090xo3zBPNM98wh B8e0aq+grVciXvBaxOizgFVeeaiuCuouvFZ+JeJH4b02VVFBqVfS32LjscE+022eSZ1XFarP AhJ5H021V2DRGxHPIu+sqYoKSjmExwaP8IrBI9OJOfRZQDbeNVPtFbXolXTPTD1CDo5pj/DY 4BFeH3hkXh+oPgtIoVMxaK/AojcinhXeRwuVY1q1V9DWKxGbeTVg9FnAEuf+qqKCugPPyyHw bO4RzutNzUISR/k7eeJV9VlgT+L9L49MmT70WUA22v+C0gpIoxnfIxvl9bZmITvFvUeOwPbM ZKfc3yXTGTr0WUAy7X9BewUWvRHxLNOOGFRUUMohlVt3COX+LplO1aHPAhJotwvaK7DojYhn gXa7oKKCUjNJgVufSaTc3yXTOTv0WUAarRehtGIIncC5hM7Zbc1C9sKldtrtGsgd09BngT17 ZQt32ska2hp8H9+H6LOAZFpTQmnFkMhWOySx95lmM2imoFSl3S6osaB1h9CKYaiZiPU+0nk9 VFS07o3PRaDGojZ6hFYMtmbxPvJo4REedTxCqwqXTCf40GcBabSTBV0Vlzz9c2uUbwzPTETe R6PdLqiooJRDeGTyCK08XDKd8kOfBSTReZtL6NzOJXTK75HCI4rqqrikv/vCo5d9ZibiKa1X rD4LWKT9L6ioaN0eoSzFJbQ6ccgWeURRpRVDeKzyCO1/DTUTMd6rPgtIozUulFZAKmcpDmm0 XrE1C+EzDyitGMJjlUdoR2yomYj1vtCXANBMQd2JMxBLnv7ZEmcy9pmJiPeJds2gmYJShceY Vnj08gjtkQ01E7HvI9C3AVBR0bo9Qud2LqF9NIe0wCOKaq/As1ciXtBKyOqzwLONvg2Aigo8 cwhnMh6hVY5HNh4tVHsFbb0S8YJWOVafBSzTzhpUVFC3QzhL8QivaRySeWxQpRVDeNTxCO2s DTUTsd4H2muDiorW/U6eKC875y3mme7rTGrgsUGVVgzhUccjtNc21EzEeK/6LCCVzsmgvQLP 3oj4Wmk/DroqKLXxaPFOuoUbneBbfRawTCf4UFFB3Q7hfMMjvKZxSOa4V+0VtPVKxAte0xh9 FmWqzwKycw7gEc4lPMLrlZmUwHGv2ivw7JV0z/jMw+qzgDVer6iKCjx7JU+85sK5hHlGfJ1J 4yhX7RW09UrEC16dGH0WsMyrE9VVQd2R19OvRPyItPsGFRWUeiX9LWYeLewz4sVM5pWH6rOA 7LyzptoratEr6Z6ZeoQcHNMe4bHBI7yq8Mh0qg59FpBC52TQXoFFb0Q8K7zXlhrHdGo8ErwT sZnXEEafBSzxikF1VVB35Pn9lYgfkdcHKXEEq/YK2nolYjOvD4w+izLVZwHZeJWpSiuG8Gzu Ec70Tc1CDo7pd/JEZzx4tLDPiF8zmXN/1WcBKbwjptorsOiNiGeF98hURQWlZtJ4bHBI5dzf I9MZOvRZQALvf8XAa9NXIp4F3hGLiWPaIzw2eIRzf49Mp+rQZwHZeLcrbLzufCXdM1OPEFa2 cAmPFh7hTN8h+5zpqz4LSOb1Ysh0cgY1FtjoEDpDtzULYWUL6Kq45IngwCoawzMzEU95NWD0 WcAS3XKBrgrqZi2FdyK+Bp6FAutYuIRHFI/wasAjfX3wnbKlzjKu8pY6y9ivljrLGPdLnYXi damzMFnqLNbXpc5CZKmzjG0tdZbB16XOwqPVUmcZ42Ops5AfS51lbGups1jPljrL9FX2UmcZ v8pe6ixttHGps4xWL3WWwdelzkKlljrLV8lSZ1nqLEudZSRLnWV490udZfR1qbMQWeosI1nq LCNZ6izjGLfUWb5OljrLUmdZ6ixDW0udZfB1qbPwuLPUWcb4WOosXyXi2VJnGUstdZaRLHUW IkudZSRLnWUkS52FvF/qLEudBWypsyx1Fvi61FmWOgvYUmcZPVvqLKONS51lsHqps4wRvNRZ qK2lzjL0z6XOwmPTUmcZ42Ops3yViGdLnWVsa6mzjPYsdRYiS51ljNelzlKILHWWwcYfjzrL 9x9+8qGdL7DuzeizKFFdlXa+wLxvRnulnS8w7vs/QvL5E5WhnvRl26vRZ1GimilaSpVWtGZV Y1F7DFEvtNTo1+UtPNv6CQ+I9BH4Kn0Enr0R8RX1iK/SQ0Ek8lFqK1JKapavjmEPiHpRyHuj vQIm2isg0iNQN4i0nwJbhGfEahDxTPojiEQ+Sknko2b5ohj2gKgXB3sPXRUw0VVRouonWrdq pmj7r6Rbberpns1E9VDgq8Q5fAVRm2ei8xD82AJFp2qdwDM584Ifb0Q8Qz3i2Uw2jmnVQ0HN W6IIMkS9iBSdRjMFTDRTQOLOdcsJF9p/I2I16hHPZpI5plX9BDXnjSLIEPWisfdQSAEThRQl qmOidRvS21c9FEMyxeJMVKMEngWOe1U/gWcganNkX6F+Aj9E/QSkBopFVTaBH2+kW23qEV9n 0jiCVdkENYOozTOpUyyq1glIrBSLqmOC1t6I2Ih6xI+ZZI5g1TFBzSBq80z0Oy1lqmwCsvOc q6ol2tor6TaaerofDjk4XlW1BDWDqM0zadOYojomIIVnWEOktcLzsnlGrJ5JSxRnqkiCekDU wpnEabxQjRKQGChiDJH2QcTGmChiVDcE9cwkcwSbZ9TCmWxTDKn+CMjGc6Uh3Q9DutWqNgJy cFSpkghqBlF7ZpKm+FBtEZDC86Ah0n7h/FeVREAqR4yqhKDmxtmuQ+qc7apuCEjgGc0QaT9w JqsqISCpcKnEMWSI2jOTKW+FJgjIlsb+aMnTviWPjVAAATkC1+OQNPZ0+4zYM5N9ykmh9wGS aSayRPzIO1udj7EXQYMDpWrjmus2zkyWqIWUgVotD7BEGShUOdBaoJWNJWJ1KGO/gr4GSqXI NSfKLi1RCyN7lqbsEjodII1mGUu6RYZ0q1WVA2RvXGpvXPNOmaMlaiFljlaDA6xS5gjtDNSd ad55J2I16hHPMo27UMpAPQ4pFEPmGfViJlMuCcUNkEAzEdQ0tP1XIr6GwJ4FGq2hi4FSkSNY 9TXga6SdCFtq9GvwVfU1QBpll9DOgGdvpFtt6umeqb4GyM4RbIjUvBeKRUPUC8o3rZoGmKhp gGSa9SwRi3JgqzPtREDhAqUKR7kqZcCPQrsMttRo8+iHKGUoUYULrVtVMLT9V9KtNvV0z1Qp A75GjmBVuICvDmkcQXhG/ZpJmqJTdTFAGs+eqnkBX9+IeN8oS4UuBsjGMa0KF6h5p51MS8Rm lBr9Gn0VFQyQxDOsKlyg/TciVqeNPUs856gyBUoVym2heQF7Cs8nptTo1+iraF4oqQfPwob0 9uvBc7d5pltdef8XChfwNXLcGyK+RtrJtES84D1iq2cBz7ZCEayqE/AVO7ni2RsRX1GP+DqT jeNedShQs0Nob9M+o37NpEwRrOoVIInn7pp4fn8l4kfi7NshheNedShQc6HdTkvUi0QRbLQq wALtcUBRQusuO8/vr6Rbberpns2kBo57VZ2Ar2HnKAs8C5lSo1+Dr6pMAVJ57jZEPKs845tn xNfKWbzqUIBsnNeXjUcLVZ2APRvtg9hSo1+jr6I6AZLoXAGKEmj/jYjViXZPPJI57lVRAjVn 2hlxSZuiUzUmlKgShHqm+hHa2ivpNpp6uh8zKYFjWvUj4BmI2jwT/RoGfjTO61X3AZ5Vns1f iXhWOYt3SOMIVrUI1Nw4i/fInMWrfgRI5HnZEGkt8mxunhGrZ5I5Z1fdB9STabfTErWZs3ij DaFMtSFAdjpFsKRbZEi3WpUgQA6OPFV5gB+B91xmYnQfwBqdDELBAVYXOjOwRGwsnH2rOgNK Nc72DFF7ZjKd+kHTASTyPJgiz5WvRGyMnEc7JHNUqV4Das6cRzskzXm0KjiAbDzrGdJbixvP leaZbrVDDjrRgxYD6jk4R/bInCOrOgNI4R0WQ6T9wtmuajGANI4qj9BpnX1G7JlJnfNfVV4A CTx/GSJ+BM5kVWcBJHFUGSI1J85kDVELOZM1qgrKVFUBZOPZypBuUZj2iFVDAeTgGDJEaj44 Og1RCzlLNYoJYJWz1JB5bjJELJr2iFUfAaRuXKpynBmi9sxkzjdVDQEk8LwTAs9Nr0RsDJxd qhoCSOLI8wjvkZpn1IuZTPkmtA9ANso3oWsg7b+Tx1dbz+MZtA9AdopFS6Tmg/ZILVEvKAO1 SgdglU7roFmA1jKtbCwRqzPtcUB9AKVq4Zor7X9aohYW9qxO53dQMQAJNKNZIhbxjjA0C0Di waXiwTUnOku3RC082LM4nehBoQCk0bkC1Ae0/VfSrTb1dM9UoQBkL1xqp51Ml9COqH1G/ZrJ lIFCjwAkJ647R27/jYgfObGvmWYGaASgVKUsFeoDsKfSqG9LjX6NvkY6PYRqgNa9HTSfvpNu 9cb7yFAfgK+RY9oQ8TXS/qcl6kVj7+N0wgitAZBG86kl4lmjWdg+I77yrjGUBUB2jntDpOad 9j8tUS8o/7U6AmCFTiFx2x91J5qX34lYnehc0iOF417v/6Nmh9COqH1G/ZrJdHYJ1QAlerdf 624Hzd3vpPth6um+zmSLHPd6/x++xsJRFnmGMaVGvwZfVSMApPG83CrP3a9EfG2Ua0MjAGTj uG8b7WRCEQD2bDwLmVKjX6Ovhc4ucW8fdSfa48D9f0NoxWaJeJZoHwR38lGq8GjRCu1/WqJe ZPa+TGeXuO2vRO/ka916k1/bfyXdalNP92wmLXDc601++BroNNMl02km7vaDVJ679d4+/Hgj 4lmlnN0jG8e03ttHzRudS7pkOqnETX6QxDN1TTybvxKxMXGG7pDMEax38lFzof1PS8Tmwlm8 ubcPFmiHBbfrtW5Devtl5/ndPNP9mEkNnMXrfXt4Fmj/0xK1mfN6cycffjTac8Htelhd6czR EvGj0i4Mbs6j1MZZoyHS+kzatMOC+/YgkedTvUuP1t6I2Bg5Q3dI5ljUu/SoOdMOi0um00Pc rgfZefbMO8+wr6TbaOrpfsykBI5FvTkPzwJn3zMxd+nBGmffeuMdnhVe5+XCM6x5RvyYSeNc W2/Fo57GmbVH5sxa78mDRNpzsUTaj5wj6614kMyR5xE647PPqIUzmbNmvQMPsvGsZ0j3w5Bu td54Bzk4qgyRmg+OV0PUQs5/zf12sMb5byo8xxkiFvEeMW6zgzSOocRfhlmi9sxkzmT17jpI 5PnLEGmfd4RxUx0k7VwqcVQZovbMZM5J9V46yMYzUdx4tnol3UZTT/dD76WDHBxnHqE9UvuM ejGTOSfVW+gghecvQ8SPwtml3jkHqRxVhkjNjfc/DVELOQM1N8zBEp3W4a44Wgu8som8I4z7 5CCJo8oQqTnR6bolaiHnm+b2uDK9PQ6y8dxkSLcoTLu9YeP9i8C3bC2Rmvn+riViz7QjbG6G g1XOJUOm0zrc+kb7b0SsznRah5vhIJUjT290o2aH8I6oeUb9msmcb+o9cJDAfSbw3U9LxI/A o3XgO7WWSM2J9zYNUQs5A9U73t8pWze8qe51w5ssWje8bXSuG94UC+uG99g/1w3vdcN7aG3d 8B78WDe8xxhaN7zXDe+h1LrhTV8Srxve49d764b3+M3huuG9bnjb9tcN79HqdcObal43vMcI Wje8h+hcN7zXDe/B17pueA/trxveQyyuG95jBK8b3mN0rBvetAu0bnhTNKwb3mOpdcN73fC2 ra0b3kzWDe/Rj3XDm6xeN7yJrBvexrN1w3vd8B6sXje8ydd1w3uIznXDe4zgdcN7jNd1w5sj eN3wprrXDe+vEbkdu254j6XWDe/Rs3XDmyJv3fAeY2jd8KY+vG5401iwbniP8bFueDNZN7y/ SrqN64Y31bxueJMf64b3V4lYvW54j6V+3ze8r7/i/V8/5HpmN8d1h7r0GTS3M9c25FdK4i53 3qQUyPcf/sPHX19Plutvjp9l+y4WiOw1nSRff7v8JLvWL6T3gpPE6++SG6J2aimy3JYyJF1/ u/wkG7dunhFStfXBC498b1gM+uYeUmRnSev2SCKrQcSzIrtY8FX2keCr7DXBD4cEbWuw2SPG s36z3HomO0vwYyZ1IxtB1DPZswKRXSOUkp0l1OyQqm0NNnvEeibfNYIk7g8l4dcXUrT9p1/p vXZYrc+oZzORfSTU7JCkbQ02e8R6Jl8xKslHpL6fj0C+ZvkeUf0AEatRSv0IHMEe2SiG9F77 TIwfWfaaQGqjfp1rZc/k60P4oUT9qDSKnW1lrschiSLmhVg/8kYxlFOiXpxTYM/iQTEEolZr KSWy24NShaPTIXmjiHkh1rOQKIbSzr9+2hu1ZskTQ2kvZDWeEc9mkgNHp0cK9TS9sz4T41m/ 7W09q9wfUk3sq3xHCKtnsnHkOaQdFDF6+3wm1mr5shAk7tSvUuR5MEWePUHU6sjjd8oceR4p FB9613wmxo8o3xGC7IV6Udx5jos7z4wgYjVKqR+BI28m8TgoGvRm+UysH/JlIUjl3zoWntEs eeIjFp4Z8Yx6NpPGkfdOBps9Yj2TXSOQyL9+jIV9le8IYeNM5BtB+GpIfx+ZI88+M5PBZo8Y z/ptb+NZ2Lk/hI0z2bBxTuqQgyPPI436ld4+n4m1unEGGgr/1qFwBhoKZ5cOaRxnHonUZ/T2 +Uys1YmzyxD5dwyRZ6sQOHN0SOKoeieDPR6B1XL/+wdDNsocXVLHnu6RI499fyB33z9J4ZoP yhwHMtjsEetZ3ca+n49Cv/VJKJc8CWWFHqn7OMec5OB6HEKjLG6oz8T6kShzPBNX+vVP0tiz QFmhR1Ie55iTFK7HITSm4ob6TIwf+06Z47nG59963yiXPAllhR45Apeayb6PmRLuo8/EWi07 QiCZskKXYLx63iyIWp1pL+Bsq1LEWPJEzF45Fu0zQihPfCPW13hQxOyB8kSXRLY6RPYs0F5A 3lOgGNoTx6JHaCTG7fOZGM/6vW3j2dYol3QJ5ZKGiB9bo1zybKtSVG07R6dHaLTGXfOZWM/k G0GQzP1hy5RvngQj4dOv9GY5rM6UXXqkcrx6hNb5uH0+E+tZpJV/3gLlmw7RW+PqB4hY3Q7a Czjbop26gfQ3FDnK7TNCKAN9I8bXfkvb+NoaZaAu4RkWRH1ttF9wtkU7dSfhmPYIZaBvxHpm 9mE7yZSBeiTxDNt4n/QktINwtkU7dSfhmPYIZalvxHom3/YpqQf3h3pQ3nqSQpGnN8LVajwj ns2kRY5pj9DuAG6Nz8R41u9bW88arVFOEtlXs3Pa/VCifjSeGep2cD0Oodz2jVg/Cu0g5Jpo jXISnk9r4lkYRK1OPA/UQjt1uRaOV49wbvtCrGeB9hRyOTi3LbxPmsvBc27hPVBTSj0LB/fP yPHqkMDZ7gsxnvVb0dazyv2h8M7pQJ6oKpVnYTyjvs5k43j1SKGoKhtnxEqsZ/JNHkji1U9J nBEXs7va/VCiVice9Uvh6PQI7SDglvZMrB+BM+Jrb33saZl3Tk/CMyyIWI1S6kfg6PQI7Sng TvZMjB+5cbabK691Mu+T5lx59gRRPyrtO+S8cSx6hHPbzDunINaPTPsOOSf+rTPvnA7kiZgc efbEM+rHTDLH4jsZbPaI9SzQqVZOO//6aedsN+10PuWQHDjOPMK7DDlwJqvEWN1vPFurK//W iXdOcyqckzqkcVR5hPcUEu+KglirM2egKfLvmHhXNKfI2aVDMseQR3gHIfGOJ4ixOh6cXcad f8fIO54Defp+3HiOwzPih0MOjqp3MtjsEetZo9OoHAv/1rFwvhkL7zI4pBWaUSzp76NxVNln ZjLY7BHrWeLsMkbuDzFyvhkjZ44OSXTqm2PmOHNI4lE28l4qiPGj33g2foSNf/2wcb4ZNs4c HXJwLhkOjjyP8H5BmHZOlVg/KueSofBvHaad01A4T3RI48h7J4M9HrFWp0LxEQLniR6hsydD 1OrA+wUh8W6eJU/EhMSxaJ+ZyeCFR+Cr3Gb+wZCNMkeXUOZoSPfsJJQ5nm3Rbl46jsQ1O4RG a9zAnon1rNL5VDoy5ZIuoTzRI5X27tJRN67HITQ24wb2TKwfiU6s0hHo10+XHuw+thYoT/RI SlzKIbSqx33rmRir+01lY/W+UebokUZfZRgiVu8brfzTvtO+3EDuGDrJwW3tdNKB29XshUes r5XOudKeKZd0SWGrc2HPMu0OnG3RvlzaK0enRyjffCPWs0jnXGkPlG86RO9Aq40g6keg3YG0 R9qXS3vk6PQI5aRvxHjW7xwbz7bG/WFrlKWmzeyTPv1K70DDV/7y0yM7x6tHaOWPe9IzsZ4V 2gtIW6a8NW05sa9mn7T7kSknNaWUVNqXG0h/Q5Wj3D7TSaFM9o1YXyPtF6R2UCZ7Epo9Uzto zjVEPEMp9TVW7tWRY9ojlMm+EeNZvz1sPWuUybqEZ9jGu6KpNdpTSG2nvbvUdo5ph2yU274R 61mh87LUMveHlijbTc3srj79qiWehfGMejaTwjHtEdpBwP3mmVjPAp2XpXrQWifVg/LfVA/6 LtYQsRql1I/IEewRyn9xd3kmxo9+D9j60WhlkyrvnKZaeRYGUT8qzwN14+j0COW2uKk8E+tH oX2HVBOtbFLlfdKT8AxbeQ/UlFJSOG/1CGeyL8T6EWgnIpWDf+vC+6QDeSKm7DzD4hnxYyY1 cCx6hL53wL3kmRjP+q1f61nlX79UznZLpRMrj2wcZx6hPQXcQp6JtTpzblsS/9aF90lTSZy3 OiRzVHmEdhBww3gm1urAWWreeY2SeQ/0JDzrgYjVKKV+BI4qj9AOAu4Tz8T40W/rWj8q/7KZ d0UH8kRDrjzr4Rn1bCaN4+ydDDZ7xHqW6Xwq5ci/fo6cpeZIuwweyfTd+ED6+8gcZ/aZmQw2 e8R41u/4Gs/Szv0h8e5qSjvnmzPJgTPQHDjyPMI7CIn3UkGsH43zzVT410+8l3oSziUd0jjy PML7BYn3SUGs1YlzyRT5l028T5pS5DzRIZnj7J0M9njEWN1v9Bqr4855okM2OmkyRKyOG+8p xIP27gbyxEc8OPLsMzMZvPCI9bXRaVSKhTNHj3BW6JDGO3WxcZx5hEfiyHupINaPROdTKUbu DzFyLhkDZ4UO4fuOKfKdSJfwuBt5nxTE+NHv+Bo/wsa/ddg4lwwbZ4UOOTjOPMLr/DDtgSqx Vlf6CjaFwnmiQzKdTxmiVhfeCwiVd+oseSIm8H3H4RkhnDm+EOtrojOsFAJnjh7heRBEPQu8 FxAS79QFvu/oEs4uXwg8i8dOZ1jx2Ci7dAnNg4Z0P05CewFnW7RTFw++7+iRncZvsdkj1rNK p1rxyNQf4pEpJ42H2Tm9+9VJKludKQP1CN+AdAmt88Vmj1jPIq3847UjP/T9eITEvgb6LtYQ tTrQXkA8Eu3UDaS/Ib43OTzTSaQs9Y0YX/eddgfi3ihLdQnNsIaIZ3uj/YK477RTF/d945od QlnqG/lO2bqJP/aQdROf/Fg38anmdRN/nOHWTXyKoXUTfyTrJj5HzLqJP0bMuolPNa+b+Mkl 6ya+2Lhu4keXrJv4Uve6iT/6sW7is9XrJv5Yt0PWTfyBrJv4RNZNfJesm/hS97qJP1i9buIz WTfxybN1E/+rZN3EXzfx10388bdeN/FHsm7iczSsm/hj31838anmdROfImbdxB/nuHUTn9pa N/GTS9ZNfCXrJr6JoXUTnyJm3cRfN/FHsm7iW8/WTXyqed3E98m6ia9k3cQf6lk38X2ybuKL jesm/mj1uolP0bBu4o/xsW7ij71o3cRfN/EHP9ZNfCLrJv7YZ9dNfLI6cOa4buJTzesmvk/W TXwhP+ab+N9/+MmHf/vhv36I4eP1v/5/f/PDxz/59sP/+u/S8fH05Poy/uO3332IzyMf78vE 23UbN3+JZ9vf/vDhP376s8/fnNNPOo790w+f65etnIviT7/4/E36Uq/z7E+//fxN+NK2mNL2 6Zefw5cat7MD2id+/flMwuo5sn/6m8/fxPqlnvnup3/4fPXk3Oqnj5+/2b5sdd/qpz/9fEZJ qGX/9FMU/9XZasqp/yOdLX36zyjSK8+7bfzj57Tt/+nb/+PD6eS51sofvzmn63OwTx+//fnp 0p9+/qZ+uZzfPv1Gbfs1iv/d52/Ot3mOK3nw7jd4Aqa41rvO/93n/cu1J5q+9vbU6uuUfju2 x+p8dpjb6n/zOX7ZQtyvd3vlGvWs6W/vmlLL9Xy3Ar93f4WfqyG/+FzPEeL8Qa+2/uzbs5uc P/8ZX9tRzh708be//HAvSK6pLm098SnHubC7U2PZtAKRy18oNZNNk5GTHX350Os+/1Xv6SfJ xQA8I4M0l7qkJgar/92//lFYfYXlE4qnwc8/zvf9tTCN28f2pdYSig3TfOa18W757N57D9Oz T5+/f97O3/83n9vVe4/t7Hz419WZ6jnwnD+/wCsc05fWYjk7Z/5yDU/HGVvpy+nAwdXcneib s8Q5wOzHpz/XAv/75y3F1Z1Wd/r/qjuVdCZT9zZvKfLDlPhsvslCEUSuPKDUTIpuLpQj54fV nvqU41xoPxuUfWLHM3J0xqW87vRjsPr30Z1KLtevd20xn78sdadQv9Kd5F+/eDrWkfLZnc40 tmyxcW/at3hNxvrgVbptddvO/pS/nCW2Qv3pzBpDWv1p9ac/TH867TpTuOMy+MulTrXfP5CH X7w/U/LTwaPFNAzO4cxU74PRc3Zo3fs//3wu50o7PfnutPrLdQngTB6FncNw+5JDzPHKouWf v7rf2FZDO/95LX/ODnC9Hfnvv73+ef4jVVPVz0+vY9jy83pOr/ejnIXOxe3Rs08pjjK/NmXk X3/nmGlsQ5FeYymf/v5u8DohNg12I88u8el/+nxtyIcQ//GsI8i3gOVa4957GHKzGUR2tFBq Jvga7wys9uyehn7qX679hHvvQ74o0Gd0v4hLvWYd/4Kt/v1kHeUMsrvWs0P0jv0XGre/8bKK nyr8uztxOMqZf5whfC53jqNKCF9JCQaAjxq4f/3piubr22Gb3Wh+Yqr8h88pfzmXT9unP7pK t7xFU89PzmXeGdjnGhbjyG+fRGbbdpMP/WIytxxPjXeZvzzrOe6+/N/0wR/O9do5zuZz6fYz HsP2crVzuXDV80Xr8f711597eJQVHis8Vnj87uFRrrOiDft5P3yo1w56vknfXwWRL/9QSr4O 5HrujhZb3weULy7KOe8+e3zy3T6e2VH3UMpNCn8EVv9eksIzr43PHrEND03hpvi4sjkbH0MC uB3buMytta2OsTrGe8e4hqza9o9//+H6YLXu7XTl6BNHvM6H7319uWH0k+kn0VLb3s/84nWH 6/oBNlGpMy/kd3sP7bJ5v45Vji9bs/PHOeM9Q+/1j1+CjJPDxX6O/2j9bu1cL95VP2dhlzDi 2czHa87dWvv421+c/e93s/a6zXY8veNaWT3W/p+fvznOued8x5/+y7SeC9WdxJ713BGK+a/4 TTHjPBNFauleQV0/ZLDzp5lUf2Fawfb82YvPd/oXH779V//xXBA+s2Uqn759rDt/v9/BJnUI RuFB2PQrXapijvyISfm/OL79BnV7/xmL3184hv0UPUKm73qYuf/jkGP0iv6xt65pwHcobV+7 rNCfDprNS+9dbwXaCrQVaH/wQDt7CoLoWixeX+pfdzZb7cuuVJ+ziJP073xOUh+dHZn0T/Lc 9FSNpXRpzmw36WfiJ6mP7pB8kXyS9Dwjt3xTPVOFR3UpSj1X3N2kST2tPvYc/YuAk+SuZlWl 5nYv56CBZUiRek7rb+0q+RocRL7PQKnCrW8VfsWHNK2n+77Jzfnz/WyPcpae8Fx6SMet/tbT pPsmw03k1sPZo+JD5H5iOpdgd1t71lK1PyPfPKXWej2iE5va3tuSG5xpC489u6gdpC31muXW a7p0x+5nZEmctq23JQvwM296esIu94/uG27Hrago9ezPeddJDiH9dz9kQ/lceIZH81K+KE9H emxWjcX7/uldSja007E/v8Wh98NC7M/oN+ah9HpUqfLSdL3t0XvbMT6/4KFfKMaSeyn5Cud0 vpcSkuPTN1Aql9hLSc2XtvhTSlq/FFnqYGHJ7EXpfUw9zddfBxg1KGvvGwe+wS9PnOpbzVfE Pb8F3/3XXydft5Bu7UTcKavPb2FUIbsXO+5QHXnsLfm6XTb0qLzlXkrvDV/6d3fNqmC89XjX 3nvr+G22h+fr7uWjgSjvcI+9Hr0ftKdn1NJoytfN0yHizlYfmzUq87X82Wzk3nqRQ3Sf/jxv Q0eAkzy9F1qCe3t6y6b3bPQZ1WHQevTeqLTVdran6fe9YrOOoupX03sm4juU2eT9NL1XIe+w 6dej8p6b3viT36LpHX/5vareSZTftGrfkN+9Tn2jQsG095/auI9VfCvZ+2HlWw1GPUz6c8WN 9t7nq2qkSFxAhUxip+pNcImvGjkGq6pUS5xC4UtiuepXmRLvVW+my5hQVdNTxo2q3/Cn/ptW 7auxz4yGlP5+tFRUe5KOY9K6jAkh772UvJ8Q+hvTOeX68vJ+RvRq0nV0+CiXyfh8pN6WvLFr Y7C/VRmx90Oeka8Y9q0/I1o0aZf3LDcqzrlAntnkGXnz8oVu2lO3sOgMEp4xvOqMdqYrz3uu Ojftzxhe5S7NfR/66VE6W9X+nuXe6TnHSc8Uey6tz5uIHsQ5M/bfQr6XTvmQejRLGbOmX334 7l/9Uzc2Tk/ug8B87Z9I5v6nukfqbu7aY9Df/SONq8J2faB3n4K2MxEfTkF1i/ijyWSl9N+i Fe8/g0mmWq7P0s5eFNJebc7q5rS/cDy8U9qzhx/eQuLs9x+/OV9VCjk+H9PB9984Vv1qfh9f 2Wf/R9/gvev0cX4Olhtvf0OLh2sz/od7dZbakexK4R//wOb+FxYMf4vtLn0t5yspZ5963s35 fP88kpZCV92/Mufk/4MbaPgZfu69CM/a64z6nAriWWNf/hzVFPnKi9Ju8dFp27w9tyv90gkR 83ETFkrWoP76zsmlXuvx8+31TzTdTjK+xOsf3jLul2j0o1l2vi3K4v5MjinJxea4PwN7SvKR fNyeZBiXrOIl2/B8aNan1HhG8VOPiDvGa3C7LzCJeEZsR//QTa6Bxbb1euTPCsRWez1yRThe F94fIvZcHyrfRD6Ij3UPnYiFtXa/RDgkXhP5Q/rAHssex6ta8bpi+xDxq6Q6XtWK+ShUT34W iaatnIWIPZfQXRxsvt746Nf1+V4d3sb1J1PGNxaP7qm+1fikiCfZheS9X3jri4V47dk8v2Cf sGKQzwDlcngMrbcuFwljKL1mudQQQ+rvUKTTYgixXzbsE99xFj87zHXVstdztNKJpNnHvXIq 14XI7vtx/Tj7dpHu6XGtt+5SMjVfK4trD+58qf0dXnrzTymZZK9M4XlGhGn3e816tSWJ5d5i f0aSzztfvkiR5cyVTTxEFkHXWvOup4jUx51B38/IV0976V7opWs8I2cdqEcu36GtfbJHxGHU 5ippv/pV5UKD+l6lZ+r70Qv3+g6r9B99z1U+NtXfosqlGP29qixw9Det0jf0d6/yB0m0b7Sg faz3nybJsPaxJn1D+6EKVGhfbXLFVvtzk9RO+7xKVmhcNEnkNHaaLBs1vlQKRGPwEvDehzht IvqosdwkkdN4b/JtgI4JTS7H6bjRpGfq2KJSIPGSGIgDqSlQqSsxrUPNdRcirbcoRMfeEsiL 1npb6ukl9XK/Q30bWyr0xrZnIWne6vYsncyb30V0RH+dPT3jPH7BvWyjDEm8xKvumrUn7Af3 liOmLs0h9Rw5dhkQqecoXZxBRy35wFp7bzx2kc8QT48+N2kUpPAsdREp92W3m0g0nbng45dG XLpE/B45DS1Vn56gkXt/93GLTkh0p9DnUx0BTiJiDbIICluXqpCRBKTgmS5ekVGzyCeoPa1/ hanbX6FHSpEFOyzUjbXwbClAduD09InKfGg9hcQTzvfztJVFRuckT81ZNwND6jOIbhiGKMIE sry6FpuDDEE8ejRlEaQ5f1O5ZC/vMPXvTeOuvW7Mdv45i6lznLoS3udERQ5tzJnC997n7Wcy djrQTvYX+M+/GRcgd6r49TSdMmjvYAVLrK+sEGSRZI4FcNLgnS+YbNc7iPjvt91HSEPGPi2h zhq+ukz4b57DsFS+2tneP1HamubPOU/nMdexTl8fnL1E0vGtfWVJoQZ9pYxzpPIdn/ZcR1Xw 5/v7pOTsju5J1Zd8v5jxDX19OXA3+Cvn1zAnQHAMP8dvzHJFj5z+Vn/Bj6bz6H/+jdMnvEW5 eWl/q3357+8dBulZt/vDiuv10OgSX7i3LET0K8Wjb9Hq4cH1Fci9ZSyC0yn2rfld5Ffu6+7V bj2nKAcVh47Lcpgh187PcfA5btlF8uwcB/vWvEhQnyNaP3KQb/fO8at0InN2n13yIX8aIh79 WOuQMfecpWRrXtYDR6U/D3Vf3X0OKmQWv/4s1LDFf86R/cBDjgHOefTZrtLDg/ti6HMsIeuB s7s8RI7i7m96Dvtnt+K19XzX03Rer70eOZyLl1TibWFr40x/EpmP9/JsaR2b2lP6W5U/Zxb3 3A9FNs0Pcn+r8vXPSfr72dXmtPdnmjzTN3+PXb1I/QBGhKLi9QePbi/kkC9eR013zYe+wydT LCFodhLvN1aCHPsZ0vSZe+7HH5cDEcGQk8Sn5qg2C0lqoZRK+g6lLV1PqoUFbyM/pMLToxOt 59nYLaGpzeXuYyVsWs/zK+NPFt7Xke9Su/7KTw5awqG/6XOAdxLxvffMEpG9peeZKJvIZ/aW O5Gaj/a8jZgQO/2POuoG8bXSqPaPOkpWcRKN3Cc7KVG3g3smVKLkEPeXvLeFIgKfrj9AeZOa ZNzIx1NKjzwvSe67Zs1XTlcfC3Ub91ppVPuHMOWyHv585pmVdN8lR7/Xx3fr8sfXzlzveEop ucTD7ta1VM3d5oaj5f42Gg7a9/6MWNgie9FK90I9ba3brG+jTW9s630Vb/U6zrpb1ze/9R6F X2fbtv57yS+4Hd1CHAPIO5SeIFv86C23COxDdNO/9TcmvS7tT/aPnpn2o8eO9N50PN8EoYen a6SNNgrS8Yz8iJR0PLtgiKZ0PFkyIk4OmxGV6erh1f4pzXT096zRnY7eV3UEAIko1Z7WdaWh 9QS1p/UxQT9WOFr3Qj9oOPqB4nGo77WP4SJkni45iGdc1bfRPxfQsTdds8vzTNK30cdwOYbU IyL9Y5fpmuOG2SFda7x7fN7UwtTnwaZHTXJorZ+JXIfVz/ylFkb5s5FqYegfEOgHKLvM1FWP mg45etd+2D9S0eP5MwPr846Isd8Czs+8rJ8m9E9JDvmTG+na5rnryfigoc+nWXtvkc8XJLqv 4+vNZgV6rKV//jHtPWvCRw976L+X/LkRPejCpxLXPu9toWQpaZOsQISJbsHe5+BfD8xq/72C xnvppTQj2mTu1tVjHyXyLntwMpKY7Ku1nrNphtb6Aaf+ychz1OLcTw7MdvkuTz/92XUVeq3g 77xu009tYv9YQY/irrX484x4UVr/k4m6di2ZPla45bruY3Xtq5TB/rMO8M4XWp85/kuTA7y/ ui9L5Nr6tYnrX398/et8Mp//9Zv7+oc9BME510/HG4u8kPy1WTQ4yzM8+DPnCMSuPbSwnjR5 i5nXxePZS7cz16YzuJ+hau+4ZzqQuTz9uWMi7oeYQy73tOdc14Sg65V/++H/BYi1x+hlbmRz dHJlYW0KZW5kb2JqCjI0IDAgb2JqCjUxNDk5CmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFn ZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMCAwIFIKL0ZvbnQgMjEg MCBSCj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMjIgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSAwL1BhcmVudCAzIDAgUgovUmVzb3Vy Y2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDMwIDAgUgovRm9udCAzMSAw IFIKPj4KL0NvbnRlbnRzIDIzIDAgUgo+PgplbmRvYmoKMyAwIG9iago8PCAvVHlwZSAvUGFn ZXMgL0tpZHMgWwo0IDAgUgoyMiAwIFIKXSAvQ291bnQgMgovUm90YXRlIDA+PgplbmRvYmoK MSAwIG9iago8PC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUgo+PgplbmRvYmoKOSAwIG9i ago8PC9UeXBlL0V4dEdTdGF0ZS9OYW1lL1I5L1RSL0lkZW50aXR5L0JHIDcgMCBSL1VDUiA4 IDAgUi9PUE0gMT4+CmVuZG9iagoyMCAwIG9iago8PC9SOQo5IDAgUj4+CmVuZG9iagoyMSAw IG9iago8PC9SMTEKMTEgMCBSL1IxMwoxMyAwIFIvUjE1CjE1IDAgUi9SMTcKMTcgMCBSL1Ix OQoxOSAwIFI+PgplbmRvYmoKOCAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0Z1bmN0 aW9uVHlwZSAwCi9Eb21haW5bMAoxXQovUmFuZ2VbLTEKMV0KL0JpdHNQZXJTYW1wbGUgOAov RGVjb2RlWy0xCjEuMDA3ODddCi9TaXplWzI1Nl0vTGVuZ3RoIDEyPj5zdHJlYW0KeJyrrx/Z AADEMX8BCmVuZHN0cmVhbQplbmRvYmoKNyAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUK L0Z1bmN0aW9uVHlwZSAwCi9Eb21haW5bMAoxXQovUmFuZ2VbMAoxXQovQml0c1BlclNhbXBs ZSA4Ci9TaXplWzI1Nl0vTGVuZ3RoIDEyPj5zdHJlYW0KeJxjYBjZAAABAAABCmVuZHN0cmVh bQplbmRvYmoKMjcgMCBvYmoKPDwvVHlwZS9FeHRHU3RhdGUvTmFtZS9SMjcvVFIvSWRlbnRp dHkvQkcgMjUgMCBSL1VDUiAyNiAwIFIvT1BNIDE+PgplbmRvYmoKMzAgMCBvYmoKPDwvUjI3 CjI3IDAgUj4+CmVuZG9iagozMSAwIG9iago8PC9SMjkKMjkgMCBSL1IxMQoxMSAwIFIvUjE1 CjE1IDAgUi9SMTcKMTcgMCBSPj4KZW5kb2JqCjI2IDAgb2JqCjw8L0ZpbHRlci9GbGF0ZURl Y29kZQovRnVuY3Rpb25UeXBlIDAKL0RvbWFpblswCjFdCi9SYW5nZVstMQoxXQovQml0c1Bl clNhbXBsZSA4Ci9EZWNvZGVbLTEKMS4wMDc4N10KL1NpemVbMjU2XS9MZW5ndGggMTI+PnN0 cmVhbQp4nKuvH9kAAMQxfwEKZW5kc3RyZWFtCmVuZG9iagoyNSAwIG9iago8PC9GaWx0ZXIv RmxhdGVEZWNvZGUKL0Z1bmN0aW9uVHlwZSAwCi9Eb21haW5bMAoxXQovUmFuZ2VbMAoxXQov Qml0c1BlclNhbXBsZSA4Ci9TaXplWzI1Nl0vTGVuZ3RoIDEyPj5zdHJlYW0KeJxjYBjZAAAB AAABCmVuZHN0cmVhbQplbmRvYmoKMzIgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmlsdGVy L0ZsYXRlRGVjb2RlL0xlbmd0aCAzMyAwIFI+PnN0cmVhbQp4nIVWeVwUV7aupunqVhrEvjZb S3eDDQEyzaKYREVFxIUoRAFZXBsFRGyWCBIzUelggjDlMtGohEYal0DEhxuKI5jocyMY44Ka xCRm9EUn6uhLHsPkVM9pf/NOtZn5/d5f74+qunXvqVP3nu983zkyztODk8lk3lNWrcizmpPK rPmpmdJEuKiTiSM9xGC5gIXOK06rQlDLBbVn50ifdg18Pxw+GAbFvpxcJrP9YWvm2+UFhXnL CowHjJlFBcbUstKySpoyTi1bVV62Kq9yRVmpsdy6LNqYnFeZ9/8YxUjOjBll1tXSTIUxpZS+ ixs3LtZMt9HRxilWqzF9xfKiygpjekFFwaqqgnz33o3S3t0jjuPCprxduiw1qSw/bWpB4Zxp q5ZXFM2oXJGRmVK1ct5b1rysEnNEpDGE40K5+dwbXDIXzY3i5nDTuBjOxE3nZnBxXDiXwc3k MrkULoKbx73OxXNjuSgum5vNvcLlcKlcEvcql8b5cEO4oZyM8+DCKYxcJFfBfSZ7WbZJds/j XY8r8kz5R3LRs9SzT/GKolbxNV/OP1KmKW+oYlW5qu+HaIeYhywfcnNo3NB1Q3d4TfGqVPup Y9Rr1BfUvd4aZ41gFx/aZTDcLhbZ5TDcT6xzKlx1zxW83a4VH4pFroeuIqWPs1BwwChQQzNM kAlgBi1E0WWWO5f64TGnRYFmHg8+tyjAzF+CVxXQyfchPeJ4bIbDWszmn0LzM2xW+IhnsRBk 4lOHbBuEQz2EyreJdi3kupremftm3iwh8PfCms2rt+4yBnz8/sf1HwuDQnfHiUGwiv8VgKE8 ersU6CsqFBjO+4ggiGmuNNFuHnzLoekHhgyCYT4E+7NGsdOPhcNXSqGzvr12T+WzmKZsQcXq pgvppYvnqNjMb5ApWZ3LrmS1EMyTabVSuLi1c1tLQ9fxth4yrbnWtAzVBtz9woL2XQ2e6AnL IRTmIgec5gSE+LMGsUWUaVkDeBZPPYsaHUZHvYSTceLTMPgdBH77Bfi2GVgi6vYqWEPSuuI3 s3XTlpyCYeBxsuuagRk/EzrKP5wHun0BPs7bAqyBH8FMJwnCILD2guESlNAoyJ896fdjTyBI 7OUh1NWrAAM9xV6FqxeCnBYlu4UlPI5wrUU/ca2C3UMrz548t7hhA2/IAC8YD16aWxCGYVCH dWL+MghBJUT5s4FbTouWDZAx64M6/qdNFzft2wKyXbfuCiBTMU/h7vwr8ftVbHRf27HPrwYJ 7Rta1+1fdCe9GaMpSAN4jCenXlpYWtfz/v5SYUmgsKikJLcWF9QFwHglHvUktyoewrtWT84t tVo2GNhA3briP2Tr6FwZEoQUVegHT1knhMAHECLvBIcWp/wtBF6DaFCACuIgBuXAYxzGoCd6 oFkPIRu0A+fO3+w/lxE2KjMjeWrm+QG925Usyml5PsI5Ak8OwniH5jgY4W0IxpEwklKD+bMm m3jSjxltUsxCOSTgd3K4U5nXk7tvrqBCFhONyZj4LBy8CBvbRaHvkxOXVCzRNlnJkm3AeJcH 7NOy4dz/fHrmytWe+eilJwchOfNm62l9Uv5FUBncMa+h327W3HbjGAKHKERuFB/c9mOPCMXl PJxwLVcwAsRpwSDXKh5Piask4EJ49ugFcNUwTBxCYPmCr6YbIv3ZEbEN7Fp2JLRi7sJJulFT b0AKTL7V/3dKr2+EC4ubEmHUoQB2BPT5kf0YpcOFqEM91mAVHV5POWD+5SuI7TKg8aREwuoB E0w7d2fin8F70DSgOQhGNBLB82CkP2u1iSoYp2WNtuy1pastutnCgu76uyp4ykNhzM8YjfqX TJiI8pMYC8uA/+Y/fz6kZ4kUzr2K7WCg+Ngwj6evb3X2XNbT23nhZN7mBJUP3BccbzmteAO4 vw1qdsF1fE/i6vFdJAAsAjkli/+aZ8muGAimoRijZBEDwPEs3nSYP2tv7HS01NXu0e9+Urir 4IN8IRBZ8XyMN7CIybyPM0YQR7pGOi2udPCBJeBNyW6C7VLcmm75sZlg4lkC7H2ivCJ8uqVj 27M9fT8IIBeAT709rqV8W/rWMQT/Wp7NpOCDSfxJyxJu8GeEQ/VNdd01HUVCtmpidgX66hNg iftnxKosusa8+BGaxE2uTWKbq0087s9+oR/WiMfBm2e/uEyQRV7B5X5DF4zhmUn0l96OuNpo SgJbDBTEua65op3kZRgp2ZcvlIzEBZb4MRPEKyHTce6mo+W9tXv1XeBVurtku1UIZHWLhZJ3 lkwnNbv9bzV7z61VgIWDoU7Tc5OzxGUHOVwdJC6E4DBxLQYTH3SgQy1oKTaJl1Zo2W4O1Tcy IFHPjImQ1nsdsgxiIWqVLDExSUmr55dmtc3S4XCzGZMw9l4IjLh8pu38cQOxooZ7ZXVZdFZV w7FaPcY1K0jZLmiZyjbY/emX107nGPX0uSk7a0bqgtPgoZfy7r8jKG8XwtjIZySgI2ikp23s hQgta4r8+G4qhOgg9rtvnzy0tKP5hAH1RzduFvap2tob+2h7F4QDq3cuBe2+ANb0lzfTTmGo DiOnTY8L6yuCwkWGk7ZdNUKFanlRFREycZZQ9En1WdRXBbgrRa4rl8h2kkqFJA39/6oUzZAv KWCyJAa1zy1S6oVDgxKUhz69o2e11+0r0cuArS/mLyiF7vqO2j2rB827s0j/atOErDcX56hY MtiJtM1E2mo4it7g/Su866ZuD0RCAXyB4RDuzzrEKInCHTAulrcUp5S9QUk3bNw9mASjv/sO NAY298/CBYtjGphaA8jKvzTyW5yuw1IMxlCswjVEUhNUkBkMFWDEmV7Spg44SlKGX/B081YS xaqBh17w0DRCD66VgnsdLkv8um6GWTzqJyhMSmaZjR48u34Zq3hhwebiLe/sSOla+bVwXDi8 7eBH1X8PqKh5e+N6QbViY+MPBigg+8c8s4AHuW8XHGKF4wYw2U0Ilt8U72spjoz2R9p43xOC KYeDXXaJIuvBB32gAXZCBapBrekDPbSCicA+DOsIbIxv/utYSNHBjF9/oKXAlEs4v9uAXm1F LcIJVVd361eE9/fC0ZJdSRD2AeENAbVx93CmDieYX0UVetx4HcYsM8Do/P3rhSxV1oJF0YT5 GCGn6/dPMGSdG3NSG4sEhqZF/BJF6eefwPrf1CBC/EnJYqEIvF1fItExAlYQUV0/vTik8zWH 7BqEya/5uSU67LlF6gAEKqP3HbLN8NIV8L5GxQqK/cCXh6WiXUHSHYG7339no21NWmDZj5Gw W4EmHgpcdoX7ywf4QLS77KRQ3YT3qw6Y5tBcJS4Gw4kPYSKVqAh/tiXxqh9LSpQaEg1H5fOL qwrp1Q/XKSCCZ1NsmA53YTqkK3CiZIJjcZaCCpnoi5SeSYn/rhw4zGklIblJGkjFx5/96aaU 4w0ujVKYsDVtx9L9yD3NgNGUwTlQefav8KFBVGOYkiyMSgzZMAO1ExYeu1itZ3M2Ntd3fh4k BihZDh2HUlyAGVSY02RbQHcAhrdD4B4IaAedHBL8IIj/Ee4/wPsKCOBhvBQUHQXl0Vh4pMBA fjQ+ipJGQTy8JkXlX3F2Z5IfBFOcg1/EufrpK2Krq0QswQ7owEkwKXRQc1iKlbgAA0EXAjp/ VmuDJHBp6Xm6ab/9tO7bj6pSDKveXWKbVY3B5dmLhVjV6Cuv/6pnIdznwtm93aeojifuKPrj ui0bVKDjabri9HsH/hJEDjbDWAVELT5N6haUuvClMj1TceBbqYDZKNeWK4Xi+tV11Sq2jcuv XmxdqFuy8uCxU41bYVKXwV0K0sRtDuqJx/wMLw9QRwzb/SCGhw9/a4qTXa2YIrYqMJaH7dQg +/zDWxAzXZm/da19oEENcSiZqvRIek6lY2pAQx1sYp9E23qbW9U5KSfCbPBHJQw/0HNbT/OX GkrR04BHJGWilc1K8G4/1y+tnNttjTTg6d8W7ilBl3NZalXqbW8I2eWLMlU0fc46vzVFR1Oz hXnli2lqJtevpBtqeBIRaheCZQdhj/wgZGhhD+1pD+kjLWCh461/TKJ9n4GAlscxjym14AwW alnma5CyEoZDfJAAMW2gfgC5KjPPckLx5Vxq3cYGCfjyWUz4GaNUj/+Po/94FPO4BQKoDeiQ /Mwkqcn8BcxniGqjydfYdIiPBKMqmmezH2BuK6oxJojNFDBuBQaNx6nUVbRLjQUE94htmAAJ mocQgaG0Y+6OP/ucdpRK4n6HZ7GH4J8KNgcSMIJ4jwnU0R3CfypKkdbrQKqKwdIR1zc4FzVi wU4Y2MtjIdUB36Gg92r5bEfTjsa9ajV4Ne9Qe29S+3Dc/wI4ovObCmVuZHN0cmVhbQplbmRv YmoKMzMgMCBvYmoKMzI0NAplbmRvYmoKMzQgMCBvYmoKPDwvU3VidHlwZS9UeXBlMUMvRmls dGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNSAwIFI+PnN0cmVhbQp4nIVYeVgU15avFrqqowa1 r20DHbvQiBsioGJQMaKgIi7IpohLUFlkRxahgYZmUVvLha3Zm24W2XfXuOKSuCQ+EY1xFE00 mgnJRJPJcorcfvPNLfC9N/PNH/PxfV3Fveeeuvcsv/M7V0SZj6JEIpHUPyImNHFDaIpvXMzO 2I1+6/2F0em8QsR/MIr/wOxjHP2X69BaMTfWjBtrfuoD1l7KO02ArnEQO54aJRJpjvur4kPD du4OtWm28d8TarM+LjYuiQzZuMclxMcl7EyKiIu1iY/ePdfGY2fSzv9HyEFQZuMXF50sjCTa rIkl65wWLXK0Jz/z5tosj4628Y0I35OUaOMbmhiasC80ZHj/NuQANsMnoCjKbd1yVezu9Wlx IRvc40O9PfaGbVyZEL4qcY/v6qQIP8/kSP81+6JSonduSo3Ztdl+roOj07zC+TMXzHJeaGfz 0RyXRYspyp6aSgVR3pQHNZfaSm2kVlIO1DTKh1pFOVK2lC+1mnKiplN+lCc1g/Kn1lDzqZlU AOVFLaBmUZuotZQzNZvaTK2jAqn11ArqI2oLtYFyp1woC2ocNZ6aQEkpREmoidR7lIwaTU2i 5NRYSkRZUu9TVpQ1paCWE98QVVnUT6LtIjzKd9Rbs61mRnNP80fideI/6JV0BTOeqZCMlxS9 5/pe52huzNwxj8bue9/q/XMWlhZHxvmMezk+avyrCb4Taib8Ke1G65Fx4tKJlbJFk6wnFcvt 5e7y3fL98j5LO8tSy+dWflb5Vr9ZO1qXKcwUaxTrFIcU9z7Y+MH1yaOHqrlK/nWlCCZU8nsq zWDCJF47JDZp/y6mKytl/Gt+j+m1aQ9jwQOnV53m3+ilBujFvbzOtHBQjur5+7BWhjzwZN/w g3ipwm7/sYcsv4BBjq9LDG+VetyrYpDHszLNfNa0jEHaBVmZLkoVr2Oug2f6MbHFUBgHJfyH BlERhIB11XMoN+N3QILspF1ZTEESp7bikjPSN2slKijXMwHHkqrCvsNp/AXLNBqrTad3zVHn BGRbqSBEz6zLz6zkjFxpfnXJiXO/W4KOVnfKcCoNEjCAOTaILXgtjn7Ln9aLCsi3FGBrVsD7 yVRMV051em0QOOPXllFLk3wS01M4q436Q1weJ4lOVcXHNuztufLFuZcdLHjxvsbLJaXtx630 2FbFtJXuT83UZu7PZGdgDosgObt2fxVXZtVQV9BMTh5CbKYlNvsFNE3tN6UF4IhnwV5sP7DP COaQgGc9laMeN1jIj5KhBLdBBk2g9tFIQmFFQKGqLL/kWDFnRSZajqdhcxYvZlCeZoU6O0Cp gr16hkyszS3tZ0HDdJ/uMXZzkkuGiEUsXjssptVmeypUkEDk5rn5aMrus+DHABPSu0xJFm7l tkRvXiex4DeqH8NRmBnVKm1/4spTctTFO8DHMnWhGHUtidgZsV4xz/fHP38+/2X/6cqMT3Qs 8vykuCCzR9FUWVnPoq5L624swKPt7PAUbPudw6/f/ttdGF2ntPjrfU7Pd/6u0kurwBt7QxpO G/r3vx8+A8WVsBDasfcPc8FbjurcePtJ6LZbJQ3F/FWxaQODcjQLMrJdyQHbycZvuy1Rl37L 8h4Mmka9qCh5oiSDjjbYm8bZpgqcx1eIyQT2VtFk3VfV+5axJg9hlbNaI6hII9LXqcWZJS9Y foMwDsWmqyQGNhKPtEXCZNgA4yPaySYNPGsSVafzYxKq5GiNG+8Ck2XIyS2NRh4ap5x09QIF /oiGXt5GjCQavWkMQya1eLy4mkaHqRf5bcfvKGAGjS+ZWDFaQal4VhDIh8lCvKk7+Dktovbv 4dhrMzjGB8vw+3OmYMX0u9gSbGHCj3+ADUxy+BmPYzOiZd9cn4NtMNq+fd1CPxDBpD9P3r7P Ckqu6tohHaiiZogwSNtewyxwXFybNLAYHOxq5MikgbeXZKjXjbj+kE0tTd7A8vqBqoz9Gm0O iSCTJupQ4xuWLxemk2k0isLWAYVp5fklR4uHp1uOJduyLgx66Fa/N6osRIGRE54o/H3r+DNL tF3gTlafOSdpNyeysXFxGTGKlasfgCWILv1b/9UzQZ4FLE5nSCJrinOGnP8+W88fAZsFL4ll M8ETT4N0PPkM9JMomHwmjVi43pg5NFuGaIrggkTTn6c7eNFHgtyMpmAG2QrOW0Kcl06cN16z KEtwnh2D3Mbza0zNYiJVxV+jidhIOOA0ooO2eVqWtZA1TWBMM/k8MVGMPWmLIYeMM7wrJO/p kHaCGe9VxVXI0Sn+zdAiGTqXRufFZKSncvu57OOZhdvqtpVs5SQ4AE/Dc3Aw3gJWmAUfsHhx BUbfZTN0rljkG+fMWWGHuUDBOgj+FkbDLBZ5/M597X8SKyQVNDqXAcnDABOpB69muN3UeT/Z INVCJs4gzhpQ6SHppRzddzvMz5AVpJfm644WEdtHuLUWqr1Yk5Db1CJN3hpy9ExydB83z5wK ktsfMG0xDdnnOQmM/YZ8ejrIVn5PPhzhFshtj9/uKvlNMKFq2KVKfzE4LpWRpZfPG8u7FESo /8ISLMGjtq9eERDW1p3DaksO1XGdEljCCJn/FCIaYUyHqKsPdv+n2R/QKoM7NIxyfzADj5nv hO3x1O+c/nzT/92rcmW6LnZpcKwPZ2W3+iVI2UbzokcXzl7lbnGtu4+7SvBuYu6wjI6hUR2i DjDnl4K5GT+KGBr7EmCYjoPwTpiCPwQv8CQnmAXbYTOeDjOwG5u9RwZTHmFzHIJDHefi8Xht PET8CgGPgQZLVigNelV7xAX+5uWwLhJOYD7Im4GZHB2smoQOwkUaMkkaT4DQvvRb0VfYtX/a 92B/4shaFT1Sb9yY+WrNYqWKAZ8LMjSPv8mgNcVd7flNCnAEM/LdtdiL/NLYjkXz4rg9+buK JSM+VA3JTd59tc3Q3y5tewbzYR+2f5peKUeXKH4ZSWNi9nQauVEqjUqTmiNBSyljYpQujKTO tKnYDlsNLHxxocfYf5PFAQTVKPfMHG/i2n3Ete9R67LL7rFkBf+AWYJ/l8WExaWHchK3DV/A WJDevPXwdlfoShaHMRbwguCosgPCO6Q90IFbwYDXDcjRK9jFO8rQRmA6aBSCGRrcCnpuNeoz o4xKY3RFVjUnqTYaDac3nFwfFpmTGst67Uzy5/D7ErTReQ9Z8QKfp5HWWa1eRbZkIFu6sYve nn7iKxaFwHkSGr2cHlpaVY3QeDGkZxjEO7HPIOwULP+ZhjzvyNBKTc7p7gMtCpB/9YgEprlz P/Zg8QFi+NKsBYLh0R3NgswsYnvoJF+YQi3KLPmOhQCm0Rw5UdAozBecMB6vUnx7fcNcF1+f 1SwZT+X2HttTKBlhGp2wiWCGvAPswTa8k+zDyBeaFgzaw3+lVp+ubjbIUe05CB2iZWiaG3jR aGbXa86QpneQEFzOpfLAVmwqVAnDz0tySCysYMjowkw12RJfyCB/7Q1YLE6hfbA4Ks2WBI05 HbS/+EsW4sCWIYuecaXJuo8lRHc1pAlaUmk0UbNcm5C8TIFtabIeKkY8RMp77Kkjb4bLux2o 8LynKWRvPaSskzCZkEIKOv4gIH+4nutIyvu2HU+byuLlJOPXHDyctoZUaZVQpX1Sar5gIYrR dzScMnBlEe1cDSepqzbUN+2tDw8JjfQMZZHvW2aYw3wOToYUPhj31anhc7ezRbXS5vsR3y79 MhWG8IcvjJ1y9CgQ7OAjGdJ6evpp9iZZIzMbLqVU3Z7iuTI5louTkImtgzt+JSSIGRjsDTm5 oUiJs8sOc1w9V1akb6qXoEn5ebW12hrFn333nnflNKtq2c/o1qMcxxkPGjkujpPMoaONYbpg TvLh8hXzfJq3XItnv4UGGRqf/3n3hrmue8KDfHddJfXDzOZJV/cFpZNpjaxn/w3tw0MSVCP5 Sduk2WO9LWALfm/myqbTdRVNLW3KkdCLhGRseYpsf8TrldCFu/hs01Ti+Qcq/T1SQW50wU7B 755uMJ1G/Y7fc61Jdc6SKhqJqf2C37OJ35s0z8rUC4dDsd9xBAagixi6SZNIZ3AZxzOKkssO lnK3JYQKjhVk7nC1iUdWSYhWPSQLaoXg0azISVb5KfBYQSGUEfNbqZuSYQE4wJy4RunFG75Q h2sq0+G6+4MtBB7KNPBQ8Pt4t3Q6N+OgNpuTkLEKD/WxLMVif//lGxpjXgazg9vqkrhPJKie Co2K+USJdrmt5XzPq76XoOVUOl5Ak4FK+nhxwfHC4eVZX5zOrVB8/fDaQG/k6TVtrEe7b+O+ Wq7Hqqml6VNh9U2uM67eTtBXSaKUgjn/IJ7Th7zwUHP75xBpIPHphGcT1mk/kFQLZhCPZxIs qcqHj4a8ZMjGLemfxKAiv/RoAYnUwPzW46lTWdMsBmXbrNZk+ChHCGVgvldexT2BeF640lra wkluVERiEYvnCXIrDo0wz/hhQb9h5jmPAduo6y4792QucVciGw08JWzBgbj6XDM0fToM7VXE yz7Ew6W9MGoPrJQTeBhymYSy3fSMe1FE9bqX+APwtUReGjCrv3LnmTXXndWW1LDtmn8VZkny 7v8X4qNiakFWlss7b19z+0hT+pIATx8DSfiOmGiElbQpEn6QoV0UNAniBa31x6oVRPeL674u LBmesWIHtlUKNa2tHvpV+j8hNKJdSkobfAbFeOmPoXqORGE7xf8lsAmhAB+KzM7JInQi87iq UILuUifcY/O3Kkjls8fzyG8QzMJKiHl9T3/yEQufMGgq9dpY2EsITDEhMHeph+UqVxb7McGJ OzKDyHFmYAqUhJ96/QxjYDZLoglGcX2EaowVglyiSYNQsQW05F3343/GayrT26U6srH1TzMq 3lTLkQ6c+e9laEUGid/w+bs3eSdKkGU6g3T9+Cq9pDHks7Oftn5Ro0ylNXuT1fs4yd7Uys9Y OMMgy9/baSSdSqMVMINgWwuJID44xQCKN9Km4eCJwfPeOD1LJpyzmwJbIW6kVFxycnx8bVJD Q01tQ0NyTTx7CmfKkJsm+f90MsupluMqAn1uAtlZpVH7Eh/FEB8tp/w05X0sYKH2ZHSHQgpO GZqK/UAV0iO98/hjQs+tyE5WOr9Yr5ejI278DsHsa2xIftpQMfuzc9MUuYLliyRkUh8SVhSu wOaLXecsPL8Npi9iYdzqrhjOW4IKKZ/ALYuVZCW25LZ/k/o7YZ0CedJocAqDCmz09PHm4sIq rog7kXciV1CW+mWx9oyCEMFv3n6/9Szp11iM7oV2cJckVy5d/JuSrPmFu+tZiccJyvU0Gk2B ihmmLXC1E07/I6xhz/BDjn6EXQAydAd8GHTqZXnZAImALhIBdx7rs52G2+NT/wOp7iTS6QSo 1P8Eqh1wE+8gMvPSh3ukYZlFmeWkRRJWvigrf/ZOnxeBPmcWk6/cwTdpoYO42dEED/TSI+C0 eADEMGdJTfLTJeAoR4MUv4Q0wUIjNYfYYpD6/HCZOtAaFzCohdoSFKGOU+yKrH7OwhXSe2mw 07DMzcosXxZvZfDYbv+vzzWXPn+snCPI19BEBqyv51Vlkt4jm/h8ChWlbSRFYJCCOiGkcHRP yPf8bRJTb6Ut4Ojwdh5phoVqaTu0VoYmkmCKi6tJbmysqWlsTK6JY0/jLBmaQrpiz/8VSrXN +aopLO5n5uSEh2sydCVqJfJsCjt0NFWxLzU1iUW1yY3xN3978BDslfymkasLXg0Ou05Jm6s1 fLfJCdqw96DTa4gkCdOt4b8WWpKZlKmbRg81udhBaO6mUi8KOhtfKZ6Yjgmj79rKNr2QvkuG 28pjP5CmSfOEa43ULRZox0xCOxzEw6xgiNZL6wW3/yBHfXBbL0P5/3LnAcGdPMmDb1+Wl/7D afn/rFfGfwQBEdALUK428Ev0oiIIbzA8gelmRSO3FvsNecbNsMBkYWmgYT4/UX+urLTjqJUe TyeT5XlpOQfVeSp2KtZ9CFxepbacK7E6UVZ0knwu/F19gKP4KO+Hg3gfXFEBKQZpEeEwjpA6 UiMmwCa8CWJIyhnBRUj28UKRmGqDrQKK0wRPCEXC00iKhA1rIk1aNuWZmbme7DuVmCg/f11O yQMWZjIwGbuXpRVkcXlWmXl5iSNJ789lFS3+FZPCYAnMH2Ki5nRPc2nvUQnRX4E3MWQgg6k7 pMvmMrnsA3m7wrD4Q0uilPcR8kttgGpwJ2WjADY26KsgotTQD1Pk6BvhPgc5qpie3DJN9VYJ ugXTTGPFehomQY8YnQVz3CMmxprFTypvN1Y3Ctc4U4ixDus0wncOqver7DFnaQs6bcHhQq7Q iquv1J09KtHjCCJ1SJ9bGVK/xtIOh9qB7kCFtpTTWXH6Ql0HkSDZgTfSI6A55EVM2QwOeAbE EVMKeFkP6wULriCoOJ7Yr0iw33AH6NF8PG0Ka5rNIC2BRH9inTiiy8M7iyAi8uBfC61aznW/ 2yWN4A4BeD7Mj22Sdj7zegazSQI7yVGDBrq/kKFmt03GlJb29voLXUrCrldqwsIOHNIo9mkr SPWbwwAT043HKInYNG8/v9gqVR1LZOqqqprZQzcqTlzlJHcMEdNZlOOGfVZ7B7tarzq7/faZ 6pLbA8pWc1SoidoVlZagCI/sOP/5yUZAl4XVeJngiwzDENKLiqH2uR6kEGw2FERSCQer6O68 Vg0Xy6nz4tPDsKNpoiV25S0zOnLruSorrra04lYBsWutirl5oELdvAqOmO5ZEkel8zdPfFFX e7HYSj8SpLyDXloG4Xg36R1p8twKdnL0sExwdLCKOclV5Vxc+S0eZ2mPJ4hR2ebV6sx44bJw up6JOaKu4Cq4gpKqmuYHP1l+aWeM0aVyuVbpaZq9xM7heibsaOaxgCfYHBZY3nomRiGX/mas 7BTcbadi6nWazBxNSmIUGxYYfTnmrLaAeLuiWNcg3EIF43DS81YPUyxelFjX9ZnvjeHkmQl7 8Vzhfm+00DE+cR2A994xreJCcOFFMlRc/yODzN0IpAWNJphWpCp9h2nF9aQ8ElBbJmQSiQW/ d/d8xfXrsoVMymOaOi41dBJGGDT6cn34chb7C5Oe2kPpqxUjvWXQ6BFmlsdcPN9S3sFJeo1R H7+TW609nLH6HTGbluObXXWXBX8G6N29S7fuSlvqqVTfDm7zI9ptNAFc3L4Vy4VOWN0J91uM fQJ9PCRcYyTXQMo3cvQHzOUJ//4DHjNIKhR6whsLhi+UhA7ndcuxfdNY027meujV1CucBCb+ SvjmNPjA9bkDi/7Ywm2LCfaWRJv3dDcIe/zy1lrSgY9f77kxLLyqNZIFI2Pxl0eGgZ8BhSrB 94eu6DnQnTG8hiA5OvuXqwDVzjhIRV+sV8en58apd7NYahJhBKaMU3lNJLzaqnWXCczpVMyF A1X7G9Z1zLDEo3AfnsQz6lO5DQQIG42lZ4nEIRVziytMbXUSoGKL6bwAFbP5JWJUB7NNSwSo WM+3tPxHReMNci5nvdDwwcaHolOQb3YKymUrIP8hziejx9QgEvUDZQYTfpTFJCbGxNQlNDfX 1Tc3JdVHswQV1IYhR4PoyEnY1mMGbQQKQmic9/dA8UkacocChYujrJYhcauo8yfI/tGsE57K sM9rwrjeB+n3JPA/gUB7+BCPxhb22A4HKX/KkkHEaZA8/vq0LV6L00OwaPFMFWwESjmC7EMu BIJI7K3EiwjIuwxfXdTDe/ygrCjDqKvKLxWgp7Vwny2Lhwj0cE4H8xaTxsyTlATyr4BArkcP FL625q8zaEW6AFrOruIR1V/xdY9IL64wMXpo/KaGULJYfgcgGYpV0QnBCdkOhMAup436S70D r3767dxL7rFkcPFTTM1w98Rj05V6uu7h9Z4vOUn/594fsSifw6Nc8BichsMkyFfFKxgU+ykg oYjyrrVgAdSMt9JBmLX9UzlqAgnvSsr0s5Zz1+9bX9t1irROG0P3JkXG1CWfYFHTUe4I11ok KSnUpIakJGwIZ5MECMk6E/wdFJSr4a3n36RwfSDkgRy1XObbZJW5YhR9tf10wyXFnfM7PF3X r52nYVGhmoH3vl5j6+G70TNWc7w6hEXRhtD9R1WK5LQ0FZnfeyL+FTj+PgiTn+68tahVicbe utJ88aL1I8/PFzj7B84LVZK940j90F8G0alBM/gCB8rwxO+2ggUHORzEfAY2MPpLiYHBzh5Y hNdweAeHt7/BS2CZs2QE9ECLtUMupkO31/fxjgZpJR+Alz7d1CtHh/lQ0BLWPY9wdOFefPkm Gk3DN01rxWjiepKL0EYmsPtT4dWdQRNfkXawj8FLJyEpVtOghmdi/Iz51/4gaNCsZmihDCbO v4Df53Auh3dvxtPx+FUSFQPOD0AEazjYwcH2GbAUf/xckjJs0cuBb/ms51LYAtnL7xC/8KuE nIzH2TRGWCdGWvDMA+LWidYuq72WJSQWVSUoUbwxOu9Y2jsraqPaI5/CFBgLDChANuUNdqlT Isezr8SwlUbx3c+HU6IR8JlguEpQ4MwPkPtCjtp4/yEXGRrAKXgV9sYqPPoenivY899/AznQ Hw84bduWHrWNPQ8r3/wEsyoImukZfB3/SNa0X6sprFcMnLfHZjM3+fvO3wXjXjUc6yg4y1rw t/r4WtxxUqonj84eOdoI5X2EsfXQ5E1L4B60J8kr1tIoHw6EMOT1gFAEDu4WBA6SUawVUGCE qn31hGz4FwDcdE2Obv1CTLMWO5UfEKNbt9u6jI8U4EXjINOg+Bphy7B3aLoYbdRjENbjJTXk GOazfpZeBdvdJ8nqq3gJCfhf2s/e+pv17ZBTwSTg98TFR0cYUlpJwBdxx482l0oK8nM0m0MD PZPZ5GH3NAyNbZLe+sqzH+LuB9wj1RL84YUM1dut2uPvY+0w4AEUMI+//uGr3ZfwqBdKFAhm ffUXLlp/5dFng0e5uzv7VQf/7qx83CtbfFeMAqNbVO3t1lc+PXv37qldqwM10UtXKgM8iD4Y N7tzh5+17/YdHh6BV7+5c6L36qcC/qgJs+zdcS6fl0W1Sk++gAQQzSU0eH2vWobs4QQ5Yi6s BAcHGIPHsOgMljh9iK3xmK+X/nDqfFXbZXY3XkagTowna0mHRuLwGgyShXujt2fEKNy3DIDF f16+8tmrk3jc3ARtxP6dw/hKIrUEKOkLEJHemRI49xR+pwz1jYBxIgHjuubmxLoY9rBplAwZ YxITYocxur6+mUV9TYn10UqLjIqh2VU4oxwSS2H1URpHVzGdowfGGCvGjm3VVet0ZRW6hju1 zWPfp6j/Bs8DiskKZW5kc3RyZWFtCmVuZG9iagozNSAwIG9iago2OTM5CmVuZG9iagozNiAw IG9iago8PC9MZW5ndGgxIDUwNjAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzNyAwIFI+ PnN0cmVhbQp4nOVXC3BcVRn+zz1795F93t27z+zu3Vd3u4/sbjbZvB+bskmbtKHpu6UOJYS2 KTRt2sQWsEB5NECprYMwZXR0tAPMYHlUUFQEDBoQRAsqA0VKh5YBFQWqVmWgufU/d3fb1EHH kXHU4Z75z73/ua/zff/rHCAAYISdQGFg4ZJMDpTD8gF2y4dGBkdLunknAFk5tG08YHzO9Csc OIqyYN3o+pGp+U+JeG826ovXb7xqXel58gaAfu/w2sHLHo82ZQFse3CwYRgHjCtUL+D9HahH hkfGryw9LwwAcN6Nm4cGS7oR/8tZRgavHNX5iRmf/xoOBjYNjqwtz+8IdtLo5rHxkm7byO6P bl07mrnmul/g85Oo+/hl9EEAeR8shsegCPfAs3AYenHuA3A/PAJfgh/BIfgifBmugh8gA7vh AmiDFXAz7CVJ6CE+uA8OwI0kAG/AuwWT0aCv0mk1al5FOQIpZ6atJsVEsDazzom9xTndxvpT Sv+60r/E+mmUUyivo7xUk5qqSU3WMJoAtHGcH6iXy8flE+o+NnLecTMbIRrYACpF55SzCd+D M2fYQMFAKOU4wl7Mku+SXteuz/sc0IkHcZTekPAL1fwytLAGwgULr+aISkOBV3FUrSGQaTva xuTsRZ1QJ8SEsCCdlp7kl314UOKdH/4WCJHIMa6Dm8bvZAp+wJNECFFli6WfUy5MANVD2ENS 8ickf/lUmyVCUMDX8QNEko/jdFhH1/G3ghcGCo0mHdF6XU7RZgaNXUsddqLTEg50Ji1xOR3U CHbRRo0I2ksgwpnYT8ymyk8sCWyTlklIJNmJ/UztdGCzB/OOxoaYoNaoNTFb0KaJxqIxcjuJ hwZcrdO9d9XEyQPDQ8J8k2qDab4wNPwA3/3ROzdmwhqODAyQdPYGlYMb2/KKkZySDcYjo2Mc 4zIPoPoWcumGFFxc6BINMSkmVXucdjXo0S2IG4hBTyjyEdZrsocMotvJiUD1HGfUeACqPTwR 2fztIpKGGBMlDFNs8nh+F0lLJDMZhsOWD+YQh2DRqIPBfF2usaGxIS/UIwheEJ0ONsC0YAjx qfPk13e/f9HB7z8gvyi7vQt9Iq/WWzeT3pB/+JnLNueWy6dGI1YV5cWuNesm5WPy0089PEey RuO9tLDZ08E9evruqwP+rTvJ2Ae7TiTsfuYy0HXmTeqnz8Ns6C5EAWIGGqjSZ4sI00eAGqtt empAUiCkRaQ+pxl9KZ3OZDLpMhCbJZGwdTKFqWgYJxcOxaL5+saGupzTYRc16hl6NBoOCaKD AeNe77r8rUc2jezY/tBXV7RUhxrr/S5vdVyvd61pfy+aaBi8i+ir5T/t23P0+O6JkblL6sNJ NENK8vP1bfKKXfc19KCl2OyzOHsnBGBBIYXOUyXyBkO2aOBIlY4DjoLoYjDVxMW8OOAiEHBZ qnQMBeJIpysONmVLngcj6Cix31jCI5TxaNAYYWYMmp1+kcxuuuXyubFY+/WvfX39zp1r9/7y 8ubvVNdu2FaLhj/2zJqJpelFAXl6062Evrdvy0tbLrlm0b5Dc9fhdJB6eoIfglrYUrgQgPdE ssVkrdtmsEYSkZBHT9R+oMEAZ/RLflJrs2LgQW3S5rYa/G6JY4AEkggFDXqBujn0tGSCeNwk IKFTlpxNCRMWLxb0tNJ1yWC12aBQwaC221kM1WEQ1aHfNQoseML5WYICFY0nlG5zj3pnFa/o kHR64hJbg3JXsFV0EXbtJKnPHLypqxZDmWncpXdlCzs6uvouPjHmcRHMTi73ON271e0knabp A0+sumBx8RL528q9MgsvIAsZuLZwqaBXVVkdQS4V91COl9LU7eKM+H8SCpJIOCDRTJroq9An edALVSpfOhWRfEQdCtA4xwUodQhOJMbjVlGBCiz6MkDCIRIMEKuAGYbwFWaSJUIUasrZJBgk mn9AxayGfH04nA/aFcY0NnyqsY6+IMvyq4uIy94alVtnskGs7Sslcoc94Q8Vjv81K0bbBHK0 98EKG56xChunb38/H6/p7DRbm38ib5svxFgJULL4MWTEDvMKWcyMGrNNw9mBM9pEG9FqMJdo TRpiM4llH6ikScw03EzLK+AqmfLjgJFlOPmW80zJD310w8x5bvE4FSthVuDvpz+Efri9sB7A 5WnmPZ3Z4tz+VFSaZbD2tOdr/KKeaGuB1tdxxs7m2lwt6Y/OQq/lOeifG03NkqyGdr2Nq03l yvPuQc8lNskvkBRFBHN7COLL15OaFKnLzTBVyXMVPFNTibPquTid6cwVoB8zdA472nKWvaEU zE7sHTMdXbXTHZq3PO/TaRgjPvmw2r5xRc6tqyIOe5tP7g42292Y/u3NTiKJkf4rtnb7Pavu 7toUiGg1pQAoPFxfHMx3pnfKssIlF9iTuHMom2+YKA8oIUHeHnO7Ok335mJLlkTmfK851zSv pUfeW4qLUla7FrOaGXzQVPACOF1aiwuyRS2uSVgydmtVdq0BK48qk6lwgZl46rwM9nfZ1xli hFjqcoyeKHnrse3Dw9smn9o2PLz98dxqV+bIKxn3avr8/ptePbJr//5dL7920/45xcYrnpX7 yMOHN7R0od1az/yO+yl6QhOMFRZg8XOJKncuWxS5hgYscx6P38uxpaVSOli2bQKC6cvnVUpl zGrROtPZQ+mmtOTlePBRC36S+H3Mcy1TyXNAKuUymUlmZgISwhwzq110loxWBqcYOyzUlRN2 nhXP6NkChEPcnR25J4qJVLt/4TdaRgcXX9/bEW4x60RbS0s4vmiivya5tOaWqz+7dMH4+tVW g1hFH5RfJjSeaO+Ji56G5LLde1b1eUwRXYGsvq51PF/bdXF9dWr2xNrtvXMa9WkEYUBeruUF jN7RwhKWzU3Zoolz+pAJ0aAjqiqOESA57KCmPkaMt5rhxmxGoRpYLFfhCliPRIFARZbPcXmB zGFUY/5TVaKhfMZCleysJHNSWSXk83V2S4mOvBDOM3evE4J20m929hV93uIfr2xJ6tR33NbQ ZGwlNjo8/dxI/cLuOWu8Uflwd31vYz/X2CItWnWv/JUeRBQ583t6nD4OcdjGEDkoWxGE46Ta Y8XaqTYhoFBQsKiMJhJHjwxIZhOFeFjyBDiTzsyxNZBAQlZBIDoGB/MwmhpTMb5sMZ8X35C0 WSYncRVhYxcM188YLj6vroCpZOKzQCsD5eL09NDTu9ujGnU5A7t8vZuKeaZIpF4ZM534zdqO vs4l5JKtHqUQXT2ev+C6wQNnxkp1KT7uLtUjYEvXf2vtK5TWvuWVLzsi5dYH937yRryfqH0O 2yuscRcp7U1aQ9+mb6ty5fYkH+MP/Afbjz/tTdmhlXZ9uE9Q9s64TyBqvFDR2LyVK5b3zOcX Xrh4YAI+bYcKOpRexfg5aWb73ZNE2fUSZResQr5iMA9W4p59OfTAfOBhIVyIu/0BmFCesiK3 rCiqwQiwdGlXLtudm9PdNJ7NKntv8gV84189tOerJ+HkmfMGyjt30oKp4ZwA1455Y5584n9B VKch/98SugC6FNlxTlQakCpC3wEJlzAS/3OIMqFP4jMzhJOhlbsNDCoTRP4fhWsHKMX3PzmY DxEy95uHHnpsjbntz0BLTnfwD39ZVj6vlY/L+9R96nsUr+ZKr/0Nksnb3AplbmRzdHJlYW0K ZW5kb2JqCjM3IDAgb2JqCjI3MzUKZW5kb2JqCjM4IDAgb2JqCjw8L0xlbmd0aDEgNDY1NjAv RmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCAzOSAwIFI+PnN0cmVhbQp4nMS9CVxc1fU4fpd3 3wzDnpWEEAYIhEAIzD5kIewmJiRk0xCThgEGGAMMmRmIRGvirlFrWq173bVaW0PAhRiXVK1L 1WpXtVoTl1q3qG1dWjXhd+59992ZRL+139//9/n8wffOeeeee/Z77n0DEYQRQqloJ6KoeeWa cicSX6Mfwu2k9t5Av/E8oiGE32kfjNlbz373bSC8hpDV2tnf1TuypBfmWIHGXu7qGeo0+M9+ GqH8/O5goOOFrZ4VCN13JxC93UCYqE34HKG0h+B5Vndv7DSD/956kN/RE24PGM+3gf7UKb2B 0/rTHpoIY2mHgGjvC/QGZ78283WE0vnj5P5wNHbZWy/djVB5FkI14/2RYP+W3ateQGgrPGcO sx+gXLZcXDPoFSgbofE34AJbx989euL412wLKjh66vghOhG0zzIu+VWIzkWz0LvoSvQo2oSe JRQ14HloPdJwFpqGCK5Ey3AGmooYtqFiVICWoWY0GZ2I/opT0R7kQO/jRnQWLkQr0fUoH61A U1AN+iG6CZ8w/h46C/0eh9DdMPtOXI1mo+V4yfhBtAo1jz8AOhBagK5C1+I0lAsjNlww/jpI iKIL0IPoT2gcbUBXs5tASjNajfrGH0Ab0W/xBnzK+Ay0FPWhM9HV6Gb0MHobX4gPaGy8FXlQ G4pgC56Ii+nZ43ciP3s56b7xJ8ZfRBnAfzNI/ZCUao3jH6Fq9K6Gx7uhEiYiF3z3oVvQ/eg1 nIU9tA6lITfo2oTOQHtoMdi4BF0Evj2IT8d7aNr4beCND7WjHegQPg0fIHnsZfbJ+HY0Afxz g6W70G3ol+hx9AFIa8Rrae/RxeMrEEZWVIoaQNO56Hx0D0TuMfh+AqfjPLwUJP8Sv47foH30 HZD8U3QYfY7+hYtxCJ9JFpOzmfPIWeP3oSLwsBpkLEUnox70c1yEq/EpMPd6so2cSXbQ++lr WrH28bh//HGko3LgPRv9DPz6Dfo9egny1Yib8J/ImXSUnT9+OthbjrrBi3PR7Wgf+gwznIRT 8CRsxy7sA89OxwfwGySHFJD1tI3uYZeMD41fivKgVjahIMw8FZ2DzkMPoBfQm+gDdBhPh5nl MHMxbsaX4svwE+QFejLdSK/UqrUrtbu1x7SvWSZ77Ohvjx6CqHM5FagJvjehTrQdYj0G34+j P2OKs/FMkLQInwiSNuNOfAbejX+Mb8V34PvxU/hF/B7+GP+bZJFLyBVkP/kVeYG8SHNoCa2n N9LntDztz9pXlsCRnKOPHv14PHm8dNw1vnv8+vFXxw+LLMyAil+M6qC6tkAvOBftRj9GP4GY 34ueR3+Eujsovt9Gn0AOvsI6VNM0sCgfF+DZeC54dzJej7fhXfhyfBt+Er+B38ZfE0RSSD58 lxAvOZFsJGeTD8nX1EYLaA09jV5Ff0e/1IaYE77vZvexT/S3LYXW576+7sjrR9HR0NErj143 7oFa1KHyJsKac6NaqLkTIcsdaCt8R9Ag2gYx2g4Rvx4qZw8aQfvR0+g5iP0L6FXoUNxe/v0e ZOJTdAQdxQTyybAVvg3bKyAzdVAtrTgIuTW+T8dn44vw1fB9Hb4B3wzx/S3+Hf49Pojfwp+B T4iUkRpyAnjUTE4hm+B7M2knZ5GLyb3w/RvyJ/IqeZN8STNoJs2ls2kD7aIX0l10mN5L/0D/ qBVpNdoSbYv2lPZb8HwJW8o2s3Z2MbuZ3coeY79mb7Nx/XL9Fn1Mf9dis3gtzZa1lossd1n2 W16zjFtnQz01gfVzUPzrcnyKVk5243EyBn4/QmL0WXIFvjuBA7FdYEEH2kzG6MPkJ2fspm/S n5OzEdLqxfAi6GLPoYfQc+z32mT2LnqKTEcfQT+8ggbII+QakoW9dIF2nvYcdJ0hsPNWcpBY yB7g+ACysRmtw9PQP7ST0McQ/xfYLohpI3kd302eJCdCJb+MbiP70TXoJhTEPrCuA92HvkQ/ xPuoHd8PdbcDvYg+RIfi1mrlR2rJYj2LDOrzIUP78Krxp8ic8Q9g1b+Bz0Ov0i+h9k/CK3A5 ugO9BVn/I3bjXO2olo1+C51vJroOqvZvaBTW4K+1WbCCPkP7qBtt0A5BzsuPPHO0nsXoOfhz UgPpnCo690rejaEHXw29ivfRNLQHKgG6iFjRH6DncT5E8ff6n9G16DL0IJ2MCuntZCcZp09r dvQjdIguB63fh/40A7tBUi8KgR/28XeO3gYSTkV+5MdteAOqh5ElaOZ4L1h+B/Si6vGN49ew FlaKfoOX48noUeheWRDFK1nS0cPAeS+sw1fREnwxGj3agQ7AvpKFC7ETqukwG2S72c/YvewR 9rzuQKfBqr0Osvgm+hR2DTtuh1i8j76AWq+F1TMX1k8NWLEE9rAe0kIfRnV4OuqHHlgMfbsW YrABMhkFKWejS2A93Q57yG/QJzgDb0SPoJdh5UyFdd4O+q0gZxlaB1mPojugO56DR4HSgWai EojTlzgN+0kM9PE+eyX02QNg02voHegc48KuuXgBrofstaMv+FoGDV7UjPfCnnw/qoSdsp4+ h/6KZsHuWgtr9DaY1wq1kYZyUCV7CxM09+iKcT8J0YfxFNgN06Cq1sLOvghvBSvSwY8jaDJe iTxHTwBpd0Mva2a3V9esrV5ctWjhgvmVfp/H7XI6Ksrnlc0tLZlTPLuocFZBfp49d2bOjOzp 07KmTpk8aeKEzIz0tNSUZFuS1aIzjRKM5jYUNLbah4tah7WigiVLyvhzQQAIgQRC67AdSI3H 8gzbWwWb/VjOauDsPI6z2uCsVpw4w74QLSyba28osA8/X19gH8MbVq0H/NL6ghb78GGBNwl8 t8BTAc/Lgwn2hqzuevswbrU3DDcOdu9qaK0HcXuTbXUFdUFb2Vy015YMaDJgw1ML+vfiqVVY IGRqw/y9BFlTwajh6QX1DcPTCuq5BcO0sCHQMdy8an1DfXZeXkvZ3GFc117QNowKaofTSwUL qhNqhvW6YYtQYw9xb9DF9r1zD+y6ZCwDtbWWpnQUdAQ2rh+mgRauI7MU9NYPT93+dlb8EYRP qFt/QeJoNt3VkBWy88dduy6wD9+0an3iaB6/t7SADJhLChtbdzWC6ksgiMvW2EEbOa9l/TA+ D1TauSfcK8O/YEEDp7Seah9OKqgt6N51aiukZvquYbR6KG9k+vTqfeOH0PQG+6616wvyhhdn F7QE6mfsnYR2rR4anVZtn3bsSNncvRmZRmD3pqVLJCU1EQmqMYEJdo4tW60ii7lFBUuhIIbt 7XawZH0B+OTnt6Af7Wr3Axt8tWCYNdwBGQkNJ9W17sqYz+l8/jArzCiw7/oMQQUUHP7wWEpA UvTCjM8QR3mdqFKDcRMfLi0dLinhJWKpg5yCjVXi2VM2d3CM3FjQn2EHAOFDzRDbQMv8cgh/ Xh5P8MVj1agNHoZ3rlpvPNtRW/YIqi4vbRkmrXzkgDkyeR0f2WmOqOmtBVDJ9yL+gjJ52Fqk /kvPmDKxoXv+MJ7yH4aDxviyNQXLVm1Yb2/Y1Spju2ztMU/GuF+NSWx4Yt16mk0kRrKpGIWi 3KiY+cP6lGGtEP7TRVF3jFmsUJWCgu2NwxmtS4x7iy0v77+cNDb+CZ8lQHyaNHN4fumxzwuO eT7GvJRdFAzWisiytRt27bIdM9YIHWjXrsYCe+Ou1l2BsfGdbQX2jIJd++C4MntXf0OrmdGx 8Qcvzh5uvKQFnOjG86FaCardW4AvXLW3Gl+4ZsP6fRnwHnbh2vUjBJO61tqWvbNgbP0+O0LV gkoUlT/Z+RO8OEGljxCrGMreV43QTjGqCYJ4bh/DSNCsJg2j9jFi0DIEDb7KeO4teUcb0MkZ 6KuLjhaBMRgd+9XCKfou9A+0EIXhLEngraccdi9kuSBzGE6XBHg2a9vhTgX/UXHnOIYd7ajE oR8Sq8Qp6sF/kriGivG7Emcoi0yQuI7mklqJW+D8Y8qxoiLypcST0PlJ+RK3sZOS7pR4Moqk mfwpqDO9X+Kp+r2kT+JpaGP6n5SvOzKcEscoPWOvxAnSMr0Sp8ibmSNxDU3KLJI4QymZCySu oymZayRuQT1KjhVNzNwj8SRUN+lxidvI3ZN1iSejyqkmfwpyTX1f4ql0Q2ZI4mloXlYOWII1 HvW0rC0S14C+TOAM6LasaySuoZKsIYHzrOlZj0tcQ0VZtwrcwvOS9Z7EIRdZzwjcCvSUaZkS 19DcrL8LPEnm18CN/Bq4kV8DN/Jr4EZ+DdzIr4Eb+TVwI78GbuTXwI38GriRXwM38mvgRn4N 3MivgRv55biNx2raIolDrKYZMUwG+oRpWySuIec0I4Yp3JdpP5E42D/t+wJP45U/7QWJa6hi 2h6BZwg5P5E4l2PwT+QxnzYucYj5tIMCn8TtmV4ocbBnOhP4ZKBPmr5G4hpyT3cJfIrgv0Di nL9L4NME/30S5/w/Fng2r4Hp70kcamC6kdMcUQPvSZzXgEHP5fzZEyXO+f8p8Fm8BrIXSRxq INuIWwmPT3ZI4hCf7KUCLxNyfihxkJO9lePWhPhbE+JvTfDLmuBXSgJ/SgJ/SkJeUsy8rEVD cAIPwpt+ALUDtKO74FqLugXeBP2qD66Y5LLD23kY3nr7xT0A9JDgsAOlB+bPA6xe0AP/HyWV K8vsaA2M9KABxRMFGn8/MvQ54IxdiSpQmcScgloDM3oAroY5XWBDTMxaDfKicPH39iC8L6yF 0V5Bs8OpPwjv8pwnDLQAyL9H2M+t64AxTougLUALQ7T+7z2zAzUINoVAa0zYwi2xwzPniUmp 68BrO7xJ8Pl2VCT0NcF9JejuFB5yC/m8IEiNCtu7pbR537Bp/nd4aoe3Lx7jDuA8SUiJKqtd IK8Cvu3wltYE1HYYDcM4j0IMzUmQbMiNS20GH8qU5CbgXAH2r4XcNcJVBzni+Eqgcr8a4b5c 0BuAsgbuPIsngLwG+G4S1LUoFdnExaMfEt7EvlHBJt2IZL+wt194xXnN/H0zb0bFhSE3PG/9 MH8oIc4hWUMDItpwkhSjQ8A/oHS2w9NgQk4HxFz+HLfHyHmv4Dcs4WulR0Q2KKo7KGhdQkpQ xLYPZvGct0ht3TA+KPjCYAdfbbx6DJ2x/xAZM2vbRC0HRfWEpGXcxg544vR2oPUI/zpF9Hq/ NV5h6RePWDBByjYp89v0dci6jwBsE2vasLpNZqZPSv62DM0WXh0bKV53876lKr6p2aDzWA/C nfeTAGjtkdGOCmmx/1H3PLEm+wR/VEga+kYujDwdu6J5dAytUSGnHaidwoP/Jud2WYt9oov0 wVNcL+9KHSLSxkoNiH4XSeh3cxV3JKFuDf9i3xmpHrGuQypDhidxedtE/reIbCZ2uU5ZF3HO MPAa/W9ARJzL71b+GHYlVjfvHrwajPgbq6pf1odZpcfX0H/yKF4fS4Xv38wcjzCXvxXoQSHb 9KZdwHaR1b7jchA5Lt5xydw/jvWIyHEbBoHP6LpmH/hvsm/KM9YkX6uDMhvxNWbK+2YejWgZ HsRED4h96zo2MxY4Ltad/ytr41H+poZ2ucu0yadEiwx/eAXNVxL47lcD1DKx6/iRG/lgp7HD 3QFPZbAbucWexE+469AyyVkBow4YcUvcB3uXT8zyIg+cDPjFpfNsxcCy+XDKKId48e954Mfx K75ddL7/aZ/gWL1YndtUXRi7c0h2W27TGuGn0TeGZPQjok65VL5CTxL8MZmD5SJ7HaoC+JnG BWeaeGeLJJxF4h3sm72+U/TyqJDCdzM+GjjutGFKN5/NM03iacGog+XC3g65KvpELfOOFpA7 69yEOtombG0X1RkS+reJDmsXfkXFijF2K77q+VkuJlejsXp5l+BVZqzGPrUXtYlVEBaWHb9X mHVqdKUe8TmyXeTUiACX2i4iw7t3p1ib9mMqNCLiEz9jGraZEQnLlR5SnbbjmNxHhe6gXHm9 8sx47AngP9fCbBmh+A5s9iBjb/zPdWKcE7+Zv8QIGzHqk5b2KVpEdJkukS9jnQbRaWJl9ols DcpdwdjbjBgNJpytzKgaVTQoznuDak10ik6ZeDoIy3O0UXPfvsv/d2vM8K5WVI5R12Flv1GX IdWfot+IuFFzHaojdYgaMTvSgPDd0NksZPWLE8KA6JPmqbAZfI3vz3NVxZvV3Kv2lrDcDaLC 0x5Zdd0ij2YnjMidjXsXFZkfOGb9cGv5ijt2T+5S+eB+87j0CPlGhjnWJXbKkOjixhm4XeS8 X4weu590wUhYvlm0y9z0whwj1icDX4fQMITMvTveT9rE3C3SViNCvWKvCKDt8owaPaZX8Fo3 3pTME0v4mB7aIepr4JgsmpID4s0nnCDNOBn0i5wMHcPZIc/lMcFh5HXe/3InKBf8vSC9HO4x 0Qm4XeXiNL9ZyDZWndEfI+pNaJ6a+f9W4zaRCbMn/r/QYo6VH7fjK9lrh/qDnYH2oP0u+9ru oL0p3BeOAcleF470hyOBWCjcZ+/vaZ9nrw/EAt/BVM6F2deEewY4JWpf2gfzHJWVFWVwc86z 1/T02FeHurpjUfvqYDQYGQx2rA31BqP2FcFt9tXh3kDfnfa1kUBHsDcQ2WIPd/5HZfZIsCsU jQUjwQ57qM8eA9Z1a+zNgZi9yL62yb6ys3OePdDXYQ/2RIPbuoFtnilp/nFK7bXhno75JwUj US7aNa+iwl7cFGqPhKPhztgcwQy8grV5TRlnblq7YuXapY1L62rWLl25wr6y0b58aV3DijUN 9poTVjc0NDWsWJtqS7Wt7Q5F7TEzwBwHI/sj4f5gJDbE/VO+QeDCXZFAf/eQsDkEERqIBu1t Q/ah8ACf2R4eFJ4O9HUEI0IOeN4b5UIC9p5Qe7AP2ANdkWCwN9gXm2dvgWndgcGgPdwWC4T6 YGbsGGO4a9sCkaA9GAJhEXtHKBJsj/UM2Tsj4d64XWHQFe4KCpZtwBmf1wGxj4TaBmIgGswM 9wUTHZodNY0KRuepUKjJgAfsg4GegUBbD5gdjQZjibPn2df19QSjUeG88AJ8komOhWFqtD/Y HuoMtX/TcztEsS8W6usScwMdHSFeL4Eee0TU3VxOjojYgr7Y8Ub1hHpD3CFQIvi2hSNbojGj 5DohFoIY3gb1N9DWE4p2cz0gywh3b2DIDvZDqvqHeODiETpWkYjH0s64c4G+IfvWgWBUqGkP 97UHI33Sg4i0WzBHu8MDPR1Q94MhKF1eA990n/NBJoMhWFtGxjif8hHMAgWxQHssnmPuWEBa 3fntYoXJakI7LJm2oCkI9ARi8znDujU19jJ7sd/tm2P3OfxlFe6KiqSkdcuAWOFwuN1w97l8 dp/XU+mpTLV1x2L988vLt23bNq/XTHx7uDdxTQTt9ZHANh4LWM5gFEhaEwtAbQyB+ZFQNNw3 135SqD0GHiwPRDp4AByVLqcotojoIqLAVNV3hiLRmD3Q3x8MyLbB2TnkncZoCxCD5eG+DkhF X3BbtD8Ai3WuiNG27lB7NyxN+7ZA1N4RjIa6YFnNs9uXxiCNkN6BtmgQ0tjHV1FbEDwJmquC xxRKqacjau8NgwHRgfZ2KO/OgR67EdBIUNRYFKRxQ8C1rhAv2g7D+6h9G1Q/FFhHUDaA46IA y81YwLyCYDUeFxPoico/w2CwqA+E9nEsEh7o6oYitAdPi0HaoXLAySBvtIOiW3FTIUSD4Z5B nonOgYjRDmBt8MglLPlvyRioqw1EIdZhLh9iGeL1FDUNh8h18ELqGBCFNBDlM5uDkf5gbCAg WmFzj1jPc3ngeZh7+WqBFmyPxoYgte3dgQgvQpAWC7VH7bDcRH4CHYF+uZK7uB/B09qDPT3c 4R7YNtpCPSHowO3hgf4ec510hcOwWYAt4d4hsPrkUEcQEjkQNeqkLRzeEhUG9Qa6Atuho0aN qogEYVPijSVsVGhHuH3AcJEzB3qiYcEGzaC/J2B090AH9PJYiPs6739YBOXdsd6e8t4Y/+3U 8t7o5hhPHdRjhG9C8/jgfzlxW7CHV+J3T+FP5XLhC+7v/Ih5hTiIRsQhOvCd3HDQxqmAvfed nJ3ouz/Kt6NGoTf2XXz0QvowfYI+Cve9/7VHof/Ko+UwbnzkFBYzBr5zxgni1cD8aJIf9r/b y/fg4LYFfQ5a3oPZ38V/kpD8XVxLxFF7UET6u7mbkfER+oB45TA+mvzfRPI7vdRytSptgVan eTW/Vq0t0pZpld+pYe1/XU/LuLfYAfh3cxqvL1u+22acid6kBfD03VUSFq8xAePn5+JrPA89 jr7lS9+FECaYIv4TbIZ0ZEFWlIRsKBmloFSUhtJRBspEE9BENAlNRlPQVMR/c3w6ykYzUA6a iXJBYR7KRwVoFipERfDuXYzmoBJUCm9iZXDmLxefozmRC7mRB3mRD/lRJbxVLEAL0SJUhRaj alQD79918JbeAMV3ApTKUnQiBGY5vGvzn/Y0o1Xg3hpwex0U28loPWpBG9Ap4re4vwdvMK3i M6x28U7ZKT6DCKFTIaA9EJA+8VnkVvkp1oD4XdvT4P1kOzodnYG+j85EO9BOdBY6G52DzkXn ofPRBehCdBHahS5Gl6BL0Q/QZWg3+iH6EbocXYF+jK7EGroaXYOuxQxdj36CbsA6ugndjG5B t6Lb0O3oDvRTdCe6C/0M3Y1+IX4TfBjtRSNoFN2L7kP3owfQGNqHHkT70UPYgh5Bj6ID6Jfo McjNE+hX6En0FHoaPYN+jZ5Fz6Hn0W/QC+hF9Fv0e/QH8dvLL6GX0Svoz+K3gv+CXkcH0SH0 BnoTvYXeRn9F76C/oXehON9HH6AP0WH0EfoYfYL+jv6B/ok+RZ/Bgv4C/Qv9G32JvkJf898j RuMYYStOwjacjFNwKk7D6TgDZ+IJeCKehCfjKXgqzsLT8HScjWfgHDwT52I7zhO/czwLF+Ii PBsX4zm4BJfiubgMz8PluAI7sBO7sBt7sBf7sB9X4vl4AV6IF+EqvBhX4xpci+twPW7AjfgE vAQvxSfiZXg5bsIr8ErcjFfh1XgNXovX4ZPE72O38H8XgDfiTfh7eDNuxQHchttxBw7iTtyF u3EIn4q34B7ci/twGPfjrTiCoziGB/Ag3oZPw0N4Oz4dn4G/j8/EO/BOfBY+G5+Dz8Xn4fPx BfhCfBHehS/Gl+BL8Q/wZXg3/iH+Eb4cX4F/jK/EV+Gr8TX4Wnwdvh7/BN+Ab8Q34ZvxLfhW fBu+Hd+Bf4rvxHfhn+G78c/xL/A9eA8exnvxCB7F9+L78P34ATyG9+EH8X78EH4YP4IfxQfw L/Fj+HH8BP4VfhI/hZ/Gz+Bf42fxc/h5/Bv8An5R/p72H/Af8Z/wS/hl/Ar+M34Vv4b/gl/H B/Eh/AZ+E7+F38Z/xe/gv+F38Xv4ffwB/hAfxh/hj/En+O/4H/if+FP8Gf4cf4H/hf+Nv8Rf 4a/xEXwUjxNEMCGEEo0wohMLsZIkYiPJJIWkkjSSTjJIJplAJpJJZDK6kUwhU0kWmUamk2wy g+SQmSSX2EkeyScFZBa6ihSSIjKbFJM5pISUkrmkjMwj5aSCOIiTuIibeIiX+IifVJL5ZAFZ SBaRKrKYVJMaUkvqSD1pII3kBLKELCUnkmVkOWkiK8hK0kxWkdVkDVlL1pGTyMlkPWkhG8gp ZCPZRL5HNpNWEiBtpJ10kCDpJF2km4TIqWQL6SG9pI+EST/ZSiIkSmJkgAySbeQ0MkS2k9PJ GeT7/N9SkJ3kLHI2OYecS84j55MLyIXkIrKLXEwuIZeSH5DLyG7yQ/IjdB25nFxBfkyuJFeR q8k15FpyHbme/ITcQG4kN5GbyS3kVnIbuZ3cQX5K7iR3kZ+Ru8nPyS/IPWQPGSZ7yQgZJfeS +8j95AEyRvaRB8l+8hB5mDxCHiUHyC/JY+Rx8gT5FXmSPEWeJs+QX5NnyXPkefIb/m8eyG/J 78jvyR/IH8mfyEvkZfIK+TN5lbxG/kJeJwfJIfIGeZO8Rd4mfyXvkL+Rd8l75H3yAfmQHCYf kY/JJ+Tv5B/kn+RT8hn5nHxB/kX+Tb4kX5GvyRFylIxDu8eUUEo1yqhOLdRKk6iNJtMUmkrT aLr4rf8JdCKdRCfTKXQqzaLT6HSaTWfQHDqT5lI7zaP5tIDOooW0iM6mxXQOLaGldC4to/No Oa2gDuqkLuqmHuqlPuqnlXQ+XUAX0kW0ii6m1bSG1tI6Wk8baCM9gS6hS+mJdBldTpvoCrqS NtNVdDVdQ9fSdfQkejJdT1voBnoK3Ug30e/RzbSVBmgbbUcP0w4apJ20i3bTED2VbqE9tJf2 0TDtp1tphEZpjA7QQbqNnkaH6HZ6Oj2Dfp+eSXfQnfQsejY9h55Lz6Pn0wvg0HYR3UUvppfQ S+kP6GV0N/0h/RG9nF5Bf0yvpFfRq+k19Fp6Hb2e/oTeQG+kN9Gb6S30VnobvZ3eQX9K76R3 0Z/Ru+nP6S/oPXQPHaZ76QgdpffS++j99AE6RvfRB+l++hAcCx+Bw+EB+kv6GH0cDoq/ok/S p+jT9Bn6a/osfY4+T39DX6Av0t/S39Hf839rQf9EX6Iv01fon+mr9DX6F/o6PUgP0Tfom/Qt +jb9K32H/o2+S9+j79MP6If0MP2Ifkw/oX+n/6D/pJ/Sz+jn9Av6L/pv+iX9in5Nj9CjdFxD GtaIRjVNY5quWTSrlqTZtGQtRUvV0rR0LUPL1CZoE7VJ2mRtijZVy9KmadO1bG2GlqPNhOOT XcvT8rUCbZZWqBVps7VibY5WopVqc7UybZ5WrlVoDs2puTS35oFDlg+OWZXafDhyLYTDVpW2 GA5dNVotHMDqtQatUTtBW6It1U6EY9hyrUlboa3UmrVV2mptjbZWW6edpJ2srddatA3aKdpG bZP2PW2z1qoFtDatXevQglqn1qV1ayHtVG2L1qP1an1aWOvXtmoRLarFtAFtUNumnaYNadu1 07UztO9rZ2o7tJ3aWdrZ2jnaudp52vnaBdqF2kXaLu1i7RLtUu0H2mXabu2H2o+0y7UrtB9r V2pXaVdr12jXatdp12s/0W7QbtRu0m7WbtFu1W7Tbtfu0H6q3andpf1Mu1v7ufYL7R5tjzas 7dVGtFHtXu0+7X7tAW1M26c9qO3XHtIe1h7RHtUOaL/UHtMe157QfqU9qT2lPa09o/1ae1Z7 Tnte+432gvai9lvtd9rvtT9of9T+pL2kvay9ov1Ze1V7TfuL9rp2UDukvaG9qb2lva39VXtH +5v2rvae9r72gfahdlj7SPtY+0T7u/YP7Z/ap9pn2ufaF9q/tH9rX2pfaV9rR7Sj2jhDDDPC KNMYYzqzMCtLYjaWzFJYKktj6SyDZbIJbCKbxCazKWwqy2LT2HSWzWawHDaT5TI7y2P5rIDN YoWsiM1mxWwOK2GlbC4rY/NYOatgDuZkLuZmHuZlPuZnlWw+W8AWskWsii1m1ayG1bI6Vs8a WCM7QfwLohPZMracNbEVbCVrZqvYaraGrWXr2EnsZLaetbAN7BS2kW1i32ObWSsLsDbWzjpY kHWyLtbNQuxUtoX1sF7Wx8Ksn21lERZlMTbABtk2dhobYtvZ6ewM9n12JtvBdrKz2NnsHHYu O4+dzy5gF7KL2C52MbuEXcp+wC5ju9kP2Y/Y5ewK9mN2JbuKXc2uYdey69j17CfsBnYju4nd zG5ht7Lb2O3sDvZTdie7i/2M3c1+zn7B7mF72DDby0bYKLuX3cfuZw+wMbaPPcj2s4fYw+wR 9ig7wH7JHmOPsyfYr9iT7Cn2NHuG/Zo9y55jz7PfsBfYi+y37Hfs9+wP7I/sT+wl9jJ7hf2Z vcpeY39hr7OD7BB7g73J3mJvs7+yd9jf2LvsPfY++4B9yA6zj9jH7BP2d/YP9k/2KfuMfc6+ YP9i/2Zfsq/Y1+wIO8rGdaRjnehU13Sm67pFt+pJuk1P1lP0VD1NT9cz9Ex9gj5Rn6RP1qfo U/UsfZo+Xc/WZ+g5+kw9V7freXq+XqDP0gv1In22XqzP0Uv0Un2uXqbP08v1Ct2hO3WX7tY9 ulf36X69Up+vL9AX6ov0Kn2xXq3X6LV6nV6vN+iN+gn6En2pfqK+TF+uN+kr9JV6s75KX62v 0dfq6/ST9JP19XqLvkE/Rd+ob9K/p2/WW/WA3qa36x16UO/Uu/RuPaSfqm/Re/RevU8P6/36 Vj2iR/WYPqAP6tv00/Qhfbt+un6G/n39TH2HvlM/Sz9bP0c/Vz9PP1+/QL9Qv0jfpV+sX6Jf qv+Azesb6OnJ6Av38Q/0Qn1dkWBsINJHewcctD/koCu7e7WGgUjY0tEbaI+E+5L4R+XR9nAk qPeGOjrCMb2mLRIcDOoBASw14a5wX3CLJWBAvb49ALP0DgPUR3sC0W5Lg2QKSqYGYzRogOWB 9oFYUO8xwHKD2COAthw0aj1c7QpjuM8AKwyuPgGSVna0GbOTwiamrzZARD4Z/BEDrDGIUQGs a9uDHaGenoA1JhF9rcEWE4Cti0CY2AC/J61TmgaUpg0G2C6AtoFbvB1u7IRAb2+Are0OxgK0 uTvEAj393QHWEeyJBSzB/mioB2RHQ129ARoLDND+7lCq+DhSBBuEJwVPa+8J9HKsLzrAP+wL R/T+YBTEJQUikfC2nmBnzCKwgX6bgOLjbWOwI7ytz8DawrHuJMnW0ZeisLZo0BaOxLp5TgI9 KSH+Q4Go8alncnDrQGgw0BPsaw+y7vBANJgKye4Jd4XaAz194ZiNM3dFAj2xfoW2xaxrGh0V /IsjDolUKMRlIk4TcZuI30QqTcRrIj4T8UjEbcpxmtM9pgqPKdllynGaFKfJ4zTleExT3Saz yzTDqRBTu9O0x6UQc8htqnAopaZkp2mqWzGbkt2mPW7llynZbU73KAeVHEGxDPS39YTbt1gg hxwy46mn04CRmHyORbsDHUEm7paOLQImdUKBQ3WFT7MZGP+c2xKLhAJdA/0GjMjnjj4D9nTq 7aFIe08wKdQ32AbNIxjjmKRFe0M94scBUECD6oFGB/r0zmAvlJDGbyzaD8q19p6BNtYdDICK jlCgN9zXkdw7EJVFFUxLwKHqydITSejU5L4A/58IRML93bwD9Yl1yz9Y7kgKdIZCXofT7Tcx f6W+BDLuc+lLHH6P2wAehwAuly3cH+wz7LfUGM3NEjBgch33ZqC3syd4WnJ7HNfq+GJuh5ul Qc4IGlBvMLpgUACtgfMF4ZZ8QoKkrgRJJ3COLrhZTzDbTZdEkpckzOlOmLOkLRDRuuGmL42F ejqCekgAy1JpS0jastSwJWR05KWy2YYMmHxigvRT47h1mWnHFomkbOE/oerrCfR1hNqty83h HhNZYSJ9EqENfV002NdlWSkNCkuDVhoGhQWwrjbnRUyH1ySYFE1weC13OMYdXmc4PGA4vE7K H5Dy1xnyBwyH10mHB6TDJydI35aAtyTgQ3GcQR/uitpqeH8XLRx6qYlaahoMGAgKmLxSbGgG Ho7jSQFetD3BUEA/GZoh2LbNACcbe8M2g+vkjlAwEoyGoknbTExvMRiHBEjdOhDmP5vle26w IykS6OALIniaqPAKf6XbkcR/stkbgBWSBM4GecPvTol1Q+IMPJrcGRo08ZQoSOozB9rDsB8F 2tuDfbEMsdMkEFgs3BeOpppWiSdbDd+wBJrSYOxX4sHaEDOoSUvDEktZ2ct/xG+Mp6xLYLat 7A12GUyZIWA/RgMTGrRa2NJYvdgXpR5tA980QY/GVbBlgf7+AJwTets6AqRpgKwYIOtDFqmT NIfo6u4wWyO20rWBAYvUT+u6Q7Q5GkpZmqA3XQ6az7ZA3MlgopNB08mQ6eSkgWOnCqLWxo3v 4lu9tp0bzR9jfM/X+ES2RZjeY5jeN0BOC8EqEXbTSHdYF/u/wyIl03awGFAW5kFLSYxX+nHK U8KJER9IjHhYRVyUDew0TpeJeRwKcyosPupWmEdhXoX5FOZXWKWJeSsUpnR4TR0Ot5LnUFIc SopDSXEqKU4lxaksdSr7nEqeU9nnVJKdSrJTSXYpyS4l2aUku1QMXEqHS+lwKR0upcOldLiU DrfS4VY63EqHW+lwKx3xuLiVDrfS4VY63PE4qxleNcOrZnjVDK+a4VNW+ZQtPmWLT9niU5J9 SrJPSfYpyT4l2a8k+5W/fqXDr3T4lQ6/0uFXOvxKh1/p8CsdlUpHpdJRqXRUKh2VSkel0lGp dFTG/YhLMXUArjCHwlTtVrgU5laYR2FehfkU5leY0uFQOuI2e+K+GTP4AjCPMy6PE85uwcGA DfpToDMa7Ar3GGg/3LqTBboVTjCxKOsORUJbWSwKvYEJRiZ4dHM4DA1I3zrQNhCL6h2BrmC0 m/UG4dzOegNbA51aJNAZhBnR4FYL/zUc/roVFcAaDYO26MBWDXahTgq9jnWFeoM9rAOeY6Q7 SAcDg2x7YCjUR6Hn0RhcQ+EOayf/hYstgU4KFwPdQUnqDfZSuIyHvoE+Che8hvUGt3RrXIhF DPQHSX/QJtBYFDogE3e6NQyWgukatxHemQaTOsIDbT0QoUEdLtArCYDpXbxNdicBgC16KNSb yn//pDu4NdjDf9XEBvzS01TTVhHrNPPJiJxN2C7ClxFHjQhawDpuczIXJIXZBC7QTEESnHIw I4EiCEk8qCJRNo4ZKgWxN9Af2poE4TbYk0XQJS5Cb+DW7qCBJIE/clgkQ1JjJmMShMTAlINy QGHJwj9JhRxJDBJkYClGmoyHVJknaYaJJItEyZmQLgOz8UxINB4Ca0yabAXbRVgt4C+vRAvY xCG87HIgAiKMm7A9CO+uoY5Yd1+479RwqC8YSVck+cxfimNh8SLMP+BIF1gszMn8Wawtj88l O43H55arm2M+hVWamOzogMmdk2NOham5cufkmEdhXoUpyR5Tr6vSqTCXwtwK8yjMqzCfwuJS lKUVytIKh/JS2Sz3ZK/L4Y3bYs71uE0LPC7lh7TF6/TLUY7FaYZ9XrdTRohjpo5KFQ2X3A34 qNOcq6zyVCg+r2mLy1ehMOWHT8XKp2LlU3N98Vgpf31xz6U8p1PF3iN7ttdZKWkck3EGzKf4 PMrmSoX5FBaXZ9IqzTiDlEpFq1B8SpvX9Mjjjc+VHjldUi/HvGpuXF58hkdhis+j5kp5XgiQ S2FxWqWJedVopfK30sylP26zPPEATe5lQFNZrZSnFj5qyvM745ip1+9StHg1+eO1oWrNHx+N Z8Gr5saxSstAX8hZ4ayRsFbCegkbJKwzoLfBasDGBZIgJ3pr5UCdOSAkNFZU1EhYK2GdhOa4 0NDY2Fhn1n+FW2EehXkVZsax0owjYCqOTjOOlW5VS65KRXOpeMcxJdkdr2u1Ft3xCjcjX+lR euN8sqtxLM6nJHuUzapuzLrmmJTiNk+xgJkz3OY7AmDmDHdFfJ2oTuLwq/o3u5rT7Gpepy/e ax0ORVPdSsXPF++/Zh0CTXVih1vRKhXmU5jaFRxmzfnU6nU7vIqmJCs/fGpFux1Knjdun1/R 4qNxHXH7lFU+5bk3Pld1e6ca9SlbfMoW1S/dzjhNWe9TMVCd0+1U8fPFLVCW+lRcnEqbX8XF qeTF9xun8s0ft0VZ4Fe5dCod/vhoXF7cPhUD1Yl9/vjcuH1qtFJ5VKliFd8fXHGasrRS+ab2 YbdLxa9SWVCpLFU7stulOlhFfIbaM+J7s0v1twrV3yric1VcXPFRtd/EdyO1K7hVj4j35HjH 9iecY5QOtSr8jvhclaP4Xu+I16SS7FD5iPduVbF+Vfd+h8qHW9msKsyvatfvVPlQncvvjM9Q tjhVPtxKh1Pp8MXlqXyorud3xmOgLHXFT3VqbjwzKuf+eFbj+XAp+1zKZpeyyqX0upQ2t9IB 2erqGervhpdLR7JhAZy9ypzJpjXuBNxR5lTcHoV5zXGfI4HXn4D74nhlorzKBNyTgDvjesBL E1MaXYZGsSPLWeIMl4B7E3BXAu5JwJ1KI5z6ErR7E3BX3BKoBxPzJUTKlRApV0KkXCa3R0XY 40yIlCshUq6ESLkSIuVKiJQrIVKuhEgpPbArmJjS6HUmRMqVEClXQqRcCZFyJUTKlRApV0Kk XAmRciVESlniUzHzuRIi5U6IlDshUirD0N1NzJ8QKXdCpNwJkXInRMqdECl3QqTcCZFSevwq k36l0e9PiJQ7IVLuhEi5EyLlToiUOyFS7oRIuRMi5U6IlLIEOriJVUqMf/JjYg6FORXmUphb YR6FeRXmU5hfYUqHQ+lwKB0OpcOhdDiUDofS4VA6HEqHQ+lwKB1OpcOpdDiVDqfS4VQ6VE9x xHuKuyK+GgF3JeButrI7HOljYXFfJ+4D/G5KUb3DoXqHw+WVJ2QT+iSsnNAe7m0L8X+Y1R0O bwm0hQeDxpCjQkKXhA4J5aHb4ZmkpoofDhk/vzA1ulWU3H5jgrPO2sF/wBPq6rOG+4Kx7lCk Iym2LSyQqLRHRdSjvPB45FijVOyU0C2h9MkhfXJIfY5KCeVbg0O+NTgaJJTynNJRp3TQ6Yw7 Jn4WZDgWJ4ofIRlEKak+Uw12hGNtwZ7wNilLBs8pbXFKW5zSFqf0wSl9dEpfnNIXpxk7+Ybj lLY7pe0uaTvslDWm5qSAidlqVE5tAYVm1MR/5CZcyQgcT0jgEBFI5BCESQkcSvCkwLcQE2WJ MkmUJQgTEzhMyycGvklLNn7fxfiRXyABN+jCLkkXeLpBV5akB459lvOEDXKewNMMuqk2LXDM Y1KDwhTN1hCPc1y+3mD86NSQmtFwfJCDxxMajo968PioN3xb1IPfFvWG46MePD7qDd8S9eA3 abalcd9CCk1aqqIQUthKhYXV7JXx2eG4dSuPdz18PGHl8bEIHx+Lld8Wi/C3xWLl8bEIHx+L ld8Si/C3xEJ0XuNH0+E4KqjCKIMq0DRBVUakhY95NOYI5cYcgaYKqqktNZz4lLROYQPKnnVx gQNxdF3ctIE4ui5u5UDcynXHWjlwrJXr4lYOxK1cd4yVA8dY2aKwIWVlS1zgUHx1tBirY8j4 xQLoYrCz1EvYIGGjAesrJHRI6JTQJaFbQo+EXgl9EvolrJSwRsJaCevkXuOsdCrMpTC3wgz5 7kqnhC4JvRL6JKyRsFbCOgkN/9w1cn6NnF/TIKHhr7u2QkKHhJK/VvLX+iWslFDqq5X++A05 To8cb5D8DeYpxaVOKS51SnGpU4pLnVJc6pTiUqcUl9OrMJ/C/ApTOlxKh0vpcCkdLqVDnVdc LiO+Xo9LQreEku6rkNDYqWs9DvmspLrlTJ+S7jbneiyC4vbJZ+WF8bklUJQ3Sq6fCYp8Mvbw Wq9PQr+E5vwaaVWjpFdIaEqrleMuCd0SmhaaVejyKku8Kq5KS71J8amoxv33mf6bNkhdXqnL K3X5pW0e06Y6CevluJLtV5H0qzz5TSlKr3qj4D/PMTFpsV/a4JNx88m4+cxxaZvP5DOfTS2q 8tTbglu9LbgrZHT9pvROA5oe+s1xqVVZFZdlUmpMisOcU6soMq5+GScVgXr5bI43yGdZZf5G U4JTyqxUljvlnEpZzX4Ze9WD3MZpECguRZG2qp7kdplyPYpiyvUqirS20qco0r54RF2mZBUF 9RkJ/8zKxEzZKjJupVd9UuA211hlnaIoPR7lv7nKKusVRfmpTv9uc3VUNiiK8sLjV5hpvYq3 uepqlD6vku5V0s31UGNyK0/VynN7le1m/6lRktTKc/viNNm1asw1J9eYV9aOV+a5RkXOr2xU 687td0our5wlV7RP1rXPtFhFw6hwoCjLK017VU7jtRWvqUrTXpXTeOXEK6bSlG7m1KPWoEe9 sXsqTKvluqiXMTB2ZoCyomsa1Ay/wsw4exzS7lqlQb2le9Rbusch7a6V66dSxrlSxlnutt5a NVfteh6163mc0uJa2X0qZR+plP2iUlZWrVvNUBarvc7jMi32KIrSqnY6j8u02KsoccynMBnp WkVxK7vVmvS4TbuVNW5loVqTHreMd62y1B3nVzSPab3cwSob5bOMqLk6alXuPcputRo9HtNu cz17vKbcRkVRUVGr0eOVUamTlV0j12Sd1FonPa2TvadO+WmugTpZXQ3ms1wz8pznrZM5ledA b53MbX2dfJY7e4OpwVwvHrOv18lI1MvI1CkfzU5fpypa7Swe1es9laZlKhLy7Oitl143mD5I 2xuk3HqVcbMSjdMvxEnaUi8rV54WvfI07DXXWr0pSXpfb8qR0ZGnYK8ZjXq5buobJJR6GmQ2 zSg3yLyYUWuQehtk/hqkftMTeQr1Nkj9DVJ/g9TfIPU2mtH3qvXlVWdJr7nfNdYqikthboVJ GxrrFMWnML/CpCWNpma5e5s9t0bWSY2yQ60sr9rtvOqTLq9aW161trxqv/N6ZJ9yyN7oaFAj sks6GhVFSVfry6t2O69HSVeffnvVp99etca8ao151Y7n9SoPvEqHOm961a7nVbsenLoVpnSo fQ9O2uhBtHb8gEZHGxqc1WMAS+cJOFI8x7mPD4xMn+F8WKPkGjQb5QIBj0zJFiNopLZWInCW FMhoSZnzYI1NQ+hjuAj/J6So2Jg1WjzP+cmj8IzpUZSOMafSr0czJoE2emQ0faKzuiaD/hs1 w0XQMN2LDsBFUJh+hnbARYB9z0iZgyuie0Ztac4M4P8Y2eHaCRdFN8Edi+dquDj/x6MTp3Dx fxtJzxTzDo5UuA1kNCPL2Vwzib4G9jxDf4cKUC59E+BMgE8BzAH4JH0apQo7bxtNz3DuBH23 AvutdAjNgeHb6XbkBHgnPRNlC7ZXRtIMPa+MFJc4a2z0p/QMwRKlW5EbYA/dMuLMte+nt4Gl 1fTD0aRkbt+HIxmTnQ/T9+gWNAm43gauqbnpD9M+VA4X92RsNCnVubsmhY6Bm2MQllywEaMb xb2a/m4EBIG+u+hONAXGXqBnockAf0bPHpmce2A//UKwfc6lgL5bRqwuDkZT05wHapLoLTA6 TP8BEf+H0PbpaJHfiWqK6CWoAi4CQX0LsLf4n1agHwH2EaTpI0jNR5Caj8CKj5COED0MI4eB p5y+jvrpq2g3XDcCroHIoRGI4D6BzCp27qPfp2dAJDL2Q+wwUM8cTUrjlp0xMmGiYDtjNCXN ufhh+hJaCRcB418enZrlDO+nPxCu7B7NyuYT/jCSlAKhO93IBUzcznPwMN1JzxaROEtEYPgR eMQonZ4jJo+PpmQ6d0D218JjGO6XwfUiXB/DpQHbWvBhLdoMFwX25tG0dGf6frpBTF46kubK fZguAdeXiGgtGZmcL2w+YRSQVfvpMiiSlXTFSEcuGLhqBCbz0RWj/vnOiv10hXB4xUhugUEe mThNII0jSUbx1I3aMrm6esFYOmJNE+RSue5oyeikqc5cKMb5wiUX/7Mj1Ac58kH8fbAYXCLi ztGMCVDiHdQpzHaiVrhugmsYLg0S6QR2JyTSiQ4JSjr1gk9eNA4XhQR60SdwEaA70GK4LoPr UbgOwcUEtRUuAvQK0NAK991wEZBYDs8ZcK+GqxWunXDdBNcBuD6By4JeoGWgh/8tigq474Rr GK6DlP9FijCdC3bM5X+vg9rREStCuWgHuaZ6Pt6BduAdZAfdoe1gOzJ2ZFqrPYVzndWn8ts8 fiuGm681qT9pZxKtSKpOak6iGUn2JDI2fmDEMt8FoHqCPt/156b3m75sohN8u/XdFvJCTQrO RAfh+hjzv6XyAs6Apwx4yqi+gL5QdbDq4yr6QtPBpo+b6AuvH3z949fpC2UHyz4uo9VN2fOd vs04jHfgy7CWi8vxYrwSa5tpmO6gl1Etl5bTxVALWmtyf/LOZFqRXJ3cnEwzku3JZHfyTcnD yQeSX0xmw/oB/UX9kP6Jzpr1Vr1f36nv1m/S9VxLuWWxpVrXPqmpI69CUG+C+zBcBO2E+26B ZYiRA3B/UTzvFs+tcO8Xz9VwbxZYAdwrOAZXAcj6M/DthPtuuDgffy6AewV/hqsAWvgrQOuH +264CHmlekZ+xazqWSRjln0WQbPwJ7Pwi7MOzSLDsw7MIgdq5pOXhZUvg5UvCytfhpkvC90v g1zA4CoAa18SfC8B30uC7yXg49i30Vrh3i+warg3C6wA7hUcIy+NFPjSa6aS60DiZrjfCNdB uCgqh/tiuMLiKZdzkOvgXk2uHZ0917lzjFw7UgSNEEC+AWYaYIYAo9OmOzfXpJNrQeS1IPJa EMKfcuFazJ/GD5BrRuo57zUjiwww33WwxgdbJTflGrQHLoJWwv1GgZXDfbHA9giedPU8DPdD AuuH+01q3maB5cLdnEvJtfB9DWDpZDtQt1cnEzRlCkJoQqZ1whh5cCQ0IXeM3DtSnAFg1AAj HNRMJBRin4o/Evd7xP1Gcb9C3E8W9/Tq5ILUfxek/qog9acFqTU2ciKaBeRPxP09cT+1Om1W 6ruzUp+clXrrrNRbZqXux2+hfBjIq56en/rX/NS/5Kc+kJ/6s/zUy/NTN+anrspPXZ7PRRUj O0olOfyOvyfuM6qn2lO/tqe+YU991p76tD31Zntqiz11vh3Y8T9g00zF14v7VeLuecCdmutO zXGnPkigM+FTRtJR0n5C8CkoldpGSqpyx2iSACRvpKkQwIyRphoA2SNNqwFMH2mKAJg40nR5 bk0SScd74USSS9LwXiuHKSMlZ8FwsgGsIyXfA8BGSipzx/DRkZICAF+NdOYA+HKkcyaAz0c6 3QA+4+Ah/E/USUAM/vtI5w0gHr+PirlY/DdURO4GODbStBi4HzC043tRFS4E8giq5lbgn4+U gHH4zpGSYgA/HSmZBeAOA9w6UpIL4OaRznkAbhjpvBzAT0Y63wZw7UhxD5d3DSoWcq5GRQJG R5qyYXjrSBOX0D/SVA4gPNLkAbBlpOp5AKGRqrf51C68F0Nl405UIiwNjHSWwPBm6cgmVCyG NyKPkHzCSBMPSSMXUpOKG6Qj9biOH+xwLd4rpFSPlFQAW9VISRGARUbkFo50lgLwjxRDjLFv pPgGiJxXKpjD8/MQngVmcEEFIyV3A1PuSOccADNHOhsAZPOZYNREqXUCqhJGZY6UcK6MkRJ7 7iM4GXUKiTZUhK+9P/cIyP2qagyfNJL7ZfWYFY/kflEM4P7cD5vacj9oGoNjbe77sITvvj/3 ILC+XgVodXLuayVv577amZ/76xLgqM7OfaZkXu7jRUO5Y8X7c0ebZubuBcOGO9ty93QKCfcU wbSR3DuLxwiG2Td1Ls+9uqQ096qiMW7Dj4D5Aq4DBJ1XMpR7dtFZuQNQCrGmi3KjJTm5/cXf yz21mCuamhsqWZ3bDY50wZxgZ1duoOTy3FaPsPh7Jc/nrvEIH5Z1Co+WVomBJZ2rcxvBAhhY zAfAggVQl06YOs+zn8cIleG60edz1/keIrAL451wRarnWR62nGlps6y11MJ+M9tSaMmzzLRM sk6wZljTrClWm9Vq1a0a/8NhVkQmjY0fqi7lf4Ftki7+DJ3O/2I60gSeQfidiD/Qhgi2EnQi Gp5Il5Fla2qHfaXLxizjq4f9pcuGLc2nrN+L8Q9a8LLhA+1oWZt9+PM1BWPYtmrDMCuoxcMT lqFla2uzgHmYXDiG0dr1Y3iczzgvm//BzH0I47nnXZrNYeN5l7a0oCmDi7MWT6jKrGys/5Zb q7w31JfGv7JKS495yhm+ctma9cM/y2kZdnJkPKdl2fAc/kc195EecmpD/T6yhYOW9ftwN+lp WM3puLu+BdgWCDZURbYAG2riANjIRlTF2YC+MYEN7wVy/d6qKoNpJd7LmWDRrBRMGwymukQm ejGuE0x19GLBdIOhsATsAIXVHAAb60ElQmEJ6xFsWZxtb1ERSOos4ix7nUXAsLfIKYZXxYeL jeFfGMO/4MNjGMfHPUWGtcWoSGgoIsXAU/r/41ew9v9iEh5dNNi3nv8x1NaChiBcrcMXD3Zn De9ss9v39g3Kv5Ja1NrW3s1hIDg8WBCsH+4rqLfvXbT+W4bX8+FFBfV70fqGtev3rq8O1o8s ql7UUBCobxldcZZ/6zG6LlK6/Gd9i7CzuDA/17Vi67cMb+XDK7iurVzXVq5rRfUKoWvZ6lq8 rHn9XiuqbanbaMBRkmyD1dKanddSOyWjv0osnQV5WWdmP6ghfCdKLm0ZTimoHU6Fiw+V1ZTV 8CFY0nwojf/BWzmUdeaCvOwH8Z1yKAPImQW1KJbVEKqH/6LwFYsNwBfEOBo1Yp1lDMRKG8Q4 MMQAi4kv4AScX1FBleMxNBD/Ki01eFG0tG793qamhqxQfTYc4kf5ubu0JYpKSw2FpaUIdILX 4qA/RRz0k/Uprj82/bXpsyZ6QJzwX4TrkDjhH4DT/YtwHYIT/kx6oOrFqkNV9EDTi02HgPf1 F18/9Do9UPZi2aEy6pMWcFUtGCyMfw+URgc4uRQLb4Xf8BgrjZZyl80YwFMpp/KowJdBF/NK QUqpmlsaR6LG4ICYYlCj8QKGvjoDITaD8b/vaEG19xL8uG4Zo9bqiYhpj1Nks2iPYzTNqrPH CX0I16AkXIhPQlmlGZ8vPLJwRcanC5uOLESLAc/4Gm6OirzMvMxCuOEZGvraTg98Xc3QV8iu HeBtfNX4G+xktgXO+jn70JTxnaNJNveMMQPqEqYCrG4BJGV6UrZ3YtP086dcPP2y7ItmWLdk bpkwlDk04aLMn+p3pt4+9ampz2bb9CmoqG5KzYydU86ben72uTMe0PbPtJUXdedu0wdTB7PP n/hgusWXljlhVg7aQHIwHsOTqgHNuytzQho7NYemnTo5CW8uz8SZ0/uLcNGEwr592An+rcio W1+dlG7LtRFb07Rpnza9tyl71MAOt6zI2PT5pqa30eLDiw9nVlZ++OlhnHH408Mo4xlHxbI1 Q3ud1rqh6llTZuipKUVTC61JliSiZxelTrEVIn0G3JKz0gpR0nRWiCHjkIaS0tKzzsKbtqJN W7HoK5kFRUUF+bpFnzxpwhSX0+ubrOsF+bOIxz1hlss5VZDYybPnfnL1jj84Fm984vqdfxyM fHH7K0f3PPAsbnnsshs3TrOXW9iWoyVjT/xo8Kp99x/94zX9Fw1s23IPbhx7DG88UDWr3MUz Mgch7Uu2HDnwiurDU7RpScTuqnD1u3a77pz60qSXpr4z9YupSUO22OQz5l1EfzSJXWS7ml5t u3zynfROm26f1DC52tXsGqLMRm024qqelLL4Cu36pNu0e5LumMRSMLKsSkl51ppjsdtzsvLz S1c5HG/MzSnVV2H8LMvR8+w5c/ILsI5SLKlocsZkMnlK6aTJU+hUy9QpoxPmZTmK5+B5KSlZ c0iWVbekW1ZayGK4XWbZY3nBctCip1vCFmJxuvaUPlpKyksXl64s3VwaLt1RelnpjaXW0nMy pvRP2T2FTple7cIulJ6am0pSq/Ls05yL7uMZ5sW7aaFM5qatmRMqN22NlEM5L55QWX44A74P L8ycMLUS8xG44L9SSPSHKOOIBOYjzWALofjRJly6dRN8oa04k+fIlVkwjxRkTpoyxSUeaZ7H xf+5ideT6Z5dNLuooMCTx3MNGJmXfVYso6gopakzMNE9f9Ujf3UWLvqqp2zBrOlpycyWXVRb poWLckKt/mu1o0devuWGI/NjV7iOnt3vtA/fe3RV4eS0/KxOesbGyQUTZxQeDV++c+YEyO88 yO8dkN+58DrVZNGSbHNpfvKJyUxnuq2IFNEirchWlFyUspI22lYmd9oGbefb0rbP2T3vPu0+ 25Pak7Z3tHdsn7PPbbY0e86k/IIce87k/PyiVXPnjpHi6lNn5xSlW7GVJzkpxwonQMsqQp7V cywz7Tmz8gusFksRSVmZCqeSokcLceH04Xl4HsKp6Wm5aSStKicd8b9EWjVzZs60skmT5xbP IsW4OCU1ddaktJxKTihExYWzyGRr2byHMEF5aBG2wNoshQwt5PlZ+Cnkp7J84WHxgEVGMw5v yoCsLjTyCs/vZLwjmGSuPtt0HCwtdVTwtWekTOQMFp9M2uSEhBUdky7X7A2RlSkFBRPv2jJ7 al1l2ZEFRqqmAK6dNict2rvwFkjU7707e4+c/MvTjwa63bMLzSxx/OjpF52bnW6sQfIR5CgX 7aouy6v2zVhss+eQ/Pzp9pwJ+fnZ9hycX5Bsz8nML5iQCW+n1unp2bnZJLsq2ca3pqzGgsWH bLjCVm3rtx2waZvhRmzT7Hl8MDs7x30oD/fnHcgjFXnVeZvzduYNw4O+aBAWAFR7acan/C4W ArTxxQt5+4F4lBZ+0/PJBfkW3pJEZMhHiQ6TX3E8PRkCUXiMkwb+9bmAg6cnwl6TAp7a0c/3 oXzYe7Omu/O5nQsyJrjt+dX5zfkH8rUKQAj+i8XyNTTsLHtORn5+kj0nPb8g9y/Tp389MyfX Mh3e/UlGuhX1Y97RS6rzrelJuUkkqWpaRha2ZzVn7c6iWfaMXGzPbc7dkbs7V8t9EJegLHLP aF7fer57gdsLM+ACvz+Vrh9ZaK5qc1lDILZuku149rfVhIhIQSZLmWVfUV+0OTi1bn7ZkflG LNouqjp5ahFbfvSHO8J5E756Px4Obcr8VVfiMP+/ZW8c/yd9nT6OHGghObF6sp6RUanZMyqd 1Qvr3Rd7Lrdc56FVPECBZZ77K/GZljvKfr7wgbIny17Oe6nsZc87ZUkeS4PlxIknTl3qWT+1 0/pjdJ3ndnw/vt+a4oJXsqprtGvLrndoqKq5qn1Ka1Vk6pWT9+Db5z+KD1XZrFOaq2IL6BIr mTxhMlnAtTwxtfLjBdjpsiZZLaVzi0vnFpbOnbPQdbdrv4tqrkWuJtf3XZe6bnT9wvWw6zeu v7gOu5L7obMumGTNswatA1aNWBdYl1u3Wy+y3mi9w/q09RVrUrI129pvpZMmWGlWalFuKUic 01m+YAlxXoU2lZeTrOo5pe70rNyszVnhrBuz9mQ9mmU5mPVh1teQwazqtAx3Fsm1kOT0ublz y+cunqvNrZ9Tl16YW0gK30eoPGlx0o6kR5M0OwCCkjKgBsbw/uqM6qqdVaS6qrWKVN05GU/m B73q4ubixePZOLsU+TJ8xOdk1QWF7jD7hJEKVs2aWSvT2LRF/nVZY9hxHt8eNm0tbTq89dOt pb/cBKXy6aZNkYXQWj5/e5PYIUrLYTxjYcanvPkc+fTtjMOZU/kGInYROBXwXaMy4xlrxsK0 hQvRplIc2auTurXr703JyskiaFOLowJOCU7//BkFtgyqpRfmFOUVJhdVFqXNzJyJUuxJM2Hd z6e+mShjRupMbMuHm19bMBOJcyJolme4s+ALR7ZuQnDhraVoK9AK4bRQ5HF7Cz187ebzc8TU KZMnSarX5ZwCj6Kanb6p/GhRNDtTN7hcTrL07gubTx3DnqnVxTUl02cULV2weF3kub7zrpua ZpuUOj17pnNLffMG29CC2f+nvWsPjqM4890zu7OP2d2Z3Z19zD5mdmdmH9r1amUxa0lI9o78 kGTLlmQexo8ohjMmBptDNgcX20dsxxQUJLGB8LpzrjC+KrhAqmwQ2LJzVxbFYY4rqizyAJJU BVdQ3QEXgSkelVzO0n3ds7IN4QpSlbq6P9zj6W96pqd3p/v7vt/v+0aysnKl9d5Hbhzc/PS+ r9/U1pQOxSNquTh3yfLL+vb2bF1YemT6ISsr5uLLFvU/hDt6V85ra9aThHcMzEyy60HvdfSh dfMnHDY8eI3nCeUl5iX9Tfwe/g3j8rrxHKYkXaPe4PmGervndu825ZHwj8I/ksaYE9JR5YT+ knI6F0Q4EkZsIDWBzoA1TeAzmHFgCTM4G47E5fhZ4HX/Gc/zrmyfgxcCOFDGhPK3ynVM3aMn aAoYH8RH4I7E4dwHoFVCSk0xqVZXox+RR4tlcwKwjdzi8QVMl2y076MEogzeYcXUMIUamPcV k9soJ5zaKnaBBgRBEzoAVoBCEGaIgRYMw0rl6IwDl2sjC2GvCiUDdJ2ilN2xlrrwpVt+fOaG nW/e//SS9s4VHi4WU1s086qlbf1zV38Y/5vtOHHq5P2HH1jbsXjg+rosX7bisTs/7Cw3E68y ODPpWAJ+VkEVvMPSH/X/o/+4/1jUEQq1uZEiKkxMrXjc8UOq8pIuuMC8XGP4/efwIU6Fg3XH 3OU7fT43T3J2lhzbns1LLhgKIbfoZtzgRcU4Ey/RCQzADAl4EDNHwBEnqiRi6q8RMdo53yQS GGHAHKpOVJmR6sEqU1WBY1siuRAht4q4RbTEIXFCdIhyc/ue+HmzI3O6DTT5U7s1ZftoINn1 LjC3T6b+G38yXGYDIgB9Fx6mplTUSv6wkdNzDBfKFwtNBYYL5LRwvoBKfqhywWwBF4RygRiQ zbpLe/YAy6+O+EfCI9pI6Uh1vMqNBHaFbo/t0keadlbuit1bedT/SPTAnCeiT885MSewW7gn yJBVHCZh8XFUhSeVs3X6xPEMlc/G1DoZfQ2QwSDYUzQWcdbIghfOmx7hfnm9FqYrPrvkbexP OHelffq23lt6Rjddten5TYs2dXp8LQvvXrY5F89VzUqsuHrAufwPr94sZTOO7IoHVy04+O1/ fuSDHWY3TmyOplOlc3ftk9QfPP7MU/nwvbYWsMNgYxGUwTVrNRfql4alW6RNkY3x7ZIr532S OcW8EnyNeY190/9m5CP2d37vrgjWrHDEXMXewN6i/TW7S9vL3hV4z/9OxFNyz0Sx2+MpEzXI uFn3sDMTRbgnOoaLzyXzYZdzDCujPt4TpQEzrG7UkjUzeiMiFkQWG8yezBMfMBElLsEaSlS1 urZe+0BzaJkmAatghq1iw/KoVEK2zLeYVGt8oE4TIhblbMMCh4kLBPYySWywXCbKUi53USv8 GIJScM/Dk1h8ZSvVEHCs6Vw8JscYLhVSFZSQogpWgkkFxyJQ2XpRKkMoViaLvBVnbWu0fSRZ wBCsn8ucNdYIO3xuxrN2yXVdf9GuLR/bPrF51bmn9r32vp6L6Ga2E39yYsuVi66JHthzcM/J 93Dk3UOPf1MNXbbmgA5T0QPMvJ0y87eOI27m7LN8RzN5wmp/zXT2MMxQ80Qz43I6uSiX5xyC H2lojuoXNXEOFzocOBlgkhiFDTUwxvzKCmoFQ9V0zWOofl1PGWp2jPmltUEvGuocXcdJuBUB 7XBp2Wwg4Pe6VQ/2lKSwle2uh60lvWbYml8LW4tg77gcGi1zoSoUoSpXoNIMqBQVKjFong5j IYwz4dNhRgzjMAHb0HgzVpuPNDPV5pFmptlaUCMPMgpDUQmjUQkDUgkjUTmnmUorAPrWjGy3 WyoW6Cn4YmcLuFoYL0wUWHJqtO1yk8rqXFvCl6JdPemsWZArA7brIMoADoPSWbGBj4DGAN1b t12Ut+uy2S5oB7iUOnHV9DQrBogzoZadhc8I8XXKoj0Q1gZIbEtb4agfWrEAVLIAVVKsB4jd Z6X67PhriEfCw9tIPIiAPlKzp4AbA/J4nlNDgE88xEXnCjX84ordS1bf0VScP51vlUOhcrK4 fI4Q7pzOd8rBwgLn8nNvr1x0/d0Hp7+/ueYyDFc2sRE//led2bYl0/z1suY2DC4T3cwevcl0 58AHlAAOdOcWxKMU+pUVVXYHY3WB/IGVlBoUQ2KKixlqiDh/zW+oQXKgxw019WP6Xo+Dpw2a 88zDHOYshH0pLhT0esgcpOCszbYstsnnsyPrUjxmwfAxMhmX14gYzegmleEYlVa10mIeieH9 MYxiYoyJ7bSUIYVRlWuVg8oRxVFV6sp+OBhXzihcemAciDos3KfDBFsbywZ0C4yT0PX6FLV9 OtVl3HqB3oQ/O88wp/nutessa+3aV5sXTbsWKFLzQucWesKy1k13nktuaHMYBqPFNjAaHObA OpcjxN0GvrOHGbDUXgaHQqrlVdrcQhh1oR41DKrTw+F5bbKhAiF54zmtYqhFOLAkrdtQu3RN MNSwrlsFrBlqYYx585hudeI2Q+2EY6ukLzTUHl13aZV5WRd2KF2tNziUG7xehwv1cF2dxYIU 9vZZ4AT7yKxdrWgm6jvYd6RvvM/RF4slAoKgCoxQSshguDKx0sfkk/JpmbXk/TIjv5vVSs0V uFShlyonK6crrFXZX2Eq7yKhTQXyW1rYTUZOpDXz2u4z3czB7iPd491sFaqJbrZb7u0bY64c zRKzKg9cCBEpy4FAqSGHuwaWbFz871tJRE6AmKwKicCBCjfSJmR9yL8L1kUdsVGdm0zzfifX kk/l5zqbFcy50nxCwT5/lWtVcNKn2O4YWC4luoTkoqVXbbdCasbtybiVglP1ZAsok3W7MLFj sDMK5sa1fWf6GM5n+Eyf1fc67xx0DroHPIP8eJ+znRnkBn3/xTnALuGRbAjvA/WMpulEj4qR Ojc287tRMHUqwQH4xmbOnpdBv30eJG0LvN0WGtfFxn0gSfsZvgNd9LLA5gQRmwN8uUtYwDRO uci5z2n0Kyv2DqzdkR36/tB1t1YKC6bTHcmQVE6XV1eCse7pVKEiSNVkMVutwTWFeg72yZ1X Lbpq1dqhNfc8PL1niwmewllIXocfuGNxtl6f9m5M5IgR6HOvwA/ssoyI2j/t3VDnqD/ZwojU n9io1QZ2UWYcBLXeeZ7v8HC4QnSpvb82VMHk//fPcewvmNfZnyfYCFcDLGNfx28lmZAQQFlU VgNiViwfFk4KbpxMSYYq2AiWB9TSNS8gGkWwDEGwiA64Vtb1bCYjCAGvfIOTdbiSQEtHJ0jg P/O8tSpew9uB0HFeimmRiERATQLdFySckU5LjEQATgJwkwi4SVZtHlSASRKxDYnAnEQQTiII JxGEEyUsEVgT1MqRClOtjIDZAKZVGphGJQxSaWBbpYFllQbGVRoYR+dEAGyrpOw0V6lQyJ8H tzyu5sfzE3k23wC3fAPc8jaoGWZennMB1CimiReBWpnEoxd0i5qj2EC1j8tbAdS6pmyA+yNk y9jIlplFNoEgW2YW2QSCbAJBNoEgm/B5ZJvbgrYRZgTkHCLNWW3+AkX+Y519se/O5eu+KYmg koVaTAyVE6uWFWrThYZ6bh/o3djfcWj6wS0U2HLyBnzw1q7szmn+xnbXZ9QQJnMZcNtjoId+ lMVXWfGXE7jgw6Fr3IG8HyNXLO/yuPm05ZiNURxWvmwKDuxI6HaMQkWvLepUjHbMN4m0DIj2 xvUJnUG6pV+rk0OnpT+mM7oQUkNMyJrgMd/gqFTC0EQeBWrKyxqMsfu5Qq19K/Gc9uLZ0UyD gXxK4sQpZC9Q1xR1h4sxBMlMTlUyCsNJ4UiY4bh8MpVIySmWE/yhAjxlWsFRT0hBcVe6gIO+ QAErbEDBYW9MQSlnrIAaPobGNeSFAjjDuUXcgZfipeJ2n3OE2+XbJY7Iu7n9vv3ibvlfmVOq d5cLYh9hV3y/a7d/t7A/7oYYdXjrGgzkl3gnyWUHqqGYxtHkQNROfJH1zOPpHT+5eeOON346 +e7py5bGAnxfc0Up+KV8LsG++K137n35rkO4+OIruNy74u1/2zzcu0zW5q/H2ad2pSMkA9CP EPuXsIJNuGB5+TzfwUs+0Z5QMEeQ/zGaVM0yac81idz9rFqjzbRinxZEKq2CFDXFMn6Yv6/M 8LIfQnryl+Ka1LSoiE0cjkRjMaRBrEtpTuyUmqY0RzfUJjiw0rq3VbCULtD3VFtd+AZxMaiJ U9JeYRh5T+D1yIHXH7vPNeE642IhPD5h8ahJiKnAXkq6ZmuTRn2BSXOZo8mMndOUQlFzXMMj GkaaqDHaL0sDV5PMY4PNAHp+/PHw1JQ4abMZ0IVyGf6VXTSoJUAJ1LHBfABgy7PGNpswaGRj IzE7yARLs98qUHgY/m53+6Lu5tqAy+tPJ5oiGezyVdunXfPLbm++hX3yZ/evX1JftGyxg4tq 9etue6O9Q0zKLEBCxw7GORRNJZw5+r5ukvkZrFErc7f1Nb4lItYdor9JEtNNDk6KSqdyp/K/ EN8Tfy+6msRcqV2cV7qbf0h/yPgh/w/6GP+cTv++i7sp4uvl+32cxVs+JtSqogOMijHxOtji Q/XHaA53iRVGB0JVOGFWPyrHVflAUk0kiFlBl/sSODGGN1u6fCD6USjkzJddISUf4kN2yGiF IiZeF0JZMctQis7zgmm3NELNrWYwVTWAAwnBxFVz0Fxv3mLuMg+bnBkS3KqbcVtwg32kJZqK swFrERdnUz5F+TJi0cSgIcScBOq5FZzp8+4M+Eg36RSDG9yWlK27uyI6VNEcNOGrN9wmsf9P t5FMhn1jNmOHE2csD4yQ/TrcTb75KAxAJYxBJQxD5LPnRyqvmaQjWDK2inGYwVQQKjEJVSAG lT9qd1wDITD5IEVRhLoyNvObUZ9kS+hB5LPQnXak/Y4jJ6BpCPo6FejoVKCXU5rtIv6WsO7G O87fknfjllC1vMF61fIIUMGzkG6kk92LfHKuAl8N7Hhi1JbwqIAquQrgC7R+anngIFcByMmN zXw4GlOJnDwWz9R9KTlbv0Cc1iAI3mnOZRgMImy/GSXOyEFMgcblYAo6exnxTvNqJs2lQRgw +56UeVDQ5u/tbrpcyuD88MC+VYtGFD4bzYpa5e97WuZ3bfrbysKHvre8NxkMRePsC9Mv7NvU ZiTlppe/s2rg4aES34qH7ryzs9TS03tT+xUbthzOCQKJ3/MzHzEPO84hGT1qBfbz+30MrXgf ksfwUVgehySxkb0M5jI8+VFdlt/m2RjgGXYMB6y0kz/qSySxw4EEp+pknKVwNLJdgpAcJj9M 9EkEZl4Nj4cnwmxYThDPYSc7gAZ8TJEeoH1A/HTFFDRR/dzkMHl/QfMdXZgmG+0XWhH9fJaX Oo1aUAc/0YbHfv1rIS92X66sPLpmZ9C741vPLHScm35qw7mTK6vpDdHxDfO1h/Hv9TX/sp34 6vrMpGMu+yTS8APHkQHf7gngesaEwXh8SV/Jt9Tn6PD9XeqHqbGU4wPX+25Gs3i/mSWV4ERh 1SmGHW+58IwLY0N16rodGykkZaE7OadX3ujhvTzSNJgADnEl26pLCkeoGwdcjgP6xhH6xhHm xhHSxhHSxhEOxxHmxtHcBIcFDme40xyDOJFjOELjvAZhhAYwOKPB4IwGczMazI3IZ0v2ZRjZ aBA4Ii0ZCNy4gVXjiMFUjRGDMSQ1giMlgfiVURg40OBvgQZ/C9iDUbcTBhp3NoCrgfHARIAN yPrA+QQnRQCapbg4M/G5PAVAxNT5PAXhC5TNDW+1Q16aogIahhtEi6bx8zbXyjZWfV4bbbKv FudP711015WDO0uFBfiOcFPSSBfbCes6Z5A8wh1DS6/79iF8K6FX5/Zcf7kSTgzij22yBWXe n3GbQTP4A+YFsrHzvnA7+b9tzk7Y3uOmXP9ENvcHnu/YGx/zrfN3kS0QEH4ghoKXyqVyqVwq l8qlcqlcKpfKpXKpXCp/xkLjIob8ahIUCbFE4ATsHPrSwn55lzwqNiE058KJtouvLkY9vX0I 9S+H46GVVyB09aprVn/5oP9nxYFepbWDzM/Z22ZmoM6QmvxyF/pKE/AVSh72IvnpWfSZmbqo tH3hWVIWw96DelEfbfWT9720DKGV6Ap6dDVaha5Bq+l3Rvg+5PzK38v92eZZdHbmMydsnUFc B07N7uS33P6/7M6X0Uq6r0JNjrdR8+zOplHTV93h3mV/6g6K8TWys99DA45b0SDI8zu0e5gO VLp4555Cy8l5uGfZ7A59++HzVzJPoTxcq9O5Bm175sjhE+uFrk/csr04h96u9RB5/OfPL/3D Pee+KyJ3Dfp6ZtfmfwAKELeeCmVuZHN0cmVhbQplbmRvYmoKMzkgMCBvYmoKMjM3MzcKZW5k b2JqCjQwIDAgb2JqCjw8L1N1YnR5cGUvVHlwZTFDL0ZpbHRlci9GbGF0ZURlY29kZS9MZW5n dGggNDEgMCBSPj5zdHJlYW0KeJyFV3lUU1e3vzHk3jCINacJIDWhgoCIAgZQUEQErDJLFccq IOAEYpXWflYElSp6W2v7cGqoQdRWEWdx/OznSGWqWFAQQdBIpIgFW3WfvB3Xeyf41vreev+8 tZKsc/c9d2efvffvt39XwlkN4CQSiTxs1dKUzNgZlrU7dZbQDwbQD6TbMMO005QlE+2kop3V kQ8GZyrgzWD4dhDMfY8bIJHkfzXjHyvTM1IWpbsccZmxJN0lNntFdg4zuYRnr1qZvSolZ2n2 CpeVmYtGu0Sk5KT8P5t8LM5cPs7O/MxiWe0ybQV7zi8oyHcU+xkz2iUsM9MlceniJTmrXRLT V6ev+jw9rT9qjuO0MWH/WLEodvLa7LS48JXp8REZCZGrFq9ekrP0489mTPt8TWZKUlbqqNG+ flpP/xGBI128g4I9OG4UN4yby8VzEdxozpWbxyVwkZwP58ZN56Zwvtxw7iPOj3PnPuamcjO4 adxMLorz55K4AM6Lm8XN5mK5ydxYLo4L5+y5QdxgTsG9z1lzSs6Gc+DsOAk3kBvCOXNLOH+W YG4Ec1HKgSRSsl3SMyBlQMUAKl0nPW+ltCqw6pZNkH0te8xH8F/zjcICoVbuKl8tL7IWrFOs i6yPWD+xibSZa2Ow1dgW2gl2Q+1G2eXYnR7oNjBt4NWB/2W/wv6c/UV746D4QZmD9pk2ijra qZPAYB1dopPCYBUtNMnMhW9lvE6npJ10ibnTvESwp1fF9rGm5DV6RWO3N53hQE42qkghndHO kx34micJJjtvgex4myzYm3xEPcxpht77km29MPklxL2RblP18i2QJYN/8e2YJXvD40VTsmw4 jz+9TZZBKlxStkCG7sKei0UXnXalFc8pjb+Pcx1xC29PCzGjw2Sll+i64YJBWoXzlSUF+wqL xTax/MyvEABz6EFHLY9SvJGbnpe2IdUpvyLvTO4p5OCaozcPc8zFySgryI8XndaJa7d/sWPn OEfLaeh083Sqi2pS1LVMMMBWgwM5W8dOZIATPDkLTtWn7t8/muKlxjsGaBDEs9t+3qJb2xZ/ 3lsMF2dkpyfKScK9CQI5a9ax3BTmNdIPGySnO6XUExKVedq5qVNEeUBCJbjA0Nu3n946vyRS p+nYs+ZVWCXKRCcc4e+OkzDsj5EwDGTtDWC7T+O/S2Zvuif+RQvA2uWN4t4zn67R4Aq+HWPb YRIQX6MDOTLpnoqcnPSMsnxfnwSLzK9lHTyk0ecyZjU/N5qSBXIwHwmPGWYTLqQmZufQlWd3 /6cu7cA+mR39NfT6vivmhQN5xepYDYd4iDT+DkMfzavxP6QhZ38rL791ewjIAu7iSDXu58kr 5qGbapWQCa4CKC9+Onbi/BUo16APj+1WIArMSRAP5EZGgIa8CpiVjjZqnGIpn/h7RBMVGqbU J1Qq9HShOYZOQAP87UCm61UkjC5swgJ+iZixNa3w2q+OxAaOQZuMKCrNLLvDwmGxQIoOi+Vf n/oGH5kHOZKICEsvvst3uRFudUrLYbcSw1+MhOEw+ulLiIRxHn+iK3r7DscQtVEFTjV1hid1 H+H7+EFUlFYbXQtO6n4XcabktxqTBnc1QLBeccwIBwxBbeMfOpDifOquIpPy23jikm9J6jBO yxMFhzuFrIo5h2NEOTnEoVPAMAxG/y6Ugqrm8qFfyjUkkosS8AiLh22GoZVVD9TMwcOqKBym sTzxfmxsqJptmmiJQWNvyhBhNB0FoxRNRt8eyvdYavy0SUW6jPRXntqZf5WRxh5Tsq+5kjfb 0UoZ6fDiSVd/KTPyWun9VsWVHi8T50A6aAd8qyQlaPfpxFgXZ/QcBxKI05CEv8phKqR2Vy9w LVd37WcOwDHdvQldnTEVHXEYrsY8sEcXWAYjgHsEvmc03gdkLDk4T7/GpH6rNqWaf26kbvWK uofjDXCw04H8WIfzlGSygSfO8J1wJP1SdiVLRyw4dYEVjIVA/1foNHXBp0npGuJ2Z7xAYt+m Cg8pe8QZhvz2+/0mlgxH1ERHh6hJ7MS4KkseLLWAiAYY0aA42enHOjPb75kD+YsGwXgl+Sts 5YLlUc4BYnRVAfBy6sBD3IQ36Iuunu44WU0KMKR7BHiDXUvV68Nq310yrIBhSrLM+N3tW63O beIvM4u85XiOtzfts6SsTXL5Bc19Ib0ML5W4GFzRC+ZDMqjBEz6FVagGL0zGBfgha6AN6hdb Le0ubQdn8H2C9jgBY4a7sjsurq9hktpSv3Z6vkPS3E1dX0ibVbCLh1UsC/ZQACSjL7RGk3Qx Xoe2ohzFt8l8d7uSngcv4aZ4ZvOhjXezb4SK6CXHTyJCMFyNo3h7KBNZ1jOxrB7eb1UUwT5M eMJY6YmKRDzhiT9NEohnXz1buV/iq/U/XtMVbyv8Ub23Keu77O2rGKnYrErB8RriGTKF7XnA kwhzUj/oqa3Z1pRsDmmHog5Fcze8YagvblaRqd08mQDnIVqAhXXPwf74pvLcw5pFbVE/oxeL uZQnU/tBb6tk24rYtnPi4a26LVdyyxeI8fJx8+ehvRpj+Xe8UtgO2R2KFla9PHMe/cH8Ay1z IH0tKrKRlrEZ0WeOhkLmkLr0X7hANk/c6PgOxk3mH5jF0tTwWKQxjB50441szNQyWnYge2pV pIA1mxscEGDAsVu1Jfu/Wl+iLmvL3JdVlCU6kcJUMfPLRWFyMrWFEUZhPx1fxYwGUDdSZYPi qHEyjR7zNKgtuNWBvLySrCR30ap1Brz3r/NF+uPqlnMHfhXBU05nBscIJOfKojkH4pxxqPZD DES3NrSBYbculV44rRGnbc3e8oWcFCZ8mbI0yDlcTPtp0/XAPY6NUKskw2BwVc2DhzVRSNTM vVNs/Pig+EoYqu4fDFALfuENigsd8BWDz4Uy8FGSCzhg351EGOIM73Xced6Z/hOGXtB4/pyz UzwtP3G0rFVNJt0RTy7/j6THux3JhdbcBTXo4YwkOnKC9p/LIGCRpnt1Sa6YJl+Ynh48fsGp +o1q//Wy/qG20LzQlIx776/RWzitzgDbWBL3scG2mSXRHU4KYHWpslNNNt89na7VYJtBYNY2 AWTLDOjOzLHirJzUeXISATu1AtncX5aygjZqW6/4EQowgjVkPexqUZL6wi/Xb9vgnLqx+LoG bggk+SnrzPoxMI33T5Lh+8wQzdqwvgZ/4dG+NONP/f7tOw6q1z+Q2cMqUU9X65/3SeoM0jqK SkOf1p03o5WB6rRmnaWf8jpo/SNJwzPAZ9ILsFb5LY4C2RhIEOUwGqRPYfCL6dWoOq7Br2o+ KxLr5JVX/gk8DLg+37dIbfx+MwwZ/hADGSJGuk9Am2nlM+sXaw7l3vzy+joISLmSK46XT46c 54KDw24Ct149ZpMldXlN0VRnjqfxihoDFBpCHjDkUS8GPQaks1THoKfFMrZE2wXTfZLSf76Y ry7UbS0TL8rhrBbvC2LGN9nb1xYHV33SJd4Vrx05e4slMZQ1I1hAnRzYoSiltdjR7UAOw+53 2PM02QrEFzZ0mGsD2RXkWwBnK/TzgGmcXtLVLe1SdZuSvRl5WObo31Sjl+z641Xrm04pZKja eJhNdTI/HgW8m5uev2zTSqcNJ/KP5R1DK6hx9LFIH52sf8pwTAzZQjnYKbYb7zwOMFYbrxmb OxzI5XwIVLHJZORfUVe99hHWyIw8SWZW5jiQR1uzm4yc49yom8yXD8Kba6dtXLxtsxPKqA8z sAdBa/kLS0UtAdcYpDUqgylZ2x/w1bx6OrxBceIP0D+NZoTeRz1rlES+ffV3nxX9Q/6Mgf6z M1/thbFDwFoQz2z9qfCHtQ9iT6C1iEPFyXNWo+RxnuO+xmOH2kT5n4eWe2mW5s3aELEJhdwx GSJK5f7VscDX3yy5XqsugNlKchIdF0cg+Wjx8UvXjpU83aOuKbq86+geuYWeWuhbveRbGACR Boh5LoXjqh4eypkAHcljkrl4XVpeWn6aU/6JvNPrKjCOFju68VDGhKlFkNFoczRNNCf+Wyuu NEA2Q5WOoWq3AfbzoDx3o6P2p7QQNXYa4Jrw5trFxrpDi33V+NAAVACb6TfcomZmxaWqyexb a+aWT3SeIn68bPlsOfFs/Ddn/V89Utsa3Bb0buYW54OHiomQWiaw82cfv/zpbWcY1NcHU0Dr /zc6aciHXKI4LydjvhyKLAqQiZUIjkGXTOba+G2gU7LHQFFb36xmN5tux6AzOkZPnahhu/zm 3QVHDaNeWG6QHIVS6VFYroRSA5Zq+wdSr8TYKzWqens9PPpL2kAfNUoqOoFJ3Qp4rcTCZhwI vuDzgE29LbB5AryHo9EnBAfhFnWnChZe6Oxpq0rEfFwfmxAcHHsL8izaywKJRfhjB/jrFXDK kHiTESO1ZqgwLRJIRCKTXZmxIeEjPpEHCmTqdf2Di+fOyM032dpgCWJ9I1T8BmsbFVRpTPiD NVYFTFeSQrTd3TkOFM6gefknDO6aWxOo1xDf2iPHrlYNee33EO1QFvwR2nyuNqzb8/hyxR3R qf7y/GgNuR0yPXW4esPEg9+VfKsTndpuJQSPjY4aFznnbO8ajTaPtfdjzND/p0ovud35qFoK 6zFDWc17ge9c8BXBT4SJp0AGHMTJYxhicMxM9BRxrIgRTRjag/Zyy3lhB+5gI7iilSboFXse B9BNGGsIb3AgPwDTexY15QWhAnHraWUrJvIm0zSBhIWzC2wxp8mCoZoVE0MF2GHFTDk85ECT DJuE/xVb9SPGCu+x2Ngkb4ZQESJEGDsDPNkQG8Mie4Oxp5EXcaKIfnPR1wt95dXvKgoPmyGq UXGqz50mh7Bue0U301NK8gqk60J/Q5kzersih4dRfOkB7uDQ9RKYml0CQ0d1o/XUqKyoFPU3 MLWqp1esFU8vLg41fO+IiFXMwbPq6paHlXGebnHRYeNi7r1glW8FOc3CI22KG5TpnEcOJAG2 g5z15yP2Bgmz2dSAWUx1J+As9loJs8YJliWzYlKQZUOS5WVztoUh+3tT8bR3zhUHUvJURUqu 8FsT1q7I+PJAuuPNgwfPiffkvQK56sGzr/DumNHN0NKoYL17okfL4PvqOgSzIFG2934UWDlD yBNwgO/ha48XOByVI73Y74fsDczm99pTN9ikmZLg6RKTcqwlVz22QAZmuKMkX3gkxLGerja+ /O3ug6aqaHd1f1Twe5+ks1faSQOVvX0ebLIFWr2DD3xMU+F7tGM0fL435DoLvI6msrNfZ5Rb CkNkpATsPCyHtWM4349DZPa5e03JuzF9FzwvZe90e4V7Ns9sS47t23nNzu6Z3UCO+29bYXpD CmVuZHN0cmVhbQplbmRvYmoKNDEgMCBvYmoKMzk3OAplbmRvYmoKNDIgMCBvYmoKPDwvU3Vi dHlwZS9UeXBlMUMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aCA0MyAwIFI+PnN0cmVhbQp4 nGNkYGFiYGRkFArPzEtPAeJi3aDU9NKcxCKQqMoPacYfMkw/ZJhPdf/w+pnO2s3D3M3DsuT7 KqHvqYLfk/i/xwswMDMyFlY1OucXVBZlpmeUKKxUMLS0NNIFEqYKvpnJRfnF+WklCs75RQV6 Co45OQpBIFXFCkGpxalFZakpehANBiANhgohlQWpCsH5OaUlmfl5xToKnnnJ2HXB3VtcWJpY lGrCwMDAuJyBsZOBiZFR3eFHR/epHy9PMZ46+b3vFPMpsR/cP9P/cP9NZzt5SvTHy+99f17+ 7mPn+xH3Pff7Vsb737cx3/+eK/p92/etv7f93srGVzn3Z/rcxXPZfifO/d48n30J1xLuJTw8 S3h4GRgAARt3ZAplbmRzdHJlYW0KZW5kb2JqCjQzIDAgb2JqCjI4MQplbmRvYmoKMjkgMCBv YmoKPDwvQmFzZUZvbnQvU0xJRVdRK0FyaWFsLUJvbGRNVC9Gb250RGVzY3JpcHRvciAyOCAw IFIvVHlwZS9Gb250Ci9GaXJzdENoYXIgMC9MYXN0Q2hhciAxMjEvV2lkdGhzWwowIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAKMjc4IDMzMyAwIDAgMCAwIDAgMCAzMzMgMzMzIDAgMCAwIDMzMyAwIDAKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDcyMiA3MjIgNzIyIDAgNjY3IDAgNzc4IDAgMjc4 IDAgMCAwIDgzMyA3MjIgMAo2NjcgMCAwIDY2NyA2MTEgNzIyIDY2NyAwIDAgMCAwIDAgMCAw IDAgMAowIDU1NiAwIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3OCAwIDU1NiAyNzggODg5 IDYxMSA2MTEKMCAwIDM4OSA1NTYgMzMzIDAgNTU2IDc3OCAwIDU1Nl0KL0VuY29kaW5nL1dp bkFuc2lFbmNvZGluZy9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjExIDAgb2JqCjw8L0Jhc2VG b250L0VSUE9LVCtUaW1lc05ld1JvbWFuUFNNVC9Gb250RGVzY3JpcHRvciAxMCAwIFIvVHlw ZS9Gb250Ci9GaXJzdENoYXIgMC9MYXN0Q2hhciAxNDYvV2lkdGhzWwowIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMjUw IDAgMCAwIDAgMCAwIDAgMzMzIDMzMyAwIDU2NCAyNTAgMzMzIDI1MCAyNzgKNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDI3OCAwIDAgMCAwIDAKMCA3MjIgMCA2 NjcgNzIyIDYxMSA1NTYgNzIyIDcyMiAzMzMgMCAwIDYxMSA4ODkgNzIyIDcyMgo1NTYgMCA2 NjcgNTU2IDYxMSAwIDcyMiA5NDQgMCAwIDAgMCAwIDAgMCAwCjAgNDQ0IDUwMCA0NDQgNTAw IDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUwMCA1MDAKNTAwIDUwMCAz MzMgMzg5IDI3OCA1MDAgNTAwIDcyMiA1MDAgNTAwIDQ0NCAwIDAgMCAwIDAKMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMzMzXQovRW5jb2RpbmcvV2luQW5zaUVuY29k aW5nL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKMTMgMCBvYmoKPDwvQmFzZUZvbnQvTEtPTE9L K1RUQTIwRTJCRTh0MDAvRm9udERlc2NyaXB0b3IgMTIgMCBSL1R5cGUvRm9udAovRmlyc3RD aGFyIDAvTGFzdENoYXIgMTUvV2lkdGhzWwowIDI4MCAxNTMgNjIzIDQzNiA1MDcgMzE4IDM3 NCA0MTIgNTAzIDI4NSAyNTAgNDg5IDQ2OCA3MjcgMjgwXQovRW5jb2RpbmcgNDQgMCBSL1N1 YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKNDQgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNl RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL2V4Y2xhbS9zcGFjZS9E L2UvdS90L3MvYy9oL3F1b3RlZGJsL2wvay9vL20vc2VjdGlvbl0+PgplbmRvYmoKMTUgMCBv YmoKPDwvQmFzZUZvbnQvQVJXVU9RK1RpbWVzTmV3Um9tYW5QUy1Cb2xkTVQvRm9udERlc2Ny aXB0b3IgMTQgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDAvTGFzdENoYXIgMTE3L1dpZHRo c1sKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwCjI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDcyMiAwIDY2NyA2MTEgMCAwIDM4OSAw IDAgMCAwIDAgMAowIDAgMCAwIDY2NyAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCA1MDAgMCA0 NDQgNTU2IDQ0NCAwIDAgNTU2IDI3OCAwIDAgMCA4MzMgNTU2IDUwMAowIDAgNDQ0IDM4OSAz MzMgNTU2XQovRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1N1YnR5cGUvVHJ1ZVR5cGU+Pgpl bmRvYmoKMTcgMCBvYmoKPDwvQmFzZUZvbnQvQUdNWE9KK0FyaWFsTVQvRm9udERlc2NyaXB0 b3IgMTYgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDAvTGFzdENoYXIgMTIyL1dpZHRoc1sK MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwCjI3OCAwIDAgMCAwIDAgMCAxOTEgMzMzIDMzMyAwIDU4NCAyNzggMzMzIDI3 OCAwCjU1NiA1NTYgMCA1NTYgNTU2IDAgNTU2IDAgMCA1NTYgMjc4IDAgMCAwIDAgMAowIDY2 NyA2NjcgNzIyIDcyMiA2NjcgMCAwIDAgMjc4IDAgMCA1NTYgODMzIDcyMiA3NzgKNjY3IDAg MCA2NjcgNjExIDAgNjY3IDAgMCAwIDAgMCAwIDAgMCAwCjAgNTU2IDU1NiA1MDAgNTU2IDU1 NiAyNzggNTU2IDU1NiAyMjIgMCAwIDIyMiA4MzMgNTU2IDU1Ngo1NTYgMCAzMzMgNTAwIDI3 OCA1NTYgNTAwIDcyMiAwIDUwMCA1MDBdCi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvU3Vi dHlwZS9UeXBlMT4+CmVuZG9iagoxOSAwIG9iago8PC9CYXNlRm9udC9GS1BJSFMrV2luZ2Rp bmdzLVJlZ3VsYXIvRm9udERlc2NyaXB0b3IgMTggMCBSL1R5cGUvRm9udAovRmlyc3RDaGFy IDAvTGFzdENoYXIgMTY3L1dpZHRoc1sKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MAowIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAK MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwCjAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAKMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMAowIDAgMCAwIDAgMCAwIDQ1OF0KL0VuY29kaW5nIDQ1IDAg Ui9TdWJ0eXBlL1R5cGUxPj4KZW5kb2JqCjQ1IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvQmFz ZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMTY3L3NxdWFyZTRdPj4K ZW5kb2JqCjI4IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvU0xJRVdR K0FyaWFsLUJvbGRNVC9Gb250QkJveFswIC0yMTAgODI0IDcyOF0vRmxhZ3MgNAovQXNjZW50 IDcyOAovQ2FwSGVpZ2h0IDcyOAovRGVzY2VudCAtMjEwCi9JdGFsaWNBbmdsZSAwCi9TdGVt ViAxMjMKL01pc3NpbmdXaWR0aCA3NTAKL0NoYXJTZXQoL0EveS9uL2MvTS9CL28vZC9OL0Mv ZS9mL1AvRS9yL2cvcy9oL0cvdC9pL1MvVC9JL3Yvay9VL3cvbC9hL1YvbS9oeXBoZW4vcGFy ZW5sZWZ0L3BhcmVucmlnaHQvc3BhY2UvZXhjbGFtKS9Gb250RmlsZTMgMzIgMCBSPj4KZW5k b2JqCjEwIDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvRVJQT0tUK1Rp bWVzTmV3Um9tYW5QU01UL0ZvbnRCQm94Wy03NyAtMjE2IDkzNiA2OTVdL0ZsYWdzIDQKL0Fz Y2VudCA2OTUKL0NhcEhlaWdodCA2OTUKL0Rlc2NlbnQgLTIxNgovSXRhbGljQW5nbGUgMAov U3RlbVYgMTQwCi9NaXNzaW5nV2lkdGggNzc4Ci9DaGFyU2V0KC9laWdodC9ML0EveS9uL2Mv bmluZS9NL3ovby9kL2NvbG9uL04vQy9wL2UvTy9EL3EvZi9QL0Uvci9nL0Yvcy9oL1IvRy90 L2kvUy9IL3Uvai9UL0kvdi9rL3cvbC9hL1YveC9tL2IvVy9oeXBoZW4vcGVyaW9kL3NsYXNo L3plcm8vb25lL3R3by9xdW90ZXJpZ2h0L3RocmVlL3BhcmVubGVmdC9mb3VyL3BhcmVucmln aHQvZml2ZS9zaXgvcGx1cy9zcGFjZS9zZXZlbi9jb21tYSkvRm9udEZpbGUzIDM0IDAgUj4+ CmVuZG9iagoxMiAwIG9iago8PC9UeXBlL0ZvbnREZXNjcmlwdG9yL0ZvbnROYW1lL0xLT0xP SytUVEEyMEUyQkU4dDAwL0ZvbnRCQm94Wy0xNDAgLTE0IDcwOCA2OTFdL0ZsYWdzIDQKL0Fz Y2VudCA2OTEKL0NhcEhlaWdodCA2OTEKL0Rlc2NlbnQgLTE0Ci9JdGFsaWNBbmdsZSAwCi9T dGVtViAxMDYKL01pc3NpbmdXaWR0aCAxNTMKL0ZvbnRGaWxlMiAzNiAwIFI+PgplbmRvYmoK MTQgMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9BUldVT1ErVGltZXNO ZXdSb21hblBTLUJvbGRNVC9Gb250QkJveFswIC0xNSA4MDcgNjc3XS9GbGFncyA0Ci9Bc2Nl bnQgNjc3Ci9DYXBIZWlnaHQgNjc3Ci9EZXNjZW50IC0xNQovSXRhbGljQW5nbGUgMAovU3Rl bVYgMTIxCi9NaXNzaW5nV2lkdGggNzc3Ci9Gb250RmlsZTIgMzggMCBSPj4KZW5kb2JqCjE2 IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvQUdNWE9KK0FyaWFsTVQv Rm9udEJCb3hbLTEgLTIxMCA3NjkgNzI5XS9GbGFncyA0Ci9Bc2NlbnQgNzI5Ci9DYXBIZWln aHQgNzI5Ci9EZXNjZW50IC0yMTAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDExNQovTWlzc2lu Z1dpZHRoIDc1MAovQ2hhclNldCgvTC9BL3kvbi9jL25pbmUvTS9CL3ovby9kL2NvbG9uL04v Qy9wL2UvTy9EL2YvUC9FL3IvcXVvdGVzaW5nbGUvZy9zL2gvdC9pL1MvdS9UL0kvdi93L2wv YS9WL20vYi9oeXBoZW4vcGVyaW9kL3plcm8vb25lL3RocmVlL3BhcmVubGVmdC9mb3VyL3Bh cmVucmlnaHQvc2l4L3BsdXMvc3BhY2UvY29tbWEpL0ZvbnRGaWxlMyA0MCAwIFI+PgplbmRv YmoKMTggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9GS1BJSFMrV2lu Z2RpbmdzLVJlZ3VsYXIvRm9udEJCb3hbNjMgMCA0MzggNzIzXS9GbGFncyA0Ci9Bc2NlbnQg NzIzCi9DYXBIZWlnaHQgNzIzCi9EZXNjZW50IDAKL0l0YWxpY0FuZ2xlIDAKL1N0ZW1WIDY1 Ci9NaXNzaW5nV2lkdGggNTAwCi9DaGFyU2V0KC9zcXVhcmU0KS9Gb250RmlsZTMgNDIgMCBS Pj4KZW5kb2JqCjIgMCBvYmoKPDwvUHJvZHVjZXIoQUZQTCBHaG9zdHNjcmlwdCA4LjEzKQov Q3JlYXRpb25EYXRlKEQ6MjAwNzAzMjcxMDM1MTkpCi9Nb2REYXRlKEQ6MjAwNzAzMjcxMDM1 MTkpCi9UaXRsZShNaWNyb3NvZnQgV29yZCAtIEVjcml0X2NvbW1lbnRzX2ZpbmFsX0RULmRv YykKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yKQovQXV0aG9yKFNydl9QREYu Y29udmVydCk+PmVuZG9iagp4cmVmCjAgNDYKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDU4 ODYwIDAwMDAwIG4gCjAwMDAxMDYxNzQgMDAwMDAgbiAKMDAwMDA1ODc4NSAwMDAwMCBuIAow MDAwMDU4NDYzIDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwNjg1MCAwMDAw MCBuIAowMDAwMDU5MjYyIDAwMDAwIG4gCjAwMDAwNTkwOTQgMDAwMDAgbiAKMDAwMDA1ODkw OCAwMDAwMCBuIAowMDAwMTA0NzEwIDAwMDAwIG4gCjAwMDAxMDE5MzUgMDAwMDAgbiAKMDAw MDEwNTE0NiAwMDAwMCBuIAowMDAwMTAyNTE5IDAwMDAwIG4gCjAwMDAxMDUzNTQgMDAwMDAg biAKMDAwMDEwMjg2NCAwMDAwMCBuIAowMDAwMTA1NTY4IDAwMDAwIG4gCjAwMDAxMDMzMDgg MDAwMDAgbiAKMDAwMDEwNTk1MSAwMDAwMCBuIAowMDAwMTAzODA4IDAwMDAwIG4gCjAwMDAw NTg5ODggMDAwMDAgbiAKMDAwMDA1OTAxOCAwMDAwMCBuIAowMDAwMDU4NjIzIDAwMDAwIG4g CjAwMDAwMDY4NzAgMDAwMDAgbiAKMDAwMDA1ODQ0MSAwMDAwMCBuIAowMDAwMDU5NzU5IDAw MDAwIG4gCjAwMDAwNTk1OTAgMDAwMDAgbiAKMDAwMDA1OTQwOSAwMDAwMCBuIAowMDAwMTA0 Mzg5IDAwMDAwIG4gCjAwMDAxMDE0NjAgMDAwMDAgbiAKMDAwMDA1OTQ5MyAwMDAwMCBuIAow MDAwMDU5NTI1IDAwMDAwIG4gCjAwMDAwNTk5MDcgMDAwMDAgbiAKMDAwMDA2MzIzNyAwMDAw MCBuIAowMDAwMDYzMjU4IDAwMDAwIG4gCjAwMDAwNzAyODMgMDAwMDAgbiAKMDAwMDA3MDMw NCAwMDAwMCBuIAowMDAwMDczMTIzIDAwMDAwIG4gCjAwMDAwNzMxNDQgMDAwMDAgbiAKMDAw MDA5Njk2NiAwMDAwMCBuIAowMDAwMDk2OTg4IDAwMDAwIG4gCjAwMDAxMDEwNTIgMDAwMDAg biAKMDAwMDEwMTA3MyAwMDAwMCBuIAowMDAwMTAxNDQwIDAwMDAwIG4gCjAwMDAxMDI3MzIg MDAwMDAgbiAKMDAwMDEwNDI5OSAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDQ2IC9Sb290 IDEgMCBSIC9JbmZvIDIgMCBSCj4+CnN0YXJ0eHJlZgoxMDYzOTcKJSVFT0YK --------------090207020203080603050609 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 --------------090207020203080603050609-- From ecrit-bounces@ietf.org Tue Mar 27 11:08: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 1HWDHH-00072W-EX; Tue, 27 Mar 2007 11:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDHG-0006wd-Ah for ecrit@ietf.org; Tue, 27 Mar 2007 11:08:02 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDHF-0001Fz-N5 for ecrit@ietf.org; Tue, 27 Mar 2007 11:08:02 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by ebru.winwebhosting.com with esmtpa (Exim 4.63) (envelope-from ) id 1HWDEl-0008VL-RE; Tue, 27 Mar 2007 10:05:28 -0500 From: "Brian Rosen" To: "'Hannes Tschofenig'" Subject: RE: [Ecrit] ECRIT Architecture Review by Deutsche Telekom Date: Tue, 27 Mar 2007 11:07:56 -0400 Message-ID: <0e3501c77081$b5edc860$81238182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <4608FA31.2060803@gmx.net> Thread-Index: AcdwX796cLfQw9Y3Sgmzg4Qe9KOTAwAB87tw 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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: ecrit@ietf.org 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've looked at the review from Deutsche Telecom and have some comments. There are three major themes to the response: 1. No one knows if the IMS emergency call support will align with the = IETF ecrit architecture 2. Giving endpoints location has a number of economic, operational, and possibly legal ramifications 3. It doesn't match existing PSAP systems In addition, there are some misconceptions about the ecrit approach. I'd like to examine each of these in turn. We are well aware of the issues surrounding the alignment of the IETF = ecrit emergency calling architecture and the 3GPP IMS architecture. As = members of the work group know, there has been significant effort expended between = IETF and 3GPP to explore this issue. I believe there is intent on both sides = to not allow the architectures to deviate, and indeed 3GPP has gone to = great lengths to make certain that its protocols align with IETF protocols = where they are appropriate. A great many individual participants in both 3GPP = and IETF are committed to making sure the two architectures align. Clearly, getting DT behind the effort to align IMS and ecrit would be beneficial. I would also point out that nearly every IMS system supports a raw IP = packet service, which typically could allow a device with, for example, a PC = Card to have Internet access. With such a card plugged into any device which routes, and has other access connections such as an Ethernet or WiFi, regular hardwired VoIP phones could be attached to the 3GPP wireless = network and would work through nearly any VoIP service. These VoIP telephones = or terminal adapters could reasonably be expected to conform to IETF = protocols, and specifically draft-ietf-ecrit-phonebcp (or at least the expected RFC that it will become). If these phones cannot place emergency calls = because location is not supplied in a manner the phones can use, the access = network may be liable. =20 It would be unreasonable to expect EVERY phone device to conform to IMS specifications, while it would be reasonable to expect every phone = device to conform to IETF standards in this regard. While IMS handsets may = conform to different requirements and be able to place emergency calls on any IMS network, the cost to the carrier who supports both a raw packet service = and an IMS calling service will be significantly larger if there is a = divergence of architecture. The ability of the access carrier to specify the requirements of all VoIP end devices is very limited. Warnings or other mechanisms that disclaim support for emergency calls on such devices are unlikely to be acceptable to regulatory authorities. Further, there is work in several countries to specify next generation = IP based PSAP interfaces. So far, the IETF standards have been looked upon favorably, and indeed, in the United States it now seems quite certain = that "Next Generation 9-1-1" systems will conform to IETF standards. In the = U.S. effort, there is also great interest in assuring that IMS standards and ecrit standards align, and participants in that effort expect that they ultimately will. Turning now to the issues of supplying devices to endpoints, we observe = the quandary that has largely driven this decision: The access network and = the calling network do not have a relationship. Historically, the calling network and the access network have come from the same entity. The = Internet has broken that connection. It is possible, today, to take a device and = use it from nearly any access network in the world that supplies a raw = packet service and get to any calling network. Since the emergency calling = system needs a call, there are only three choices: 1. Force relationships between access networks and calling networks to = allow the access network to supply the calling network with location 2. Force all access networks to support emergency calling for all = possible end devices, thus restricting location to the access network. 3. Force the access network to supply location to its subscriber, and = have the subscriber supply it to the calling network, noting that the = endpoint is the customer of BOTH the access network and the calling network. Forcing relationships between calling and access networks won't scale. There are thousands to tens of thousands of each, and any calling = network may have to process an emergency call originating on any access network. = My usual example is a nomadic caller from Sierra Leone, using a Sierra = Leone VoIP service, connecting a softclient through a WiFi Access Point in a = caf=E9 in Chicago served by a WiFi network with a DSL connection from the local ILEC. Trying to create a relationship between the Sierra Leone VoIP Services Pty and any of Starbucks, T-Mobile Hotspot or AT&T (DSL) is not feasible. You can claim this is a corner case, but it's happening NOW, = and there are millions of subscribers to VoIP services who are independent = of any access network (e.g. Vonage). To make it work, the access network = has to trust the calling network that there is an emergency call, that the putative caller is actually using the access network it is contacting, = etc. Further, it would be necessary to have some kind of identifier that the calling network can determine, which is known to the access network, and = can be used to identify what location is needed. Assuming NATs and VPNs, = such identifiers are very difficult to create, especially without the = endpoint directly participating. We have looked at forcing all access providers, regardless of whether = they offer any kind of calling service, to have to support an emergency = calling service. We have determined that this is unfeasible. There is too much variation in services as seen by endpoints. For example, Next = Generation PSAPs are expected to allow Instant Messaging. While the PSAP interface = can reasonably be restricted to SIP/SIMPLE and/or XMPP/Jabber, clients may = have those or AOL AIM, MSN Messenger, Yahoo and/or Skype interfaces. The = access networks would have to accept a wide range of clients, but interwork to = a small number of PSAP interfaces. Text, video and voice clients would = need to be supported. Any form of authentication would be difficult, and = PSAPs do not like unauthenticated callers (although they may accept such calls anyway). To expect every access network to pay for the cost of = supporting these services seems unlikely at best. DG worries about the cost of supporting the location service; this would be additional costs beyond = that. The latter alternative, requiring access networks to give their own subscribers their location provides the most practical answer, and also meets the very real requirements in the IETF architecture to protect the privacy of location. The endpoint is the ONLY entity that is known to = have a formal, authenticated, contractual relationship with BOTH the access network and the calling network. This is always true one way or the = other; albeit in some networks, the endpoint has a formal relationship with a = home network, that network has an existing relationship with the visited = network, and all of the issues solved by the endpoint getting location from the access network hold. With respect to privacy, if the only entity that gets the location is = the endpoint, then it can decide who else gets it. It could subsequently delegate some service to serve as its location provider (e.g. presence service), but assuming the access network is the subscribers location service of choice is not seen as conducive to allowing users to control = the privacy of their own location. We understand the economic implications = of this architecture. In theory, if the endpoint has its location, it can = give it to anyone else, and the access network may not receive any payment. = It may be permissible, in some environments, to prevent this contractually. It=92s also quite clear that IMS standards will support endpoints = getting their own location and unless DT intends to prohibit this (and thus = restrict the range of applications that can execute on IMS endpoints), that particular issue is moot. With respect to PSAP interfaces, as DT well knows, there are no international standards for TDM interfaces to PSAPs. Every country has their own standards. Networks have had to cope with these issues, and = will continue to have to cope. Next Generation, IP based PSAPs may not have = such variation. There is reason to hope that international standards, and probably IETF standards, will be able to be adopted worldwide for = emergency calling. The benefits to DT and other carriers are obvious. Again, the benefits of alignment between IETF standards and 3GPP standards are = obvious if this occurs. IETF does not believe it is feasible to standardize mechanisms that will work with ALL existing TDM based emergency calling networks. We do observe, however, that it seems feasible to interwork most of the = IETF emergency calling architecture to existing standards on a case by case basis. The LoST based routing mechanisms may not be able to be used in = all cases, but the location, marking, and other components of the ecrit architecture do seem to map fairly well into existing systems. DT may = wish to look at the NENA i2 standard to see how the ecrit location = architecture, in particular, smoothly integrates into existing North American PSAP networks. The nomadic cases will fail, of course, which is a large incentive to move to IP based PSAP interfaces that don't have the restrictions of current networks. Finally, the DT paper has some misconceptions about the IETF ecrit architecture. Most prominent among these is the assumption that there = is some kind of relationship between the SIP REGISTER and any other part of emergency calling. There is not. It would be common for the endpoint = to REGISTER on boot, and it is specified that the endpoint should get = location at boot, and periodically thereafter, but those operations are = independent. The endpoint's interactions between it and the access network and = between it and the calling network are separate until there is an emergency call. Some other specifics: In point 3, DT worries about the liability of providing location when = the device may be corrupted. I do not understand this issue. The access network has never been held liable for any other information it may = supply the device when it is corrupted, why would location be treated = differently? IMS standards permit devices to learn their location. Would this = engender the same concerns? With respect to point 4, there are some who believe that contractual limitations may be effective in preventing location dereferences where = there is not a genuine emergency and no other arrangements have been made. In general, I do agree that when a location is dereferenced as part of an emergency call, the LIS cannot demand any form of credential, or we are = back to the problem of forcing relationships between access networks and = calling networks. In point 6, I do not believe the ecrit architecture would permit callers = to dial the PSAP directly. The caller would use the sos urn marking, and = route with LoST to a URI that was the "front door" of the PSAP. The PSAP = could, theoretically, restrict who can place calls through that front door, but = as a practical matter, as with the example of Sierra Leone VoIP services = PTY, the Chicago PSAP is unlikely to have some kind of authorization in place = for the Sierra Leone call. The notion that calls only come from known-in-advance, small number of domestic carriers is an anachronism of = the PSTN, and no longer holds on the Internet. The law may have to change to reflect reality. That would be up to the German regulators, of course, = but in my discussions with EU regulators, they seem to grasp the issues, = even if they wish it were not so. Point 7 refers to what is called "Location Update". The IETF documents (-phoneBCP) specifically suggests that devices get location when they = boot, periodically thereafter, AND JUST BEFORE PLACING THE EMERGENCY CALL. It = is, of course, best if the route chosen for the call is based on the current location of the caller. However, the IETF ecrit architecture is = designed to work in stressful situations (such as disasters), in which, when the emergency call is placed, some of the infrastructure is busy or not available. In these circumstances, cached location should be used, in preference to no location, or failing the call. Although getting = location at boot and periodically thereafter does place some load on the location infrastructure, it is fairly minimal (devices don't boot often, and the update interval can be controlled by the access network). The load is = much less than most location based services, and does help substantially in disaster scenarios. Note that in most mobile networks, it may be = reasonable to provide a coarse, cell site/sector based location until the emergency call is placed if the location determination infrastructure can't = reasonably support more accurate location determination. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, March 27, 2007 7:04 AM > To: ECRIT > Cc: Liess, Laura > Subject: [Ecrit] ECRIT Architecture Review by Deutsche Telekom >=20 > Hi all, >=20 > the chairs have sent request for reviews to VoIP providers and we have > already received a few responses. Here is another one from the = Deutsche > Telekom. >=20 > We would like to thank Deutsche Telekom for their honest review = comments. >=20 > Ciao > Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 27 11:51: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 1HWDxT-000372-EA; Tue, 27 Mar 2007 11:51:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWDxR-00036n-LP for ecrit@ietf.org; Tue, 27 Mar 2007 11:51:37 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWDxQ-0002bQ-Bw for ecrit@ietf.org; Tue, 27 Mar 2007 11:51:37 -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 l2RFpJvt009713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Mar 2007 11:51:19 -0400 (EDT) In-Reply-To: <0e3501c77081$b5edc860$81238182@cis.neustar.com> References: <0e3501c77081$b5edc860$81238182@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <860D9328-0DB9-472C-B73E-B1A31C5494E3@cs.columbia.edu> Content-Transfer-Encoding: quoted-printable From: Henning Schulzrinne Subject: Re: [Ecrit] ECRIT Architecture Review by Deutsche Telekom Date: Tue, 27 Mar 2007 11:51:51 -0400 To: "Brian Rosen" 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: 2086112c730e13d5955355df27e3074b Cc: ecrit@ietf.org 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 additional remarks inline. > > Forcing relationships between calling and access networks won't scale. > There are thousands to tens of thousands of each, and any calling =20 > network > may have to process an emergency call originating on any access =20 > network. My > usual example is a nomadic caller from Sierra Leone, using a Sierra =20= > Leone > VoIP service, connecting a softclient through a WiFi Access Point =20 > in a caf=E9 > in Chicago served by a WiFi network with a DSL connection from the =20 > local > ILEC. Trying to create a relationship between the Sierra Leone VoIP > Services Pty and any of Starbucks, T-Mobile Hotspot or AT&T (DSL) =20 > is not > feasible. You can claim this is a corner case, but it's happening =20 > NOW, and > there are millions of subscribers to VoIP services who are =20 > independent of > any access network (e.g. Vonage). To make it work, the access =20 > network has It is also quite likely that even if an ILEC provides VoIP service, =20 that it would want this service to work outside of its own network. =20 In other words, DT will, in order to be competitive with other =20 providers, want to be able to have its VoIP users use non-DT access =20 networks, e.g., while traveling, using a public hot spot or visiting =20= neighbors. Thus, even DT has an incentive to make this type of =20 arrangement work. Naturally, this is not a concern if DT is not =20 interested in selling VoIP service at all. > > With respect to privacy, if the only entity that gets the location =20 > is the > endpoint, then it can decide who else gets it. It could subsequently > delegate some service to serve as its location provider (e.g. presence > service), but assuming the access network is the subscribers location > service of choice is not seen as conducive to allowing users to =20 > control the > privacy of their own location. We understand the economic =20 > implications of > this architecture. In theory, if the endpoint has its location, it =20= > can give > it to anyone else, and the access network may not receive any =20 > payment. It > may be permissible, in some environments, to prevent this =20 > contractually. > It=92s also quite clear that IMS standards will support endpoints =20 > getting > their own location and unless DT intends to prohibit this (and thus =20= > restrict > the range of applications that can execute on IMS endpoints), that > particular issue is moot. To emphasize a point you hinted at earlier: the customer is already =20 paying for location information, by subscribing to the DSL or similar =20= service. Since location is fundamentally an access network service, =20 unbundling it makes as much sense as charging separately for getting =20 an IP address or IP packets, since they can also used by other =20 entities to derive value. It should also be noted that there are regulatory models in the US =20 that allow network providers to charge customers for emergency-=20 calling related services (the 9-1-1 tax). The model has its flaws, =20 but it is disingenuous to claim that there is no alternative beyond =20 giving location information "for free" (as untrue as that is) or not =20 giving it out at all. > > We do observe, however, that it seems feasible to interwork most of =20= > the IETF > emergency calling architecture to existing standards on a case by case > basis. The LoST based routing mechanisms may not be able to be =20 > used in all > cases, but the location, marking, and other components of the ecrit > architecture do seem to map fairly well into existing systems. DT =20 > may wish In particular, LoST can easily point to a proxy, which dials the =20 'hidden' PSTN number through a special gateway, so that the number is =20= never visible to callers. > > Some other specifics: > In point 3, DT worries about the liability of providing location =20 > when the > device may be corrupted. I do not understand this issue. The access > network has never been held liable for any other information it may =20= > supply > the device when it is corrupted, why would location be treated =20 > differently? > IMS standards permit devices to learn their location. Would this =20 > engender > the same concerns? Plus, a corrupted device could easily just snoop on audio, likely =20 obtaining far more sensitive data. (Besides, users will enter their =20 home location on e-commerce web pages, so a keyboard sniffer can =20 easily get this data on a machine that has been 0wned.) I'll also =20 note that DT (used to?) use telephone numbers as identifiers for DSL =20 customers; these numbers provide fairly fine-grained location and =20 identity information. (In Germany, area codes are often specific to a =20= small community of no more than a few thousand people, so even =20 unlisted numbers provide lots of location detail that is likely =20 equivalent to the amount of detail needed for PSAP routing.) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 28 11:35: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 1HWaAm-0007Xr-Qd; Wed, 28 Mar 2007 11:34:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWaAl-0007Xl-C2 for ecrit@ietf.org; Wed, 28 Mar 2007 11:34:51 -0400 Received: from mail.skype.net ([195.215.8.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWaAh-0002EN-NJ for ecrit@ietf.org; Wed, 28 Mar 2007 11:34:51 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 544F14DF5A for ; Wed, 28 Mar 2007 17:34:44 +0200 (CEST) Received: from [172.16.57.26] (unknown [80.169.194.194]) by mail.skype.net (Postfix) with ESMTP id E84554DF5F for ; Wed, 28 Mar 2007 17:14:14 +0200 (CEST) User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Wed, 28 Mar 2007 18:14:13 +0300 From: Andres K=?ISO-8859-1?B?/A==?=tt To: Message-ID: Thread-Topic: Ecrit Digest, Vol 26, Issue 33 Thread-Index: AcdxS74m/MZBXd0+EduerAAX8i4icA== 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: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] Re: Ecrit Digest, Vol 26, Issue 33 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 > Forcing relationships between calling and access networks won't scale. > There are thousands to tens of thousands of each, and any calling network > may have to process an emergency call originating on any access network. = My > usual example is a nomadic caller from Sierra Leone, using a Sierra Leone > VoIP service, connecting a softclient through a WiFi Access Point in a ca= f=E9 > in Chicago served by a WiFi network with a DSL connection from the local > ILEC. Trying to create a relationship between the Sierra Leone VoIP > Services Pty and any of Starbucks, T-Mobile Hotspot or AT&T (DSL) is not > feasible. You can claim this is a corner case, but it's happening NOW, an= d > there are millions of subscribers to VoIP services who are independent of > any access network (e.g. Vonage). Most of the Skype network operates on the very same principle of nomadic subscribers, so there are 100+ million of people working exactly the way. This is by no means a corner case. Yours, Andres _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 28 15:28: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 1HWdp9-0004Jw-Dy; Wed, 28 Mar 2007 15:28:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWdp7-0004JR-KP for ecrit@ietf.org; Wed, 28 Mar 2007 15:28:45 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HWdp6-000661-6V for ecrit@ietf.org; Wed, 28 Mar 2007 15:28:45 -0400 Received: (qmail invoked by alias); 28 Mar 2007 19:28:42 -0000 Received: from ip-90-186-88-144.web.vodafone.de (EHLO [90.186.88.144]) [90.186.88.144] by mail.gmx.net (mp034) with SMTP; 28 Mar 2007 21:28:42 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19JAmRqURpJwoaZWQ1C/QpCdMRQWSNjRedZoIB9ua oeZ3vpOph3WLdw Message-ID: <460AC1E7.4050407@gmx.net> Date: Wed, 28 Mar 2007 21:28:39 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] SDO Emergency Services Workshop: Reminder 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 high-level agenda for the workshop is now available and the agenda will be updated frequently: http://www.emergency-services-coordination.info/2007/agenda.html Please do not forget to register for the workshop (by using the EDAS system as described at http://www.emergency-services-coordination.info/2007/, Section "Meeting Organization"). The size of the meeting venue is limited and for safety reasons we have to limit the number of participants. Hence, we may need to enforce a first come first serve policy. Best regards Jenny Hansen Marc Linsner Stephen McCann Christian Militeau Atle Monrad Henning Schulzrinne Hannes Tschofenig Harry Worstell _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit